システム開発における構想、事業企画、要件定義の違いをデパート建設で理解する

プログラミング

はじめに ― “設計以前”を理解する

システム開発の現場でよくある失敗のひとつに、「どこで何を決めるべきか」が整理されていないことがあります。
構想、事業企画、要件定義が混ざってしまうことで、後から「こんなはずじゃなかった」と軋みが生じるのです。

この3つを明確に区別し、誰がどこまで考えるのかを理解することが、
プロジェクトを成功に導く第一歩です。
この記事では、デパート建設を例にして、初心者でも直感的に理解できるように解説します。


構想・事業企画・要件定義の境界線

比較項目構想(Vision)事業企画(Business Planning)要件定義(Requirement Definition)
目的理想・ありたい姿を描く成功の戦略方針を設計する戦略を実現する構成要素を定義する
主体経営層・創業者事業責任者・経営企画PM・開発責任者
関心価値・意義市場・KPI・ROI機能・業務フロー・性能
成果物ビジョン・ミッション事業計画書・KPI要件定義書・合意記録
スコープWhy(なぜ)How to succeed(どう成功するか)What & How(何を・どう実現するか)
責任範囲理想の提示戦略の妥当性(方向の正しさ)戦略の実行可能性(現実の成立性)

👉 構想が「理想」を描き、事業企画が「成功の筋道」を設計し、要件定義が「実現の構成要素」を固める。
この3段階が明確に分かれていれば、どんなプロジェクトでもブレにくくなります。


構想とは? ― 理想を描く工程

構想とは、実現したい理想やありたい姿を描くことである。

ここでは、まだ「数字」や「手段」は考えません。
「どんな未来を作りたいか」「社会や顧客にどう貢献したいか」を言語化する段階です。

例:デパート建設における構想

「街の中心に、世代を超えて人が集う場所を作りたい」
「家族が一日を楽しく過ごせる空間を提供したい」

この段階では、利益や集客数といったKPIは出てきません。
大切なのは、「なぜこの事業をやるのか」という存在意義(Why)を明確にすることです。

構想は経営層・創業者・経営企画部が中心になって描かれ、
企業のビジョンやブランドの方向性と深く関係します。


事業企画とは? ― 戦略方針を明確化する工程

事業企画とは、その構想を実現し、事業が成果を出すための戦略方針を明確化する工程である。

ここでは構想を実現させるために戦略を考えていきます。
市場を分析し、顧客を定め、競合との差別化を考え、投資に見合う成果を設計する。
つまり、構想を現実の事業として成立させるための道筋(How to succeed)を定める段階です。


デパート建設の例:事業企画フェーズ(簡易版)

  • エグゼクティブサマリー:駅前に地域密着型のファミリーデパートを建設し、街の活性化と収益拡大を両立する。
  • 前提条件・市場定義:郊外モールの台頭で市街地が衰退、再集客の余地あり。
  • 環境分析(PEST・3C・SWOT):交通利便性◎/競合減少傾向/地域のイベント需要が強み。
  • ビジネスコンセプト:「買い物・食事・娯楽を一日で完結できる、家族が集うデパート」。
  • 顧客の定義(セグメンテーション・ペルソナ・ターゲッティング):30〜40代の子育て世代ファミリーを中心に設定。
  • 価値の定義(ポジショニング):駅前立地+地域イベントによるアクセスと体験価値で差別化。
  • 実現施策(4P):家族向けフロア構成/手頃な価格帯/駅前立地/SNS+地域広報で訴求。
  • 顧客管理施策(CRM):会員アプリでポイント付与・イベント通知によるリピート促進。
  • ビジネスモデル:テナント賃料+駐車場収益+イベント協賛で安定運営。
  • 数値目標(KPI):年間売上200億円、平日来館者5,000人、休日1万人、平均滞在2時間。
  • 投資計画:初期投資50億円、2年で黒字化、5年で投資回収を目指す。

👉 この段階ではまだ「どう建てるか」は決まりません。
決まるのは「どこで成功を目指すか/どう成果を出すか」です。


事業企画フェーズの責任分担

項目主体目的成果物
エグゼクティブサマリー経営層/事業責任者事業の全体像と狙いを要約する企画概要書
前提条件・市場定義経営企画部市場環境と事業機会を明確化する市場定義書、業界レポート
環境分析(PEST・3C・SWOT)経営企画部/マーケ部外部・内部要因を分析し、成功要因を整理する分析レポート
ビジネスコンセプト設計経営層/マーケ部事業の方向性とコンセプトを定めるコンセプトペーパー
顧客の定義(セグメンテーション・ペルソナ・ターゲッティング)マーケ部主要顧客層を特定し、具体像を描く顧客定義書、ペルソナ資料
価値の定義(ポジショニング)マーケ部/事業責任者他社との差別化要因を明確にするポジショニングマップ
実現施策(商品・価格・流通チャネル・プロモーション)事業責任者/マーケ部戦略を実行するための具体施策を立案するマーケティング計画書
顧客管理施策(CRM)マーケ部/システム部顧客維持と再来店を促進する仕組みを設計するCRM施策計画書
ビジネスモデル経営層/事業責任者収益構造と持続可能な仕組みを定義するビジネスモデル図、収益計画
数値目標(KPI)経営層成功を測る指標を設定するKPIリスト、OKR
投資計画CFO/経営層投資額と回収期間を定義する投資計画書、ROI試算

👉 事業企画は“成功の道筋を描く”ところまでが責任範囲。
ここで定めた方針を、次の要件定義で「実現可能な形」に変えていきます。


要件定義とは? ― 構成要素を明確化する工程

要件定義とは、その戦略方針を実現するために必要な構成要素を明確化する工程である。

経営層が描いた戦略を、実際に動く仕組みに変換していく段階です。
要件定義は単なる“仕様書づくり”ではなく、
「戦略をどんな構成で実現するか」を定義する、設計前の最重要プロセスです。


デパート建設の例:要件定義フェーズ

  • 現状把握・課題定義
    • 市街地の人流データを分析し、商店街の空き店舗率や来客減少を把握。
    • 「家族で一日過ごせる場所がない」という課題を整理。
  • 顧客要件
    • ベビーカーがすれ違える通路幅(1.8m以上)
    • 各階に授乳室・オムツ替えスペース
    • 駐車場1,000台以上、EV充電対応
  • テナント要件
    • 飲食フロアには排気ダクト・給排水設備
    • スーパー用冷凍倉庫
    • アパレル用バックヤード
    • 各テナントの搬入・在庫スペースの最適化
  • 運営要件
    • 搬入専用エレベーターとスタッフ専用動線
    • 24時間監視・警備システム
    • 清掃・メンテナンスルートの確保
  • 顧客体験要件(CX)
    • 照明・音響・サイン計画を統一して快適な動線を設計
    • キッズスペースや休憩ラウンジを設置
    • 混雑時もスムーズに移動できる導線計画
  • 非機能要件
    • ピーク時来館1万人でも待ち時間30分以内
    • 停電時も最低限稼働(非常電源・エレベーター確保)
    • 防災基準は法令+独自基準を上回る水準
  • 優先度設定
    • MUST:駐車場1,000台・授乳室・耐震設計
    • WANT:屋上ガーデン・イベントホール
    • WON’T:映画館(今回は見送り)
  • コスト・スケジュール見積
    • 設備・建築・内装費を算出し、工期を12か月で想定
    • 予算とROI(投資回収計画)を照合

👉 この段階では「何を作るか」「どんな体験を提供するか」「どの水準で動かすか」を明確にします。
つまり、事業企画で描いた戦略方針を、構成要素のレベルまで具体化する工程です。


要件定義フェーズ(デパート建設でたとえる)

項目主体目的デパートでの具体例
1. 現状把握・課題定義プロジェクトマネージャー(PM)/建設企画担当現在の商業地の課題を整理し、何を改善するかを明確にする既存商店街の空き店舗率や来客数を調査し、課題を特定する
2. 利用者ヒアリングPM/現場担当者実際に使う人の声を集め、要望を具体化する買い物客・テナント・清掃スタッフ・警備員などにヒアリングを行う
3. 機能要件定義設計担当/施設管理者何を備えるか(施設・機能)を決める授乳室、エレベーター、エスカレーター、駐車場、案内システムなどを定義
4. 非機能要件定義技術責任者/インフラ担当性能・安全・運用性などの基準を定める耐震基準、防火設備、非常電源、ピーク時の混雑対応を設計
5. 設備・動線要件定義設計担当/運営担当設備の配置や人・物の流れを最適化する搬入口の位置、エレベーターの数、清掃動線などを決定
6. テナント要件定義営業部/テナント管理担当入居者が運営しやすい条件を設計する給排水、換気、倉庫スペース、営業時間などの要件を設定
7. 顧客体験要件(CX)定義マーケティング部/デザイン担当顧客が快適に利用できる体験を設計する通路幅、照明、音響、サインデザイン、キッズスペースなど
8. 優先度設定(MUST/WANT/WON’T)PM/経営層実現すべき要件の優先順位を決める「駐車場1000台」はMUST、「屋上ガーデン」はWANT などを整理
9. コスト・スケジュール見積PM/技術リーダー実現可能性と費用感を具体化する建設費・設備費・工期を見積もり、全体予算と照合する
10. 合意形成・承認全関係者全員の共通認識を作り、責任を明確化する要件書を経営層・現場・施工チームが承認し、着工へ進む

要件定義が難しい4つの理由(実務ベース)

① 要望が止まらない(スコープ肥大)

ヒアリングを進めるたびに「これも入れたい」「あれも必要だ」が増える。
機能を増やせば増やすほど、コスト・納期・品質が崩れる。

👉 必要なのは“選ぶ力”
事業企画で定めた戦略方針に沿って、MUST/WANT/WON’Tを明確に分ける。


② 曖昧なまま進めて手戻り地獄に陥る

定義が曖昧なまま開発に進むと、
「思ってたのと違う」「仕様を変えたい」と後から修正が発生。

👉 要件定義は“曖昧さを潰す作業”。
ここでの詰めが甘いと、後工程で爆発的なコストが発生する。


③ ステークホルダーの合意形成が難しい

経営層・現場・開発・外部パートナーがそれぞれ違う立場から要望を出すため、
誰の意見を優先すべきか が曖昧になりやすい。

👉 要件定義の本質は「技術文書」ではなく「合意文書」。
全員の“理解の一致”を作る調整力が求められる。


④ コスト・スケジュールの見積もりが不確実

「要件が確定していない」状態で見積もりを求められることが多い。
結果、楽観的に見積もって炎上するか、余裕を取りすぎて承認が下りないかのどちらかになる。

👉 要件定義の目的は、確定的な見積もりを出すことではなく、前提を明確にすること。
「この条件ならこの見積もり」という前提を整理して、透明性を確保するのが理想。


まとめると

No難しさの原因核となる課題対応のポイント
要望が止まらないスコープ肥大MUST/WANT/WON’Tを明確化
曖昧なまま進む手戻り・仕様変更定義の言語化とレビュー徹底
関係者の意見が分かれる合意形成の困難要件定義書=合意文書と捉える
見積もりが不確実コストと納期の不透明化前提条件を明示してリスクを共有

おわりに ― 理想を現実に変えるために

システム開発は“モノづくり”であり、
同時に、考え抜いた構想を形にする“知的な創造行為”です。

  • 構想で「理想の姿」を描き、
  • 事業企画で「成功の道筋」を設計し、
  • 要件定義で「現実の構成要素」を固める。

この3つの流れ(構想・事業企画・要件定義)を理解しておくだけで、
「何を作るか」だけでなく、「なぜそれを作るのか」「どう実現していくのか」が明確になります。

設計や開発は、そうした考えの上に成り立つ“実現のフェーズ”です。
デパート建設でいえば、設計図を引く前に「どんな街を作りたいか」を考える段階があるように、
システム開発もまず“構想・事業企画・要件定義”という土台を整えることが重要です。

それができていれば、完成したシステムは美しく、使いやすく、長く愛される。
それこそが、システム開発における本来の“モノづくり”の姿です。


コメント

タイトルとURLをコピーしました