「現場から次々と出てくる機能要望に振り回され、プロジェクト終盤で経営層から『思っていたのと違う』とちゃぶ台返しされないか不安です…」
ITシステムの開発やDX（デジタルトランスフォーメーション）推進の現場において、最も手戻りが大きく、深刻なトラブルの原因になりやすいのが「最上流での目的や背景の曖昧さ」です。
「最新のSFA（営業支援システム）を導入したのに、現場が入力してくれず営業プロセスが一向に改善しない」「現場の細かな要望をすべて詰め込んだ結果、予算が膨れ上がった上に使いづらいシステムが出来上がってしまった」「プロジェクト終盤に役員から『このシステムでどうやって売上が増えるのか』と問われ、返答に詰まってしまった」といった苦い経験を持つ方も多いのではないでしょうか。
これらの失敗の多くは、要件定義の第一関門である「事業要件定義（ビジネス要件定義）」が十分に詰め切れていないことに起因します。
事業要件定義とは、単なる「欲しい機能の一覧作り」ではありません。「事業におけるそのIT投資の意味を言語化し、利益を増やすシナリオを定義して、関係者全員で共有すること」こそがその本質です。
本記事では、事業要件定義の基本的な位置づけから、経営目標と日々の業務・機能を一気通貫でつなぐ「ゴール分析」、そしてプロジェクト終盤の「ちゃぶ台返し」を防ぐ「ステークホルダー分析」の実践ステップまで、具体例を交えて詳しく解説します。
- 事業要件定義（ビジネス要件）の本質：IT投資の意味と「利益を増やすシナリオ」の定義
- 要件定義の3階層（事業・業務・システム）における最上流としての役割と手戻り防止効果
- ゴール分析の3階層（ソフトゴール・ハードゴール・タスク/機能）と実践の4ステップ
- 利害関係者の4分類（ベースライン・サプライヤ・クライアント・サテライト）による網羅的洗い出し
- 期待値マトリクスの作成と「重要度×影響度（+5〜-5）」によるキーパーソン特定・合意形成アプローチ
事業要件定義（ビジネス要件）とは？IT投資の意味と成功シナリオを共有する大前提
まずは、事業要件定義とは何を定義する工程であり、どのようなゴールを目指すものなのか、その全体像を確認していきましょう。
事業要件定義の本質：IT投資の意味と「利益を増やすシナリオ」の定義
上の図「事業要件定義の全体像」に示されている通り、事業要件定義は発注側が提示するRFP（提案依頼書）や企画資料を起点としてスタートします。発注側と開発側（またはDX推進部門と事業部門）が綿密に対話・インタビューを重ねながら、「ゴール分析」と「ステークホルダー分析」という2つの重要手法を駆使して進めていきます。
この工程を通じて作り上げる主要な成果物は、以下の3点です。
- プロジェクトの目標：今回のIT投資を通じて、事業として何を達成したいのか（定性的なビジョンおよび定量的な達成基準）
- 業務の一覧：その目標を達成するために、現場でどのような業務プロセスを実行・改善するのか
- 要求の一覧：新業務を円滑に遂行するために、システムや組織に対して何を求めているのか
事業要件定義を一言で表現するならば、「事業におけるそのIT投資の意味を定義すること」です。
企業が何千万円、何億円という費用を投じてITシステムを導入したり改修したりするのは、システムを作ること自体が目的ではないはずです。システムを活用することで業務の無駄を省いてコストを削るか、あるいは顧客への提供価値を高めて売上を伸ばし、最終的に企業の「利益」を増やすことが真の目的です。
「このシステムが稼働すると、現場のどの業務がどう変わり、なぜ企業の利益が増加するのか」という利益創出のシナリオ（投資対効果のロジック）を論理的に言語化し、関係者間で目線を丁寧に合わせることこそが、事業要件定義の最も重要なミッションとなります。
発注側の責務と開発側・推進側の役割分担
事業要件定義を進める上で、あらかじめ認識しておくべき重要な原則があります。それは、「事業要件定義は、本来は発注側（事業部門やユーザー企業）が自ら完了させておくべき責務である」という点です。
「自社の事業をどう成長させたいのか」「どんな経営課題を解決したいのか」を一番よく知っているのは発注側自身です。しかし、実際のプロジェクト現場では、発注側自身も自社の課題を十分に言語化できていなかったり、関係者間で意見が割れていたりして、事業要件が曖昧なまま開発フェーズへ突入してしまうケースが後を絶ちません。
開発側（ITベンダーや情シス部門）の立場からすると、「事業要件の整理から請け負うと工数が膨らんで見積が高くなり、失注するのではないか」「顧客の業界や事業モデルに疎いため、コンサルのような提案は難しいのではないか」と躊躇してしまうこともあるでしょう。
しかし、この事業要件が曖昧なままプロジェクトを進めてしまうと、後続の業務要件定義やシステム設計の段階で必ず認識のズレが表面化し、深刻な手戻りや炎上を招くことになります。
だからこそ、発注側と開発側が「対立関係」や「単なる受発注の壁」を越え、対等なパートナーとして対話を重ねることが欠かせません。開発側はインタビューを通じて発注側の思考を整理し、不明瞭な部分を一緒に具体化していく姿勢（伴走型のアプローチ）が求められます。こうした事業視点を持った要件定義のスキルは、ITコンサルタントや事業会社の情シスリーダーとしての市場価値を飛躍的に高める武器にもなります。
なぜ事業要件定義が必要なのか？システム導入の形骸化と手戻りを防ぐ理由
要件定義という言葉は広く知られていますが、一口に「要件」と言ってもその階層は大きく3つに分かれます。なぜ、その中でも最上流に位置する「事業要件定義」がこれほど重視されるのでしょうか。
3つの要件定義における最上流の役割
上の図「要件定義編の進め方」に示されている通り、ITシステム開発の要件定義は以下の3つのフェーズが連動して進行します。
- 事業要件定義（最上流）：プロジェクトの目的、利益創出のシナリオ、ステークホルダーの期待値、対象業務の特定
- 業務要件定義（中流）：新業務の業務フロー（As-Is/To-Be）、担当者の役割分担、例外処理、業務ルールの明確化
- システム要件定義（下流）：業務要件を満たすためのIT製品選定、およびセキュリティ・稼働時間（サービスレベル）・レスポンス速度・データ保全といった「非機能要件」の定義（※具体的な画面レイアウト等は後続の基本設計フェーズで詳細化）
後続の業務要件定義やシステム要件定義の具体的な進め方については、以下の個別解説記事で詳しく解説しています。
これら3つの要件定義は、ピラミッドのような従属関係にあります。最上流である「事業要件（Why・What）」が定まるからこそ、それを実現するための「業務要件（Who・When・How）」が設計でき、最終的にそれを支える「システム要件（非機能要件・IT製品選定）」や設計へと落とし込むことができます。
もし土台となる事業要件がグラついていれば、どれほど美麗な業務フロー図を描き、どれほど堅牢なシステムを構築しても、最終的に「誰の役にも立たない、誰も使わないシステム」が完成してしまいます。事業要件を初期段階で強固に固めることこそが、プロジェクトの最大のリスクヘッジとなるのです。
粒度の細かい「機能要望」に振り回されないための羅針盤
要件定義の現場でよく起こるのが、「現場の担当者にヒアリングをしたら、要望が山のように出てきて収拾がつかない」という問題です。
現場のユーザーは、日々の自分の作業範囲しか見えていないことが多いため、「画面にこのボタンを付けてほしい」「この入力欄を自動補完してほしい」といった局所的な機能・タスクレベルの要求を次々に挙げてきます。しかし、それらの要望を鵜呑みにしてすべて実装しようとすると、開発コストと納期はあっという間に破綻します。
| 状態 | 事業要件が曖昧な場合 | 事業要件が明確な場合 |
|---|---|---|
| 個別要望への対応 | 声の大きい人の意見に流され、不要な機能まで次々と採用してしまう | 「その機能は上位の事業目標にどう貢献するか」を基準に、客観的に却下・見送りの判断ができる |
| 要件の抜け漏れ検証 | 現場から言われた機能しか作れず、目的達成に必要な必須機能を見落とす | 上位目標から逆算して、「この目標を達成するにはこの機能も足りないのでは」と積極提案できる |
| 終盤の評価・合意 | 完成後に「思っていた効果が出ない」と不満が噴出し、責任の押し付け合いになる | 当初合意した評価軸（ハードゴール）に基づき、客観的に成否と改善ポイントを振り返ることができる |
明確な事業要件は、プロジェクトに関わる全員が「何を採用し、何を捨てるべきか」を正しく判断するための不動の羅針盤（評価軸）として機能します。
プロジェクトの目標と要求を構造化する「ゴール分析」の進め方
では、具体的にどのようにしてプロジェクトの目標を構造化し、現場の要求と紐づけていけばよいのでしょうか。そのための極めて強力な手法が「ゴール分析」です。
ゴール分析を構成する3つの階層モデル
上の図「ゴール分析とは？」に示されている通り、ゴール分析ではプロジェクトの目的や要求を以下の3つの階層に分類して整理します。
- ソフトゴール（最上位：定性目標）： 定性で抽象度の高い目標です。「自社の漬物を通じて、人々の豊かで楽しい食生活に貢献する」「業界で最も信頼されるパートナーになる」といった、企業の経営理念や長期ビジョンがここに該当します。方向性を示す重要な旗印ですが、単体では「達成できたかどうか」を客観的に測定することが困難です。
- ハードゴール（中位：定量目標）： ソフトゴールの下に配置される、具体的かつ定量的な目標です。「2028年度までに年商◯◯億円を達成する」「営業リードタイムを現行の30日から15日へ半減させる」「顧客離脱率を5%以下に抑える」といった数値目標が該当します。達成可否が白黒で判定できるため、プロジェクトの成否を測る直接の評価軸となります。ハードゴールは必要に応じて複数階層にブレークダウンされます。
- タスク・機能（最下位：達成手段）： ハードゴールを達成するための具体的な実行手段やシステム機能です。「SFA（営業支援システム）を導入する」「活動計画の入力機能を作る」「進捗状況をリアルタイム集計するダッシュボードを開発する」といった要素がここに含まれます。
重要なポイントは、「発注側や現場ユーザーから上がってくる要求の9割以上は、この最下層の『タスク・機能』のレベルで語られる」という事実です。
「◯◯機能を作ってほしい」という現場の声だけを聞いて開発を始めてしまうと、その機能が本当に上位のハードゴール（売上増・コスト減）やソフトゴール（ビジョン実現）に寄与するのかが見抜けません。ゴール分析を行うことで、機能と上位ゴールとの「因果関係の鎖」を可視化することができるのです。
ゴール分析を実践する4つのステップ
ゴール分析を実際に進める際の手順は、以下の4ステップで展開します。
- ステップ①：導入対象の配置（真ん中から置く）：まずは今回のプロジェクトで導入・開発を検討している対象（例：SFA/CRMツールの導入、基幹システム刷新など）を中心の基準点として配置します。
- ステップ②：下位タスク・機能の配置（下へ展開）：現場へのヒアリングやRFPの要望事項から、「活動計画を入力したい」「商談レポートを出力したい」「顧客データを一元管理したい」といった具体的な要求やタスクを下に並べていきます。
- ステップ③：上位ゴールの配置（上へ展開）：「そもそもなぜその機能が必要なのか？」「それを実現してどうしたいのか？」を問いかけ、「営業プロセスの標準化」➔「営業成約率の向上」➔「年商◯◯億円の達成（ハードゴール）」➔「豊かな食生活への貢献（ソフトゴール）」へと、上位の目的を上に積み上げてつなぎます。
- ステップ④：階層・要素の視点を変えた過不足の検証（横へ展開）：上位ゴールと下位タスクがつながったら、注目する階層の視野を広げて不足している要素がないかを確認します。例えば「営業プロセスの標準化」を達成するためには、SFAツールの導入だけでなく「そもそも標準営業マニュアルの策定」が必要ではないか、あるいは「他部門の基幹連携」も必要ではないか、といった抜け漏れを洗い出します。
このように、上下左右に視野を往復させながらゴールツリーを組み立てることで、発注側と開発側の双方が「何のためのシステム開発なのか」をしっかり腹落ちさせることができます。
「ちゃぶ台返し」を防ぐステークホルダー分析と期待値マトリクスの作成
事業要件定義におけるもう一つの重要テーマが「ステークホルダー分析」です。どれほど明確なゴールを設定しても、関係者の利害やキーパーソンの思惑を見落としていると、プロジェクトの最終局面で「そんな話は聞いていない」「この仕様では承認できない」という致命的なちゃぶ台返しが発生します。
4つの視点によるステークホルダーの網羅的洗い出し
ステークホルダーを洗い出す際、多くの人が「システムを直接操作するエンドユーザー」だけに目を向けがちです。しかし、周囲への影響を捉えるためには、上の図に示された4つの視点で視野を広げる必要があります。
- ベースライン（直接の当事者）：システムを日常的に直接操作し、利害関係を持つ中核グループ（例：営業現場の担当者）
- サプライヤ（情報・資源の提供者）：ベースラインが業務を行うために必要な情報や支援を提供する関係者（例：商品マスタ管理部門、契約法務担当、情シスのインフラ担当）
- クライアント（価値の受け手）：ベースラインが製品・サービスや情報を提供する相手（例：取引先、小売店、顧客企業）
- サテライト（対話・連携パートナー）：ベースラインと情報を交換し、相互作用しながら協力する関係部署（例：マーケティング部、経営企画部、営業推進部）
食品メーカーA社がSFA（営業支援システム）を導入する場合を例に考えてみましょう。
直接の利用者である「営業組織（ベースライン）」だけでなく、商談で得られた顧客ニーズを新商品開発に活かしたい「マーケティング部（サテライト）」、商品コードや価格マスタを登録する「マスタ管理担当（サプライヤ）」、そして商談相手である「小売店（クライアント）」まで網羅的に関係者をマッピングします。こうすることで、後から「マスタ連携が考慮されていない」「マーケティングに必要なデータ項目が足りない」といったトラブルが起きるのを防ぐことができます。
立場ごとの期待値・要求の把握とマトリクス整理
関係者を洗い出したら、それぞれのステークホルダーが「今回のプロジェクトに何を期待しているのか（何を達成したいのか、何を避けたいのか）」をインタビューを通じて把握します。
当然ながら、立場や役割が異なれば期待値（要求）も大きく異なります。
- 現場の営業担当者の期待値：「外出先からスマホで手軽に入力したい」「入力項目を極力減らして直帰したい」「他メンバーの成功事例を簡単に検索したい」
- 営業マネージャーの期待値：「部下の商談状況や案件確度をひと目で把握したい」「予算未達になりそうな案件を早期に発見してテコ入れしたい」「蓄積したデータから売上向上の示唆を得たい」
これらの期待値を業務および要求と紐づけて構造化したものが「期待値マトリクス」です。
上の図のように、「顧客訪問（業務）➔ 外出先からの短時間入力（要求）➔ 営業担当者（ステークホルダー）」「進捗確認（業務）➔ 部下の状況把握・示唆の抽出（要求）➔ 営業マネージャー（ステークホルダー）」というように、業務・要求・関係者を1枚の表にマッピングすることで、誰のどの要求を満たすための機能なのかが極めてクリアになります。
重要度×影響度の2軸によるキーパーソンの特定と合意形成
プロジェクトに関わるすべての関係者の要求を100%均等に叶えることは、予算とスケジュールの制約上不可能です。そこで、関係者を「重要度（業務上の関与度・必要度）」と「影響度（意思決定力・決定権）」の2軸で評価し、キーパーソンを特定します。
この2軸マップにおいて、アプローチは大きく2つに分かれます。
- 重要度が高い人（現場のキーパーソン）： 日々の実務に深く関わり、その業務がないと現場が回らない担当者です。この人たちには、後続の「業務要件定義」において丁寧に詳細インタビューを実施し、業務フローや例外パターンを一緒に作り込んでいきます。
- 影響度が高い人（意思決定のキーパーソン・決裁者）： 役員、事業部長、情シス部長など、最終的な予算や方針の決定権を持つ人物です。この人たちに対しては、日々の細かい設計に巻き込む必要はありませんが、要件定義の節目（マイルストーン）ごとに必ず方針を報告し、事前の合意形成（根回し）を丁寧に行います。ベンダーが直接報告してもよいですし、発注側のプロジェクトリーダーを通じて社内報告してもらう形でも構いません。
影響度の高い人物を放置したまま開発を進めると、最終承認の場で「聞いていない」「現場の都合ばかりで経営方針と合っていない」と一発で覆されてしまいます。節目での合意形成こそが、最大の防御策となります。
グラデーション評価（+5〜-5）による柔軟な優先順位づけ
ステークホルダーの影響度や重要度を評価する際、「影響がある／ない」といった単純な二元論（0か1か）で判断すると、現場の実態を見誤りやすくなります。
上の図のように、「+5から-5までのグラデーション（尺度）」を持たせてプロットすることをおすすめします。
| 評価軸 | 高評価（+5側）のイメージ | 低評価・中立（0〜-5側）のイメージ |
|---|---|---|
| 影響度 （決定力） |
・最終決定権を持つ決裁者（+5） ・意思決定メンバーの一人（+3） |
・意見は聞かれるが決定権はない（0） ・プロジェクトに反対・無関心（-3〜-5） |
| 重要度 （要求の必要度） |
・この要求が満たされないと業務が停止する（+5） ・日常業務で極めて重要（+3） |
・あったら便利だが必須ではない（0〜+1） ・自身の業務には直接関係しない（-3〜-5） |
幅を持たせたスコアリングを行うことで、限られた開発工数の中で「どの要求を最優先で満たすべきか」「誰の合意を最優先で取り付けるべきか」を客観的・合理的に判断できるようになります。
現場と経営をつなぐ事業要件定義を成功させる組織づくりのポイント
事業要件定義を机上のフレームワークで終わらせず、実際の成果につなげるための実践的なポイントをまとめます。
「言われた通りに作る」から「対話を通じて本質を引き出す」共創姿勢へ
要件定義が失敗する最大の原因は、発注側が「開発会社に丸投げする」、あるいは開発側が「言われた機能だけをそのまま作る」という思考停止の受発注関係に陥ることです。
現場のユーザーは必ずしもITの専門家ではないため、自分の真の困りごとを正確な技術用語で言語化できるとは限りません。だからこそ、開発側やDX推進リーダーは「なぜその機能が欲しいのですか？」「その作業で一番ストレスを感じている瞬間はどこですか？」と寄り添い、対話を通じて言葉の裏にある本質的な課題（暗黙知）を引き出す姿勢が不可欠です。
年齢や役職、発注・受注の垣根を越え、「事業をより良くするための対等な共創チーム」として信頼関係を築くことが、プロジェクト成功の第一歩となります。
後続の「業務要件定義」へのスムーズな橋渡し
事業要件定義で「プロジェクト目標」「対象業務の一覧」「ステークホルダーの期待値と優先順位」が明確になったら、いよいよ次のステージである「業務要件定義」へとバトンをつなぎます。
業務要件定義では、事業要件定義で定めた方針に基づき、以下のような具体的な業務フローと運用ルールの詳細化を進めていきます。
- As-Is（現行業務）とTo-Be（新業務）の業務フロー図作成（スイムレーン図等を用いた役割の可視化）
- 業務イベントごとの発生トリガー、入力・出力情報、処理手順の定義
- 例外処理・エラー発生時のリカバリー運用の策定
- データ項目とマスタ管理ルールの詳細設計
事業要件定義とは、事業におけるIT投資の意味（利益を増やすシナリオ）を言語化し、関係者全員で共有する最上流の要件定義です。
- 目的の共有：RFPからゴール分析・ステークホルダー分析を経て、プロジェクト目標と評価軸を確立する
- ゴール分析の3階層：ソフトゴール（定性）➔ ハードゴール（定量）➔ タスク/機能（手段）を一気通貫でつなぐ
- ちゃぶ台返しの防止：4視点のステークホルダー洗い出しと期待値マトリクス、重要度×影響度の2軸でキーパーソンと合意形成を図る
まずは、今回のシステム導入が「どの業務を変え、どのように企業の利益を増やすのか」という基本シナリオの言語化から、事業要件定義をスタートさせてみましょう。
要件定義全体の進め方や失敗を防ぐ思考法、後続フェーズ（業務要件定義・システム要件定義）については、以下の記事で詳しく解説しています。
【DX人材育成・学習ロードマップ】
全社的な教育設計やご自身の学習計画の参考として、本サイトでは3つの役割に応じた学習ロードマップを公開しています。
経営層・管理職向け
DXの定義や必要性、組織変革を支えるスポンサーシップを最短で学びます。
一般社員向け（DXリテラシー標準 DSS-L準拠）
DXリテラシー標準(DSS-L)に準拠し、デジタル技術の基礎知識や変革マインドを身につけ、身近な業務改善や自社課題の発見へ主体的に関わる土台を作ります。
ビジネスアーキテクト・推進リーダー向け
既存事業の効率化から新規事業の開拓までをリードするため、プロジェクト推進法やチェンジマネジメント手法などを体得します。
コメント