企画・構想策定とは――要件定義の前に決めておくこと

「何を作るか」の前に、「なぜやるか」を決める

ウォーターフォール開発では、一般に要件定義から工程が始まるように説明されます。しかし実際のプロジェクトでは、その前に「企画・構想策定」という工程が置かれることが少なくありません。要件定義が「何を作るか」を決める工程だとすれば、企画・構想策定は「なぜやるのか」「やる価値があるのか」を決める工程です。

ウォーターフォール開発の工程全体

工程	略称	主な内容
企画・構想策定	—	目的・効果・概算費用を整理し、実施可否を判断する
要件定義	RD	業務要件・システム要件を決める
基本設計（外部設計）	BD	画面・帳票・IFなど、利用者から見える部分を設計する
詳細設計（内部設計）	DD	プログラム構造・ロジック・DBを設計する
製造（実装）	PG	コーディング
単体テスト	UT	モジュール単位の確認
結合テスト	IT	モジュール間・機能間の連携確認
総合テスト	ST	システム全体を要件と照らして確認
運用テスト（受入テスト）	OT / UAT	利用部門が実業務の流れで確認
移行・リリース	—	本番環境への移行と稼働開始
運用・保守	—	稼働後の運用と改修

V字モデルでは、要件定義↔運用テスト、基本設計↔総合テスト、詳細設計↔結合テスト、製造↔単体テストが対応します。企画・構想策定は、このV字の外側、最も上流に位置し、最終的には「稼働後に効果が出たか」という評価と対になります。

企画・構想策定で決めること

目的と背景：どの経営課題・業務課題を解決するのか
目指す姿（To-Be）：現状（As-Is）との差と、変えたい範囲
期待効果：定量効果（コスト削減、工数削減など）と定性効果
概算費用とスケジュール：精度は粗くてよいが、前提条件を明記する
実現方式の方向性：パッケージ／スクラッチ／SaaSなどの選択肢
体制とスポンサー：誰が意思決定し、誰が責任を持つのか
主要リスク：実施を左右するリスクと前提

成果物としては、企画書、構想書、ビジネスケース（投資対効果の説明）などがまとめられ、経営層による投資判断（Go/No-Go）の材料になります。

要件定義との違い

観点	企画・構想策定	要件定義
問い	なぜやるか・やる価値があるか	何を作るか
主な関係者	経営層・事業部門・企画部門	業務部門・情報システム部門・ベンダー
見積り精度	概算（幅を持たせる）	より確度の高い見積り
出口	投資判断・予算化	設計工程への引き渡し

この工程を省くと何が起きるか

企画・構想が曖昧なまま要件定義に入ると、要件の優先順位を決める基準がなくなります。その結果、「あれもこれも」と要件が膨らみ、スコープの肥大化、予算超過、そして「作ったが使われない」システムにつながりやすくなります。要件定義でもめる原因の多くは、実は企画・構想の段階で決めるべきことが決まっていないことにあります。

PMとしてのポイント

目的と期待効果を、関係者が同じ言葉で説明できる状態にしておく
概算見積りは前提条件とセットで示し、数字だけが独り歩きしないようにする
「やらない」という判断も成果として扱う
企画書の目的・効果は、要件定義以降の判断基準として引き継ぐ
契約上は、要件が固まっていないこの段階は準委任で進めるのが一般的

企画・構想策定は、プロジェクトの「最初の品質」を決める工程です。ここで決めた目的が、その後のすべての工程の判断基準になります。