プロジェクトの工数見積もり：IPAの実績データで検証しながら精度を上げる実務手順

工数見積もりの精度は、根拠にする数字で決まる

WBSの作り方でスコープを固め、進捗管理で実績を追い、資源管理で人を割り当てる。この3つの間に挟まっている工程が工数見積もりです。WBSでワークパッケージまで分解できても、それぞれに何人日かかるかを決める段階になると、多くの現場は担当者の感覚に頼ります。

感覚に頼った見積もりが外れる理由は単純です。見積もった本人が、過去に同じ規模・同じ工程で実際にどれだけの工数がかかったかを、数字として持っていないからです。持っているつもりでも、記憶に残るのは順調に進んだ案件が中心で、手戻りやテストで膨らんだ案件の記憶は薄れます。

この記事では、WBSのワークパッケージを積み上げるボトムアップ見積もりを起点に、IPA（情報処理推進機構）が公開している実績データで見積もりを検証し、不確実性の大きい作業には三点見積りで幅を持たせるところまでを、実務で使える順番に並べます。

見積もりの単位をそろえる：人時・人月

工数の単位が担当者ごとにばらばらだと、積み上げても意味のある合計になりません。IPAが「ソフトウェア開発分析データ集」で採用している定義では、1人月は160時間です。日次で管理するなら1人日は8時間が基準になります。

見積もりを依頼するときは、「何日かかりますか」ではなく「何人日かかりますか、1人日は何時間で計算していますか」まで揃えて聞いてください。1人日を6時間で数える人と8時間で数える人が混在すると、合算した瞬間に数字が歪みます。

ボトムアップ見積もり：WBSのワークパッケージを積み上げる

最も精度が出やすいのはボトムアップ見積もりです。WBSの作り方で分解したワークパッケージ（8時間から80時間程度の単位）ごとに、実際に手を動かす担当者が工数を見積もり、それを合算してワークパッケージの親、さらに全体まで積み上げます。

粒度が粗いまま見積もると、担当者は「だいたい2週間」のような曖昧な数字しか出せません。ワークパッケージが十分に細かく分解されていれば、担当者は「設計書のレビュー観点出しに1日、レビュー対応に半日」というように、具体的な作業を思い浮かべながら数字を出せます。ボトムアップ見積もりの精度は、見積もる技術そのものよりも、その手前のWBSの分解がどこまで細かいかに左右されます。

パラメトリック見積もり：業種別の生産性データで検算する

ボトムアップ見積もりだけに頼ると、担当者全員が同じ方向に楽観的な場合、積み上げた合計も楽観的なまま検証されずに通ってしまいます。ここで使うのがパラメトリック見積もりです。過去の実績から「規模あたりの工数」という比率（生産性）を求め、今回の規模にその比率を掛けて工数を逆算し、ボトムアップの合計と突き合わせます。

自社に十分な実績データが蓄積されていない場合、IPAが公開している業種別の生産性データが参照点になります。IPAは2005年から「ソフトウェア開発データ白書」を発行し、名称を「ソフトウェア開発分析データ集」に変えたのち、2022年公開の版を最後に本シリーズの発行を終了しています。現時点で参照できる最新かつ最後の版は「ソフトウェア開発分析データ集2022」で、2004年から蓄積した5,546件のプロジェクトデータのうち直近6年分1,479件をもとに、工数・工期・規模・生産性・信頼性を業種別（金融・保険業、情報通信業、製造業）に分析しています。

自社の見積もりで「1人月あたりどれくらいの規模を作れる想定か」を出し、同業種のIPAデータと大きく乖離していないかを確認してください。乖離が大きいなら、規模の見積もり自体が間違っているか、自社の開発体制が業界平均と大きく違うかのどちらかです。

IPAの実績データで見積もりを工程別に検証する

規模と工数の総量だけでなく、工程ごとの配分でも検証できます。IPAの「ソフトウェア開発分析データ集2022」は、基本設計・詳細設計・製作・結合テスト・総合テスト（ベンダ確認）の5工程（要件定義より前の工程と、総合テスト後の工程は対象外）について、新規開発プロジェクトの工数比率・期間比率の中央値を公開しています。

この数値は中央値なので、足し合わせても100%にはなりません（プロジェクトごとのばらつきを含むため）。使い方は比率をそのまま当てはめることではなく、自分たちの見積もりの配分がこの水準から大きく外れていないかを確認することです。IPAのデータでは、結合テストと総合テストを合わせた工数比率は32.0%です。テスト工程の合計が全体の10%程度しかない見積もりが出てきたら、テストを過小に見積もっている可能性を疑ってください。

期間比率で人員配置の「山型」を検証する

工数比率が「何人日かけるか」を検証するのに対し、期間比率は「どのくらいの期間で終える計画か」を検証します。上表の期間比率をプロジェクト全体の予定期間に当てはめると、工程ごとのおおよその開始・終了時期が出ます。

この期間に工程ごとの必要工数を割ると、期間中に何人を投入する計画になっているかが分かります。多くのプロジェクトでは、序盤に少人数で立ち上がり、製作工程でピークを迎え、テスト工程で徐々に減っていく「山型」の人員配置になります。序盤から人数が一定のまま推移する計画や、テスト工程だけ急に人数が跳ね上がる計画は、フェーズごとの負荷を見誤っている兆候です。資源ヒストグラムを使って、山型になっているかを可視化してください。

見積もりに幅を持たせる：三点見積り

過去の実績と照らし合わせても、初めて扱う技術や外部要因に左右される作業には不確実性が残ります。こうした作業には、1つの数字ではなく幅を持たせます。三点見積り（Three-point estimation）は、楽観値（a）・最頻値（m）・悲観値（b）の3つを見積もり、PERT式で期待値を出す手法です。

期待値 E = (a + 4m + b) / 6

標準偏差 SD = (b − a) / 6

最頻値だけを1点で見積もる場合に比べ、楽観値と悲観値の幅からリスクの大きさが数値として見えるようになります。標準偏差が大きいワークパッケージは、実行フェーズで進捗を注視すべき作業として、あらかじめ目印を付けておけます。

見積もりが崩れる5つのパターン

第1は、ボトムアップの合計を検算せずに提出することです。担当者全員が楽観的な見積もりを出すと、積み上げた合計も楽観的なまま承認されます。パラメトリック見積もりや過去の実績と突き合わせる工程を省くと、この歪みは見積もりの段階では発見できません。

第2は、人日・人時の単位を担当者間で揃えないことです。1人日を6時間で計算する人と8時間で計算する人が混在すると、合算した瞬間に工数が実態と合わなくなります。

第3は、IPAのデータが対象とする工程の範囲を誤解することです。IPAの5工程データは基本設計から総合テスト（ベンダ確認）までを対象にしており、要件定義や、リリース後の運用・保守は含まれません。自社の見積もりにこれらの工程を含めたまま、IPAの比率とそのまま比べると判断を誤ります。

第4は、業種や開発形態が異なるデータをそのまま当てはめることです。IPAのデータが業種別に分かれているのは、業種によって生産性の傾向が異なるためです。自社の業種に近い編を参照し、新規開発と改良開発のどちらのデータかも確認してください。

第5は、見積もった時点の数字を更新しないことです。見積もりはプロジェクト開始前の一時点の推定にすぎません。要件が固まる、設計が進む、テストで想定外の不具合が出るといった節目ごとに、実績工数で見積もりを洗い替えてください。進捗管理で完了基準ベースの実績を追っていれば、この洗い替えに使う実績データはすでに手元にあります。