要件定義の「粒度」が二重コストを生む理由

「要件定義書はちゃんと作ったのに、なぜ追加費用の話が出てくるのか」——開発会社からの見積もり修正連絡を受けて、そう感じたことのある現場責任者は少なくないはずです。資料自体は分厚く、ページ数もそれなりにある。それなのに、いざ実装フェーズに入ると「ここは書かれていないので別途お見積もりです」と言われてしまう。

実はこの違和感、要件定義が「あるかないか」の問題ではなく、「どこまで細かく書けているか」という粒度の問題であることが多いです。分厚い資料でも、書かれている内容が「入力フォームを作る」レベルの粗さで止まっていれば、入力チェックの条件やエラー時の挙動といった細部は結局現場合わせになり、後から「それは想定外でした」という食い違いが生まれます。この記事では、その粒度のズレがなぜ二重コストにつながるのか、そして契約前にどう備えられるのかを整理します。

要件定義の「粒度」とは何か

要件定義には大きく分けて2つの階層があります。ひとつは「何を作るか」という機能レベルの合意（例：会員登録機能を作る）。もうひとつは「どう動くべきか」という仕様レベルの合意（例：メールアドレスが重複した場合はエラーメッセージを表示し、登録を止める）です。

多くの要件定義書は前者、つまり機能レベルまでは丁寧に書かれています。しかし後者の仕様レベルは、双方が「実装しながら決めればいい」と暗黙のうちに先送りしてしまうケースがあります。これは怠慢というより、要件定義の初期段階では細部まで見通せないという事情もあり、ある程度は自然な流れでもあります。

問題は、この粒度の粗さが契約書や見積もりの前提としてそのまま固定されてしまうことです。発注側は「要件定義書に書いてあることは全部込み」と思い込み、開発側は「書いてない仕様は都度相談・追加見積もり」という前提で動く。この認識のズレが、実装フェーズに入って初めて表面化します。

なぜ二重コストにつながるのか

粒度の粗い要件定義のまま契約が進むと、実装中に「仕様の確認」という名目のやり取りが増えます。ここまでは単なる手間ですが、問題はその先です。確認の結果、当初の想定と異なる仕様が必要だと分かった場合、すでに作り始めた部分を作り直す「手戻り」が発生します。

手戻りが発生すると、最初の実装コストに加えて、修正のための追加コストがかかります。これが二重コストと呼ばれる構造です。しかも厄介なのは、この追加コストが「当初の見積もりに含まれていない作業」として扱われるため、発注側にとっては予期しない請求として感じられやすい点です。粒度の粗さは、契約時には見えにくいコストの種になっているのです。

こうした手戻りのコスト構造については、要件定義の手戻りが二重コストになる仕組みでも別の角度から扱っていますので、あわせて確認しておくと全体像がつかみやすくなります。

要件定義の詰め方が後工程の負担に直結するという考え方は、独立行政法人情報処理推進機構（IPA）が公開している非機能要求グレードの資料でも示されています。この資料は、性能や可用性、セキュリティといった「非機能要件」を発注者と開発者があらかじめすり合わせておくためのチェック項目集としてまとめられており、項目が曖昧なまま進めると後工程での認識合わせや手戻りが発生しやすいという前提に立っています。粒度の粗さが後から表面化しやすいのは、機能面だけでなくこうした非機能面でも同じ構造があるためです。ここは、要件定義書を見返すときに機能面だけでなく非機能面も点検する視点として、メモしておく価値があります。

契約前にできる粒度チェックの視点

粒度の粗さは、完成した要件定義書を眺めているだけでは気づきにくいものです。そこで、契約前に以下のような観点で確認しておくと、後々の食い違いを減らせます。

• 「異常系」が書かれているか：正常に動く場合の説明だけでなく、エラーや例外が起きたときの挙動まで記述されているか
• 「誰が」「いつ」使うかが具体的か：機能名だけでなく、利用シーンや操作する人物像まで踏み込んで書かれているか
• 画面遷移や条件分岐が図や表で示されているか：文章だけで説明されている部分は、認識のズレが起きやすい箇所として要注意

これらは、要件定義書を受け取った側が「読んで分かった気になる」のではなく、「実装する人がこの記述で迷わず作れるか」という視点で読み返すことで見えてきます。ここは、次に要件定義書をレビューするときにそのまま使える視点なので、手元にメモしておくといいところです。

まとめ

要件定義の粒度は、資料のボリュームやページ数では測れません。機能レベルの合意はあっても、仕様レベルの細部が詰め切れていないまま契約が進むと、実装フェーズでの手戻りという形で二重コストが表面化します。

• 要件定義は「あるかないか」ではなく「粒度」で見る
• 粒度の粗さは契約時には見えにくく、実装中に手戻りとして顕在化する
• 異常系・利用シーン・条件分岐の記述有無を契約前にチェックしておく

分厚い要件定義書に安心せず、細部の書き込み具合を確認する習慣が、後の追加費用トラブルを減らす一歩になります。