C4システムコンテキスト図の書き方：予約サービスの例

C4のシステムコンテキスト図は、「これは何をするシステムか」「誰が使うか」「どの外部システムと関わるか」を示す図です。実装の詳細を知らなくても、まずシステムの境界を理解できるようにします。

チームでアーキテクチャ図を共同作成するときも、最初に決めるのはその境界です。ここでは、顧客とサービス調整担当者が使う予約プラットフォームを例にします。画面、データベース、デプロイ先のインフラは、この図には含めません。

予約プラットフォームの責任範囲を決める

C4モデルのシステムコンテキスト図の説明では、一つのソフトウェアシステムと、それに直接関わる人や外部システムを扱います。全体を俯瞰する図なので、プロトコルや内部コンポーネントより、利用者と責任範囲が重要です。

顧客がサービスの利用日時を予約し、調整担当者が予約枠を管理するプラットフォームを考えます。このプラットフォームは、外部の決済サービスに支払い処理を依頼し、メールサービスに通知の配信を依頼し、外部のカレンダーシステムに予約の更新情報を送ります。

中央の枠には、予約プラットフォーム：空き状況、予約、予約変更を管理すると、一文で説明を書きます。技術的な位置づけだけを示す「バックエンド」というラベルより、システムの目的が伝わります。

顧客向けアプリケーションと調整担当者向けアプリケーションは、同じシステムの一部として境界の内側に含めます。一方、独立して運営される決済、メール、カレンダーのサービスは含めません。連携用のコードを管理していても、接続先のサービス自体を管理しているとは限らないため、責任を分けて示します。

枠を配置する前に関係を一覧にする

まず、要素と関係を短い一覧にします。図の見栄えを整えるために、重要な利用者や依存先が抜け落ちるのを防げます。対象システムとどう関わるかを説明できる要素だけを追加しましょう。

最初の二つは、人から予約プラットフォームに向かう関係です。残りの三つは、プラットフォームから外部システムに向かいます。ラベルは、その方向でのやり取りを説明するもので、すべてのリクエストと応答を描くためのものではありません。

たとえば「支払い処理を依頼する」という線で、プラットフォームが決済サービスを利用する関係を示せます。応答のたびに別の線を加える必要はありません。ただし、独立した非同期の決済通知が設計上の議論で重要なら、その関係を明示してラベルを付けます。「データ」とだけ書いた両方向の矢印で、何がつながっているかを曖昧にしないようにします。

この図に含めないものを決める

次に、追加したくなりやすい要素を検討します。データベースはアプリケーションに重要ですが、それだけで外部システムになるわけではありません。この例の予約データベースはプラットフォームの内部要素なので、より詳細な図で扱います。

会計システムの例が重要なのは、矢印によって未実装の接続があるように見えてしまうためです。担当者が情報を書き出し、別のシステムに手入力することと、予約プラットフォームが直接送信することは違います。現状を正確に説明し、計画中の連携と既存の連携を区別します。

将来の構成を描くこと自体は問題ありません。ただし、タイトルで将来案だと分かるようにします。稼働中の決済連携と、提案段階のカレンダー連携を、説明なしに同じ図へ混在させてはいけません。

会議の後でも伝わるラベルにする

C4の表記ガイドでは、分かりやすい要素の説明、関係のラベル、凡例を重視しています。見た目の表現は選べますが、灰色の枠が「外部」「任意」「未選択」のどれを表すのか、読者に推測させないようにします。

図には「予約プラットフォーム：システムコンテキスト：試験導入案」のように具体的なタイトルを付けます。人、対象システム、外部システムを区別する小さな凡例も添えましょう。用語は周囲の資料にそろえます。プロダクトチームが「サービス調整担当者」と呼んでいる役割を「管理者」に変えると、別の責任範囲を持つ人だと受け取られる可能性があります。

説明は、別の資料を開かなくても読める長さにします。「メールサービス：予約確認と変更通知を配信する」と書けば、事業者のロゴだけより意味が伝わります。ロゴは現在の提供元を示せても、そのシステムが必要な理由までは説明しません。

すべての線を時系列の手順として扱わないことも重要です。システムコンテキスト図が示すのは関係であり、予約処理の厳密な実行順序ではありません。「支払いは予約確定より前か」という問いには、この図の注記を長くするのではなく、動作を説明する別の図を使います。

Boardmixで予約システムのコンテキストを描く

Boardmixのキャンバスの中央に予約プラットフォームを配置します。片側に二つの利用者役割、反対側に三つの外部システムを置き、関係のラベルを書く余白を確保します。基本図形とコネクタで十分です。意味を伝えるのは特別なサーバーアイコンではなく、名前、説明、境界です。

一覧にした五つの関係を、一つずつ追加します。「顧客が予約プラットフォームで予約を作成・変更する」のように、始点から終点に向けて声に出して読んでみましょう。文として分かりにくいなら、次の矢印を増やす前にラベルを直します。

図の横には、範囲について未決定のことを書き留める場所を設けます。たとえば「調整担当者がカレンダーを直接更新するのか、それともプラットフォームが更新情報を送るのか」という問いです。両方の経路が確認済みであるかのように描いて、不確実な点を片づけないようにします。

Boardmixでボードを開き、自分たちのシステムの周囲にある関係を整理してみましょう。利用者の業務に詳しい人と、システムの依存関係に詳しい人を交えて考えると、同じ図でも異なる抜けに気づけます。

最初の図の意味を保ちながら詳細化する

コンテキストについて合意できたら、C4のコンテナ図で、予約プラットフォーム内部のアプリケーションやデータストアを示せます。ここでいう「コンテナ」はC4の抽象概念であり、Dockerなどのコンテナ実行環境を使うという意味ではありません。

次の図では、一つだったプラットフォームの枠を、顧客向けアプリケーション、調整担当者向けアプリケーション、アプリケーションサービス、予約データストアに展開するかもしれません。外部の決済、メール、カレンダーのシステム名は同じままにします。二枚目は一枚目を詳しくするもので、突然、別のプロダクト境界を持ち込むものではありません。

カレンダーをプラットフォームの内側と外側のどちらに置くかで合意できないなら、まずその問いに向き合います。責任範囲が未決定のままでは、図を詳しくしても解決しません。境界を明確にしてから、次の問いを説明する図を選びましょう。