本記事は『要件定義の極意 「機能不全」「予算超過」「遅延」を防ぐ20のルール』（著者：松本 均）の「第2部 『機能不全』を防ぐ極意」から一部を抜粋したものです。掲載にあたって編集しています。
導入：なぜシステムが機能不全となるのか
『このシステム、結局あまり使われていません』。みなさまもこれまで数え切れないほど現場で耳にしてきたのではないでしょうか。開発チームはまじめに要件を整理し、スケジュール通りに納品し、技術的なバグもなかった。それにもかかわらず、実際の業務では使われない。リリース直後から裏運用が生まれ、導入効果が曖昧になり、関係者の熱意も次第に失われていく。これが「機能不全」の典型的な末路です。
この「機能不全」という状態は、不具合や動作不良を指すのではありません。技術的には正しく動作しているにもかかわらず、ユーザーにとって価値がなく、業務で実際に使われない、という状態を意味します。画面はモダンで、処理も正確。しかし、現場の業務に合っておらず、入力項目が多い、手戻りに対応できない、紙との二重入力が必要になる。こうした小さな違和感の積み重ねが、最終的に誰も使わないシステムを生み出してしまうのです。
書籍『要件定義の極意 「機能不全」「予算超過」「遅延」を防ぐ20のルール』では、要件定義における代表的な失敗要因として、「沈黙とすれ違い」「担い手の不足」「判断の複雑化」という3つの構造的課題を整理しています。これらはすべて、機能不全が生まれる源流でもあります。
- 沈黙とすれ違い：現場と開発側で認識が共有されず、合意形成が表面的に終わってしまう
- 担い手の不足：業務と技術の橋渡しを担う人材が不在で、業務ニーズが正しく要件に落とし込まれない
- 判断の複雑化：関係者が多すぎて責任の所在が曖昧になり、重要な意思決定が先送りされる
ここからは、機能不全を防ぐために、現場視点に立脚した7つの実践的なルールを提示します。これらのルールは、現場で数々の失敗と成功を経験し、現場の声に耳を傾け、何度もやり直しを繰り返す中で体系化された再現性のある実践知です。7つのルールは、以下の3つの問題構造に対応しています。
| 問題点 | 対応するRule | Ruleの内容 |
|---|---|---|
| （1）業務全体の視点が欠如 | Rule1 | 業務フローを起点にする |
| Rule2 | 現場の声を直接取り入れる | |
| （2）現場が理解できない設計 | Rule3 | 「超具体的なユースケース」に落とし込む |
| Rule4 | 動くプロトタイプで具体化する | |
| （3）現場の主体性の欠如 | Rule5 | 要件の意思決定は確実に現場がする |
| Rule6 | 本質的に必要な機能に絞ってリリースする勇気を持つ | |
| Rule7 | 開発経過を利用者と共有する |
これらはどれも、「業務に役立つものをつくる」という当たり前の目的に立ち返るための原則です。技術的な選定や開発手法の議論に先立ち、まずは現場の声を捉え、業務の流れを理解し、使われる未来を想像すること。それが、要件定義における本質であり、すべての成功の起点です。昨今では、DXやAI導入など、技術革新の波が一層加速しています。しかし、どれだけ技術が進化しても、使いやすいかどうかは、変わらず最も重要な判断基準です。現場で活用されないシステムは、どれだけ先進的な技術を使っていようと価値を生み出しません。
今回は、使えないシステムを未然に防ぎ、真に業務に貢献するシステムをつくるための視点と手法を、失敗事例をもとに丁寧に解説していきます。現場と開発チームが、目的を共有し、ともにプロジェクトを成功に導くための道筋を、これから一緒に見ていきましょう。
