working-with-architects について
エンジニアリングマネージャーがアーキテクトなどのシニア技術パートナーと協働するためのガイダンススキルです。責任範囲の整理や相談の準備を支援し、異なる組織モデルで早期に連携する方法を示します。
主な機能
- 01マネージャーとアーキテクトの責任整理
- 02技術相談の依頼内容を構成
- 03集中型と分散型のモデルを説明
- 04準備と早期連携を支援
活用シーン
- 01複雑なプロジェクトについて相談する準備
- 02アーキテクトの時間を確保する
- 03チーム間の意思決定の担当を明確化
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/working-with-architectsを入力して読み込まれたか確認します。
同梱ファイルreferences/sources.md
詳細
アーキテクトと協働する
始める前に
まず EM に関するコンテキストを確認します。.agents/em-context.md が存在する場合は、それを読みます。
.agents/em-context.md が存在しない場合は、詳しい助言をする前に、まず最低限のマネージャーのプロフィールを尋ね、保存します。役職／肩書き、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項を確認してください。
会話の中心となる特定の人物がいて、.agents/reports/[name].md が存在しない場合は、詳しい助言をする前に、まずその人物の最低限のプロフィールを尋ね、保存します。役職／レベル、在籍期間、強み、現在の課題または成長領域を確認してください。
その後、会話から長期的に有用な新しいコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新します。安定した事実やパターンを保存し、推測、一時的な不満、未解決の解釈は保存しないでください。
回答のスタイル
最初の回答は簡潔で、役に立つ内容にします。ユーザーが詳しい説明を求めない限り、フレームワーク全体を一度に提示しないでください。
基本方針：
- 可能性の高い診断または推奨事項を最初に述べる
- 不足しているコンテキストによって助言が変わる場合に限り、的を絞った質問を最大 2～3 個する
- 次の具体的なアクションを示し、必要に応じてマネージャーが使える正確な言い回しも提示する
- 関連するフレームワークに簡単に触れるが、すべての要素を説明しない
- まず直接的な回答をしたうえで、より詳しい説明もできると伝える
このスキルの使い方
- EM がアーキテクトとの関係で担う責任が不明 → 自分の役割を果たす
- プロジェクトでアーキテクトの時間を確保する必要がある → アーキテクト側の約束 — 遠慮せずに働きかける
- アーキテクトが関与する複雑なプロジェクトを開始しようとしている → 相談する前に
- チームとアーキテクチャ機能のどちらが意思決定するのか不明 → 2 つのアーキテクチャチームモデル
この内容は、他チームと連携するシニア以上のエンジニア（アーキテクト、スタッフエンジニア、プリンシパルエンジニア）に適用されます。肩書きは組織によって異なります。
回答の基本構成
アーキテクトやシニア技術パートナーについて支援する際は、責任の所在を明確にします。
- 状況： 助言、レビュー、意思決定、プロジェクトの停滞、またはアーキテクトの時間確保の依頼。
- EM の責任： 支援を求める前にマネージャーが担うべきこと。
- アーキテクトへの依頼： 必要な具体的な意見、意思決定、レビュー、またはエスカレーション。
- 準備： コンテキスト、制約、選択肢、意思決定の期限。
- 関係づくり： 功績を伝えること、フォローアップ、または期待値の見直し。
アーキテクトが明示的にデリバリーを担っていない限り、EM のプロジェクトのオーナーとして扱わないでください。
自分の役割を果たす
依頼への対応を遅らせない
アーキテクトから何かを求められた場合（セキュリティ更新、共有サービスのリファクタリング、新しいテスト手法など）は、迅速に対応してください。こうした依頼が本当に緊急であることはほとんどないため、対応を遅らせたくなりがちです。そうしないでください。
大きな副次的メリットとして、こうした取り組みを最初に実施するチームは、アーキテクトからより多くの支援やガイダンスを得られます。アーキテクトは、共有作業に迅速に取り組むチームに、より多くの時間をかけてくれます。
積極的に相談する
複雑な技術的なジレンマについては、通常なら関与を求めるほどではない小さなことでも、決定する前に意見を求めてください。早い段階から情報を共有しておけば、後の段階で支援してもらえる可能性が大幅に高まります。
功績を伝える
長期プロジェクトでは、実現を可能にした初期の支援を忘れたまま、完了してしまいがちです。終わる頃には、初期段階でアーキテクトから受けた重要なガイダンスを忘れていることもよくあります。
機能を発表する際は、アーキテクトの支援に触れ、本人に感謝を伝えてください。特に優れた働きをしてくれた場合は、その人のマネージャーにも知らせてください。
アーキテクト側の約束
自分のものとして責任を持つ — 忘れないでください
複雑なプロジェクトでは、アーキテクトが道筋を示すために、初期のインフラストラクチャやサンプルを作成することがあります。その初期段階が終われば、責任は完全にあなたにあります。アーキテクトの役割は、最善の方法で進められるよう支援することであり、問題が起きたときに責任を分担することではありません。
アーキテクトが関わった作業に、インシデントやミスの責任を押しつけたくなる誘惑には抵抗してください。あなたのプロジェクトです。
アーキテクトの時間を積極的に求める
アーキテクトの時間が自動的にあなたのチームに割り当てられることはありません。明確に声を上げる人が支援を得られます。
協力を求めるときは、次のことを行ってください。
- 必要な支援の範囲を定める
- なぜ必要なのか、また組織にどのようなメリットがあるのかを説明する（期限の迫ったプロジェクト、ほかのチームにも役立つ新しいテクノロジー、ミスの代償が大きいコードベースの重要な領域など）
- 自分の主張をしっかり伝える
より上級のチームリーダーが多くのリソースを得られるのは、自分の主張をよりうまく伝えるからです。練習を重ねれば上達します。
些細なことを押しつけない
何をすべきか、どう実行すべきかがはっきり分かったら、もうアーキテクトの手は必要ありません。次の重要なプロジェクトに進んでもらいましょう。この特権を濫用すると、関係を損ない、より難しい問題に充てるべき時間を無駄にします。
相談する前に
まず背景情報を集めましょう。アーキテクトがアーキテクチャ作業を始める際、最初に尋ねるのは次のことです。
- 問題について何が分かっていますか？
- ビジネス上、なぜ解決する必要があるのですか？
- いつまでに解決する必要がありますか？
この3つの質問への回答を用意しておきましょう。
2つのアーキテクチャチームモデル
集中型： アーキテクトがすべてのアーキテクチャ上の意思決定を行います。あなたは対象分野の専門家であり、アーキテクトは問題領域を理解するためにあなたに相談してから、解決策を設計します。あなたとアーキテクトの間で、緊密かつ継続的なコミュニケーションが必要です。
分散型： アーキテクトは、あなたのチーム向けの解決策をあなたが設計するのを支援します。アーキテクトは原則とテックレーダーを定めます。ガイドラインに従う限り、意思決定はあなたが行います。コミュニケーションの負担は軽くなりますが、あなたが主体となって物事を進め、積極的に連絡を取る必要があります。
どちらのモデルでも、早い段階から関わってもらいましょう。相談が遅すぎることが、最も大きな間違いです。すでに多くの作業が進んでいると、方向転換には大幅なやり直しが必要になったり、実現できなくなったりすることがあります。
さらに詳しく
ユーザーがフレームワークの由来を尋ねたり、このスキルのトピックについて詳しい背景情報を求めたりした場合は、references/sources.md を読んでください。
関連スキル
delegation— アーキテクトとの連携は、外部との協働のなかでも特に効果の高いものですinfluence— アーキテクトの時間を求めて自分の主張を伝えるには、より広いステークホルダーへの働きかけと同じスキルが必要ですmanaging-high-performers— アーキテクトがあなたの直属の部下である場合は、関係性も力学も異なります