要件定義が失敗する5つの原因と兆候｜発注側が手戻りを防ぐ進め方

要件定義が失敗する原因の多くは、開発会社の技術力ではなく発注側の準備にあります。目的が数値で決まっていない、現場の業務を棚卸ししていない、決める人が決まっていない、この3つが重なると要件は途中で必ずぶれます。日経BPの「ITプロジェクト実態調査」（2018年・1745件）でも、満足度が低かったプロジェクトの主因の筆頭は「要件定義が不十分」でした。この記事では、要件定義が失敗する5つの原因と、それぞれが現場でどう表面化するかの兆候、発注側が手戻りを防ぐ進め方を5手順で解説します。

要件定義はなぜ失敗する？原因が発注側に集中する理由

要件定義とは、システムで何を実現するかを決め、機能・業務の流れ・制約を文書として確定させる工程です。ここでの失敗とは、納品されたシステムが現場で使われない、開発の途中で追加費用が発生する、納期が延びる、という形で表れます。設計や開発の腕前ではなく、その前段の決めごとが原因になっている点が特徴です。

日経BPの「ITプロジェクト実態調査」（2018年、1745件のプロジェクトが対象）では、スケジュール・コスト・満足度の3条件をすべて満たしたプロジェクトは52.8%でした。満足を得られなかったプロジェクトの理由の筆頭は「要件定義が不十分」、最も苦労した工程を尋ねた結果も「要件定義」です。同調査は2003年・2008年にも実施されており、要件定義が品質と納期の壁になる構図は20年変わっていません。

原因が発注側に集中するのは、業務を知っているのが発注側だけだからです。伝票の例外処理、取引先ごとの慣習、担当者の頭の中にしかない判断基準は、開発会社がどれだけ優秀でも外からは見えません。技術で埋められない情報の差があるという前提に立つと、要件定義は「開発会社に任せる工程」ではなく「発注側が主導して情報を出す工程」だと分かります。

逆に言えば、失敗の多くは発注側の準備で防げます。必要なのはIT知識ではなく、自社の業務を言語化し、決める人を決め、決めた内容を文書に残すという段取りです。

要件定義が失敗する5つの原因と現場での兆候

失敗の原因は、細かく数えればきりがありませんが、中小企業のシステム開発では次の5つにほぼ集約されます。それぞれ表面化の仕方が違うため、兆候とセットで押さえておくと早い段階で軌道修正できます。

原因1は、目的が「システムを導入すること」になっているケースです。何がどれだけ良くなれば成功なのかが数値で決まっていないため、機能の要不要を判断する基準が存在しません。原因2は、現場の業務を棚卸ししないまま要件を決めることです。標準的な流れだけを説明し、月末だけ発生する処理や例外対応を伝え忘れた結果、稼働後に「この場合が登録できない」という問題が噴出します。

原因3は開発会社への丸投げです。「プロなので良いようにお願いします」と業務判断まで委ねると、開発会社は一般的な業務の型で作るしかなく、自社の運用と合わないシステムができあがります。原因4は決定権の不在で、現場・情報システム担当・決裁者の誰が何を決めるかが曖昧なまま進み、一度決めた仕様が後から覆ります。要望が後付けで膨らみ続けるスコープクリープも、ここから始まります。

原因5は、文書だけで合意してしまうことです。仕様書の日本語は読む人によって解釈が変わります。画面や帳票の実物を見ないまま「その機能で問題ありません」と合意すると、受入テストで初めて認識のズレに気づき、作り直しになります。

• 原因1：目的が数値の達成条件になっていない
• 原因2：現場の業務と例外処理を棚卸ししていない
• 原因3：業務判断まで開発会社に丸投げしている
• 原因4：決める人と決める期限が決まっていない
• 原因5：画面や帳票の実物を見ずに文書だけで合意している

手戻りを防ぐ要件定義の進め方5手順

原因が分かれば、対処は要件定義の進め方に組み込めます。特別な手法は必要なく、次の5手順を順番どおりに踏むだけで、後半の手戻りは大きく減ります。

手順1として、目的を数値の達成条件に翻訳します。「業務を効率化したい」ではなく「受注入力を1日2時間から1時間に減らす」「棚卸しの集計を3日から半日にする」という形にすると、機能を削る判断ができるようになります。手順2は業務の棚卸しです。対象業務を最初から最後まで、誰が・何を受け取り・何に記録し・誰に渡すかの順で書き出し、月末処理や訂正・取消といった例外を必ず併記します。

手順3で、決める人と決める期限を決めます。業務ごとに決定担当を割り当て、最終決裁者を1人明記し、いつまでに決めるかをスケジュールに入れます。手順4では、画面イメージと帳票サンプルで合意します。文書の承認だけで進めず、入力から出力までを1件分通して確認すると、解釈のズレがその場で見つかります。

手順5は、変更の受付ルールを先に決めることです。要件確定後の追加要望をどの窓口で受け、誰が可否を判断し、費用と納期への影響をどう扱うかを開発会社と合意しておきます。ルールがあれば、後から出た要望を「次のフェーズで対応する」と整理でき、スコープクリープを止められます。要件定義の前段にあたるRFP（提案依頼書）の作り方は関連記事で解説しています。

失敗はどの時点で表面化する？引き返し方

要件定義の失敗が表面化するのは、設計の後半、受入テスト、稼働直後の3か所です。設計後半では見積もりと工数の乖離として、受入テストでは「思っていたものと違う」という指摘として、稼働直後では現場がExcelに戻ってしまう形で表れます。表面化が遅いほど、作り直しの範囲は広くなります。

早い段階のサインは行動に出ます。要望が毎週増える、一度決めた仕様が覆る、現場の担当者が要件定義の打ち合わせに出てこない、開発会社からの質問に社内で答えられない。これらが2週間続いたら、機能の議論をいったん止めて、目的と決定権の確認に戻すほうが結果的に早く進みます。

すでに開発が進んでいる場合の引き返し方は、全面的なやり直しではなく優先度による切り分けです。要求機能を「必須」「あれば望ましい」に分け直し、必須だけで動く範囲を先に稼働させ、残りは次のフェーズに送ります。段階的に出すことで、現場が実物を触った上での要望が次の要件に反映され、想像だけで決めるよりも精度が上がります。

契約面では、要件定義を本開発と分けて発注する方法もあります。要件定義だけを先に契約し、確定した要件をもとに本開発の見積もりを取り直せば、曖昧な段階で総額を固定してしまうリスクを避けられます。

中小企業がつまずくポイントと対処

実際の支援現場でよくあるのは、要件定義の打ち合わせに現場の担当者が呼ばれておらず、管理職の説明だけで要件が固まってしまうケースです。実務の例外は日々手を動かしている人の頭の中にあるため、1回でよいので実際の入力作業を見せてもらう時間を取ると、抜けの大半はそこで見つかります。

IT専任者がいないことを心配する必要はありません。専門用語で書く必要はなく、業務の言葉で「誰が・何を・どれくらいの量・どう困っているか」を伝えれば、要件への翻訳は開発会社の仕事です。発注側が担うべきなのは、業務の事実を出すことと、決めることの2つに絞られます。

当社（UniGain）の業務アプリ・システム開発は80万円からで、要件が固まっていない段階の業務棚卸しから一緒に進めています。支援した業務システム構築では工数60%削減・対応速度2.5倍という結果が出ており、詳細は事例ページで紹介しています。要件定義にかける時間は、開発費用を増やす費用ではなく、作り直しを避けるための投資として考えると判断しやすくなります。