システム開発の見積もりが難しい5つの理由｜仕様の曖昧さとリスクに対処する方法

「仕様が決まっていないから見積もれない」という話はよくあります。ただ、実際の仕事では、すべての仕様が決まるまで待てるわけではありません。

だから私は、今分かっていることと、分かっていないことを整理して、どの条件なら見積もれるのかを考えます。仕様が曖昧だからといって、必ずしも見積もりを止めるわけではありません。

難しいのは、計算よりも、その前にある判断です。どこまで調べるか、何を前提にするか、どの工程にリスクが残るか。この記事では、見積もりが難しい5つの理由を入り口に、私が工数を考えるときの判断基準を説明します。

システム開発の見積もりが難しい5つの理由

見積もりと実績がずれる原因は、単純な作業の見落としだけではありません。過去案件との条件の違いや、顧客との認識のずれも工数に影響します。

要件や仕様が十分に決まっていない

「既存システムにAPIを追加する」という依頼だけでは、認証方式、取得データ、エラー処理、性能要件が分かりません。条件が変われば、設計・実装・テストの作業も変わります。

とはいえ、未確定の項目が一つあるだけで、すべてを見積もれなくなるとは限りません。何が決まれば工数を出せるのか、条件を置いて進められる部分はどこかを切り分けます。

作業の分解が不十分

実装だけを考えると、仕様確認、設計、レビュー、各種テスト、リリース準備が抜けやすくなります。作業分解（WBS）では、細かな数字を並べる前に、必要な仕事が範囲に入っているかを確かめます。

まだ内容が見えない作業も、存在しないことにはできません。何を調べれば作業を具体化できるかまで考えると、見積もりの抜けを探しやすくなります。

過去の実績をそのまま当てはめている

似たAPIを5人日で作れたという実績があっても、今回も同じとは限りません。既存システムの構造、技術、担当者の習熟度、テスト環境が違えば、必要な作業も変わります。

実績は比較の出発点です。数値だけでなく、その数値が成立した条件を確認し、今回との違いを設計・実装・テストなどの作業へ落とし込みます。

想定外のリスクを適切に扱えていない

既存システムの調査が難航することと、結合時に想定外の不具合が出ることは、どちらも工数に影響します。ただし、備える工程は同じではありません。

一律に余裕を足すだけでは、何に備えた工数なのかが見えにくくなります。逆に、前半で調査する予定があるからといって、後半のリスクまでなくなるとは言えません。

見積もりの前提条件が共有されていない

担当者は「既存認証を流用する」と考え、顧客は「新しい認証方式を実装する」と考えていたら、同じAPI開発でも対象作業が違います。

工数だけを伝えても、このずれは分かりません。どこまで含む数字なのか、何が変われば見直すのかも、見積もりと一緒に伝えます。

仕様が曖昧なとき、私はどう見積もるか

受注金額と時間から、検討量を決める

私が最初に見るのは案件の受注金額で、次に受注までの時間です。見積もりの検討にもコストがかかるので、どの案件にも同じだけ時間をかける方法は取りません。

規模が大きく、時間も確保できる場合は、実現可能性のある3案程度を検討します。比較するのは方式だけではなく、調査に必要な工数と、各案の開発工数までです。そこまで見ないと、どの案が現実的なのかを判断しにくいためです。

小規模案件では、比較検討にかかる費用との釣り合いを考え、有力な一案に絞ることもあります。検討を広げるほどよいというより、受注金額と残された時間に見合う判断材料をそろえる、という考え方です。

前提条件・調査工数・リスク工数を分ける

不明点が残るときは、次の3つを分けて整理します。

• 前提条件：見積もりが成立する条件と対象範囲。何を含み、何を含まないかを示します。
• 調査工数：不明点を解消するために、実施する作業として計上する工数です。
• リスク工数：想定される問題の発生可能性や影響を考え、各工程に反映する工数です。

例えば、既存認証を流用する条件を置くこと、流用できるか調べること、調査が難航する可能性に備えることは、それぞれ役割が違います。

私は、この区別を曖昧にしたまま数字を足さないようにしています。必要な調査を「余裕」の中に隠すと、何をする工数なのか説明できません。前提を書いただけで、リスクが解消したことにもなりません。

確認できることは聞き、残る条件を明示する

顧客へ事前に確認できることは確認します。まだ回答が得られない事項は、確定した事実として扱わず、前提条件として明示します。

認証方式が未確定なら、「既存の認証基盤を利用する」「新しい認証基盤の構築は対象外」「認証方式が変われば再見積もり」といった形です。

概算を出した後も、仕様の認識、対象外の作業、未確定事項をいつ誰が決めるかを確認し、正式見積もりへ進みます。正式見積もりの時点で不確実性が残るなら、残るリスクと条件変更時の扱いも伝えます。

リスクをどう工数に反映するか

未確定率ではなく、影響する工程を見る

私は、要件が100%確定している状態を基準に、未確定部分の割合・内容・影響を考えます。ただし、未確定率をそのままリスク係数へ置き換えることはしません。 同じ割合でも、何が未確定なのかによって必要な対応が違うからです。

まずリスク項目を洗い出し、影響する工程を考えます。そのうえで、案件の規模、難易度、要件確定度、既存システムの状況などから、必要な工数を判断します。

基本設計で解消できる不確実性なら、後続の詳細設計や製造にも同じリスクを一律に上乗せする必要があるとは限りません。一方、結合して初めて分かる不具合など、テスト工程に残るリスクは別に評価します。

見たいのは、不確実性がどこで解消され、どこに残るかです。どの案件にも使える固定的な係数表で判断する方法ではありません。

管理工数は、リスク対応分を含めて10%を固定で確保する

私の実務上の基準では、リスク対応分を含め、管理工数を総工数の10%として固定的に確保しています。 内訳の考え方は、通常のプロジェクト管理業務に7〜8%程度、残りの2〜3%程度をプロジェクトで発生するリスクへの対応余力とするものです。

案件ごとに管理工数の割合を増減させる方法ではありません。また、この10%は私の判断基準であって、業界標準として示している数値ではありません。

ただし、管理工数の中に対応余力があるからといって、各工程のリスク工数が不要になるわけではありません。工程別に見込んだリスク工数と管理工数内の余力を合わせて、プロジェクト全体として十分かを判断します。

その際は、同じリスクへの備えを両方に重ねていないかも確認します。割合を確保したことだけで安心せず、何に対応するための工数なのかを見る、という考え方です。

具体例で考える

ここからは、前提条件を置く例と、工程別にリスクを反映する例を見ていきます。API開発5人日と工程別リスク48人日は、別案件を想定した仮想ケースです。合算はしません。

API開発5人日：条件を置いて概算する

「既存システムの商品情報を取得するAPIを1本追加してほしい」という依頼で、認証方式やエラー処理の詳細が未確定とします。概算では、次の条件を置きます。

• 既存のデータベースを利用する
• 商品情報の取得対象は既存テーブルの範囲内とする
• 認証は既存機能を流用する
• 新規のデータベース設計は行わない
• 外部システムとの新規連携は対象外とする

この条件での工数を、仕様確認・設計1人日、実装2人日、単体テスト1人日、結合テスト1人日で、合計5人日とします。実装は2人日で、合計の40%です。 説明のための架空の数値であり、一般的なAPI開発の標準工数ではありません。

この概算には、認証方式の新規開発や未定義の追加機能は含めていません。顧客への確認で既存認証を使えると分かれば、その条件で検討を進められます。流用できなければ、追加の設計・実装・テストを見積もります。外部連携が追加される場合も、対象範囲を確認して見直します。

正式見積もりへ進む際は、レビューやリリースなど、案件として必要な作業が範囲に入っているかも確認します。5人日という数字を先に固定するのではなく、確認結果に合わせて対象作業を見直す流れです。

工程別リスク48人日：係数を適用する工程を選ぶ

次は別の案件で、基本工数が43人日と見積もられているケースです。以下の1.3や1.2は推奨係数ではありません。どの工程に適用したか、その理由を説明するための仮想例です。

工程	基本工数	係数	見積工数
基本設計	10人日	1.3	13人日
詳細設計	8人日	1.0	8人日
製造	15人日	1.0	15人日
テスト	10人日	1.2	12人日
合計	43人日	—	48人日

基本設計は、既存システムの調査が難航するリスクを見込み、10人日に1.3を適用して13人日としています。必要な調査そのものは作業として計上し、その難航に備える分とは区別する考え方です。ここでは基本工数の詳細な内訳までは設定していません。

詳細設計と製造は、基本設計で不確実性を解消できる想定なので1.0です。ただし、基本設計を終えても不明点が残ったなら、この想定を見直します。前工程に係数をかけたというだけで、後続工程の評価を終えるわけではありません。

テストは、結合時の想定外の問題を中心に、後半工程に残るリスクも考慮し、10人日に1.2を適用して12人日としています。

この例で私が説明したいのは、全工程を同じ率で増やすのではなく、リスクが残る場所を選んで反映する判断です。43人日から48人日への変化は、表の4工程だけを計算した結果です。どちらの仮想例にも、管理工数10%の追加計算はしていません。

顧客に説明できる見積もりにする

必要工数の根拠を、相手の反応で変えない

私は、顧客が納得しにくいからといって、必要工数の算定基準を変えません。妥当な工数を確保したうえで、リスクの配分や説明方法を調整します。

なぜその作業が必要なのか、どの条件で成立する数字なのかを伝えることと、数字を恣意的に減らすことは別です。前提や作業が変わっていないのに工数だけ減らしても、必要な仕事は減らないからです。

説明できる見積もりであっても、予測が必ず当たるわけではありません。実績との差を振り返ることと、今ある情報から判断した根拠を示すことの両方が必要です。

見積もりの変更と、契約の変更を区別する

開発中に情報が増え、前提や必要な作業が変わったときは、何が変わり、工数にどう影響するかを整理して再見積もりします。

ただし、見積もりを直しただけで、契約上の工数や納期を一方的に変更できるわけではありません。変更の扱いは、顧客との合意や契約条件に沿って調整します。

まとめ

見積もりが難しい理由は、仕様の未確定、作業分解の不足、過去実績の当てはめ、リスクの扱い、前提条件の共有不足にあります。

私が見積もりで目指しているのは、不明点がゼロになるまで待つことではなく、今ある情報で判断できる範囲を明らかにすることです。受注金額と時間に見合う検討を行い、必要な作業と残るリスクを整理して、数字の成立条件を説明します。

見積もりを見直すときも、合計だけを見るのではなく、「この数字は何を前提にしているか」「不確実性はどの工程に残っているか」から確かめてみてください。数字を計算する前の判断が見えると、顧客とも、開発を進めるチームとも話を合わせやすくなります。