【PM必見】要件定義の「認識ズレ」を防ぐ最強の武器｜システムコンテキスト図の書き方と実践サンプル
「え、そのデータ、うちのシステムが持つの？」
「外部システムとの連携範囲が、思っていたのと全然違う……」
システム開発の現場で、要件定義の終盤になってから、このような「認識の食い違い」に肝を冷やした経験はありませんか？
複雑なシステムであればあるほど、最初に「どこからどこまでが自分たちの守備範囲か」という境界線を明確にすることが重要です。今回は、そのための最もシンプルで強力なツールである「システムコンテキストダイアグラム（コンテキスト図）」について、現場ですぐに使える実践的な書き方を解説します。
システムコンテキスト図とは？
システムコンテキスト図とは、データフロー図（DFD: Data Flow Diagram）の最上位（レベル0）にあたる図のことです。
開発対象となる「システム」を一つのプロセス（円）として中央に置き、その周囲にある外部の実体（人、組織、他のシステム）との間で、どのようなデータをやり取りするかを一枚の絵にまとめたものです。
いわば、システムの「外の世界とのインターフェース一覧」を可視化した地図と言えます。
データフロー図を構成する4つのアイテム
コンテキスト図は、以下の4つの要素で構成されます。これらを「最も高い視点」から配置していくのがポイントです。
| アイテム | 表し方（記号） | 説明・役割 |
|---|---|---|
| プロセス |  | データの加工や機能を表します。コンテキスト図ではシステムそのものを指し、内部の詳細はあえて書きません。 |
| 外部実体 |  | システムの外部にある「人」「組織」「他システム」です。データの発生源、または最終的な行き先（アクターや外部APIなど）になります。 |
| データストア |  | データの保管場所です。システムが参照・更新するデータを示しますが、コンテキスト図では省略することもあります。 |
| データフロー |  | データの流れる方向です。やり取りされる「情報の名前」を記述します。「処理名」ではないのがポイントです。 |
PMがコンテキスト図を「最強の武器」と呼ぶ理由
なぜ、PMはこのシンプルな図を重視すべきなのでしょうか。それは、この図が「スコープ（責任範囲）」の合意形成において最大の威力を発揮するからです。
PMが得られる3つのメリット
- スコープクリープの防止: 境界線を明確に引くことで、「それは範囲外だと思っていた」という後出しの要求を論理的に防げます。
- ステークホルダーとの共通言語: 技術に詳しくない顧客とも「何が起きるか」を直感的に共有でき、最短で承認を得られます。
- 外部依存関係の早期特定: 外部システムや他部署との接点が可視化されるため、インターフェース調整や先行手配を前倒しでき、遅延リスクを回避できます。
現場での失敗の多くは、詳細な画面やDB設計に早く入りすぎることです。まずはコンテキスト図で全体像を握り、「境界線」にハンコをもらうことが、プロジェクトを成功させる定石です。
【サンプル】システムコンテキスト図（レベル0）
コンテキスト図は最上位の図なので、あまり細かく書きすぎないのがコツです。システムと関連する人物や組織を境界線で繋ぎ、その間を流れるデータをすべて記述します。
作成の3ステップ
- 対象システムを中心に置く: ◯を一つ書き、システム名を記入します。
- 「外の世界」を書き出す: システムに関わる人物、組織、外部システム（外部実体）を周囲に配置します。
- データフローをつなぐ: アイテム間を流れるデータをすべて矢印で記述します。
【サンプル】データフロー図（レベル1）
コンテキスト図で全体像を合意したら、次はシステム内部の「深掘り」を行います。レベル0の「◯（システム）」を、具体的な機能プロセスに分解したものが「レベル1」です。
レベル1の構成例（注文管理システムの場合）
- 機能プロセス: 受注処理、出荷処理、納品処理などの具体的な機能に分解。
- データストア: 注文データ、在庫データ、納品データなど、システム内部で管理する情報を追加。
- 詳細なフロー: 「取引先」から「受注処理」へ注文情報が入り、「在庫データ」を確認して「出荷処理」へ繋ぐ、といった具体的なデータの流れを描きます。
レベル0とレベル1の整合性を保つコツ
詳細化する際に最も重要なのは、「レベル0で引いた矢印（データフロー）が、レベル1でも漏れなく描かれていること」です。
- フローを消さない: 詳細化に集中するあまり、外部とのやり取りを消してしまわないよう注意しましょう。
- 段階的な詳細化: サブシステムへの分解 → 具体的な処理機能への分解、という手順を踏むことで、設計の整合性を保ちながら共通理解を深めることができます。
| システム コンテキスト ダイアグラム （データフロー図 レベル0） |  |
| データフロー図 レベル1 |  |
実務で役立つアドバイス：失敗を防ぐポイント
ユースケース図との使い分け
- ユースケース図: 「誰（人）」がシステムを使って「何をするか（振る舞い）」に焦点。
- コンテキスト図: システムが「どんな情報」を「どこ」とやり取りするか（データの境界線）に焦点。
操作感を議論する前に、まずコンテキスト図で「データの出入り」を確定させるのが、手戻りを防ぐ近道です。
現場で陥りやすい「落とし穴」
- 処理名を書いてしまう: 矢印には「出荷する」ではなく「出荷指示」などの名詞（データ名）を書くようにしましょう。
- 内部DBを外部実体に書く: あくまでシステムの「外」にあるものだけを四角（□）で書きます。
まとめ：境界線を引くことが成功への第一歩
システムコンテキスト図は、一見すると「当たり前」のことを書いているように見えます。しかし、その「当たり前」を可視化し、関係者全員で共有することこそが、プロジェクトを成功に導く第一歩です。
要件定義のチェックリスト
- [ ] すべての外部システム・アクターが網羅されているか？
- [ ] システムの「外」にあるデータと「中」にあるデータが明確か？
- [ ] レベル0のデータフローはレベル1と整合しているか？
次に読むべきおすすめ記事
システム全体の「情報の境界線」が見えたら、次は具体的な「ユーザーの振る舞い」や「スケジュール」の整理に進みましょう。
- [ユースケース図の書き方｜現場で迷わないアクター定義のコツ] ユーザーがシステムを通じてどのような価値を得るのかを可視化します。
- [PDM（プレシデンスダイアグラム法）実践ガイド] タスクの依存関係を整理して、遅延のない現実的なスケジュールを組み立てましょう。
- [PERT/CPMによるクリティカルパス特定と見積もり術] プロジェクトのデッドラインを明確にし、根拠のある納期回答を実現します。
