なぜ機能不全となってしまったのか？
「機能不全」となってしまう理由は、単一のミスや偶発的な判断の誤りではありません。多くの場合、要件定義の初期段階で生じた小さな認識のずれが、設計・開発・テストを通じて固定化され、リリース時には取り返しのつかない構造的な乖離へと広がっていくことが原因となります。現場は日々の業務を丁寧に遂行し、IT部門やベンダーも与えられた要件を忠実に実装している。それにもかかわらず、全体としての設計意図が次第にぼやけ、最終的に「動いているのに使われない」システムが出来上がってしまうのです。この現象を解きほぐすと、3つの根本的な問題構造にたどり着きます。
問題点（1）：業務全体の視点が欠如していた（Rule1／Rule2）
最初の問題は、要件定義を進める際に業務全体の構造を捉えず、部分的な要求から設計を始めてしまう点です。本来、要件定義の起点はシステムの機能ではなく、業務プロセスそのものにあります。業務の流れを可視化し、部署間での連携・承認・例外処理などの全体像を整理しなければ、設計は点で終わってしまい、線としての整合性を失います。
現場ヒアリングで『レスポンスを速くしてほしい』『レポートを自動化してほしい』といった声が出ても、それを業務フロー上のどこに位置づけるかが曖昧なままでは、実際の運用との齟齬が残ります。
業務全体の関係を無視して改善点だけを積み上げると、プロセス間の整合が崩れ、結果的に現場が求める体験とは異なるシステムになってしまうのです。要件定義の初期段階で業務フローを整理し、前後の関係性を関係者全員で共有することが、すべての前提になります。
問題点（2）：現場が理解できない設計になっていた（Rule3／Rule4）
2つ目の問題は、設計段階で現場の利用者が理解しづらい成果物を前提に、プロジェクトが進行してしまうことです。設計書や仕様書は一見すると整然と整理されており、関係者からも「網羅されている」「抜け漏れがない」と評価されます。しかし、その内容は技術的な構造や画面の構成に偏り、実際に業務を担う利用者にとっては理解しづらく、納得感を得にくいものになっていることが少なくありません。この段階で生じた認識のずれは、後工程で発覚した際に修正の影響が大きく、スケジュールやコストに深刻な影響を与えます。
本来、業務を整理する際に用いるユースケース（利用シナリオ）は、単なる操作手順ではなく「誰が、いつ、どの業務の文脈で、何を目的に」行動するのかを明確にするためのものです。それにもかかわらず、多くのプロジェクトでは画面操作やボタンの挙動確認にとどまり、業務全体の流れや意思決定の背景まで踏み込めていません。このような状態で合意を形成すると、業務プロセスと設計の整合が取れず、利用者は「動作は正しいが使いづらい」と感じるようになります。
問題点（3）：現場の主体性が欠如していた（Rule5／Rule6／Rule7）
3つ目の問題は、現場がプロジェクトの意思決定に参加できない構造です。ヒアリングは実施されていても、決定権がIT部門やベンダーに集中し、現場は確認する立場にとどまります。その結果、現場の判断が反映されないままプロジェクトが進み、最終段階で「想定と違う」「使いづらい」という反応が噴出します。
この構造的な問題の根底には、情報の非対称性があります。要件定義から設計、開発、テストに至るまで、進捗や仕様変更の情報が現場に届くのは終盤になってからです。現場が日常業務と並行してプロジェクトに関与するためには、判断材料が早期に共有され、意思決定の過程が見える仕組みが欠かせません。
まとめ
「機能不全」は、業務理解・設計理解・意思決定の三層でずれが連鎖した結果として生まれます。このずれを解消するには、業務の全体像を起点にし、現場が理解し、主体的に判断できるプロセスへと再構築することが重要です。書籍では、これら3つの構造的課題に対応する7つのルールを順に解説していきます。
それぞれのルールは、理論や手法の紹介にとどまらず、現場で再現可能な具体的アクションとして整理されています。「使えるシステム」を実現するための第一歩は、要件定義という最初の合意のつくり方を変えることから始まります。
