Nothing close enough? Start from a blank mind map → Describe it in one paragraph.
How to use a mind map template.
- 01中央のシステム名を決める
中央にシステム名またはアプリケーション名を配置します。ここが、他のすべてが枝分かれするルートノードになります。
- 02上位コンポーネントを特定する
フロントエンド、バックエンド、データベース、外部連携、インフラなど、主要なコンポーネント、サービス、レイヤーを列挙します。これらが第1階層の枝になります。
- 03各コンポーネントを細分化する
主要コンポーネントごとに、モジュール、機能、サブサービスを説明します。AIが適切な深さまでツリーを展開します。
- 04主要な依存関係と連携を示す
どのコンポーネントが相互に依存しているか、外部サービスと連携しているかをAIに伝えます。クロスリンクは注記やコネクタのラベルとして追加できます。
- 05チームと共有する
マインドマップをPNGまたはSVGで書き出すか、リンクをSlackのメッセージ、Confluenceページ、アーキテクチャレビュー文書に貼り付けます。
Questions about mind map templates
アーキテクチャ図ではなくマインドマップを使うべきなのはいつですか？
初期段階のアイデア整理、オンボーディング用の概要、簡単な共有にはマインドマップが適しています。詳細な設計判断、APIコントラクト、インフラ仕様には、正式なアーキテクチャ図（C4、UML）を使いましょう。
システム構成マインドマップでサービス間の依存関係を示せますか？
はい。ただし、マインドマップは依存関係グラフよりも階層構造の表現に向いています。枝をまたぐ接続や注記で依存関係を示すこともできますが、複雑なネットワークには別の依存関係図が適しています。
マイクロサービスアーキテクチャをマインドマップで表すには？
中央にシステム名を置き、ユーザー、決済、在庫などのドメインごとに枝分かれさせます。各ドメインの下にサービスを並べ、APIゲートウェイ、メッセージバス、オブザーバビリティなどの共有インフラ用の枝を追加します。
システム構成マインドマップはエンジニア以外にも役立ちますか？
はい。プロダクトマネージャー、テクニカルライター、QAエンジニアは、コードやアーキテクチャ決定記録を読まなくても開発チームの構築内容を把握できるため、システム構成マインドマップを活用しています。
システム構成マインドマップはどの程度詳しくすべきですか？
多くの用途では、システム → コンポーネント → モジュールの3階層を目安にしましょう。4階層を超えると、明確さがあまり増えない一方で、図が読みにくくなります。