はじめに
ネットワーク構成図を描くとき、リソース間の矢印の向きで悩んだことはありませんか？「AがBにデータを取りに行くからA→B？」「BがAにデータを提供するからB→A？」
正解があることではないかもしれませんが、私が考える 「ネットワーク構成図における矢印の向きのベストプラクティス」について書いてみたいと思います。結論から言うと、私は「処理や情報のやり取りの論理的な方向」 を重視して矢印を描くことをおすすめしています。
1. 基本は「きっかけを作る側」から「働きかけられる側」へ
多くのシステム連携において、あるリソースが別のリソースに対して「何かしてほしい」と働きかけることから処理が始まります。この 「働きかけの起点」 を矢印の始点とするのが、最も自然で分かりやすいと考えています。
例：Webサーバーがデータベースからデータを取得するケース
- 実際の挙動: WebサーバーがSQLクエリをデータベースに送り、データベースがその結果をWebサーバーに返します。
- 矢印の向き: Webサーバー → データベース
なぜなら、この一連の処理のきっかけを作っているのはWebサーバーだからです。Webサーバーが「このデータが欲しい！」とデータベースに要求し、それに対してデータベースが応答している、という関係性を表現しています。データベースが勝手にWebサーバーにデータを送りつけるわけではありませんよね。
2. Pub/Subシステムの場合：「情報の論理的な流れ」を重視
Pub/Sub（Publish/Subscribe）システムは、非同期なメッセージングのパターンです。ここで矢印をどう描くか、ポーリングの実装がある場合に悩む方もいるかもしれません。
例：パブリッシャーがイベントを発行し、サブスクライバーがそれを受け取るケース
- 実際の挙動:
- プッシュ型: パブリッシャーがイベントを メッセージブローカー（またはキュー、トピック） に発行し、ブローカーがサブスクライバーにイベントを通知（プッシュ）します。
- ポーリング型（プル型）: パブリッシャーがイベントをメッセージブローカーに発行し、サブスクライバーが定期的にブローカーに「新しいイベントある？」と問い合わせ（ポーリング）て取得します。
- 矢印の向き: パブリッシャー → メッセージブローカー → サブスクライバー
たとえサブスクライバーがポーリングという 「手段」でイベントをブローカーから取得していたとしても、「イベント」という情報の発生源はあくまでパブリッシャー です。パブリッシャーがイベントを「提供」し、ブローカーを介してサブスクライバーがそれを「受け取る」という、情報の論理的な流れは変わりません。
この矢印の向きにすることで、「パブリッシャーがイベントを生成し、それをブローカーを通じてサブスクライバーが購読している」という、システムの役割と情報の関係性が直感的に伝わります。
3. 応答の矢印は省略する!図は「最小限」で「抽象化」を意識
私がネットワーク構成図を描く上で特に意識しているのは、「意味が伝わる最小限の情報だけを描く」ことです。そのため、矢印は「働きかけや情報の提供」の方向にのみ描き、その応答（レスポンス）については原則として省略します。
たとえば、Webサーバーがデータベースにクエリを投げ、データベースが結果を返す際、「Webサーバー → データベース」の矢印は描きますが、「データベース → Webサーバー」という結果返却の矢印は描きません。なぜなら、その応答は要求に対する当然の結果であり、明示的に描かなくても理解できるからです。
過剰な情報量を図に詰め込むと、かえって何が重要なのかが分かりにくくなってしまいます。図の目的は、複雑なシステムを図としてシンプルに表現し、一目で全体の構造や主要な連携を把握できるようにすることです。
常に「この矢印がなくても意味は伝わるか？」や「これはこの図で本当に表現すべき情報か？」と自問自答しながら、省略できるところは省略し、抽象化できるところは抽象化することを心がけています。これにより、本当に伝えたいメッセージが際立ち、理解しやすい構成図になります。
まとめ：矢印は「誰が主導し、何が提供されるか」を表現する
ネットワーク構成図における矢印は、単なる物理的な通信の方向だけでなく、リソース間の論理的な依存関係や、処理・情報の主導権を表現する重要な要素です。
「きっかけを作る側が矢印の始点」という原則は、Webサーバーとデータベースの例のように「要求」がきっかけとなる場合も、Pub/Subの例のように「情報提供」がきっかけとなる場合も、一貫して適用できる考え方です。
もし矢印の方向に迷う方がいましたら、この考え方で矢印を描くことを意識してみてください。今後の参考になれば幸いです。
Discussion