ウォーターフォール脳に冒された日経SYSTEMS池上俊也記者はAgileとCloudの隆盛に自己存在意義の危機という悪夢を見たのか？（仮題

お断り: 題名はTweetしにくいように意図的に長くしてあります。

日経ITPro: 「規模見積もり」が消えてしまう？
→クラウドやAgileを活用した「作りながら煮詰めていく」開発の普及で「規模見積もり」という習慣がなくなり

• プロジェクトがコントロール不能に陥る
• 準委任契約が広がる可能性がある

ということを日経SYSTEMS池上俊也記者は懸念している。ちなみに過去にもこの人にケチつけたことあり。

そこで本記事では

• 果たしてそんなことはあるのか？ あったとして問題なのか？
• そもそも規模の見積もりにどれほどの価値があるのか？

を中心に突っ込んでみる。

突っ込み(1) 「規模見積もり」がなくなるとプロジェクトはコントロール不能に陥るか?

規模見積もりの結果である成果物スコープは、工数の算出につながり、それが期間やコストの見積もりのインプットとなる。つまり成果物スコープがないと、プロジェクトの計画値のほぼすべてが根拠の乏しいものになってしまう。計画値がブレれば、プロジェクトのコントロールは困難を極める。

これは「ブレない計画を策定することは可能である」という前提で話をしているよね。IT業界の先人・諸先輩あるいはA級戦犯の皆様方はこの「ブレない計画・ブレない見積り」というピンクのドラゴンのようなものを求めて散々苦労し、数々のデスマーチプロジェクトを生み出してきたわけだ。

見積もりは必ずブレる。なぜなら見積もりは確率分布だからだ。その事実を理解せず、「ブレない見積もり・ブレない計画」の存在を前提としてプロジェクトを進めるから制御不能=デスマーチに陥る確率が高くなるわけでしょ。

むしろ「見積もりはブレる」という前提でプロジェクトを組み立てるAgileのほうが、より現実的な対応が可能になるわけで。ただしこれは「Agileがプロジェクトの成功を約束する」というわけではない。計画が現実離れしていれば、プロジェクトの早い段階でAgileチームは降参するしかない。だがそれは引くに引けないプロジェクト最終段階で刹那的に戦力を追加投入せざるを得ないウォーターフォールのデスマーチよりは余程「よく制御されている」と言えるのではないか。

突っ込み(2) 「規模見積もり」がなくなると準委任契約が広がるのか? 

もう一つの問題は、規模見積もりが実質的に消えることで、準委任契約が広がる可能性があることだ。以前はプロジェクトの上流工程のみに準委任契約が適用され、後工程は請負契約となることが多かった。それが最近は“作っては見直す”というアジャイル開発において、全工程を準委任契約で進めるケースが少なくないようだ。
　準委任契約は、ユーザー企業にプロジェクトのリスクが付くことを意味する。極端に言えば、ベンダーがユーザーに対して「作ってみなければいくらかかるか分からない」と突き付けているようなものだ。ベンダーにとっては事前に規模見積もりをしないだけに、何を作るのかが不透明で、準委任契約をせざるを得ない事情がある。かかった分へのコストが保障される契約なので、ベンダー側が生産性向上施策を積極的に取りづらく、業界発展の妨げにもなりかねない。

準委任契約が増える可能性は否定できない。だが、後半の「かかった分へのコストが保障される契約なので、ベンダー側が生産性向上施策を積極的に取りづらく、業界発展の妨げにもなりかねない」というのは誤りだろう。

Agile的に開発していくからには、例えば一ヶ月とか三週間ごとに成果物を納品していくことになる。その出来具合と契約に基づく価格とを比較して「それはないんじゃない？」と発注側が感じたら、受託側に相談すればいいだけのこと。ウォーターフォールで「こんなはずじゃなかった」と文句を言えるのは早くて数ヶ月、ひどければ一年も二年も待った後なのである。「ベンダー側が生産性向上施策を積極的にとりづらい」のはどちらの手法だろうか？

またウォーターフォールの場合、規模見積もりにゲタを履かせて「かかった分のコストを保障させる」という契約がまかり通ってしまってきたわけだ。これこそSI屋やベンダへの信頼を失わせ業界発展の妨げとなってきた感があるのだが日経SYSTEMSはそのあたりをどう考えているのだろう？


突っ込み(3) そもそも規模の見積もりにどれほどの価値があるのか?
引用記事ではFP法などが紹介されていたけどさ。FP法って自分が社会人になった80年代にはすでに存在していたと記憶しているけど、未だに普及しているとは言い難いよね。自分もかじったことがあるけど、結局は測定者の主観と匙加減でどうにでもなる指標でしかないし、「ブレがない」とは言い難い代物である。しかもわかりにくい。SI屋による人月コスト保障の隠れ蓑にFP法見積もりが悪用されたとしても、お客さんが指摘することは無理でしょ。

仮にFP法が「客観的」で「誰がやっても同じ規模の見積もり」を導出できるとして、それが何になるというのだろう？「このプログラムはFP法で3000ポイントの規模となります」という数字が出た所で、それを「いくらで」「どれくらいの期間で」開発できるのかはまた別の話なわけで。まさか「プログラマAは月間300FPの開発ができる」とか測定するわけにもいくまいし。「秋季情報処理試験・FP能力測定試験」なんて嫌だよね？

そして「規模見積もり」にこだわる人達に決定的に欠けているのは「不具合対応にかかる期間と費用」の概念なんだよね。これから書くソースコードにどれくらいバグが含まれていて、テストでどれくらいの確率で捕捉されて、それらがどれくらいの期間で修正されるのか、なんてのを計画段階で決定できるはずがないのだよ。そこを決定論的に予め計画に組み込もうとするからプロジェクトが制御不能に陥りやすくなるのだけど、ウォーターフォール脳には理解出来ないものなのか。