松本均さんの著書『要件定義の極意 「機能不全」「予算超過」「遅延」を防ぐ20のルール』（翔泳社）の内容をもとにしたCodeZineの記事を読み、普段の開発現場で感じていることと重なる部分が多かったため、PM・顧客折衝の経験を交えながら私の見解をお伝えしたいと思います。
要点（記事の事実）
- 「機能不全」とは、技術的には正しく動作しているにもかかわらず、業務で実際に使われない状態を指す
- 機能不全が生まれる源流として、「沈黙とすれ違い」「担い手の不足」「判断の複雑化」 という3つの構造的課題が整理されている
- これらに対応する形で、業務フローを起点にする・現場の声を直接取り入れる・超具体的なユースケースに落とし込む・動くプロトタイプで具体化するなど、7つの実践ルールが提示されている
- 画面がモダンで処理が正確でも、入力項目が多い・手戻りに対応できない・紙との二重入力が必要といった「小さな違和感の積み重ね」が誰も使わないシステムを生む
- リリース直後から「裏運用」が生まれ、導入効果が曖昧になっていく典型的な末路が描かれている
著者見解
この記事で整理されている3つの構造的課題は、私が実務で担当してきた案件で繰り返し直面してきたものと一致しています。特に「担い手の不足」——業務と技術の橋渡しを担う人材が不在で、業務ニーズが正しく要件に落とし込まれない状態——は、規模の大小に関わらず起きやすい問題だと感じています。
現場目線で補足すると、「沈黙とすれ違い」が起きる背景には、単なるコミュニケーション不足ではなく、現場担当者が「自分の意見を言っても開発側には伝わらない」という諦めを持っている場合が少なくありません。ヒアリングの場で発言が少ないのは、意見がないからではなく、意見を出しても仕様に反映されないという過去の経験から来ていることがあります。この諦めを解消しないまま進めると、表面的な合意形成に終わり、リリース後に裏運用が生まれます。
一方で、「判断の複雑化」については、関係者を絞ること自体が難しい案件も多く、「誰が何を決めるか」を要件定義の早い段階で明文化しておくことが現実的な対策になると考えています。私自身の経験でも、意思決定者とその権限範囲を最初に整理しておかないと、後半になって方針が揺れてリリース直前に混乱するパターンを何度か見てきました。
いきなり7つのルールを全部実践しようとするより、まず「業務フローを起点にする」「現場の声を直接取り入れる」の2点から着手し、チームで継続できる形に落とし込むことが現実的だと思います。
