なぜあなたの要件定義は終わらないのか？失敗しない「要件定義3週間ロードマップ」でプロジェクトを成功に導く

【この記事はこんな方に向けて書いています】

システム開発プロジェクトで、関係部署との要件定義の会議が全く進まず、頭を抱えているプロジェクト責任者の方
「あれも欲しい」「これも必要だ」と要望ばかりが増え、スコープがどんどん膨れ上がる”スコープクリープ”に悩んでいる方
外部のITベンダーに「要件が固まらないと、見積もりもスケジュールも出せません」と言われ、プロジェクトが停滞している方
会議で決まったはずのことが、翌週には覆される「ちゃぶ台返し」に、心が折れかけている担当者の方
これから始まるシステム開発を、絶対に失敗させたくないと考えている経営者の方

「新しい顧客管理システムを導入して、営業効率を上げるぞ！」—。希望に満ちて始まったはずの社内プロジェクトが、最初の「要件定義」というフェーズで、気づけば数ヶ月も停滞している…。これは、多くの中小企業で繰り返される、悲しいけれど”あるある”な光景です。ある調査によれば、ITプロジェクトの実に3割以上が失敗に終わると言われ、その最大の原因が、この「要件定義の失敗」にあるとされています。この記事では、まさにその”要件定義の沼”にハマり、プロジェクトが座礁しかけていたA社が、外部の専門家と「3週間ロードマップ」を実践したことで、いかにしてこの難所を乗り越え、プロジェクトを成功に導いたのか。その全プロセスを、今日から使えるノウハウとして、具体的に解説していきます。

「で、結局どうしたいの？」出口の見えない会議室で、A社は溺れていた

今回ご紹介するA社は、順調に事業を拡大する、従業員80名ほどのサービス業の会社です。顧客数の増加に伴い、Excelでの顧客管理に限界を感じ、新しい顧客管理・営業支援システムを独自に開発することを決定しました。プロジェクトリーダーに任命されたのは、管理部門のAさん。早速、関連部署である営業部、カスタマーサポート部、そして経営層を集め、要件定義の会議がスタートしました。

しかし、その会議は、Aさんの想像を絶するカオスなものでした。

営業部長：「過去の取引履歴から、関連商品を自動でレコメンドする機能は必須だ！」 サポートリーダー：「それより、問い合わせ履歴をワンクリックで表示できないと意味がない！」 社長：「そもそも、スマホで簡単に見込み客の進捗を報告できるような、シンプルなUIにしてくれ」 ITベンダー：「皆様のご要望は分かりますが、それぞれ全く別の開発になります…。まずは、このシステムで”一番解決したいこと”を一つに絞っていただけないと…」

会議は毎週開かれるものの、各部署がそれぞれの立場から理想の機能を主張するばかりで、全く話がまとまりません。Aさんが議事録をまとめても、次の会議では「いや、そういう意味で言ったんじゃない」とちゃぶ台返しが起こる。まるで出口のない迷路です。

気づけば3ヶ月が経過。プロジェクトは一向に進まず、ITベンダーからは「このままでは、当初の予算と納期には到底収まりません」と、最後通牒を突きつけられてしまいました。Aさんは、関係者の間に挟まれ、疲労困憊。「良いシステムを作りたい」という皆の想いは同じはずなのに、なぜこんなことになってしまうのか…。A社は、”要件定義の沼”で、完全に溺れかけていました。

なぜ要件定義は”沼”と化すのか？9割の企業が見落とす3つの落とし穴

A社のような状況は、なぜ起きてしまうのでしょうか。それは、担当者の能力ややる気の問題ではありません。多くの場合、要件定義の進め方そのものに、構造的な”落とし穴”が存在するからです。

落とし穴①：「何が欲しいか（What）」から話してしまう A社の会議のように、いきなり「どんな機能が欲しいか（What）」から議論を始めてしまうのが、最も典型的な失敗パターンです。機能要求は、各部署の立場によって無限に出てきます。そうではなく、「なぜ、このシステムを作るのか？（Why）」というプロジェクトの根本目的と、「このシステムで、誰の、どんな課題を解決するのか？」というゴールが、全員で共有されていない限り、議論は必ず発散します。

落とし穴②：意思決定のプロセスがない 「全員の意見を尊重しよう」というのは、聞こえは良いですが、プロジェクトにおいては機能不全のもとです。誰が、何を基準に、最終的な意思決定を下すのか。そのルールが曖昧なままでは、会議はただの”意見発表会”で終わってしまいます。各部署の要望に優先順位をつけ、「今回はこれをやる」「これは次の機会に」という、勇気ある決断を下すプロセスが不可欠です。

落とし穴③：「完璧なシステム」という幻想 「せっかく作るなら、120%の完璧なシステムを目指したい」。その気持ちは分かりますが、これも危険なワナです。全ての要望を詰め込もうとすれば、開発期間もコストも青天井になります。ビジネスの世界で重要なのは、100点満点のシステムを2年かけて作ることではなく、ビジネス課題を解決できる70点のシステムを、半年でリリースし、そこから改善を重ねていくことです。最初から完璧を目指す幻想が、プロジェクトを前に進めなくさせているのです。

成功の鍵は”設計図”にあり。要件定義を3週間で決め切るロードマップ

この”沼”からA社を救い出したのが、外部の専門家（私たち）が提示した、「要件定義3週間ロードマップ」でした。これは、家づくりに例えるなら、「いきなり壁紙や家具の話をするのではなく、まず”どんな暮らしがしたいか”というコンセプトを決め、次に間取り図という”設計図”を完璧に仕上げ、最後に内装を決める」という、当たり前かつ強力なプロセスです。

このロードマップの目的は、たった3週間で、関係者全員が納得する「合意形成」を行い、ITベンダーが正確な見積もりと開発計画を立てられる、ブレない”要件定義書”を完成させることです。

Week 1：【目的とスコープの確定】なぜ作るのか？どこまでやるのか？ プロジェクトの”魂”を決める、最も重要な1週間。
Week 2：【業務フローと画面の具体化】どう使うのか？ 魂に”肉体”を与える1週間。抽象的な要望を、目に見える形にしていきます。
Week 3：【優先順位付けと合意形成】何から作るのか？ 肉体に”優先順位”をつけ、関係者全員が「これでいこう！」と腹を括る、決断の1週間。

この3週間、私たちはA社のプロジェクトにファシリテーターとして伴走し、議論を整理し、時に厳しい問いを投げかけながら、プロジェクトを前に進めていきました。

Week 1：【目的とスコープの確定】議論の”土台”を作る1週間

最初の1週間は、機能の話を一切禁じました。私たちが行ったのは、社長から各部署のキーパーソン、そしてITベンダーまで、全ての関係者への個別ヒアリングと、それを持ち寄る合同ワークショップです。

アクション①：徹底的なヒアリング 「このシステムが完成したら、あなたの仕事はどう変わっていますか？」「一番困っていることは何ですか？」といった問いを通じて、各々が抱える課題と期待を深く掘り下げました。

アクション②：目的（Why）の言語化ワークショップ ヒアリング内容を元に、全員で「このプロジェクトが達成すべき、たった一つのゴールは何か？」を議論し、言語化しました。A社の場合、それは「営業担当者が、外出先からでも3分以内に、質の高い営業報告を完了できる状態を作る」という、非常に具体的で分かりやすい目的でした。

アウトプット：プロジェクト憲章の作成 この週の最後に、私たちは一枚の「プロジェクト憲章」を作成しました。そこには、以下の内容が明記されています。

プロジェクトの目的（Why）： 上記で言語化したゴール
スコープ（What）： 今回のプロジェクトで「やること」と「やらないこと」の明確な線引き
成功の定義： 何をもって、このプロジェクトは「成功」と見なすか（例：営業報告の時間が平均50%削減される、など）

この憲章に、社長を含めた全関係者がサインをしました。これにより、今後の全ての議論の拠り所となる、強固な”土台”が完成したのです。

Week 2：【業務フローと画面の具体化】”見える化”で認識を揃える1週間

プロジェクトの目的という”土台”が固まったところで、2週目は、具体的なシステムの中身を検討していきます。しかし、ここでもいきなり機能の話はしません。

アクション：”As-Is / To-Be” 業務フローの可視化 まず、現状の営業報告の業務フロー（As-Is）を、Aさんと一緒に図に描き出しました。「Excelに顧客情報をコピーして、メールで上司に送って…」。この作業を通じて、どこに無駄があり、どこがボトルネックになっているのかが、誰の目にも明らかになりました。次に、新しいシステムを使った理想の業務フロー（To-Be）を描きます。「スマホアプリを開いて、顧客を検索し、定型の報告項目をタップして送信完了」。この”To-Be”フローが、そのまま新しいシステムの機能要件の骨子となります。

アクション②：ペーパープロトタイピング さらに、私たちはその場で、手書きの紙芝居のような、超ラフな画面イメージ（ペーパープロトタイプ）を作成しました。「トップページはこんな感じですかね？」「報告ボタンはここにあった方が分かりやすいですか？」と、その場で手で動かしながらシミュレーションすることで、抽象的だったシステムのイメージが、一気に具体的な手触り感のあるものに変わっていきます。

言葉だけの議論では、10人いれば10通りの解釈が生まれてしまいます。しかし、図や絵といった”見える形”にすることで、関係者全員が、驚くほどスムーズに同じイメージを共有できるようになったのです。

Week 3：【優先順位付けと合意形成】”決断”して前に進む1週間

目的が定まり、システムの具体的なイメージも固まりました。最後の1週間は、出てきた要望に優先順位をつけ、最終的な合意形成を行う、最も重要なフェーズです。

アクション：MoSCoW（モスクワ）分析による優先順位付け 私たちは、出てきた全ての機能要件を付箋に書き出し、壁に貼り付けました。そして、関係者全員で、それらを4つのカテゴリに仕分けるワークショップを行いました。

Must（絶対に必要）： これがないと、プロジェクトの目的が達成できない機能
Should（できれば欲しい）： 必須ではないが、あると非常に価値が高い機能
Could（なくても良いがあれば嬉しい）： 影響は軽微だが、あると便利な機能
Won’t（今回はやらない）： 今回のスコープからは明確に外す機能

この仕分け作業は、時に厳しい議論も伴います。しかし、Week1で定めた「プロジェクトの目的」という絶対的な基準があるため、感情論ではなく、ロジカルに判断を下すことができます。

アウトプット：合意形成された「要件定義書」の完成 最終的に、全員の合意のもと、「Must」と一部の「Should」の機能に絞って、第一弾として開発を進めることが決定されました。この結果をまとめたものが、ITベンダーに渡す最終的な「要件定義書」となります。そこには、もう曖昧な言葉はありません。

Aさんは、会議の最後に社長が「よし、この内容で進めよう！頼んだぞ！」と力強く宣言したのを聞いて、3ヶ月間の苦労が報われた気がした、と語ってくれました。たった3週間。しかし、それはA社が初めて、全員で”決断”し、一つのチームとして未来へ進み始めた、濃密な3週間でした。

プロジェクトの成否は、最初の3週間で決まる。

A社のプロジェクトは、この後、驚くほどスムーズに進行しました。明確な要件定義書があったため、ITベンダーからの見積もりも的確で、開発中の手戻りもほとんど発生しませんでした。そして半年後、当初の予算内で完成した新システムは、A社の営業生産性を劇的に向上させたのです。

あなたの会社で進めているプロジェクトは、今、どの段階にいますか？もし、出口の見えない”要件定義の沼”で立ち往生しているのであれば、それはあなたのせいではありません。ただ、正しい進め方、正しい”設計図”がなかっただけなのです。

しかし、社内の人間だけでは、部署間の利害関係などを調整し、議論を前に進めるのは、非常に困難な仕事です。そんな時こそ、私たちのような外部の専門家を、”航海士”として活用してください。私たちは、議論を客観的に整理し、時に決断を促し、あなたの会社のプロジェクトという船が、座礁することなく目的地にたどり着くための、最短ルートをご案内します。