リソース、期日を決めるのではなく、要望・希望・期待を確定する

先日、デブサミの感想？を書きましたが、その中でどうしても気になる箇所があったのでもう少し掘り下げてみます。

ウォーターフォールは、要求ありき。リソースと期日は要求によって変える。
アジャイルは、リソースと期日ありきにして、要求を決める。選択する。絞る。

この話は、日本IBM社の玉川憲氏のセッション「Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス」の中で、三角形を２つ（底が安定した方と底が尖った方）を並べてお話してくださったヒトコマを私なりの解釈で文章化したものです。

スライドをご覧になりたい方は、以下のURLからどうぞ。三角形の絵は19ページにあります。
Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス

安定した三角形はウォーターフォールを説明している図です。
上の方が確定させるもので、その確定したものに対してリソースや期日を見積もる　ということが表されています。

一方、尖った三角形はアジャイルを説明している図です。
こちらは、リソースや期日を確定させて、それに対して要求を見積もる？決めていこう　という図です。

玉川氏は、この話のまとめとして「請負型から支援型にできるかどうか」だとおっしゃいました。

確かに、リソースや期日を確定させるのであれば、今の請負型の契約形態は不向きですからね。
なるほど。確かに面白くまとめられていると思います。
が、"要求"よりも"費用"が先のように聞こえるので、ちょっと無理ではないかと思っています。

ではどうするか。
私は、"要求"よりも"要望"・"希望"・"期待"を確定すればいいのではないかと思っています。

ＩＴ業界で使われている"要求"は、お客様の要望や希望、期待を実現するための具体化した案も含んでしまっているため、あえて "要望"・"希望"・"期待"という文字にしましたが、お客様が真に求めている部分、システム屋さんに頼んだ経緯や、どんな背景があって、どんな結果を求めているかを聞いて、お客様が考えている具体的な案とは、切り離して考える必要があるとおもいます。

つまり、お客様が考える具体的な実現案は、お客様の環境に合わせた実現案でもあるでしょうし、良かれと思って考えてくださっている部分も含んでいると思いますので、そこはまず置いといて、"要望"・"希望"・"期待"を聞いたうえで、費用も加味して、要求を決めていくことが必要なのではないかと思いました。