要件定義の手戻りが二重コストになる仕組み

「要件定義は終わったはずなのに、なぜか追加の見積もりが出てきた」——システム開発を発注したことのある現場責任者なら、一度はこの感覚に覚えがあるのではないでしょうか。

打ち合わせは何度もした。資料も作った。それなのに、開発が始まってから「これは聞いていない」「この機能は想定外」というやり取りが続き、気づけば当初の予算を超えている。これは担当者の能力不足というより、要件定義という工程そのものが持つ構造の問題であることが多いです。

この記事では、要件定義の手戻りがなぜ二重コストにつながりやすいのか、その仕組みを整理したうえで、発注前にどこを確認しておけば防ぎやすいのかを見ていきます。

「決まったつもり」と「決まっている」のズレ

要件定義の手戻りが起きる最大の要因は、発注側と開発側の間で「決まったつもり」と「決まっている」の基準がずれていることにあります。

たとえば経理部門が「請求書の自動発行機能が欲しい」と伝えたとします。発注側は「請求書を自動で作ってくれる機能」というイメージで満足していますが、開発側は「どの項目を、どの条件で、どのフォーマットで出力するか」まで確定して初めて「要件が決まった」とみなします。この粒度の差が埋まらないまま設計・開発に進んでしまうと、後工程で認識のズレが表面化し、作り直しが発生します。

「決まった」の基準が発注側と開発側で違うということ自体は珍しい話ではありません。この基準のズレを認識しておくことが、後工程での手戻りを防ぐ第一歩になります。

なぜ「二重」のコストになるのか

手戻りが単なる遅延ではなく「二重コスト」と呼ばれるのは、次の2つの費用が重なって発生するためです。

• すでに投じた工数の費用：一度作った設計書やプログラムを見直す、あるいは作り直すための工数
• やり直しにかかる追加の費用：修正版の要件をもとに、改めて設計・実装をやり直すための工数

本来であれば1回で済むはずの作業が、認識のズレによって実質的に2回発生することになります。これが「要件定義が甘いと開発コストが膨らみやすい」と言われる背景です。

さらに厄介なのは、この二重コストが契約書上では「追加費用」や「仕様変更費」という名目で請求されることが多く、発注側からすると「最初の見積もりと話が違う」という不信感につながりやすい点です。開発側からすれば「決まっていなかったことを新たに決めた」だけなのですが、発注側には「同じ話を繰り返しさせられている」という感覚が残ります。この温度差が、要件定義まわりのトラブルの多くに共通する構造です。

手戻りが起きやすい現場の共通点

手戻りが発生しやすい現場には、いくつか共通した傾向があります。

傾向1：要件定義の場に現場担当者が同席していない

経営層や情報システム担当だけで要件を決めてしまい、実際にその業務を毎日行っている現場担当者の声が反映されないまま進むケースです。運用が始まってから「これでは現場の業務に合わない」という声が上がり、結果的に要件の見直しが必要になります。

傾向2：要件定義書が文章だけで完結している

画面イメージや業務フローの図がなく、文章だけで要件がまとめられている場合、読み手によって解釈が変わりやすくなります。同じ文章を読んでも、発注側と開発側でイメージする完成形が異なることは珍しくありません。

傾向3：要件定義の期間が極端に短い

見積もり合意を急ぐあまり、要件定義そのものに十分な時間を取らずに次の工程へ進んでしまうケースです。要件定義は開発全体の土台にあたる工程であるため、ここを圧縮すると、後の工程にしわ寄せが集中しやすくなります。

要件定義とそもそも何を指すのか、どこまでを見積もり前に固めておくべきかについては、要件定義とは何か。見積もり前に必要な理由でも整理していますので、あわせて確認しておくと全体像がつかみやすくなります。

発注前に確認しておきたいこと

手戻りをゼロにすることは難しいとしても、リスクを小さくする工夫はあります。

1. 要件定義書のレビューに現場担当者を含める：実際に業務を行う人の目で見て違和感がないか、契約前に確認する
2. 文章だけでなく画面イメージや業務フローも要求する：認識のズレは文章より図の方が発見しやすい
3. 要件定義の完了基準を契約書に明記してもらう：「どの状態になったら要件定義完了とするか」を事前にすり合わせておく
4. 変更が発生した場合の費用ルールを事前に確認する：どこまでが無償修正の範囲で、どこからが追加費用になるのかを聞いておく

特に4つ目は、要件定義後の変更が追加費用になるかどうかの境界線に直結する部分です。この境界線の考え方については要件定義の「変更」が追加費用になる境界線で詳しく扱っていますので、契約前に一度目を通しておくと判断がしやすくなります。

発注側がすべてを技術的に理解する必要はありませんが、「要件定義とはどこまで決めることを指すのか」という認識だけは、開発会社と事前にすり合わせておくと、後々の認識ズレを減らすことにつながります。

まとめ

要件定義の手戻りが二重コストにつながる仕組みについて整理してきました。

• 手戻りの多くは能力不足ではなく、「決まったつもり」と「決まっている」の基準が発注側と開発側でずれることから起きる
• 二重コストは、すでに投じた工数とやり直しの工数が重なって発生するため、当初の見積もりより膨らみやすい
• 現場担当者の同席、図による確認、完了基準の明記、変更費用ルールの事前確認が、手戻りのリスクを小さくする手がかりになる

要件定義は地味な工程に見えますが、その後の見積もりや開発費用の土台になる部分です。契約前にどこまで固まっているかを一度立ち止まって確認することが、結果的に無駄な費用を減らす近道になります。