お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

見積りを狂わすメカニズム − 「なぜ見積りは不正確なのか」(第2回)

2009/03/28 11:30
  • このエントリーをはてなブックマークに追加

プロフィール

山田ひさのり

私がプロジェクトマネジメントを実践したり学習したりしていく中で、ためになった考え方やノウハウを紹介していこうと始めましたが、その後ケータイ/ソーシャルビジネスを中心の情報発信に変化しました。暫くの間更新が滞っていましたが、私の転職をきっかけにグロースハック/ハッカーの情報を発信するグログとして投稿を再開しました。
ブログ管理

最近のエントリー

 

前回は「ソフトウェア開発の見積りがなぜ不正確なのか?」について問題提起し、その問題の回答を与えてくれる(可能性のある)、『ソフトウェア見積り―人月の暗黙知を解き明かす』という書籍を紹介しました。この本はソフトウェア見積りの本質に迫った良書であるため、今回から数回に渡って同書籍の内容を説明したいと思います。今回はその初回になりますが初回から同書籍の主張の中で最も重要と思われるものを紹介します。(少し長いですがお付き合い頂ければと思います)

書籍の主張の解釈に(ある程度)私の主観が入り込むことについてはあらかじめご了承下さい。

同書籍では、「見積りを不正確にする原因は多数あれど、不確実にするメカニズムは2つしかない」と主張しています。それは「不確実性のコーン」と「管理されていない開発プロセス」です。

どちらが良い見積り?

例えばあなたが営業さんであると仮定して、あるプロマネに、「このプロジェクトを見積もってくれ」と頼んだとします。数日後そのプロマネが以下の2つの回答のどちらかを持ってきました、あなたならどちらの回答が嬉しいでしょうか?

  • A. 800万です。
  • B. 500万〜1200万です。 

「Aの方が金額をジャストで出しているのでステークホルダに提示しやすい」、「いや、Bの方がより慎重な姿勢が見えて良い」など意見が別れるところでしょう。しかしこの2つを比較して確実に言えることがあります。それは「Bの回答がより正直である」ということです。

見積りが難しい理由の1つに「何を作るか決まっていないのに見積りをしなければならない」というものがあります。ステークホルダに見積りを求められる時点では要件の詳細が決まっていないことがほとんどです。しかしステークホルダからすれば、「どの程度の投資が必要なのか?」がわからないのに要件を詳細化するコスト掛ける訳にはいきません。つまり要件が詰められていない状況下で見積りを求められるのは、ビジネスの世界においてはごく自然なこと言えます。

見積りを正確にするための前提条件とは?

ここで改めてAとBの見積りを比較してみましょう。Aは1点見積りと呼ばれジャストな金額を示してます。ステークホルダがこの見積りからイメージするのは、「800万程度でできるのか・・」になるでしょう。Bは範囲見積りと呼ばれ最低金額と最高金額を示しています。ステークホルダがこの見積りからイメージするのは、「こんなに幅があるんじゃ正確な予算が組めないな・・」でしょうか。つまりステークホルダはBの見積りが不正確であることを自然と理解してくれることになります。先に私は、「Bの回答がより正直である」と言いましたがこれがその理由です。事実、この時点では作成者は見積り作成のために必要な情報を与えられていないケースがほとんどなのです。

しかしステークホルダが欲しいのは(予算を検討する上での)もっと正確な見積りでありこのような幅が大きい見積りをすんなりと受け入れるはずもありません。ではステークホルダにAの見積りを提示すると同時に、「せめて実現したい機能のUIイメージがあればこの見積りの幅を半分程度に縮めることができます」と言った場合、ステークホルダはどういう反応を示すでしょうか? 実はこれは重要な事実で、「要件が詳細化できれば見積り幅を縮めることができる」ということを示唆しています。そしてこの理屈は以下の「不確実性のコーン」という考え方で説明できます。

メカニズム1 「不確実性のコーン」

上記の図が「不確実性のコーン」と呼ばれるものです。

道路工事の際に進入禁止エリアを示すために使われる赤い円錐を「コーン」と呼びますが、それを横に倒した形に似ているのでそう呼ぶようです。

X軸はプロジェクトの進捗(≒時間の経過)で、Y軸は見積りのぶれ幅です。1.0X近づくほど見積りと実績のぶれ幅が少くなります。この図の示す事実は、「プロジェクトの完了に近い時点で見積りを行うと実績値(1.0X)との差は少なくなる」ということです。上記の図では製品の定義段階では見積りに -0.5X〜2.0X ものぶれ幅がありますが、プログラム設計段階では -0.20X〜1.3X に留まっています。これはまさしく「要件が詳細化できれば見積り幅を縮めることができる」ことを示しています。

通常このコーンは自社の複数プロジェクトの予算と実績値を元に作成します(業界平均で作成する場合もあります)。この図ではぶれ幅が最高でも-0.25X〜4.0Xとなっていますが、失敗プロジェクトが多い企業でサンプリングした場合、-0.01〜200Xとなることもあるようです。

これらは考えてみれば至極当然な事実なのですが、我々がステークホルダに対して見積りを提出する時、幅を持たして(あるいは幅を認識した上で上限値を提出など)していたでしょうか? 少なくともこの問いに対する私の答えは「NO」です。そしてこれが見積りを不正確にするメカニズムの1つ目なのです。この事実を認識した上で我々が見積りを作成する際に注意しなくてはならないのは以下の3点になります。

  • 自分がプロジェクトのどのフェーズで見積りをしているのか
  • そのフェーズの場合どの程度のぶれ幅があって然るべきか
  • 「ぶれ幅があって当然」という事実をステークホルダが把握しているか

同書籍では「ぶれ幅は自社の過去プロジェクトから算出するのが最も良い」としています。

メカニズム2 「管理されていない開発プロセス」

見積りを不正確にするメカニズムの2つ目は「管理されていない開発プロセス」です。先の記事に対して、「見積りを増加させる要因の多くは要件変更の多発だ」とのコメントを頂きました。これは全くそのとおりだと思います。それではこの意見と上述の不確実性のコーンをリンクさせて考えてみましょう。

先に私は、 「要件が詳細化できれば見積り幅を縮めることができる」と言いましたがそれは「開発プロセスが管理されている」という前提があって初めて成り立ちます。上記の図ではコーンの先端が時間の経過と共に狭くなっていますが、それはプロジェクトが管理されているからに他なりません。例えばプロジェクトの終盤になり実装物が明確に見えている段階で正確な見積りをすることは簡単でしょう。しかしその見積りを作った後に要件変更が多発したらどうでしょうか? あるいは他のプロジェクトに開発メンバを持っていかれた場合はどうでしょうか? この場合明らかにコーンの先端は横長の楕円になるでしょう。ここで我々が学ぶべきは「コーンはひとりでには狭くならない」ということです。そしてここから考えをもう一歩進めてみると、見積りの正確性を向上させるには見積り技法のみを向上させてもダメで、「管理された開発プロセス下で開発を行う」という発想に行き着くことができます。

結局見積りを不正確にする理由は?

上述の主張をまとめると、見積りを不正確にする理由は以下に集約されます。

  1. 不確実性のコーンを明確に認識していない状況下で1点見積りをしているから
  2. 管理された開発プロセスが無いためコーンの幅を狭めることができないから

ただしこれらは見積りを不正確にする「メカニズム」であって「原因」ではありません。原因とはもう少し細かいものであり、例えば以下などを挙げることができます。

  • 経験則で見積りを作成しているから
  • 開発作業以外のアクティビティが見積りから漏れているから
  • 要件変更を管理できていないから

今回紹介している書籍の素晴らしいところは、見積りを不正確にしている原因を突き止める前にまずそのメカニズムについて説明しているということだと思います。そしてその上で個々の原因を分析し改善案を提示しているのです。私もこの2つのメカニズムを理解した時は本当に、「見えなかったものが見えた」という感覚を覚えました。本当にお勧めな良書なので皆さんも是非読んでみて下さい。

次回は上述の1,2のメカニズムを踏まえた上で、見積りを不正確にする原因について更に詳しく説明したいと思います。

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー