工数見積もりは、必要な作業を分け、それぞれの作業量を積み上げて考えます。「構築一式で何人日」と合計だけを出す前に、何を完成させる作業か、何を根拠に算出したか、どの条件で増えるかを行ごとに残しましょう。
この記事では、社内IT担当者や委託先の見積もりを確認する担当者向けに、作業分解から不確実性の記載までを説明します。以下の表は編集上の記入案で、数値は計算方法を示す架空の例です。実案件の標準時間や価格相場ではありません。
工数と期間を分け、先に単位をそろえる
工数は、人が作業に使う時間の合計です。本記事では1人が1時間作業する量を1人時とします。2人がそれぞれ3時間参加するレビューは、合計6人時です。
人日へ換算するなら、1人日を何時間として扱うかを明記します。仮に1人日を8人時と置けば、26人時は3.25人日です。この8時間は計算上の仮定であり、すべての案件に共通する値ではありません。
一方、作業開始から完了までの期間は、工数だけでは決まりません。例えば、設定後に検証する作業なら順序があり、担当者を増やしても同時には進められません。承認待ちの間に誰も作業しない場合、その待ち時間は作業工数と分けて、日程上の制約として残します。問い合わせや再説明が必要なら、その対応時間は別の作業として見積もります。
成果物を決めてから、完了までの作業を分解する
IPAは、成果物の構成要素を洗い出し、それぞれに必要な工数を見積もって積み上げる方法を「ボトムアップ見積り（工数積上げ）」として説明しています。IPA：見積もり手法
実務の記入案としては、まず「何を渡すか」を決め、次に「渡せる状態にするために何をするか」を分けます。例えば監視設定を追加するなら、設定の投入だけでなく、対象の確認、設計、通知の検証、手順の更新までを検討します。
| 成果物 | 分解する作業の例 | 完了条件の例 |
|---|---|---|
| 監視対象一覧 | 対象・現行設定の確認 | 対象と対象外を担当者が確認 |
| 監視設定の設計書 | 閾値と通知先の設計・レビュー | 設定値と通知先が決まっている |
| 追加した設定 | 設定作成・適用 | 設計した設定を反映済み |
| 検証記録 | 通知・復旧時の動作確認 | 定めた試験結果を記録済み |
| 運用手順 | 手順更新・引き継ぎ | 変更箇所と担当者を共有済み |
分解の目安は、担当者が作業内容と完了条件を説明でき、工数の根拠を付けられる粒度です。「検証一式」の根拠が出せないなら、試験項目や環境ごとに分けます。反対に、見積もり判断が変わらない細かい操作まで行を増やす必要はありません。
レビューや調整を各作業へ含めるか、独立した行にするかも統一してください。各行へ含めたうえで末尾に同じレビュー工数を加えると、二重計上になります。
作業ごとに根拠を付けて積み上げる
根拠欄には、数量と単位当たりの時間、比較に使った実績、担当者が確認した作業内容などを残します。IPAは類似プロジェクトの実績を基礎にする類推法も挙げています。実績を使う場合は、対象数、環境、試験範囲などの違いも記録する運用を勧めます。IPA：類推法と工数積上げ
次は、検証環境とアクセス権が準備済みで、監視対象と通知先が変わらないと仮定した計算例です。
| 作業 | 仮の算出根拠 | 工数 |
|---|---|---|
| 対象・現行設定の確認 | 担当者1人×4時間 | 4人時 |
| 設計・レビュー | 設計4人時＋レビュー2人時（参加者合計） | 6人時 |
| 設定作成・適用 | 4対象×2人時 | 8人時 |
| 検証 | 準備1人時＋4対象×1人時 | 5人時 |
| 手順更新・引き継ぎ | 更新2人時＋引き継ぎ1人時（参加者合計） | 3人時 |
| 合計 | 上記の前提が成立する場合 | 26人時 |
計算が合っていることと、入力した時間が妥当なことは別です。この表の「1対象2人時」などは架空の値です。実際の見積もりでは、対象の難しさや担当者の経験、類似作業の記録に照らして置き換えます。根拠が足りない行は、確認済みの値として提出しないようにします。
不確実性は「条件付き追加」と「未算定」に分ける
IPAは、見積もり時期やプロジェクトの特性によってリスクや適用条件が異なると説明しています。同資料は2004〜2008年度の事業アーカイブであり、現在の標準工数を示す資料ではありません。IPA：見積もり時期とリスク
不明点への対応は、一律に余裕を上乗せする前に、どの作業がどの条件で増えるかを整理することから始めます。以下は、そのための判断表です。
| 分かったこと・不明なこと | 見積表での表し方 | 次に確認すること |
|---|---|---|
| 作業内容と対象数が分かる | 基本の積上げに含める | 算出根拠と完了条件 |
| 条件次第で追加作業が必要 | 条件と追加工数を別行にする | 条件が成立するか、誰が判断するか |
| 方法が未定で追加量を算出できない | 未算定と記載し、合計に含まれないと明示 | 調査・試行に必要な範囲 |
| 担当者の回答を待っている | 回答期限と日程への影響を記載 | 回答者と着手条件 |
| 作業量は分かるが担当者を確保できない | 工数と稼働可能日を分ける | 担当者・割当時間・作業順序 |
例えば、先ほどの26人時に対し、通知先を新設する場合だけ追加6人時かかると仮定します。このときは「既存通知先を使用：26人時／新設：32人時」と条件別に示せます。「26〜32人時」と幅だけを書くよりも、何を確認すれば値が決まるかが分かります。
ただし、この幅は二つの条件を比較したもので、統計的な信頼区間や最大工数の保証ではありません。別に認証方式が未確認なら、その調査・改修は未算定として残し、32人時に収まるとは説明しません。
予備の工数を設ける場合も、対象となるリスクと使用判断を添えます。条件付き追加へ計上済みの作業を、予備へ重ねて含めていないか確認してください。前提の整理方法は、システム見積もりの前提条件でも説明しています。
提出時は合計・未算定・見直し条件を一緒に渡す
見積もりを渡すときは、少なくとも次を一組にします。
- 作業別の工数、単位、算出根拠、含めたレビュー・調整の範囲
- 合計が成立する前提と、条件付き追加の内訳
- 未算定の作業、その確認担当者と期限
- 日程を決める作業順序、待ち時間、担当者の稼働条件
- 対象数や仕様が変わったときに見直す行
作業後は、見積もりと同じ区分で実績を残し、差が出た理由を記録する運用を勧めます。米国GAOの費用見積もりガイドも、作業分解構成（WBS）、前提、リスク分析に加え、実績を使った見積もりの更新を手順に含めています。費用見積もりの枠組みとして参考になる資料です。GAO：Cost Estimating and Assessment Guide
例えば「設定が想定より複雑だった」のか、「途中で対象が増えた」のかを区別すれば、次回の算出根拠と対象範囲のどちらを直すべきかを検討できます。保守を含む場合は、システム保守費用の見積もり方を参考に、定常作業と別途の変更作業を分けてください。