要件定義の失敗は手前にあり！「企画構想」の落とし穴と8つの点検リスト

この記事は「要件定義の実践ガイド（全9回）」の第2回です。
本記事は単体でもお読みいただけますが、システム開発の最難関である要件定義を成功に導くためのノウハウを体系的にまとめています。
前後のプロセスもあわせて読むことで、より深い理解に繋がります。ぜひ他の連載記事もご活用ください！
全9回のシリーズ記事一覧はこちら（ページ下部へ）

「要件定義の担当になったけれど、一体何から手を付ければいいんだろう？」
「そもそも、今回のシステム開発の『本当のゴール』って何だっけ？」

現場でプロジェクトマネージャー（PM）やリーダーを任され、いざ要件定義を始めようとした際、このような不安や疑問に直面したことはありませんか？

実は、要件定義がスムーズに進まない、あるいは後から大炎上してしまう原因の多くは、要件定義そのものではなく、その手前の「企画構想」が曖昧なことにあります。

本記事では、数多くのプロジェクト現場を見てきた経験から、要件定義の土台となる「企画構想」で陥りやすい4つの落とし穴と、走り出す前に必ず確認すべき「8つの点検リスト」を具体的に解説します。

迷走を防ぐ！要件定義を成功に導く「3つのステップ」
要件定義を泥沼化させる「企画構想」4つの落とし穴
走り出す前に確認！企画構想の「8つの点検リスト」
プロジェクトを健全に進めるためのPM防衛戦略
まとめ：企画構想という「航海図」がプロジェクトを救う

迷走を防ぐ！要件定義を成功に導く「3つのステップ」

要件定義は、いきなり画面の項目やデータベースの機能を決めることから始まるわけではありません。まずは、以下の「1→2→3」のステップのつながりを理解することが重要です。

Step	フェーズ	焦点（フォーカス）	主な活動内容
1	企画構想	経営・戦略	経営方針・システム化方針の決定、体制構築、計画立案
2	要求定義	業務・プロセス	業務プロセスの改善、現状把握、問題抽出、要求文書化
3	要件定義	システム・機能	システム化機能の整理、仕様検討、ドキュメント化

この流れが示す通り、「3. 要件定義」のインプットは「2. 要求定義」であり、そのさらに大元となるのが「1. 企画構想」です。

プロジェクトの立ち上げ期にあたるこの「企画構想」の軸がズレていると、その後のすべての工程がドミノ倒しのように崩れ、膨大な手戻りが発生してしまいます。

要件定義を泥沼化させる「企画構想」4つの落とし穴

企画構想が不十分なまま要件定義に突入すると、どのような悲劇が起きるのでしょうか。現場でよく見る4つの「落とし穴」を紹介します。

① 「何のため？」が不明確（目的・目標の認識ズレ）

「とにかく業務を効率化したい」「DXを推進したい」といった抽象的なゴールしかないパターンです。解釈が人によって異なるため、要件定義の場で「あれも必要、これも必要」と際限なく要望が膨らみ、収拾がつかなくなります。

② どこまでやるか決まっていない（スコープの境界線不足）

どの事業の、どの部署の、どの業務までが今回のシステム化の対象なのか。この境界線（スコープ）が不明確だと、要件定義はいつまでも終わりません。未完了のまま「とりあえず作り始めよう」と見切り発車すれば、必ず後で大きな手戻りが発生します。

③ 現場のプロが不在（形だけの体制）

詳細な実務を知らない管理職や役員だけで構成されたプロジェクト体制は非常に危険です。現場ならではのイレギュラーな業務パターンが一切考慮されず、リリース直前になって「これでは現場で全く使えない」という致命的な欠陥が発覚する原因になります。（参考：ステークホルダー管理の進め方｜「横槍」を防ぐ特定・分析と管理リスト【テンプレ付】）

④ 投資回収の意識が低い（期待効果へのコミット不足）

システムは「作って終わり」ではありません。システムへの投資を回収し、利益を出すのはお客様の業務部門です。当事者が納得していない、あるいは「IT部門のやらされ仕事」になっているプロジェクトは主体性が欠如し、重要な要件の抜け漏れを誘発します。

走り出す前に確認！企画構想の「8つの点検リスト」

上記のような落とし穴を回避するために、PMは要件定義を本格スタートさせる前に、以下の8項目が具体的に「言語化」されているかを必ず点検してください。

点検項目	確認する具体的な内容
1. システム化背景	なぜ今、このシステムが必要なのか？（周辺環境の変化や抱えている課題）
2. 目的・目標	システム化によって最終的に解決したいこと。達成すべき具体的な指標。
3. 期待効果	導入によって得られる定性的・定量的なメリット（費用対効果）。
4. 対象範囲（スコープ）	今回のプロジェクトで「やるべきこと」と「やらないこと」の明確な境界線。
5. 制約事項	予算の上限、絶対の納期、技術選定など、守らなければならない制限。
6. 体制・予算・期間	誰が、いくらで、いつまでに実施するのか。
7. 想定されるリスク	進行を妨げる可能性のある懸念事項や不確実な要素（技術的難易度、法規制など）。
8. 意思決定ルール	誰が最終的な判断（承認）を下すのか。仕様変更が発生した際の承認ルート。

もし、お客様から提示された資料でこれらの内容が不十分であると感じた場合、無理に要件定義を進めてはいけません。 お客様と一緒にこの8項目を作り込む「企画支援（コンサルティング）」のフェーズから提案するのも、プロジェクトを炎上から守り、成功させるためのPMの重要な判断です。

プロジェクトを健全に進めるためのPM防衛戦略

最後に、企画構想フェーズにおいて、PMがプロジェクトを安全にコントロールするための3つの戦略をお伝えします。

1. 現場を動かせる「実行体制」を構築する

役職者だけでなく、実務に精通した現場担当者を必ずプロジェクトのキーマンとして巻き込みましょう。また、彼らが打ち合わせやレビューに専念できるよう、お客様側のマネージャーに掛け合って「通常業務の稼働を調整してもらう」などのバックアップ体制を敷くことが不可欠です。

2. 「お客様が主体」の原則を共通認識にする

「システム会社が高いお金をもらって全部決めてくれるんでしょ？」という空気感は危険信号です。要件定義の開始前に「業務の主体はお客様である」ことを念押ししましょう。要件定義に参画した担当者が、最終的な「受入テスト」まで責任を持って参加する計画を初期段階で握っておくことが重要です。

3. リスクを抑える「準委任契約」を活用する

「やりたいこと（企画）」が固まりきっていない状態で、全体の開発規模を正確に見積もることは不可能です。最初からすべてを一括請負契約にするのではなく、要件定義フェーズまでは「準委任契約」として切り分けることで、ベンダー・お客様双方のリスクを抑えた健全な進行が可能になります。（参考：【算出5ステップ・交渉術付】システム開発見積もりの鉄則｜赤字と炎上を防ぐ5つの罠）