私が見積で重視する「要件とリスク」
工数見積を考えるとき、私が特に重視するのは、要件とリスクです。要件が曖昧なら、まず対象範囲や仮定を前提条件として整理する。実現方法が不確かなら、その不確かさを減らすための調査・検証を工程に加える。この順序で、必要な作業を工数へ反映したいと考えています。
要件とリスクだけで見積が決まるわけではありません。作業分解、担当者の経験、品質要求、環境や納期などの制約条件も考慮します。ただ、何を作るのか、どう実現するのかが曖昧なまま時間だけを積み上げても、その数字を説明しにくくなります。
以下では、この考え方を一般的な作業分解や体制確認と組み合わせ、社内システムへのCSV出力機能の追加で説明します。案件、体制、工数、実績、文案はすべて架空のモデルケースです。実在の顧客事例や業界標準の数値ではありません。
要件の曖昧さを前提条件として整理する
「CSVを出せる」だけでは、作る範囲も完成も判断できません。最初に対象データ、文字コード、権限、最大件数、エラー時の挙動と受入条件を確認します。モデルケースでは次の前提を置きます。
- 既存の検索結果をCSV化し、列は10項目とする
- 既存の認証・権限を利用し、権限体系の変更は含めない
- 最大1万件、UTF-8で出力し、指定の表計算ソフトで確認する
- 本番移行の手順書作成とリリース作業を含める
- 過去データの修正、別システムへの連携は対象外とする
ここで「まだ分からないから20％追加」とするだけでは、何を作るのかは決まりません。要件の曖昧さには、まず対象範囲・確認事項・仮定・再見積条件を整理するのが私の考え方です。
列名が未確定でも、10項目という範囲と変更条件を合意できれば、仮定に基づく概算は検討できます。一方、どのデータを誰が出力するかが不明なら、取得処理や権限確認の作業を決められません。確定工数を約束する前に、未確定部分を分離して決定を依頼します。
質問は「仕様を決めてください」ではなく、「出力対象はどのデータか」「最大件数は何件か」「誰がいつ判断するか」と具体化します。回答が得られなければ、採用する仮定と、外れた場合の見直し条件を残します。
品質要求と制約も前提です。CSVなら出力の正確性、権限、件数上限での動作を受入条件にし、環境・データの提供日、既存システムの制限、確認者と回答期限を記録します。工数は作業量、工期は完了までの期間です。この例は1人日を8時間としますが、回答待ちがあれば24人時の作業が3営業日で終わるとは限りません。
前提とリスクから必要な作業を洗い出す
前提を置いたら、その条件で完成させるための作業を分けます。機能名に時間を付けるより、成果物と完了条件に分けた方が、何を含むか説明しやすくなります。
IPAの解説にも、成果物の構成要素ごとに工数を見積って積み上げる方法が紹介されています。出典：IPA
| 作業 | 完了条件の例 | 基本工数 |
|---|---|---|
| 仕様確認 | 出力項目と受入条件が合意済み | 4人時 |
| 設計 | データ取得・出力方式をレビュー済み | 6人時 |
| 実装・単体テスト | 正常系・異常系の確認完了 | 12人時 |
| 結合テスト | 権限・件数上限を含む確認完了 | 8人時 |
| 移行準備・リリース | 手順と切戻し方法を確認済み | 4人時 |
| 進行管理・調整 | 日程調整と課題整理を実施 | 4人時 |
| 合計 | 38人時 |
38人時は、前提が成立し、担当者が既存コードを理解している場合の仮定です。「検索処理を流用」「レビュー1回を含む」などの根拠を各行に添えます。品質要求が厳しくなれば、テスト条件や必要な確認も再評価します。
この表を作って終わりにせず、「流用できる根拠はあるか」「システムの制限で別方式が必要にならないか」を確認します。実現上のリスクへの対応に必要な作業が見つかれば、見積項目へ反映します。レビューや修正の計上先を決め、類似案件を使う場合も範囲・品質・体制の違いを比較します。
担当者の経験差を調査・支援へ反映する
必要な作業が同じでも、担当者の経験で調査や支援の量は変わります。「若手だから一律2倍」とせず、技術経験と業務経験を別々に確認する方法が使えます。
| 評価軸 | 確認すること | 工数へ反映する作業例 |
|---|---|---|
| 技術経験 | 使用言語、CSV処理、既存コード、テスト環境を扱えるか | コード調査、試作、技術レビュー |
| 業務経験 | 項目の意味、抽出条件、権限の例外を説明できるか | 業務担当者への確認、受入条件の整理 |
技術に習熟していても、業務を知らなければ対象を取り違え得ます。業務に詳しくても、未経験の技術には検証が必要です。年数や肩書だけでは、どの支援が必要か判断できません。
モデルケースでは、担当者の調査4人時と経験者の支援2人時を加え、合計44人時とします。調査4人時を技術調査と業務確認へどう配分するか確認し、同じ時間を両方へ計上しません。支援者の稼働や兼務も確認します。人数を増やすだけで工期が短縮できるとは限らないため、レビュー待ちや作業順序は日程計画で扱います。
実現上のリスクは調査・検証で具体化する
要件が決まっていても、技術的な難易度、実現方法の不確実性、システム制約は残ります。CSV例なら、既存処理を流用できるか、改行や機種依存文字を指定ソフトで扱えるかが未確認です。これは項目名を決める問題とは異なり、サンプル取得と出力確認で調べられます。
私が調査・検証を工程に加える目的は、不確実性を下げ、必要な作業を具体化することです。 再見積すること自体を目的にはしません。方式を選ぶ材料が不足していて、検証によって対応作業を絞れるなら、先にその作業を見積もる判断になります。
この例では、担当者の調査4人時のうち2人時を先行検証へ充てる案にします。調査範囲と上限を合意し、流用可否、必要な対応、残る不明点を成果物として残します。調査2人時を44人時へ再加算しないことにも注意します。上限で判断できなければ、結果を示して継続・方式変更・保留を相談します。
調査後は、分かった内容で作業を具体化し、当初の前提と比べます。流用可能という前提が成立すれば、その根拠を残せます。別の実装方式が必要と分かるなど、当初の前提が変わった場合は、必要に応じて見積を見直します。 調査したから必ず工数を増減させる、という順序ではありません。
残る文字処理と再テストを0〜8人時と仮定すると、合計44〜52人時が検討範囲です。これは統計的な保証ではありません。必須と判明した作業は基本工数に反映し、残る不確実性へのバッファと分けます。バッファには事象、根拠、使用判断者、残量を記録し、列追加や外部連携は範囲変更として扱います。
顧客には数字が成立する理由を説明する
合計だけでなく、前提条件、必要な作業、残る不確実性を伝えます。モデルケースの架空の説明文案です。
既存の検索結果と権限を利用する前提で、基本作業38人時、調査・支援6人時、合計44人時を見込みます。この内数の2人時で流用可否などを検証し、必要な対応を具体化します。当初の前提が変われば、必要に応じて見積を見直します。残る文字処理への対応は0〜8人時を仮定しています。項目追加と外部連携は対象外です。
削減要求では、工数・金額・納期のどれを変えたいか確認します。単価に左右される金額と作業量は別です。44人時を35人時にしたいなら、9人時を表から消す前に、重複計上や流用できる成果物、対象範囲を検討します。
CSVの件数上限を下げる案でも、実際に減る作業を再評価します。各案には、削る作業、品質や利用上の制約、残るリスクを添えます。条件を変えず短縮根拠もなければ、現見積を維持する理由を説明します。権限確認や切戻し準備を根拠なく削らず、変更内容は版と確認者を記録します。
実績との差を前提と作業項目へ戻す
作業中から見積と同じ区分で、直接作業、支援、追加要件、手戻りを記録します。顧客の確認待ちは工期への影響として別に残します。比較前には次を確認します。
- 前提変更を分離する。 列数、件数上限、環境、担当者などが変わったら、内容と合意日を残します。当初見積を上書きせず、変更分と当初範囲の差を分けます。
- 残業も実績へ含める。 通常時間44人時と残業6人時なら実績は50人時です。納期達成だけでは、44人時の見積が妥当だったと判断できません。残業を前提に次回計画を立てないようにします。
- 記録の正確性を確認する。 入力漏れ、まとめ入力、支援者の時間、別案件との混在を点検します。推定値にはその旨を記し、精度の低い記録から細かい生産性差を断定しません。
架空の実績50人時と44人時の差6人時が、想定していた文字処理4人時とテストデータ準備の見落とし2人時なら、前者はリスク対応、後者は作業分解の改善点です。範囲変更の有無と、支援・残業の計上を確認してから評価します。
次回はデータ準備を作業項目へ加え、文字処理を早めに検証する対策につなげます。一律に割り増すより、どの前提や作業を見落としたかを次の見積へ戻します。
次の見積で、数字を置く前に確認したいこと
私が伝えたいのは、要件と前提を整理し、実現上のリスクを評価したうえで必要な作業を工数へ反映する、という考え方です。調査・検証で不確実性を下げ、作業を具体化し、前提が変わった場合に必要な見直しを行います。作業分解、経験、品質要求、制約も合わせて、数字が成立する理由を説明できる見積にしましょう。
出典
- IPA「エンタプライズ系事業／見積もり手法」（既存稿での確認日：2026年10月11日）。工数積み上げの説明を参照しています。要件とリスクを重視する考え方は運営者の見解であり、数値例・文案は架空のモデルです。IPAの推奨値ではありません。
見積提出前・完了後のチェックリスト
- [ ] 対象範囲・対象外・受入条件を明確にした
- [ ] 未確定の要件を確認事項・仮定・再見積条件へ整理した
- [ ] 品質要求・システム制約・提供日・回答期限を確認した
- [ ] 設計・レビュー・テスト・移行・管理作業を分解した
- [ ] 技術経験と業務経験を確認し、調査・支援工数を確保した
- [ ] 調査・検証の目的・成果物・上限を決めた
- [ ] 調査結果で作業を具体化し、前提変更時の見直しを判断した
- [ ] バッファと必須作業を区別し、二重計上を避けた
- [ ] 顧客へ前提・作業・削減案の制約やリスクを説明できる
- [ ] 前提変更・残業・記録精度を確認し、実績との差を次回へ戻した
