- バックエンド
- PdM
- 急成長中の福利厚生SaaS
- Other occupations (25)
- Development
- Business
- Other
3点見積もりで実現する、遅延しないプロジェクト計画術
Photo by Eric Rothermel on Unsplash
こんにちは!ウォンテッドリーのVisit Client Growth Squadに所属している佐藤です。今回は、スケジュール遅延に対して制約のあるプロジェクトにおいて、3点見積もりを活用して計画通りに進捗した経験と、その手法についてご紹介します。
目次
なぜ高精度な見積もりが必要だったのか
3点見積もりというアプローチ
3点見積もりとパーセント確度によるリスク管理術
ステップ1:見積もりの精度を高めるためのタスク分解
ステップ2:未来を「範囲」で捉え、期待値を算出する
ステップ3:見積もりの「ブレ」をリスクとして計画に組み込む
まとめ
なぜ高精度な見積もりが必要だったのか
見積もり精度の不足は、現代のソフトウェア開発プロジェクトにおける遅延リスクの主要な原因の1つです。機能要件の詳細化、品質基準の遵守、そしてステークホルダーからの納期プレッシャーなど、多様な制約が求められる環境において、この問題はより深刻化します。
本記事では、まさにそうした厳しい制約を抱えたプロジェクトの実例をもとに、具体的な解決策を提示します。私が経験したプロジェクトには、以下のような特徴がありました。
- 期間:5ヶ月
- チーム:9名(BE2名、FE2名、モバイル2名、デザイナー1名、PdM1名、PjM1名)
- 技術スタック:Rails、Node.js、GraphQL Gateway、gRPC通信
- 特徴:マイクロサービスの複数リポジトリでの並行開発
このプロジェクト最大の制約は、スケジュール遅延が許されないという点でした。このような環境では、従来のプロジェクトよりもはるかに高い精度での見積もりが求められます。
この記事の目的は、5ヶ月間の実プロジェクトで3点見積もり手法を適用し、計画段階で遅延リスクを回避した経験から、その方法と効果を紹介することです。同様の制約を抱えるプロジェクトマネージャーやエンジニアが、明日から実践できる手法を示すことを目指します。
3点見積もりというアプローチ
スケジュール遅延が許されない状況で、私たちが直面した課題は明確でした。それは、従来実施してきた単一の工数見積もりでは、精度に限界があるという事実です。
第一に、現場で発生しうる要件変更や技術的な未知の課題への対応が困難であり、固定値での見積もりでは遅延要因を考慮できません。第二に、計画段階で見積もり精度を高められなければ、後からの修正は困難となり、プロジェクト全体のスケジュール管理に悪影響を及ぼします。
これらの課題は、スケジュール遅延や追加コスト、ひいては顧客からの信頼低下といった大きなリスクに直結するため、本プロジェクトの制約条件を満たす上で無視できない問題でした。
この課題を解決するために私たちが導入したのが、単一の数値ではなく「範囲」で見積もる3点見積もりです。3点見積もりでは、楽観値・最頻値・悲観値という3つのシナリオを設定し、期待値を算出することで、作業量の幅や想定されるリスクを数値として計画に組み込めます。
特に、仕様の曖昧さや技術的課題といったリスクを「悲観値」として具体的に数値化し、それらを加味した上で現実的なスケジュールを策定できる点が、制約の厳しい本プロジェクトには最適だと判断しました。
3点見積もりとパーセント確度によるリスク管理術
ここからは、私たちがプロジェクトで実践した3点見積もりの具体的な手順を3つのステップで解説します。
ステップ1:見積もりの精度を高めるためのタスク分解
3点見積もりの精度は、準備段階におけるタスク分解の粒度に大きく左右されます。大きな単位のタスクは、その内部に多くの不確実性や隠れた作業を含んでいるため、そのままでは正確な工数見積もりが困難になります。
3点見積もりを効果的に活用するには、こうした曖昧なタスクを具体的な作業レベルまで分解し、見積もりの対象を明確化することが不可欠です。タスクを詳細に分解すべき理由は、「潜在的な作業の洗い出しと見積もり漏れの防止」と「不確実性要因の特定とリスクの局所化」の2点です。
1つ目は、潜在的な作業の洗い出しと見積もり漏れの防止です。「ユーザー認証機能」といった大きな括りでは、エラーハンドリング、ログ設計、テストデータ準備といった付随的な作業が見落とされがちです。タスクを実装レベルまで分解する過程で、これらの潜在的な作業が明らかになり、見積もり全体の抜け漏れを防ぐことができます。
2つ目は、不確実性要因の特定とリスクの局所化です。 大きなタスクに内包されている様々なリスク要因は、分解することで特定・分離が可能になります。例えば、「決済機能」というタスクを分解し、「外部決済APIの仕様が未確定な部分」という不確実性の高い作業を切り出すことで、その部分に限定してリスクを管理できます。これにより、次のステップで行う見積もり作業の精度が向上します。
私たちのプロジェクトでは、1つのタスクが「0.5日〜2日程度」で完了する粒度を目安に分解を行いました。このステップで作成したリスク要因が明記された詳細なタスクリストが、続くステップ2での具体的な数値見積もりのための土台となります。
ステップ2:未来を「範囲」で捉え、期待値を算出する
「このタスクは3日です」といった従来の単一の見積もりは、タスクに内在する不確実性を無視することで、関係者に誤った認識を与えてしまう危険性があります。この問題を解決するため、3点見積もりでは未来を「点」ではなく「範囲」で捉えます。このステップでは、タスクが持つ不確実性を範囲として表現し、そこから統計的に最も確からしい期待値を算出します。
まず、見積もりの「範囲」を定義するために、3つの値を設定します。
- 楽観値 (O) と 悲観値 (P) - 不確実性の「幅」を示す: この2つの値が、タスクの工数が収まるであろう「範囲」そのものを定義します。楽観値は「すべてが理想的に進んだ場合の最短時間」、悲観値は「ステップ1で特定したリスクが顕在化した場合の最大時間」です。このOとPの差の大きさが、そのままタスクの不確実性の大きさを表します。
- 最頻値 (M) - 最も確からしい「着地点」: 上記で定義した範囲の中で、過去の経験則から最も起こりうると考えられる現実的な作業時間を示します。
次に、それらの値を用いて、タスクごとに統計的な期待値 (E) を算出します。ここでは単純な平均ではなく、最も起こる可能性が高い「最頻値 (M)」に重みを置く加重平均を用いることで、より現実に即した数値を導き出します。今回は、「ソフトウェア見積り 人月の暗黙知を解き明かす」という書籍を参考にPERT法で知られる公式を採用しました。
期待値 (E)=(楽観値 (O)+4×最頻値 (M)+悲観値 (P))/6
この計算により、例えば悲観値が大きいタスクは、そのリスクが期待値に反映され、最頻値よりも少し大きい数値が算出されます。
ステップ3:見積もりの「ブレ」をリスクとして計画に組み込む
3点見積もりの真価は、単に期待値を出すことではありません。それは、個々のタスクが持つ「見積もりのブレ」を数値化し、プロジェクト全体の遅延リスクとして管理可能にする点にあります。
このステップでは、2つの重要な変数を用いてリスクをコントロールします。
- 変数 d:個別のタスクが持つ不確実性の大きさを調整する
- パーセント確度:プロジェクト全体の工数が、ある範囲内に収まる確率を示す
1. 個別タスクの「ブレ」を標準偏差(σ)で測る
まず、個別のタスクの見積もりがどれだけ不確実か、つまり「ブレが大きいか小さいか」を標準偏差(σ) を使って数値化します。標準偏差は、以下の式で計算します。
σ=(P−O)/d
(P - O) は、悲観値と楽観値の差であり、見積もり幅そのものを表します。この差が大きいほど、タスクの不確実性が高いことを意味します。 d は、その不確実性をどう評価するかの「調整値」です。dが大きいほど、見積もりのブレは小さい(楽観的)と見なします。例えば、要件が明確で経験豊富なチームならdを大きく(例:6)設定し、逆に不確実性が高い場合はdを小さく(例:2)設定することで、リスクをより大きく見積もりに反映できます。
今回のプロジェクトでは、遅延が許されない厳しい制約を考慮し、潜在的なリスクを広く見積もるために d=2 を採用しました。
2. プロジェクト全体の「確実性」をパーセント確度で示す
個別のタスクの標準偏差(σ)が算出できたら、それらを基にプロジェクト全体の工数を「どのくらいの確率で達成できるか」というパーセント確度で示すことができます。例えば「90%確度」とは、「このプロジェクトは90%の確率で、算出された工数内に完了する」ということを意味します。これは、ステークホルダーに対して計画の確実性を具体的に提示するための強力な武器となります。
私たちのプロジェクトでは、制約条件を考慮し「90%確度」の工数を採用しました。これにより、「感覚的なバッファ」ではなく、「90%の確率で守れる」というデータに基づいたスケジュールを立てることができました。
まとめ
3点見積もり手法を導入し、各タスクのパーセント確度を明示したことで、プロジェクトのスケジュール管理はより精緻になりました。
実際に、今回のプロジェクトでは、計画値とした「90%確度」の工数に対して、最終的に「約80%確度」の工数で完了し、スケジュールの遅延や大幅な手戻りを発生させることなく、計画通りに進捗できました。80%や90%といった確度ごとの見積もり値をもとに、「どの程度の確度で予定通り完了できるか」を事前にチーム全体で合意できたことが大きな成果です。
この経験から得られた最も重要な学びは、問題が発生してから対処するのではなく、制約を前提として計画段階でリスクを予防することの重要性です。今回のプロジェクトでは、悲観値を重視した見積もりを計画に反映することで、突発的な仕様変更による遅延リスクを事前に回避できました。
厳しい制約が課されたプロジェクトにおいて、3点見積もりとパーセント確度は、単なる精度向上のテクニックではありません。リスクを可視化し、計画に組み込むための実践的な手法です。このアプローチにより、手遅れになりがちなスケジュール遅延を未然に防ぎ、チーム全員が納得感を持ってプロジェクトを進めることが可能になります。