「使われないシステム」が生まれる構造——要件定義の失敗を受託開発の現場から読み解く
技術的には正常に動作しているのに、現場で誰も使わないシステム。これは特殊な事故ではなく、要件定義の構造的な問題として繰り返し発生するパターンだ。
出典: 「使われないシステム」はなぜ生まれるのか？ 現場と開発のすれ違いを防ぐ、要件定義のメカニズム
要点 (事実のみ)
- 松本均氏の著書『要件定義の極意 「機能不全」「予算超過」「遅延」を防ぐ20のルール』（翔泳社、2026年4月15日発売、定価3,278円）からの抜粋記事
- 「機能不全」とは不具合ではなく、技術的には正しく動作するが業務で実際に使われない状態を指すと定義している
- 機能不全が生まれる構造的課題として「沈黙とすれ違い」「担い手の不足」「判断の複雑化」の3つを整理
- これに対応する7つの実践ルールを提示：業務フロー起点、現場の声の直接収集、超具体的なユースケース、動くプロトタイプ、現場主導の意思決定、機能の絞り込み、開発経過の共有
- 「DXやAI導入など技術革新が加速しても、使いやすいかどうかは変わらず最も重要な判断基準」と結論づけている
徐 聖博の見解
私がこの記事で最も的を射ていると感じたのは、「機能不全」の定義だ。バグでも遅延でもなく、「技術的には正しいが使われない」という状態を独立した問題として切り出している点は、開発側と発注側の双方が見落としやすい盲点を正確に言語化している。
受託開発を手がけてきた経験から率直に言うと、この問題の根本は「担い手の不足」——業務と技術を橋渡しできる人材の不在——に集約されることが多い。現場は自分たちの業務フローを当然の前提として話し、開発側はその言葉をそのまま仕様に落とそうとする。しかし現場が「こうしたい」と言う要求の裏には、必ず「なぜそうしたいか」という業務文脈がある。その文脈を掘り起こさずに仕様化すると、画面は要件通りでも業務には合わないものが出来上がる。
7つのルールの中で私が特に重要だと考えるのは「Rule4：動くプロトタイプで具体化する」だ。言葉と文書だけで合意形成しようとすると、どうしても双方の頭の中にある「完成イメージ」がずれたまま進む。プロトタイプを早期に作り、現場の人間に実際に触れてもらうことで初めて「あ、これじゃない」という本音が出てくる。この「あ、これじゃない」を本番リリース後ではなく要件定義フェーズで引き出せるかどうかが、プロジェクト成否の分岐点になる。
また、AI・DX導入が加速する昨今、この問題はより一層深刻になりうる。AIを使った業務自動化ツールを導入したとして、現場の業務フローに合っていなければ結局「並行して手作業も残す」という最悪のパターンになる。技術の高度化は、要件定義の重要性を下げるのではなく、むしろ上げる方向に働くと私は考えている。
(編集レンズ: 実装・運用視点、発注側 / 中小企業 / 開発実務への含意)
