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