本記事は『要件定義の極意 「機能不全」「予算超過」「遅延」を防ぐ20のルール』（著者：松本 均）の「第2部 『機能不全』を防ぐ極意」から一部を抜粋したものです。掲載にあたって編集しています。
導入：なぜシステムが機能不全となるのか
『このシステム、結局あまり使われていません』。みなさまもこれまで数え切れないほど現場で耳にしてきたのではないでしょうか。開発チームはまじめに要件を整理し、スケジュール通りに納品し、技術的なバグもなかった。それにもかかわらず、実際の業務では使われない。リリース直後から裏運用が生まれ、導入効果が曖昧になり、関係者の熱意も次第に失われていく。これが「機能不全」の典型的な末路です。
この「機能不全」という状態は、不具合や動作不良を指すのではありません。技術的には正しく動作しているにもかかわらず、ユーザーにとって価値がなく、業務で実際に使われない、という状態を意味します。画面はモダンで、処理も正確。しかし、現場の業務に合っておらず、入力項目が多い、手戻りに対応できない、紙との二重入力が必要になる。こうした小さな違和感の積み重ねが、最終的に誰も使わないシステムを生み出してしまうのです。
書籍『要件定義の極意 「機能不全」「予算超過」「遅延」を防ぐ20のルール』では、要件定義における代表的な失敗要因として、「沈黙とすれ違い」「担い手の不足」「判断の複雑化」という3つの構造的課題を整理しています。これらはすべて、機能不全が生まれる源流でもあります。
- 沈黙とすれ違い：現場と開発側で認識が共有されず、合意形成が表面的に終わってしまう
- 担い手の不足：業務と技術の橋渡しを担う人材が不在で、業務ニーズが正しく要件に落とし込まれない
- 判断の複雑化：関係者が多すぎて責任の所在が曖昧になり、重要な意思決定が先送りされる
ここからは、機能不全を防ぐために、現場視点に立脚した7つの実践的なルールを提示します。これらのルールは、現場で数々の失敗と成功を経験し、現場の声に耳を傾け、何度もやり直しを繰り返す中で体系化された再現性のある実践知です。7つのルールは、以下の3つの問題構造に対応しています。
| 問題点 | 対応するRule | Ruleの内容 |
|---|---|---|
| （1）業務全体の視点が欠如 | Rule1 | 業務フローを起点にする |
| Rule2 | 現場の声を直接取り入れる | |
| （2）現場が理解できない設計 | Rule3 | 「超具体的なユースケース」に落とし込む |
| Rule4 | 動くプロトタイプで具体化する | |
| （3）現場の主体性の欠如 | Rule5 | 要件の意思決定は確実に現場がする |
| Rule6 | 本質的に必要な機能に絞ってリリースする勇気を持つ | |
| Rule7 | 開発経過を利用者と共有する |
これらはどれも、「業務に役立つものをつくる」という当たり前の目的に立ち返るための原則です。技術的な選定や開発手法の議論に先立ち、まずは現場の声を捉え、業務の流れを理解し、使われる未来を想像すること。それが、要件定義における本質であり、すべての成功の起点です。昨今では、DXやAI導入など、技術革新の波が一層加速しています。しかし、どれだけ技術が進化しても、使いやすいかどうかは、変わらず最も重要な判断基準です。現場で活用されないシステムは、どれだけ先進的な技術を使っていようと価値を生み出しません。
今回は、使えないシステムを未然に防ぎ、真に業務に貢献するシステムをつくるための視点と手法を、失敗事例をもとに丁寧に解説していきます。現場と開発チームが、目的を共有し、ともにプロジェクトを成功に導くための道筋を、これから一緒に見ていきましょう。
事例：ユーザーが使えないシステム
概要
『これ、本当に現場で使えると思ってるんですか？』。ユーザーテストの場で、事業部門の現場リーダーが口にしたその一言に、会議室の空気が一瞬で凍りつきました。システムは予定通りに動いている。画面もきれいにつくられている。致命的なバグもなく、品質としては一定の水準を満たしているにもかかわらず、現場の誰もが口を揃えて『使えない』と言ったのです。
ここで紹介するのは、著者が数多く見てきた失敗パターンをベースに構成した、ある業務システム刷新プロジェクトの事例です。実在の企業名やプロジェクト内容は伏せていますが、構成されている状況や登場人物、進行上の意思決定などは、いずれも現場で実際に起きていたことをもとに再構成しています。
本事例の舞台は、大手企業における業務システム刷新プロジェクトです。規模は数億円、期間は1年程度。PMO体制を整え、システムベンダーを選定し、IT部門が主導してプロジェクトを進行しました。形式的には計画通りに完了し、システムは問題なくリリースされました。しかし、実態は「動いてはいるが、現場で活用されない」という、まさに典型的な機能不全の誕生だったのです。
ここでは、プロジェクトの経緯を追いながら、どこで何が見落とされていたのか、なぜ、使えないという評価に至ったのかを紐解いていきます。そしてそれらの失敗の背景には、技術力の不足でも、努力不足でもなく、構造的な認識のずれや関係性の歪みが潜んでいたことを明らかにします。
ここで紹介するのは、決して特殊なプロジェクトではありません。多くの現場で「起こりかけている」「かつて経験した」ケースのように感じると思います。失敗の中にこそ、学ぶべき教訓があります。この事例が、次のプロジェクトを「使えるシステム」へと導く一助になることを願っています。
プロジェクトの背景と体制
本事例で取り上げるプロジェクトは、社内で長年使用されてきた業務システムの老朽化を背景にスタートしました。システムは複数の基幹業務を横断的に支えており、機能追加や改修が難しくなっていたことから、刷新が避けられない状況にありました。また、現場業務そのものが複雑化し、属人化が進んでいたため、単なるシステムの置き換えではなく、業務そのものを見直す好機としてプロジェクトが立ち上げられたのです。プロジェクトは社内のIT部門が主導し、以下のような体制で構成されていました。
- PMO：IT部門内の中堅社員を中心とした複数名体制で、全体の統括と調整を担う
- IT部門：プロジェクトのオーナーとして、要件整理・設計方針の策定・進捗管理を主導
- システムベンダー：開発パートナーとして設計・実装を担当。長年の付き合いがあり、信頼関係がある企業
- 事業部門：新システムの利用者。プロジェクト初期における要望ヒアリングの対象
この時点では、関係者の間に、現場の声を反映しながら刷新していこう、という前向きな空気があり、プロジェクトは順調に立ち上がりました。
要件定義でのすれ違い
プロジェクト開始時には、業務要望整理会議と題された場が複数回設けられ、各事業部門から現場の代表者が参加しました。会議では、『在庫照会のレスポンスをもっと早くしてほしい』『レポート作成を自動化できないか』といった具体的な要望が多く寄せられ、現場からも一定の期待が感じられました。
その後、実際に要件定義のドキュメントをまとめ、設計に落とし込むフェーズになると、主導権はIT部門とベンダーに移っていきました。IT部門としては、『過去のシステムを最もよく理解しているのは自分たちであり、業務理解もある程度できている』という認識のもと、効率性を優先する形で要件を整理。ベンダーに設計書の初稿作成を依頼し、それをPMOがレビューしたうえで、事業部門に確認依頼という形で展開する流れが定着していきました。
しかし、ここに大きな落とし穴がありました。作成された設計書は、システム視点で整理された成果物であり、専門用語・画面遷移・データ構造が中心に据えられた内容となっていました。それは、あくまで開発者やIT担当者には読み解けるものであっても、日々の業務を担う事業部門の担当者が本質的に理解するには難解すぎる構成だったのです。
また、ユースケースも一部作成されてはいたものの、その内容はあくまでシステムの画面操作や入力処理に限定されており、業務全体の流れや現場での実際の使われ方までは踏み込まれていませんでした。会議の中では、「確認作業には紙の帳票も併用されている」といった現場の実態が語られる場面もありましたが、そうした情報は、システムには関係ないと判断され、深掘りされることはありませんでした。
結果として、「誰が、どの業務の中で、なぜその操作を行うのか」といった文脈は記録にも残らず、ユースケースの構成は機能単位の断片的なものにとどまりました。「業務の中でその機能がどう使われるのか」「どのような前後関係や補完的作業があるのか」といった現場の運用実態は可視化されず、設計は進められていったのです。
事業部門の担当者は、設計書の説明を受けながらも全体像を掴むことができず、「なんとなくよさそう」「そこまで違和感はない」という曖昧な印象のまま、承認を出していきました。本当に業務にフィットするかどうかを十分に検討することなく、形式的な合意が次々に積み上がっていったのです。
この段階では、『要件定義が終わった』『合意も得た』という達成感がプロジェクト全体に広がっていました。しかし、その合意の中身は、現場が理解しきれていないままの「とりあえずの合意」にすぎなかったのです。現場とIT部門との間で、小さな認識のずれが静かに広がり始めていました。
設計とプロトタイプの欠如
設計フェーズに入ると、システムベンダーがUIのワイヤーフレームを作成し、各画面の操作イメージについて説明が行われました。設計書には画面遷移や入力項目が丁寧に記されており、IT部門からは『これで合意は取れる』と判断されていました。
しかし、そのワイヤーフレームは、実際の業務プロセスに基づいたものではなく、システム内部の機能構成に即した「画面中心の設計図」にとどまっていました。業務の流れ全体が可視化されているわけではなく、画面単位の操作説明が断片的に並んでいる状態だったのです。その結果、次のようないくつかの問題が見え隠れしました。
- 商品検索の導線が業務フローに対して不自然で、必要な情報にたどり着きにくい
- 在庫確認のために複数の画面を行き来する必要があり、操作が煩雑になる
- 承認フローが帳票と連携しておらず、結局紙による並行運用が必要になる
こうした課題はいずれも、業務の一連の流れを前提とせず、画面単位で設計を進めた部分最適の結果として発生したものでした。業務と設計の間にあるギャップが、この時点ですでに表面化していたのです。また、プロジェクトの進行にあたり、動くプロトタイプが提供されることはありませんでした。これは、プロジェクトスケジュールの厳しさや、リソース制約といった現実的な事情に加えて、『ワイヤーフレームで現場の合意が取れているのだから、改めてプロダクトを試作する必要はない』というIT部門の判断があったためです。
実際、現場の担当者もワイヤーフレームの説明を受けた際には、気になる点についていくつか指摘を行っており、『最低限伝えるべきことは伝えた』という感覚を持っていました。また、プロジェクト全体としても、『業務のヒアリングは一通り実施済みであり、それにもとづいて設計が進んでいるのだから、業務に沿った形になっているはずだ』という期待感が共有されていました。
一方で、関係者の間にはコストやスケジュールへの配慮もありました。現場側も、これ以上プロトタイプの開発に時間や予算をかけるのは難しいという認識を持っており、『ワイヤーフレームで大きな問題がなければ、それ以上の確認は不要だろう』という判断が取られたのです。IT部門としても、現場から特段の強い反対意見が出なかったことを受けて、合意は取れていると解釈し、プロジェクトを前に進めていきました。このように、関係者全員がそれなりに納得感を持ちながら、合意形成がなされたように見えていた一方で、実際にはそれぞれが『きっと大丈夫だろう』と思いながら、不安や不確実性を呑み込んでいたのです。認識は微妙にずれたまま蓄積され、やがて「思っていたのと違う」という反応として噴出する下地が、この時点ですでに出来上がっていました。
リリース直前の混乱
ついにユーザーテストの場が設けられました。各部門から選ばれた現場の代表者が集まり、新システムの操作を実際に体験します。操作手順を試しながら、現場の目線でフィードバックを行う重要な機会です。最初の操作説明が終わった直後、ある担当者の口から静かに発せられた一言が、空気を一変させました。
『これ、全然イメージと違います』。この一言を皮切りに、次々と不満や違和感の声があがっていきます。
- 業務の手順と、画面遷移の構造が一致していない
- 本来業務で必要とされる情報が、画面に表示されていない
- 操作ステップが以前より増えており、処理に余計な時間がかかる
その場にいた関係者の多くが、思いがけないほど多くのずれが表面化していくのを目の当たりにしました。
ベンダー側はすぐに反論します。『要件通りにすべて実装しています』『設計書は関係部門の承認を得ています』と。IT部門も「これ以上の仕様変更は現実的に不可能」と姿勢を崩さず、「設計に問題はない」という論理の正しさを貫きました。
一方、現場は「合意したはずの内容」と「実際に触れた操作体験」との間に強いギャップを感じており、それをどう説明してよいかもわからず、混乱していきました。現場が伝えようとしているのは、画面や機能そのものの問題ではなく、業務として使えるかどうかという観点での違和感だったのです。
こうして、現場が抱く「何か違う」という感覚と、開発側が持つ「仕様は正しい」という認識が激しく衝突し、対話が成立しないまま時間だけが過ぎていきました。
表面的には確認は取れていたはずなのに、いざ動かしてみると業務としては使えない。この根本的なずれが、プロジェクト後半における最大の混乱を引き起こす引き金となりました。
リリースと現場の受け止め方
最終的に、システムはそのままリリースされることになりました。理由は明確でした。すでに数億円規模の開発投資がなされており、旧システムとの契約延長や再構築の余地がなかったためです。関係者の間には、「今さら止められない」「やるしかない」という空気が広がっていました。リリース後、現場では様々な想定外の対応が生まれました。
- 一部の作業は、新システムではカバーしきれず、Excelファイルを用いた補完運用が始まった
- 紙帳票による記録が再び持ち出され、帳票を出力して、別途手入力、という手作業が常態化
- クレーム対応では、操作に不慣れなスタッフが手順に戸惑い、1件当たりの対応時間が大幅に増加
業務は止められないため、現場はなんとかして運用に乗せるという方向で動きましたが、その過程での非効率とストレスは非常に大きなものでした。
一方、プロジェクトの上層部では、計画通りにリリースできたという報告が行われていました。要件定義も設計も、合意書類は揃っている。IT部門としても、現場の声は取り入れたとの認識を持っており、プロジェクトとしては一区切りついたように見えていました。しかし、現場の実感はまったく異なっていました。操作が煩雑で、使いたい情報にたどり着くまでの道のりが長い。画面上はモダンであっても、業務に活かせる感覚が薄く、あくまで導入されたから使うものになっていたのです。
誰かが明確な責任を取ったわけでもなく、誰もが、仕方なかったと納得しきれないまま、使えないという評価を受けたシステムだけが、5年間現場に残されることになりました。
現場が主体的にできない構造的な理由
このプロジェクトでは、現場が自らの業務に最も密接に関わっていたにもかかわらず、最後まで主体的に関与することができませんでした。これは個人の姿勢や熱意の問題ではなく、現場が受け身にならざるを得ない構造が、プロジェクトの進め方そのものに組み込まれていたからです。
要件を詰める場面でも、リリース範囲を決める局面でも、あるいは開発中の仕様をすり合わせる場面でも、現場は常に相談される側であり、意思決定する側ではありませんでした。ヒアリングはされていても、それがどう設計や仕様に反映されているのかは見えず、『伝えたはずなのに違う』『現場の実情とは合っていない』と感じることが徐々に蓄積していきました。
なぜ、こうした「現場が関われないプロジェクト」となってしまったのでしょうか。背景には、次の3つの構造的な課題が存在していました。
1．現場に意思決定の役割がないこと
現場の担当者は、プロジェクトにおいて要件や課題を共有する役割は担っていても、優先順位の判断や仕様決定といった本質的な意思決定には関与できない立場にありました。発言はできても、決めることはできない。こうした構図が前提となっていたため、IT部門主導で設計や判断が進み、現場で本当に必要なことが意志決定の場で取り上げられることはほとんどありませんでした。
2．現場が自身のニーズを適切にIT部門に伝えられない構造・プロセス
現場は日々の業務には精通していても、それをIT部門が理解できる形で言語化する機会や支援が十分に整っていませんでした。伝えようとしてもうまく伝えきれない、あるいは、一度言ったから反映されているはず、という期待から、細かな点まで踏み込めないことも多くありました。また、IT部門側も、言ってくれればやる、というスタンスにとどまり、現場のニーズの背景に踏み込むことはありませんでした。伝えられない現場と、深掘りしないIT部門の間に、構造的なすれ違いが存在していたのです。
3．情報共有・関与機会の欠如
プロジェクト全体の運営は基本的にIT部門が主体で推進されており、現場の利用者は「顧客」という立場に置かれていました。進捗や仕様変更の判断もIT部門内で完結することが多く、現場に情報が届くのは開発の終盤、あるいはリリース直前になってからでした。さらに、現場担当者の多くはシステム開発に関する知識や経験を持たないため、『話しても理解されない』『どうせ技術のことはわからない』と暗黙のうちに蔑ろにされてしまう構図もありました。こうした背景から、現場はプロジェクトに当事者意識を持てず、最後まで「自分たちがつくっている」という実感を持つことができなかったのです。
なぜ機能不全となってしまったのか？
「機能不全」となってしまう理由は、単一のミスや偶発的な判断の誤りではありません。多くの場合、要件定義の初期段階で生じた小さな認識のずれが、設計・開発・テストを通じて固定化され、リリース時には取り返しのつかない構造的な乖離へと広がっていくことが原因となります。現場は日々の業務を丁寧に遂行し、IT部門やベンダーも与えられた要件を忠実に実装している。それにもかかわらず、全体としての設計意図が次第にぼやけ、最終的に「動いているのに使われない」システムが出来上がってしまうのです。この現象を解きほぐすと、3つの根本的な問題構造にたどり着きます。
問題点（1）：業務全体の視点が欠如していた（Rule1／Rule2）
最初の問題は、要件定義を進める際に業務全体の構造を捉えず、部分的な要求から設計を始めてしまう点です。本来、要件定義の起点はシステムの機能ではなく、業務プロセスそのものにあります。業務の流れを可視化し、部署間での連携・承認・例外処理などの全体像を整理しなければ、設計は点で終わってしまい、線としての整合性を失います。
現場ヒアリングで『レスポンスを速くしてほしい』『レポートを自動化してほしい』といった声が出ても、それを業務フロー上のどこに位置づけるかが曖昧なままでは、実際の運用との齟齬が残ります。
業務全体の関係を無視して改善点だけを積み上げると、プロセス間の整合が崩れ、結果的に現場が求める体験とは異なるシステムになってしまうのです。要件定義の初期段階で業務フローを整理し、前後の関係性を関係者全員で共有することが、すべての前提になります。
問題点（2）：現場が理解できない設計になっていた（Rule3／Rule4）
2つ目の問題は、設計段階で現場の利用者が理解しづらい成果物を前提に、プロジェクトが進行してしまうことです。設計書や仕様書は一見すると整然と整理されており、関係者からも「網羅されている」「抜け漏れがない」と評価されます。しかし、その内容は技術的な構造や画面の構成に偏り、実際に業務を担う利用者にとっては理解しづらく、納得感を得にくいものになっていることが少なくありません。この段階で生じた認識のずれは、後工程で発覚した際に修正の影響が大きく、スケジュールやコストに深刻な影響を与えます。
本来、業務を整理する際に用いるユースケース（利用シナリオ）は、単なる操作手順ではなく「誰が、いつ、どの業務の文脈で、何を目的に」行動するのかを明確にするためのものです。それにもかかわらず、多くのプロジェクトでは画面操作やボタンの挙動確認にとどまり、業務全体の流れや意思決定の背景まで踏み込めていません。このような状態で合意を形成すると、業務プロセスと設計の整合が取れず、利用者は「動作は正しいが使いづらい」と感じるようになります。
問題点（3）：現場の主体性が欠如していた（Rule5／Rule6／Rule7）
3つ目の問題は、現場がプロジェクトの意思決定に参加できない構造です。ヒアリングは実施されていても、決定権がIT部門やベンダーに集中し、現場は確認する立場にとどまります。その結果、現場の判断が反映されないままプロジェクトが進み、最終段階で「想定と違う」「使いづらい」という反応が噴出します。
この構造的な問題の根底には、情報の非対称性があります。要件定義から設計、開発、テストに至るまで、進捗や仕様変更の情報が現場に届くのは終盤になってからです。現場が日常業務と並行してプロジェクトに関与するためには、判断材料が早期に共有され、意思決定の過程が見える仕組みが欠かせません。
まとめ
「機能不全」は、業務理解・設計理解・意思決定の三層でずれが連鎖した結果として生まれます。このずれを解消するには、業務の全体像を起点にし、現場が理解し、主体的に判断できるプロセスへと再構築することが重要です。書籍では、これら3つの構造的課題に対応する7つのルールを順に解説していきます。
それぞれのルールは、理論や手法の紹介にとどまらず、現場で再現可能な具体的アクションとして整理されています。「使えるシステム」を実現するための第一歩は、要件定義という最初の合意のつくり方を変えることから始まります。
