見積もり精度を2倍にしたWBS分解の方法
見積もり精度の話をするとき、「経験を積むしかない」という結論になることが多いです。確かに経験は大切ですが、経験がなくても精度を上げられる「構造的な方法」があります。
それがWBSによる作業分解です。
私が初めてWBSを意識して見積もりを作ったとき、それまで「なんとなく」で出していた工数の根拠が変わりました。見積もりを提示するときの自信が変わり、実績との乖離が明らかに小さくなりました。
この記事では、見積もり精度を高めるWBS分解の具体的な方法を説明します。
見積もりが外れる本当の原因
「見積もりが外れる」と聞くと、「自分の見積もりスキルが低いから」と感じる方も多いと思います。しかし多くの場合、問題はスキルではなく分解の仕方のほうにあります。
いちばん分かりやすいのは、粒度が粗いことです。「設計：20時間」という見積もりは、設計フェーズの中で何をするかが分解されていません。ワイヤーフレームに何時間、デザインカンプに何時間、レビューと修正対応に何時間——これを分けずに「20時間」と置くと、どの作業が時間を食うかが見えないまま作業に入り、終わってから「デザインカンプで思ったより時間がかかった」と気づくことになります。
ただ、原因は粒度だけではありません。もうひとつ多いのが、上から分解せずに、頭に浮かんだタスクから書き始めてしまうことです。フェーズ→成果物→タスクと上から割っていれば最初に並んだはずの成果物が、作業を始めてから「あ、これも要るじゃないか」と後出しで増えていく。要件定義書、テスト仕様書、移行手順——作るのが当たり前すぎて書き出していなかったものほど、見積もりからすり抜けます。後から増えた分だけ、見積もりは下振れします。
そして見落とされがちなのが、本当は予想できた割り込みを「ないもの」として積んでいることです。クライアントのレビューは一往復では終わらないし、仕様変更は実装に波及するし、動作確認では環境差で何かしら出る。これらは“不測の事態”のような顔をしていますが、経験上かなりの確率で起きる、見込めたはずの追加です。最初からゼロで見積もれば、当然あとで膨らみます。
粒度・洗い出し・割り込み——どれも、WBS をきちんと上から分解していれば防げた、あるいは小さくできたものです。裏を返せば、分解の精度がそのまま見積もりの精度になります。
WBS分解の3つのステップ
見積もりに使うWBS分解は、以下の3ステップで行います。
ステップ1：フェーズに分ける
プロジェクトを時系列の段階（フェーズ）に分けます。
Webサイト制作であれば「要件定義→設計→実装→テスト→納品」、システム開発であれば「要件定義→基本設計→詳細設計→実装→テスト→リリース」のような段階です。
フェーズを分けることで、「プロジェクト全体で何時間」ではなく「この段階で何時間」という見積もりができるようになります。
ステップ2：各フェーズを「成果物」で分ける
各フェーズの中で、「何を作るか（成果物・納品物）」に分解します。
たとえば設計フェーズの成果物は「ワイヤーフレーム」「デザインカンプ」「API設計書」のように具体化できます。
成果物という単位で考えると、「このプロジェクトでは設計書は不要で、ワイヤーフレームとデザインだけでいい」という判断もできるようになります。成果物の種類と数が見積もりの根拠になります。
この層を飛ばして思いついたタスクから書き始めると、本来ここで並ぶはずの成果物が後から「これも要る」と出てきて、見積もりが下振れします。上から成果物を先に洗い出すこと自体が、抜け漏れを防ぐ仕掛けになっています。
ステップ3：成果物ごとにタスクを洗い出す
各成果物に対して、実際に手を動かす作業（タスク）をリストアップします。このとき、1タスクは「4時間以内に完了できる粒度」が目安です。
ワイヤーフレームの成果物に対するタスクであれば：
- トップページWF作成（3h）
- サービスページWF作成（2h）
- レビュー対応（2h）
という形に分けられます。このレベルまで分解してから、各タスクに時間を見積もります。
分解が精度を上げる3つの理由
なぜWBS分解で見積もり精度が上がるのかを説明します。
1. 比較ができるようになる
同じ種類のタスクが過去の案件でどのくらいかかったかを比較できます。「前回のトップページWF作成は3時間だったから今回も3時間」という根拠ある見積もりができます。プロジェクト合計しか記録していないと、この比較ができません。
2. 抜け漏れが見つかりやすい
分解すると「修正対応のタスクを入れていなかった」「CMSへの入稿工数を忘れていた」という見落としに気づきやすくなります。「設計：20時間」という括りのままでは、これらの漏れに気づきにくいです。
3. 想定外の発見がある
分解の過程で「このフェーズはやること多いな」という気づきが生まれます。分解前には「20時間」だと思っていたのが、分解してみると「35時間相当ある」と判明することがあります。分解によって「見積もり前から問題に気づける」のは大きなメリットです。
分解後に「フェーズ合計」を確認する
タスクレベルの見積もりを積み上げたあと、フェーズ合計を見て全体のバランスを確認します。
たとえば：
- 要件定義：15時間
- 設計：38時間
- 実装：60時間
- テスト・納品：20時間
合計133時間となったとき、「設計フェーズが全体の29%を占めているが、この案件では妥当か」という上位からの確認ができます。過去の類似案件と比率が大きく違う場合は、見積もりの見直しのサインです。
タスクの積み上げ（ボトムアップ）と全体感の確認（トップダウン）を両方行うことで、見積もりの精度と整合性が高まります。
実績と比較することで分解が洗練される
WBS分解の精度は、実績との比較を繰り返すことで上がっていきます。
プロジェクトが終わったあと、見積もりと実績を比較すると「自分はワイヤーフレームの工数を毎回過小評価している」「実装フェーズのレビュー対応は常に見積もりの1.5倍かかる」という傾向が見えてきます。
この傾向を次の見積もりに反映することで、分解の精度が積み上がっていきます。WBSによる分解は「1回でうまくなる手法」ではなく、「繰り返すことで精度が上がる仕組み」です。
結局、見積もりは「分解の仕方」で決まる
長く書きましたが、見積もり精度を高めるWBS分解でやっていることは、フェーズに分け、各フェーズを成果物で分け、成果物ごとに4時間以内のタスクへ落とす——この縦の分解と、積み上げた合計やフェーズ比率を上から眺める横の確認、その往復だけです。手法というより手順に近い。
ここで効くのは、「見積もりが外れるのはスキル不足ではなく、分解の仕方の問題かもしれない」と疑ってみる視点だと思っています。粒度が粗いのか、上から洗い出せていなくて成果物が後出しになるのか、見込めたはずの割り込みをゼロで積んでいるのか——どれも経験の多寡というより、上から順に割るという手順で詰められる話です。実績と突き合わせるたびに、その勘どころも洗練されていく。もっとも、分解しすぎてタスク管理自体が重くなる失敗も私はやったことがあるので、ここは「4時間以内」あたりで止めておくのが無難です。
関連記事
本記事で取り上げた「WBSによる作業分解と見積もり精度の向上」は、LayerClock でも対応しています。 4階層WBS（プロジェクト・フェーズ・成果物・タスク）で見積もり工数を登録し、実績と自動で比較できます。フェーズ別の消化率をリアルタイムで確認できる仕組みを、無料から試すことができます。