要件定義の失敗は、キックオフの時点で決まっている
システム開発プロジェクトの成否は、要件定義フェーズでほぼ決まります。私はPMOとして10年以上、金融系、製造業、公共インフラなど複数業界で30以上のプロジェクトに関わってきましたが、失敗するプロジェクトには驚くほど共通するパターンがあります。
要件定義が曖昧なまま開発に入り、後工程で仕様変更が頻発する。納期が遅れ、予算が膨らみ、最終的にはユーザーの要求を満たせないシステムが完成する。こうした失敗プロジェクトを何度も目の当たりにしてきました。
興味深いのは、失敗するプロジェクトの多くが「要件定義書」自体は存在するということです。数百ページに及ぶ立派な要件定義書があっても、プロジェクトは失敗する。なぜでしょうか。
答えは単純です。要件定義という作業の「やり方」に問題があるからです。今回は、私が10年のPMO経験で見てきた「要件定義で失敗する会社の3つの共通点」を、実体験ベースでお伝えします。
失敗プロジェクトの典型的な光景
要件定義フェーズのキックオフミーティング。ベンダー側は気合十分で臨みますが、発注側の顔ぶれを見て私は不安を感じます。出席しているのはIT部門の担当者のみ。経営層も、実際にシステムを使う現場部門の責任者も誰一人いません。
「経営層はお忙しいので」「現場は通常業務がありますから」という言葉を何度聞いたことか。このパターンで始まったプロジェクトは、ほぼ例外なく後で苦しむことになります。
私はPMOとして10年以上、多数のプロジェクトで要件定義フェーズの失敗パターンを見てきました。特に印象的だったのは、ある中堅製造業のシステム刷新案件です。プロジェクトキックオフ時、経営層は『若手に任せる』と現場に丸投げ。現場ユーザーは『IT部門が決めてくれる』と受け身。IT部門は『ユーザーが言ったものを作る』と義務感だけ。誰もオーナーシップを持たない要件定義になり、結果として3ヶ月遅れ、予算1.5倍という炎上に至りました。逆に成功した金融系プロジェクトでは、経営層が毎週レビューに参加し、現場ユーザーが要件定義書を自ら書く体制を作りました。要件定義の成否は『技術』ではなく『関係者の当事者意識』が全てだと痛感した経験です。
要件定義が終わり、開発が始まってから問題が表面化します。「こんな仕様は聞いていない」「この機能では業務が回らない」という声が現場から上がり始めるのです。そして決まって「要件定義のときに確認したはずですが」という水掛け論になります。
IT部門の担当者は板挟みになります。彼らは悪くありません。ただ、要件定義という作業に必要な人たちが参加していなかっただけなのです。
失敗する会社に共通する3つのパターン
私が見てきた失敗プロジェクトには、明確に3つの共通点があります。業種や規模を問わず、この3つのいずれか、あるいは複数が当てはまるプロジェクトは高確率で失敗しています。
パターン1:経営層のコミットが弱い
要件定義のキックオフに経営層が出席しない。「システムのことはIT部門に任せている」という姿勢が透けて見えるプロジェクトです。経営層の関与は最初の予算承認だけで、その後は進捗報告を受けるだけ。要件定義の内容を精査することもありません。
このパターンで困るのは、要件の優先順位が決められないことです。限られた予算と期間の中で「何を実現し、何を諦めるか」という判断は、本来は経営判断です。しかしその判断権者が不在のため、IT部門は全ての要望を盛り込もうとして破綻します。
パターン2:現場ユーザーが要件定義に参加していない
実際にシステムを使う現場部門の担当者が、要件定義のプロセスに全く関与していないパターンです。IT部門の担当者が現場にヒアリングに行くことはあっても、要件定義書のレビューや承認プロセスに現場が入っていません。
このパターンの問題は、実務との乖離が大きいシステムができあがることです。IT部門の担当者は業務の専門家ではありません。彼らが理解した範囲でまとめた要件は、どうしても表面的になります。業務の本質的な要求や、現場が暗黙知として持っている運用ノウハウは要件に反映されません。
パターン3:要件を「網羅すること」が目的化する
要件定義書が分厚くなればなるほど良い仕事をしていると錯覚するパターンです。あらゆる可能性を考慮し、全ての業務パターンを網羅しようとして、要件定義書は数百ページに膨れ上がります。
しかし中身を見ると、優先順位がありません。「必須」と「あれば便利」が区別されていません。全てが同じ重みで並んでいるだけです。結果として開発工数は見積もりを大幅に超え、予算オーバーか機能削減かという二者択一を迫られることになります。
なぜこの3つのパターンが生まれるのか
これらの失敗パターンは、なぜ繰り返されるのでしょうか。私の30年のIT業界経験から見えてくる構造的な原因があります。
原因1:「システム開発=IT部門の仕事」という誤解
多くの企業で、システム開発は「IT部門の仕事」と認識されています。経営層も現場部門も「システムのことは専門家に任せればいい」と考えます。この認識が根本的な誤りなのです。
システム開発の本質は、業務改革です。業務プロセスを見直し、効率化し、時には業務の在り方そのものを変えることです。それなのに「システムのことだから」とIT部門だけに任せれば、業務の本質に踏み込めないのは当然です。
私が金融系のプロジェクトで学んだのは、成功するプロジェクトは必ず「業務主管部門」がオーナーシップを持っているということです。IT部門はあくまで技術的な支援役。業務をどう変えるかの判断は、業務部門が主導します。
原因2:要件定義を「文書作成作業」と誤解している
要件定義を「要件定義書という文書を作ること」だと考えている会社が非常に多いです。立派な文書ができれば要件定義は完了、という認識です。
しかし要件定義の本質は、関係者間の「合意形成」です。何を作るのか、なぜ作るのか、どこまで作るのか。これらについて経営層、業務部門、IT部門、そしてベンダーの間で共通認識を作り上げることが目的です。文書はその結果でしかありません。
文書作成が目的化すると、パターン3の「網羅主義」に陥ります。とにかく書けることは全部書く。抜け漏れがないようにする。そして分厚い文書ができあがりますが、「では何を優先すべきか」という肝心の合意は存在しません。
原因3:要件定義フェーズに人的リソースを投入しない
多くの会社で、要件定義フェーズは「まだ開発が始まっていない準備段階」と軽視されます。本気でリソースを投入するのは開発フェーズから、という考え方です。
これは完全に逆です。要件定義フェーズこそ、最も重要な人材を最も多く投入すべきタイミングです。なぜなら、ここで決めたことが全てのベースになるからです。
製造業の大規模プロジェクトで私が目の当たりにしたのは、要件定義に経営層も現場の熟練者も参加しない一方で、開発フェーズには大量の要員を投入するという本末転倒な状況でした。当然、開発途中で仕様変更が頻発し、プロジェクトは大混乱に陥りました。
失敗の連鎖:後工程への影響
要件定義での失敗は、必ず後工程に波及します。設計フェーズで矛盾が見つかり、手戻りが発生します。開発フェーズでは「こんな要件では実装できない」という指摘が出ます。テストフェーズでは「テストケースが作れない」という問題が起きます。
そして最悪なのは、本番稼働後に「使えないシステム」だと判明することです。ユーザーから「こんなシステムでは業務ができない」というクレームが殺到します。しかし要件定義書には確かに記載があり、承認も得ているため、「要件通りに作りました」という平行線になります。
私はPMOとして、こうした修羅場を何度も経験してきました。そして毎回思うのです。「要件定義のときに、本当に必要な人たちが参加していれば」と。
要件定義を成功させる現代のアプローチ
では、要件定義を成功させるにはどうすればいいのか。30年の経験と、現代のツールを組み合わせた実践的なアプローチをお伝えします。
アプローチ1:ステークホルダー全員参加の仕組みを作る
経営層、現場部門、IT部門、ベンダーが定期的に集まり、要件を議論する場を制度化することが第一歩です。週次または隔週で「要件定義会議」を開催し、議論の過程そのものをドキュメント化します。
ここで役立つのがConfluenceやNotionのようなドキュメント共有ツールです。私が現場で使うなら、これらのツールで「要件定義ワークスペース」を作り、議論の経緯、決定事項、未決事項を全てリアルタイムで記録します。
Confluenceの優れている点は、コメント機能で非同期の議論ができることです。会議に出席できなかった経営層や現場担当者も、後からコメントを追加できます。「この要件は現場の運用と合わない」「この優先順位は経営方針と矛盾する」といったフィードバックを、その場で文書に反映できます。
Notionは、より柔軟なページ構成が可能です。要件をデータベースとして管理し、優先度、担当者、ステータスなどの属性を付けられます。全員が同じ情報を見ながら議論できるため、認識のズレが生じにくくなります。
アプローチ2:要件の優先順位を可視化する
全ての要件を「Must(必須)」「Should(重要)」「Could(できれば)」「Won’t(今回は対象外)」の4段階に分類します。いわゆるMoSCoW法です。重要なのは、この分類を経営層と現場が一緒に決めることです。
ここで使えるのがMiroやMuralのようなオンラインホワイトボードツールです。私が10年のPMO経験で得た教訓は、要件の優先順位付けは対面(またはオンライン会議)でビジュアルに議論すべきだということです。
Miroでは、要件を付箋に見立てて、全員で「これはMust」「これはCould」と分類していきます。意見が分かれたら、その場で議論します。「なぜこの要件が必須なのか」「この機能がなくても業務は回るのではないか」という本質的な問いが生まれます。
この作業をIT部門だけでやると、全てがMustになりがちです。しかし経営層が参加すると「この機能は予算に見合わない」、現場が参加すると「この機能より別の機能の方が業務上重要」という現実的な判断が入ります。結果として、本当に必要な要件に絞り込めるのです。
アプローチ3:プロトタイプで早期に認識を合わせる
文書だけで要件を詰めるのには限界があります。特に画面設計や業務フローは、実際に動くものを見ないと理解できません。だからこそ、要件定義フェーズで簡易的なプロトタイプを作ることを私は強く勧めます。
Figmaのようなデザインツールを使えば、エンジニアでなくてもインタラクティブなプロトタイプを作れます。私が現場で使った経験では、Figmaで作った画面モックアップを現場ユーザーに見せると、「あ、これだと操作手順が多すぎる」「この情報は画面のもっと上に必要」といった具体的なフィードバックが得られます。
文書で「一覧画面に検索機能を設ける」と書いてあっても、現場の人はピンときません。しかしFigmaで動くプロトタイプを見せれば、「検索条件はこれだけでは足りない」「並び替え機能も必要」という本質的な要件が引き出せます。
プロトタイプ作成は時間の無駄だと考える人もいますが、私の経験では逆です。開発後の大規模な手戻りに比べれば、要件定義フェーズでのプロトタイプ作成ははるかに低コストです。
ツールはあくまで手段:本質は人間同士の対話
ここまでツールを紹介してきましたが、誤解してほしくないのは、ツールを導入すれば要件定義が成功するわけではないということです。ツールは、関係者同士の対話を促進する手段でしかありません。
私が30年見てきた成功プロジェクトに共通するのは、ツールの有無ではなく、経営層・現場・IT部門が本気で議論しているかどうかです。たとえホワイトボードと付箋だけでも、全員が参加して真剣に議論すれば良い要件定義はできます。
逆に、高価なツールを導入しても、形だけの会議で実質的な議論がなければ失敗します。ツールは「対話の質」を上げるためのものであり、対話そのものを代替するものではありません。
30年現場にいた私が思うこと
要件定義の失敗は、技術の問題ではありません。人間関係とコミュニケーションの問題です。私が10年のPMO経験、そして30年のIT業界キャリアで学んだ最も重要な教訓がこれです。
要件定義は「面倒な調整作業」ではなく投資である
多くの企業が、要件定義を「早く終わらせて開発に進みたい」と考えます。経営層の時間を取るのも、現場担当者を会議に呼ぶのも申し訳ないと遠慮します。その結果、IT部門だけで要件をまとめ、形だけの承認を取って開発に進みます。
しかし私は声を大にして言いたい。要件定義フェーズにこそ、最高の人材を、最も多くの時間を投入すべきだと。ここでの投資をケチると、後で何倍ものコストとなって返ってきます。
公共インフラのプロジェクトで私が経験したのは、要件定義に6ヶ月かけたプロジェクトと、3ヶ月で済ませたプロジェクトの明暗です。6ヶ月かけたプロジェクトは、開発フェーズでの仕様変更がほぼゼロで、予定通りに完了しました。3ヶ月で済ませたプロジェクトは、開発途中で要件の矛盾が次々と発覚し、結局1年の遅延となりました。
失敗パターンは業種を問わず共通している
金融、製造、インフラ、サービス業。私が関わってきた様々な業界で、要件定義の失敗パターンは驚くほど共通しています。経営層のコミット不足、現場不在、網羅主義。この3つは業種を問わず現れます。
つまり、要件定義の成功法則も業種を問わず共通しているということです。あなたの会社が中小企業であれ大企業であれ、製造業であれサービス業であれ、基本は同じです。関係者全員が参加し、優先順位を明確にし、早期にプロトタイプで認識を合わせる。この3つを実践すれば、失敗の確率は大幅に下がります。
明日から始められる小さな一歩
もしあなたが今、要件定義フェーズのプロジェクトに関わっているなら、明日から実践できることがあります。それは「要件定義キックオフに経営層を呼ぶ」ことです。
30分でいいのです。プロジェクトの目的、予算、期間を経営層自身の口から語ってもらう。そして「要件の優先順位で迷ったときは経営判断を仰ぎます」と宣言してもらう。たったこれだけで、プロジェクトの位置づけが変わります。
IT部門だけの仕事ではなく、会社全体の仕事になります。現場部門も「自分たちも責任者だ」と認識します。要件定義会議への参加率も上がります。
私自身、PJM-A資格を取得してマネジメントの理論は学びましたが、現場で最も役立ったのはこうした「当たり前だが実践されていないこと」を愚直にやることでした。理論や資格よりも、関係者を巻き込む泥臭い調整力の方が、よほど重要です。
要件定義は「合意のプロセス」だと心得る
最後にもう一度。要件定義は文書作成作業ではありません。関係者全員で「何を作るべきか」を合意するプロセスです。立派な文書よりも、「これで行こう」という関係者の納得が重要です。
その納得を作り出すために、会議の場を設け、ツールを活用し、プロトタイプを作ります。全ては「対話」のためです。経営層、現場、IT部門が本音で語り合い、時には対立し、そして合意に至る。この人間臭いプロセスこそが、要件定義の本質なのです。
あなたのプロジェクトが、この3つの失敗パターンに当てはまっていないか、今一度確認してみてください。もし当てはまっているなら、今からでも軌道修正は可能です。手遅れになる前に、関係者を巻き込む勇気を持ってください。
コメント