システム開発の現場では、「プロジェクトの成否は要件定義で8割決まる」と言われます。
しかし現実には、
・要件定義をしっかりやったはずなのに手戻りが発生する
・設計段階で追加要件が出る
・テスト段階で「想定と違う」が起きる
・本番後に業務が合わないことが分かる
こうしたケースは珍しくありません。なぜ、このようなことが起きるのでしょうか。
１．最大の理由：要件定義を「IT作業」として扱っている
多くの企業では、要件定義を次のように捉えています。
・必要な機能を整理する
・画面や帳票を定義する
・入力項目を整理する
もちろん重要ですが、これだけでは本質的な要件定義にはなりません。
２．本来の要件定義とは何か
本来の要件定義は、「業務をどうするかを決めるプロセス」です。
つまり、
・どの業務を残すか
・どの業務をやめるか
・どの業務を統一するか
・どこを自動化するか
を決める場です。
３．なぜ要件定義が崩れるのか
大きく3つの原因があります。
（１）原因①：現状業務を前提にしている
結果：
・例外が増える
・特殊仕様が増える
・複雑化する
（２）原因②：部門最適で考えている
結果：
・全体最適にならない
・統一ルールが作れない
（３）原因③：業務責任が曖昧
結果：
・意思決定が遅れる
・後戻りが発生する
４．要件定義で本当に決めるべきこと
成功しているプロジェクトでは、次の3点を必ず決めています。
（１）To-Be業務
（２）業務ルール
（３）例外処理方針
ここが決まると、システム要件は自然に決まります。
５．要件定義を成功させる「順序」
理想的な順序は次の通りです。
（１）業務整理
（２）業務標準化
（３）業務フロー設計
（４）システム要件化
逆にすると、手戻りが増えます。
６．要件定義を難しくする組織要因
実務では、技術より組織が難易度を上げます。
・過去踏襲文化
・属人業務
・例外処理文化
・部門独立性
７．要件定義を成功させる経営の関与
最終的に必要なのは、経営判断です。
・統一するのか
・残すのか
・やめるのか
この意思決定が曖昧だと、要件定義は必ず揺れます。
８．要件定義は「設計」ではなく「意思決定」
要件定義とは、仕様整理ではなく、経営と業務の意思決定プロセスです。
９．まとめ
要件定義で決まるのは、機能ではなく、業務構造です。
要件定義は、IT工程ではなく、業務設計・組織設計・経営判断が交差する領域です。こうした考え方は、DX推進やIT投資判断とあわせて整理することで、プロジェクト成功確率を高めることにつながります。
