はじめに
システムアイ Advent Calendar 2025 を担当します。
ここ数年で目まぐるしくAIが充実しているので技術寄りなものをテーマにしようかとも考えたのですが、今回は ビジネス要件分析 をテーマにしようと思います。
【背景】
昨年の話になりますが、新規プロジェクトの要件定義フェーズにて見積もりのためにビジネス要件分析をする機会が多かったんです。
そんな分析結果を可視化するためにドキュメントを作成したりしますが、後工程の基本設計工程にて顧客との認識齟齬が多かったり要件漏れがあって手戻りが発生したりと苦い経験をしました。
要件定義フェーズの中でプロジェクト成功の鍵となる ビジネス要件分析 にフォーカスを充てて振り返りたいと考えました。
【読者ターゲット】
- これから上流工程に挑戦するエンジニア
- ビジネス要件分析に苦戦しているエンジニア
1.ビジネス要件分析の目的と開発工程における役割
ビジネス要件分析は要件定義工程の中で行う顧客からの要求に対して分析作業になります。
ただ単に顧客の要求をリストアップすることではありません。
プロジェクトの根幹にある ビジネス上の課題を特定し、その解決によって得られる「成功の定義」を明確 にする、最も重要な超上流工程の活動となります。
上流工程とビジネス要件分析との関連性
| 工程 | 主な活動 | ビジネス要件分析の関連性 |
|---|---|---|
| 企画 | - ビジネス構想、システム化の動機の立案。 - 実現性と費用対効果の検討。 |
ここで「解決すべきビジネス上の課題」を明確化。ビジネス要件分析は、 この課題を具体的な目標や成果（KGI/KPI）に落とし込み、プロジェクトのスコープ（範囲）を確定させるために行う。 |
| 要件定義 | - 業務要件、ユーザー要件、システム要件の洗い出しと定義。 - 要件の優先順位付けと合意形成。 |
ビジネス要件分析の結果が、この工程で定義するすべての要件の「出発点」!! ビジネス要件（最上位の目標）に基づき、ユーザー要件（誰が何をしたいか） へとブレイクダウン。 |
| 基本設計 | - 画面レイアウト設計、ユーザーインターフェースやシステム連携など、外部仕様の設計。 | 基本設計は、要件定義で固まったビジネス要件とユーザー要件を 「どう実現するか」という技術的な設計に入るため、ビジネス要件分析は完了している ことが前提 |
2. ビジネス要件分析で失敗に陥りやすい落とし穴
- スコープクリープ (要求をyesマンで聞いているうちに知らぬ間に開発スコープが膨大になっていくこと)
- 「言ったつもり」「聞いたつもり」の認識の齟齬
- ユーザーや現場の視点不足
プロジェクトの失敗の要因を振り返った時、要件定義フェーズを深掘りした際に上述のような原因を挙げられることをよく耳にします。
上流工程では人と人が意識を合わせるため認識をすり合わせる作業が本当に大変です。
齟齬を小さくするために口頭で言ったことを目に見える形で残すことが本当に重要なのです。
そのために面倒なドキュメントの作成に力を注ぐべきだと考えます。
3. 力を注ぐべきドキュメント作成
要件定義工程で作成すべきドキュメントは多岐にわたりますが、まずは業務分析をし、その結果を構造的に可視化することがプロジェクト成功の鍵を握るものだと私は考えます。
ただし、単純にドキュメントを作成すれば良いわけではありません。プロジェクトのルールに従ってできあがっただけの成果物はただの 「なんとなく」 の成果物になってしまいます。
なぜ文章だけのドキュメントは「認識の齟齬」を生むのでしょうか？それは、「人によって解釈が揺れるから」です。 これを防ぐには、業務を「機能」「手順」「構造」という3つの側面から構造的に可視化し、それらを連動させることが不可欠です。
図同時の繋がり を意識するために必ず作成すべきドキュメントは以下の３つになります。
- ユースケース図
- アクティビティ図
- オブジェクト図
このユースケース図、アクティビティ図、オブジェクト図の3つをセットで用いることで、要件定義における 「3つの質問」 に漏れなく答える、堅牢な構造を築くことができます。
| 質問（本質的な役割） | 担当するモデリング図 | 定義する要件 |
|---|---|---|
| WHAT（何ができるか？） | 1. ユースケース図 | システムの機能スコープ（機能要件） |
| HOW（どのように実行するか？） | 2. アクティビティ図 | 業務プロセスと運用フロー |
| WHO/WHAT（何を扱うか？） | 3. オブジェクト図 | システムが扱うデータ構造とビジネスルール |
ちなみに図を描く時はテキストベースで簡単に描けるmermaid やPlantUML で描くことをお勧めします。上図はmermaidで描いたものです。
🔑 3つの図の連動が「モレ・ヌケ」を防ぐ
この3つの図は独立しているのではなく、連動しています。
- ユースケース図で定義した「機能（WHAT）」が、
- アクティビティ図で具体的な「利用手順（HOW）」として分解され、
- その手順の中で扱う情報がオブジェクト図の「データ構造（WHO/WHAT）」として定義されます
特に、機能要件（ユースケース）とデータ構造（オブジェクト）を同時に考えることで、「この機能に必要なデータが定義されていない」といった要件のモレや整合性の問題を上流工程で発見しやすくなります。
最後に
本稿では要件定義フェーズのビジネス要件分析作業の中のドキュメント作成にフォーカスを当てて重要性を説いてきました。
それを過去に「なんとなく」で作成していても成功につながらないことを説きました。
重要なポイントを再度まとめます。
- ユースケース図、アクティビティ図、オブジェクト図 の3つのモデリング図は、それぞれが WHAT（機能）、HOW（手順）、WHO/WHAT（データ） という異なる側面を定義し、連動することで要件のモレ・ヌケを防ぎます
- ドキュメントの質は、曖昧さをどれだけ排除できるかで決まります。「Why-What-Howの分離」と「ドメイン用語の統一」を徹底しましょう
- そして最も大切なのは、ドキュメントが すべての関係者間の「合意」と「信頼」 の証である、という本質を忘れないことです
要件定義は、システムの土台を作る最も重要なフェーズです。ここで作成するドキュメントは、単なる作業の記録ではなく、プロジェクトの未来を決定づける羅針盤となります。
この記事でご紹介した知識が、あなたが「なんとなく」から卒業し、自信をもってステークホルダーと対話できる、質の高いドキュメントを作成するための一助となれば幸いです。
さらに深く学びたい方へ
- 今回紹介した手法をもっと深く実践したい方には１つUdemy講座をお勧めします。今回の記事を書くにあたって勉強させていただきました。
【超実践】ビジネス要件分析・基本設計・詳細設計をやり抜く実践ワーク講座(Udemy)