見積もり精度の話は「経験を積むしかない」で終わりがちですが、経験がなくても精度を上げられる構造的な方法があります。WBSによる作業分解です。手法というより手順に近いので、手順として書きます。
見積もりが外れる3つの原因
「見積もりが外れる＝自分のスキルが低い」と思いがちですが、多くの場合、問題は分解の仕方にあります。
1. 粒度が粗い
「設計: 20時間」という見積もりは、設計の中で何をするかが分解されていません。ワイヤーフレームに何時間、デザインカンプに何時間、レビュー対応に何時間——これを分けずに20時間と置くと、どの作業が時間を食うか見えないまま作業に入り、終わってから「カンプで思ったより時間がかかった」と気づくことになります。
2. 上から分解せず、頭に浮かんだタスクから書き始める
フェーズ→成果物→タスクと上から割っていれば最初に並んだはずの成果物が、作業を始めてから「あ、これも要る」と後出しで増えていきます。要件定義書、テスト仕様書、移行手順——作るのが当たり前すぎて書き出していなかったものほど、見積もりからすり抜けます。増えた分だけ下振れします。
3. 予想できた割り込みを「ないもの」として積む
クライアントレビューは一往復で終わらないし、仕様変更は実装に波及するし、動作確認では環境差で何かしら出ます。“不測の事態”のような顔をしていますが、経験上かなりの確率で起きる、見込めたはずの追加です。ゼロで見積もれば当然あとで膨らみます。
分解の3ステップ
ステップ1: フェーズに分ける
時系列の段階に割ります。Web制作なら「要件定義→設計→実装→テスト→納品」。これで「全体で何時間」ではなく「この段階で何時間」を言えるようになります。
ステップ2: 各フェーズを「成果物」で分ける
「何を作るか」に分解します。設計フェーズなら「ワイヤーフレーム」「デザインカンプ」「API設計書」。成果物単位で考えると「この案件では設計書は不要、WFとデザインだけでいい」という判断もできて、成果物の種類と数がそのまま見積もりの根拠になります。この層を飛ばすと原因2（後出し）が起きます。
ステップ3: 成果物ごとにタスクを洗い出す
1タスク「4時間以内」を目安に、手を動かす単位まで落とします。
- トップページWF作成（3h）
- サービスページWF作成（2h）
- レビュー対応（2h）
ここまで割ってから、各タスクに時間を付けます。
なぜこれで精度が上がるのか
- 比較ができる: 「前回のトップページWFは3時間だった」という過去実績との比較が、タスク粒度で初めて可能になります。プロジェクト合計しか記録がないと参照できません。
- 抜け漏れが見つかる: 「修正対応を入れていない」「CMS入稿を忘れている」に、分解の過程で気づけます。
- 見積もり前に問題に気づける: 分解前は「20時間」だと思っていたものが、割ってみると「35時間相当ある」と判明することがあります。
積み上げたら、上から見直す
タスクを積み上げたあと、フェーズ合計でバランスを確認します。
| フェーズ | 見積もり |
|---|---|
| 要件定義 | 15h |
| 設計 | 38h |
| 実装 | 60h |
| テスト・納品 | 20h |
合計133時間。「設計が全体の29%を占めているが、この案件で妥当か？」という上位からの確認です。過去の類似案件と比率が大きく違えば見直しのサイン。ボトムアップ（積み上げ）とトップダウン（比率確認)の往復で、精度と整合性が両方上がります。
1回で終わらせず、実績と突き合わせる
案件が終わったら見積もりと実績を比較します。「WFの工数を毎回過小評価している」「実装のレビュー対応は常に1.5倍かかる」という自分の傾向が見えてきて、次の分解に反映できます。WBS分解は1回でうまくなる手法ではなく、繰り返すことで精度が上がる仕組みです。
ひとつ注意点として、分解しすぎてタスク管理自体が重くなる失敗を私はやったことがあります。「4時間以内」あたりで止めておくのが無難です。
この記事は自分のブログ記事をQiita向けに再構成したものです。詳しい版はこちら → 見積もり精度を2倍にしたWBS分解の方法