「メンバーに見積もりを依頼しても、いつも『やってみないとわからない』とはぐらかされてしまう」
「バッファを積んだはずなのに、なぜか納期直前でいつも火を吹いてしまう」

現場でプロジェクトを預かるPMやリーダーにとって、見積もりの不確実性は常に頭を悩ませる種です。これらを放置して、根拠のない「エイ!ヤー!」の見積もりを出し続けると、不透明な余裕が積み重なってコスト競争力を失うか、あるいは楽観的な予測が外れて現場がデスマーチに陥るかの二択になってしまいます。

今回は、エンジニアの頭の中にある不確実性を「見える化」し、チーム全員が納得感を持って進められる「三点見積もり」の具体的な導入ステップを解説します。

なぜ「1つだけの見積もり」は外れるのか?

エンジニアに「これ、何日かかる?」と聞くと、たいてい「5日です」といった一つの数字が返ってきます。このように、幅を持たせずに一つの確定値だけで算出する方法を「一点見積もり」と呼びます。

しかし、その数字の裏側には「順調にいけば3日だけど、あのライブラリがバグってたら10日はかかるかも……」という葛藤が隠れています。

結局、エンジニアは防衛本能で多めに答え、PMはそれを削ろうとする。この不毛なやり取りが、見積もりの精度を下げ、現場の不信感を生む原因です。

三点見積もりの基本:3つの数字を再定義する

「1つだけの数字」では表現しきれない現場のリアルを、どうやってスケジュールに反映させるか。その解決策となるのが、不確実性を3つの視点で切り分ける「三点見積もり」です。

具体的には、一つのタスクに対して以下の3つの数字をメンバーに出してもらいます。

  • 楽観値: 全てが完璧に、何のトラブルもなく進んだ場合の最短日数。
  • 悲観値: 想定されるリスク(技術トラブル、仕様の不備、体調不良など)が全て顕在化した場合の最長日数。
  • 最確値: 特別なトラブルも幸運もなく、最も起こる可能性が高い現実的な日数。

なぜこの「3つの数字」を出すのが効果的なのか?

三点見積もりが優れている理由は、「不確実なものは、不確実なまま出していい」と許可を出す点にあります。「最短」と「最悪」の両端を切り出すことで、エンジニアの心理的ハードルが下がり、結果としてよりリアルで精度の高いデータが集まるようになるのです。また、悲観値を共有することは、そのままチーム全体のリスク管理リスト(何に備えるべきか)に直結します。

【実践】現場で機能させる4ステップ

では、具体的にどう導入していくか。実務的な4つのステップで進めます。

Step 1:リスクを分解して「三点」を聞き出す

単に「三点出して」と言うのではなく、ヒアリングの際にこう問いかけてみてください。 「トラブルが全くなかったら、最短でいつ終わる?(楽観値)」 「逆に、何が起きたら工数が2倍に膨らむかな?(悲観値)」 こう聞くことで、エンジニアの頭の中にある「懸念点」が具体的にあぶり出されます。

Step 2:期待値を算出する

3つの数字が出たら、以下の式で「加重平均」を算出します。

E=O+4M+P6E = \frac{O + 4M + P}{6}
  • EE:期待値
  • OO:楽観値
  • MM:最確値
  • PP:悲観値

最確値を4倍して重みをつけることで、現実的なラインを保ちつつ、リスクも加味した「論理的な一本の数字」が導き出されます。

Step 3:標準偏差で「リスクの幅」を可視化する

さらに、(PO)/6(P – O) / 6 で「標準偏差(σ\sigma)」を求めます。この値が大きいタスクほど、「今の段階では予測がつかない危険なタスク」であることが一目でわかります。PMとして注視すべき場所、あるいは先行して調査を入れるべき場所が明確になります。

Step 4:根拠としてステークホルダーに提示する

「なんとなく10日です」と言うのと、「三点見積もりで算出した結果、期待値は8.5日ですが、不確実性が高いため最大12日見ています」と言うのでは、説得力が違います。根拠があるからこそ、無理な短縮要求に対しても論理的に交渉ができるようになります。

事例:難易度の高い「決済連携API」の開発

あるプロジェクトで、外部仕様が不透明な「決済API連携」を実装するケースを考えてみましょう。

  • 楽観値: 3日(ドキュメント通りに疎通が完了する)
  • 最確値: 5日(軽微な不具合修正や、数回のQAを想定)
  • 悲観値: 15日(認証方式の急な仕様変更や、審査落ちが発生する)

従来の「1つだけの見積もり」では、エンジニアは心理的負担から「5日」と答えて遅延するか、多めに「10日」と答えてバッファを埋没させるかのどちらかになりがちです。しかし、三点見積もり(PERT法)を用いると以下のようになります。

期待値: (3+(4×5)+15)÷6=6.33(3 + (4 \times 5) + 15) \div 6 = 6.33 \text{日} 標準偏差: (153)÷6=2(15 – 3) \div 6 = 2 \text{日}

この計算結果は、単に「6日くらいで終わる」という意味ではありません。「約6.3日という期待値をベースにしつつ、±2日程度の変動リスクを常に抱えている」という構造を可視化したものです。

これを受けたPMは、「基本は6.5日程度で引くが、不確実性が高いので2日分の予備バッファを別枠で確保する」「悲観値の原因である審査については、初日に先行して調査を行う」といった、リスクに先回りした「攻めの管理」が可能になります。

三点見積もりはどの規模のプロジェクトで使えるのか?

三点見積もりは、細かいタスク管理用だと思われがちですが、実は規模が大きくなればなるほど、その真価を発揮します。

タスク単位から全体予算まで

  • 小規模(数日): 個人の「不安」を吸い出し、遅延の兆候を早めに察知する。
  • 中規模(数人月): 「決済周りは悲観値が大きく振れているからシニアをアサインしよう」といった戦略的な人員配置に役立つ。
  • 大規模(何十人月〜): 全機能の期待値を足し合わせることで、論理的な全体スケジュールを算出します。

規模が大きいほど精度が上がる「相殺の力」

一点見積もりを積み上げると、全員が「余裕(バッファ)」を隠し持つため、全体スケジュールは不必要に長くなりがちです。

一方で三点見積もりを使うと、「あるタスクはトラブルで遅れたが、別のタスクは順調で早く終わった」という具合に、現場のトラブルと幸運が打ち消し合う(相殺される)様子を計算に含めることができます。

統計学上の正規分布に基づけば、全タスクの期待値の合計に「標準偏差の2倍(2σ2\sigma)」を加味することで、約95%の確率でその期間内に収まるという予測を立てられます。経営層に対し、データに基づいた精度の高いコミットが可能になるのは大規模プロジェクトならではのメリットです。

まとめ:三点見積もりを成功させるチェックリスト

三点見積もりは、単なる計算手法ではありません。メンバーが抱えている「不安」を数字として表に出してもらい、それをチーム全体のリスクとして共有するためのコミュニケーションツールです。

導入にあたって、以下のポイントを意識してみてください。

  • 「悲観値」を出すことを歓迎する: 悪い情報を早く出すことがチームへの貢献であるという文化を作る。
  • 期待値(E)を共通言語にする: 個人の「勘」ではなく、論理的に導き出された期待値をベースに会話する。
  • 「幅」をリスク管理に活かす: 標準偏差(σ\sigma)が大きいタスクは、早めにプロトタイプ検証を行うなどの対策を打つ。
  • 定期的に再見積もりする: プロジェクトが進行し、不確実性が減った段階で数字を更新して精度を高める。

不確実性を隠さず、論理的にコントロールする。これができれば、現場の「ギリギリの戦い」は確実に減っていきます。まずは次の定例会議で、最も不安なタスクから「三点」を聞いてみることから始めてみませんか?

ABOUT ME
hidechi
メーカーに入社し、その後IT部門が分社独立、情報システムエンジニアとして30年以上勤務しています。これまで多くのプロジェクトに携わり、それらの経験から得た知見を覚え書きとして記録することで、厳しい現場で奮闘しているSEの皆さんの一助となれば幸いです。