Claude Codeの共有コンテキストをチーム単位で集約するCockpit

estieが取った戦略は「複数プロダクト運営時に、知識管理の単位をリポジトリからチームに変える」というものだ。40個のリポジトリを持つチームでは、リポジトリを切り替えるたびに「このコードの前提は何か」「このプロダクトの運用ルールは何か」を思い出す作業が生産性を奪う。Cockpitという統一コンテキストを作り、system-map.yamlでプロダクト・リポジトリ・Jiraの関係を宣言的に記述した。つまり、Claudeに「どこを見ればいいか」という地図を一度渡しておくことで、以降は効率的に情報を引き出せるようにした。

ビジネスサイド（営業・カスタマーサクセス）からの「この仕様はどうなっているのか」という質問が、これまでエンジニアに集中していた。Cockpitを入り口にすれば、Claudeが一次回答を作り、それをエンジニアが確認するフローになる。逆転だ。知識のオーナーも「エンジニアが知るべき」という前提をやめて、「顧客に最も近い人が持つべき」という原則にした。顧客セグメントや業務構造に関する知識は、日常的に顧客と対話する営業やCSの方が、エンジニアより正解に近いのは当たり前だ。

ただし、このアプローチには難しさもある。索引が実態とずれた瞬間に全体の信頼性が崩れる。存在しないリポジトリを案内したり、廃止された仕様を回答したりするCockpitは、何もない状態より危険だ。また、コードとナレッジを別リポジトリで管理するため、実装変更と文書更新を同じPullRequestで完結できない。だからこそ、変更されやすい実装の詳細はCode側をSource of Truthにし、Cockpitには道標だけを置く境界線が決定的に重要になる。複数プロダクトを小さいチームで回すなら、知識管理のルール作りと実行体制の方が、技術選定より大事だ。