見積もりの「一式」以外で見落とされる曖昧さ

「見積もりはもらったし、要件定義もちゃんとやった。なのに、なぜ後から追加費用の話が出てくるのか」——現場責任者からよく聞く違和感です。要件定義書は確かに存在する。ページ数もある。でも、いざ開発が進むと「そこまで細かくは決めていなかった」という箇所が次々出てくる。

実はこれ、要件定義を「やったかどうか」の話ではなく、要件定義の「粒度」がどこまで揃っていたかという話に整理すると腑に落ちやすくなります。同じ「要件定義済み」でも、機能の名前だけ決まっている状態と、入力項目・分岐条件・エラー時の挙動まで決まっている状態では、実質的な確定度がまるで違います。

この記事では、見積もりの前提となる「粒度のズレ」がなぜ二重コストにつながるのか、その構造と、契約前に確認しておきたい観点を整理します。

「決まっている」の解像度が違うという問題

発注側が「要件は伝えた」と思っている内容と、開発側が見積もりの根拠にした内容は、実は同じ言葉でも解像度が違うことがあります。たとえば「顧客管理機能が欲しい」という要望は、発注側にとっては十分具体的な依頼に見えても、開発側からすると「顧客情報の項目は何か」「検索条件はどこまで対応するか」「権限によって表示を分けるか」といった、決めるべきことがまだ何十個も残っている状態です。

この解像度の差は、要件定義書のページ数や見た目の完成度では判断できません。ページ数が多くても、機能の羅列にとどまっていて中身の分岐条件まで書き込まれていない要件定義書もあります。見積もりを受け取る側が「量」で安心してしまうと、実際に開発が進んだ段階で「そこは書いてなかったので追加です」という展開になりやすい構造です。ここは、次に要件定義書を受け取ったときにそのまま使える確認視点なので、メモしておくといいところです。

粒度のズレが二重コストになる仕組み

粒度が揃っていない要件定義書をもとに見積もりが作られると、開発側は「書かれている範囲」を前提に金額を出します。書かれていない部分は、開発側にとっては「まだ決まっていないこと」であり、見積もりの対象外です。ところが発注側は「要件定義は終わったのだから、細かい部分も含まれているはず」と考えていることが少なくありません。

この前提のズレが、開発が進んだ段階で表面化します。書かれていなかった分岐や例外処理を後から詰めるとなると、それは「追加の設計作業」として扱われ、追加費用や工期の見直しにつながります。すでに動いている部分に手を入れる修正が発生すれば、その分の作業も二重に発生することになります。

要件定義の粒度不足が引き起こす手戻りの構造については、要件定義の手戻りが二重コストになる仕組みでも詳しく整理していますので、あわせて確認しておくと理解が深まります。

この「どこまで決めておくべきか」という論点は、実は情報処理推進機構（IPA）が公開している非機能要求グレードの考え方とも重なります。非機能要求グレードは、性能や可用性、運用条件といった「見落とされがちな要件」を発注者と開発者が共通の項目で確認できるよう整理したもので、要件定義の粒度を揃えるための一次資料として参照されることがあります。機能面だけでなく、こうした非機能面まで含めて「決まっている範囲」を意識しておくと、粒度のズレそのものに気づきやすくなります。

契約前に確認しておきたい「粒度」の見方

要件定義書の完成度を確認するときは、ページ数や見た目ではなく、次のような観点で見ておくと、粒度のズレを事前に把握しやすくなります。

• 分岐・例外の記載があるか：正常な操作の流れだけでなく、入力ミスや条件によって挙動が変わる部分まで書かれているか
• 画面単位ではなく項目単位で書かれているか：「画面がある」だけでなく、その画面の入力項目や表示条件まで具体化されているか
• 見積もりの前提条件が明記されているか：見積書に「本見積もりはこの要件定義書の範囲を前提とする」といった記載があるか

見積もりの範囲がどこまでかを確認する作業は、金額の大小よりも先に確認すべき手続きです。発注側が仕様を具体化する努力そのものは、追加コストを防ぐ有効な対策の一つと考えられます。発注する側が意識しておきたいのはここです。

まとめ

• 要件定義書は「あるかないか」ではなく、分岐や例外まで含めた「粒度」で見る必要がある
• 発注側と開発側で「決まっている」の解像度が違うと、後から追加費用として表面化しやすい
• 契約前に、見積もりの前提範囲が要件定義書のどこまでを指しているかを確認しておくと、後のトラブルを減らしやすい