Ownership Map：アーキテクチャ全体の責任者を可視化する
シンプルに聞こえるのに、ほとんどのエンジニアリング組織を悩ませる問いがあります。このサービスの責任者は誰か？
誰が作ったかではありません。誰が最後にコミットしたかでもありません。今現在誰が責任を持っているのか——可用性、技術的負債、APIコントラクト、セキュリティ態勢について。深夜2時に何かが壊れたとき、誰に通知が行くのか？新しいチームが連携する必要があるとき、誰に話せばいいのか？
小さな会社では、みんなが知っています。成長中の会社では、答えはあっという間に曖昧になります。チームが分割され、サービスが増え、人が異動する。組織図はある事を言い、コードベースは別の事を言い、アーキテクチャ図は何も言わない——なぜなら、オーナーシップは最初から図の一部ではなかったからです。
私たちはこれを解決するためにOwnership Mapを作りました。
概要
Ownership Mapは、Archylのグローバルアーキテクチャビューの新しいタブです。組織内のすべてのチームとユーザーを、所有するC4要素の数に応じたサイズのインタラクティブなバブルとして表示します。バブルにマウスを合わせると、接続されたオーナーへの依存関係の線が表示されます。クリックすると、そのチームが責任を持つすべてのシステム、コンテナ、コンポーネントを詳しく見ることができます。
これは「誰が何の責任者か」に対する、リアルタイムでビジュアルな回答です——すでに管理しているC4モデルから構築されています。
オーナーシップの問題はアーキテクチャの問題
ほとんどのチームは、スプレッドシートやWikiページ、Slackチャンネルの説明でオーナーシップを管理しています。これらの情報は数週間で古くなります。サービスが引き継がれ、チームが再編され、インターンのサイドプロジェクトが本番インフラになる——そしてオーナーシップのドキュメントは更新されません。誰もその存在を覚えていないからです。
これが重要なのは、オーナーシップが単なる事務的な記録管理ではないからです。それはアーキテクチャ上のシグナルです。あるチームが40のサービスを所有し、別のチームが3つしか所有していないなら、それはキャパシティの問題です。2つのチームのサービスが深く結合しているのにお互いに話し合わないなら、それはカップリングの問題です。アーキテクチャの30%にオーナーがいないなら、それはリスクの問題です。
Ownership Mapは、これらのシグナルを設計段階から可視化します。
仕組み
オーナーシップの割り当て
すべてのC4要素——システム、コンテナ、コンポーネント——は、1つ以上のチームまたはユーザーに割り当てることができます。プロジェクト図の要素詳細パネルからオーナーシップを設定するか、AIを活用したディスカバリープロセスから自動的に設定できます。
要素はチームオーナーと個人のユーザーオーナーを同時に持つことができます。あるシステムは「Platform Engineering」チームに所属しつつ、特定のテックリードが個人の責任者として割り当てられるといった具合です。
バブルビュー
概要画面では、すべてのオーナーが力指向レイアウトで色付きの円として表示されます。レイアウトは配置がスマートで、依存関係のあるチームは近くに配置され、組織の実際のトポロジーを反映した自然なクラスタリングが生まれます。
各バブルには以下が表示されます：
- チームまたはユーザーの名前
- アイコンまたはアバター（アップロード済みの場合）
- 所有する要素の総数
- C4レベル別の内訳（システム、コンテナ、コンポーネント）
依存関係の線
ここからが面白いところです。異なるチームが所有する要素間にC4の関係が存在する場合、Ownership Mapはそれらのオーナー間に依存関係の線を描きます。任意のバブルにマウスを合わせると、依存関係の線がアニメーションで表示され、どの他のチームと結合しているか、何本の関係が接続しているかが分かります。
これにより、従来の組織図では見えないチーム間の依存関係が明らかになります。フロントエンドチームのBFFレイヤーが4つの異なるバックエンドチームが所有する15の異なるエンドポイントに依存していれば、そのカップリングが即座に見えます。同じドメインに属しているにもかかわらず2つのチーム間に依存関係がゼロであれば、それも調査する価値があります。
詳細ビュー
任意のバブルをクリックすると、滑らかな円形のリビールアニメーションでズームインします。詳細ビューには以下が表示されます：
- チームのアイコン、名前、タイプを含むヒーローヘッダー
- 要素総数、システム、コンテナ、コンポーネントの統計カード——それぞれフィルターとしてクリック可能
- すべての所有要素のカードグリッド（C4レベル別にグループ化）
- 同じ要素の責任を共有する他のチームを示す共同オーナーシップバッジ
- 完全なコンテキストのための要素の説明とプロジェクト名
Escapeキーを押すか、戻るボタンをクリックすると概要画面に戻ります。
カバレッジの追跡
ページヘッダーにはオーナーシップカバレッジの割合が表示されます。これは、少なくとも1人のオーナーがいる要素の全要素に対する比率です。カバレッジはC4レベル別に分類されるので、システムは適切に割り当てられているがコンポーネントが放置されていることが分かります。
トグルで無所属の要素を別のグレーのバブルとして表示でき、カバレッジのギャップが即座に可視化されます。
検索
検索バーはすべてにわたるフルテキスト検索として機能します：オーナー名、要素名、プロジェクト名。「payments」と入力すれば、チーム名に「payments」が含まれていなくても、決済関連のものを所有するすべてのチームが表示されます。
何が変わるか
Before：オーナーシップは暗黙知
- 「たぶんPaymentsチームが担当してると思うけど、Sarahに確認して」
- Wikiページは第2四半期から更新されていない
- 新しいエンジニアは誰に聞けばいいか把握するのに数日かかる
- インシデント対応は「このサービスは誰の？」で10分始まる
After：オーナーシップは可視的で追跡可能
- すべての要素に明確なオーナーがいる（または可視化されたギャップがある）
- チーム間の依存関係が自動的に浮き彫りになる
- 新しいエンジニアは初日からオーナーシップの全体像を把握できる
- カバレッジ率が測定可能なメンテナンス目標を生み出す
ワークフローに組み込み済み
Ownership Mapは単体のツールではなく、Archyl全体に織り込まれています：
AI Chat —— 「API Gatewayの責任者は？」や「オーナーのいないコンポーネントが最も多いチームは？」といった質問ができます。アーキテクチャチャットにオーナーシップデータがコンテキストとして含まれるようになり、責任に関する質問に直接回答できます。
MCP Server —— ArchylのMCPサーバーはget_ownership_mapツールを公開しており、AIコーディングアシスタント（Claude Code、Cursorなど）が作業中にオーナーシップデータを照会できます。「このサービスについて誰に相談すればいい？」と聞けば、エディタを離れずに答えが得られます。
DORA Metrics —— オーナーシップとDORAメトリクスを組み合わせて、どのチームが最も速くデリバリーしているか、どのチームの障害率が最も高いか、どこの復旧時間が最も長いかを把握できます。オーナーシップ + デリバリーパフォーマンス = アクション可能なチームヘルスデータ。
Release Management —— どのチームのサービスが最も頻繁にデプロイされているか、どのリリースがステージングで止まっているかを確認できます。オーナーシップのコンテキストにより、リリース追跡がより意味のあるものになります。
はじめ方
すでにArchylをお使いなら、Ownership Mapはグローバルアーキテクチャビューで今すぐ利用できます。
- グローバルアーキテクチャ -> Ownershipタブに移動
- 図の詳細パネルからC4要素にオーナーを割り当て
- バブルが現れ、依存関係の線が形成されるのを確認
- カバレッジ目標を設定し、進捗を追跡
デモを使用している場合、オーナーシップデータは5つのドメインチーム（Platform Engineering、Payments Squad、Security & Fraud、Frontend & Mobile、Data & Analytics）であらかじめ設定されているので、すぐに完全な体験を試すことができます。
Ownership Mapは無料プランを含むすべてのプランで利用可能です。
関連記事：