working-with-pm

PM との協働

始める前に

まず、EM に関するコンテキストを確認してください。.agents/em-context.md が存在する場合は、読み込んでください。

.agents/em-context.md が存在しない場合は、詳しいアドバイスをする前に、まず簡潔なマネージャーのプロフィールを尋ね、保存してください。プロフィールには、役職・肩書き、チームの規模、チームのミッションまたは担当領域、現在の課題または優先事項を含めます。

特定の人物が会話の中心であり、.agents/reports/[name].md が存在しない場合は、詳しいアドバイスをする前に、まずその人物の簡潔なプロフィールを尋ね、保存してください。プロフィールには、役職・職位、在籍期間、強み、現在の課題または成長領域を含めます。

会話の中で後から長期的に役立つ新たなコンテキストが明らかになった場合は、.agents/em-context.md または .agents/reports/[name].md を自動的に更新してください。推測、一時的な不満、未解決の解釈ではなく、安定した事実や傾向を保存してください。

回答のスタイル

最初の回答は簡潔で役に立つものにしてください。ユーザーが詳しい説明を求めていない限り、フレームワーク全体を一度に提示しないでください。

基本方針：

• 可能性の高い診断または推奨事項を最初に伝える
• 不足しているコンテキストによってアドバイスが変わる場合に限り、的を絞った質問を最大 2～3 個する
• 次に取るべき具体的な行動を示し、役立つ場合はマネージャーが使える正確な言い回しも提示する
• 関連するフレームワークに簡潔に触れるが、すべての要素を説明しない
• 直接的な回答の後で、さらに詳しい説明もできることを伝える

---

このスキルの使い方

• 現在の PM と EM の関係性を診断する → 3 つの関係パターン
• 本当のパートナーシップを築こうとする → 真のパートナーシップとは + 実現するための 3 つのヒント
• PM との具体的な意見の相違に対処する → 「私にとって重要です」カード
• PM が技術的な仕事を理解していない、または尊重していない → ヒント 1：PM が技術に詳しくなるよう支援する
• エンジニアを顧客やプロダクトの成果に近づける → チームにプロダクト視点を育てる
• EM と PM の間で担当範囲が曖昧 → 経験豊富な PM からのヒント

---

デフォルトの回答形式

PM と EM の関係について支援する際は、まず関係性のパターンを特定してください。

1. パターンの見立て： PM 主導、エンジニアリング主導、見せかけのバランス、真のパートナーシップ。
2. 具体的な摩擦： ロードマップ、見積もり、品質、顧客の状況、担当範囲、信頼。
3. EM の対応： プロダクト視点、技術的な内容の翻訳、境界線の設定、エスカレーション、責任分担のエクササイズ。
4. 会話の台本： 問題を明確に伝えつつ、関係性を損なわない言い回し。
5. 共有の仕組み： 定期的な同期、意思決定ログ、顧客との接点、責任分担。

PM が緊急性を高めている場合は managing-urgency に、問題がロードマップのトレードオフである場合は roadmap-planning に関連付けてください。

---

3 つの関係パターン

PM 主導のチーム

PM が一人で顧客と話し、一人でロードマップを決め、どれくらいの時間がかかるかをあなたに指示します。あなたは指示を実行するだけです。

しばらくすると、実際の問題が表面化します。

• メンバーが燃え尽きます
• チームの誰も、なぜそれを作っているのかを理解していないため、先を見越した対応ができず、誤った状況に備えてしまいます
• コードベースの質が低下します。テストがなく、コードレビューが表面的で、手早く雑な解決策が増えます

もっと時間をかけ、より高い基準を求めればよいと思うかもしれません。しかし、この状況を経験した人なら、その現実を知っています。PM が最終決定者である場合、異議を唱えるのは非常に困難です。

エンジニアリング主導のチーム

優先順位、スコープ、見積もりをあなたが決めます。リファクタリングについても、一方的に判断します。上位レベルの設計や見積もりが異議を唱えられることはありません。

その結果、ステークホルダーや顧客を失望させることになり、エンジニアリングの本来の目的を見失います。PM が役割を果たせていない場合は、時には深呼吸をして、自分で PM の仕事を担わなければならないこともあります。

「見せかけのバランス」が取れたチーム

それぞれが自分の領域を持っています。技術的負債に充てる時間には手を付けず、プロダクトロードマップにも手を付けません。表面上は問題ないように見えます。

しかし、長期的にはうまくいきません。より良いモデルは、二人が合意した単一のロードマップです。そこでは、すべての技術的な取り組みに、プロダクトに関する根拠があります。

---

真のパートナーシップとは

真のパートナーシップは、双方がチームだけでなく、顧客だけでなく、他のステークホルダーだけでなく、会社の長期的な成功のために正しい判断をしたいと考えるときに実現します。

世界最高のレストランは、シェフとレストラン経営者が一緒に、全体の利益を考えて判断を下すことで運営されていました。エンジニアリングチームも同じです。

---

実現するための3つのヒント

1. PMが技術に詳しくなるようサポートする

PMに技術的なバックグラウンドがない場合、知識を身につけてもらうのはあなたの役目です。技術用語ではなく、実例を使って技術的な取り組みのメリットを説明しましょう。

たとえば、次のように言うのではなく、

「Javaのモノリスではなく、新しいサービスにバックエンドを作る必要があります。マイクロサービスへの分割を始めることが決まったからです。」

次のように伝えましょう。

「共有コードではなく、チームが所有する新しいサービスにロジックを実装したいと考えています。そうすれば、他のチームに足を引っ張られることなく、今後の要件にもっと迅速に対応できます。」

2. プロダクト志向のEMになる

ビジネスを気にかけないという選択肢はありません。

• CEOが全社ミーティングで話すときは、耳を傾けましょう
• 上場企業に勤めているなら、投資家向け説明会の内容を確認しましょう
• 顧客との会話に参加し、可能であれば顧客を訪問しましょう

ビジネスを理解し、顧客や他部門との距離が近くなると、技術的な卓越性だけに没頭することは難しくなります。また、PMの立場に共感し、判断の背景にある理由を理解して、より説得力を持って異議を唱えられるようになります。

3. 「私にとって重要です」というカードを使う

すべてのことに合意できるわけではありません。何度も切ってカードを乱用できるのは、どちらも同じです。しかし、ある問題を本当に重視している側の意見を通せる、ということです。

一方が自分の立場を譲る姿勢は、二人の信頼関係を築く助けになります。時間が経つにつれて、本当に大切なことについては双方が遠慮なく強く主張できる関係が生まれます。

---

経験豊富なPMからのヒント

• 自分たちの領域を作る：会社がどれほど機能不全に陥っていても、あなたとPM（そしてデザイナー）は、自分たちの卓越した環境を作ることができます。PMには役割における一定の裁量があり、二人の良好な関係が多くの障害を乗り越える力になります。
• 共感する：PMがどれほどのプレッシャーを受けているかは、あなたにはわかりません。あなたにとっては「あと2週間必要です」でも、PMは怒った人々への対応に追われています。
• 責任について明確に話し合う：考えられるすべての責任を書き出し、EM↔PMのグラフ上でどちらの領域に当たるかを双方が示しましょう。意見の違いに驚くはずです。

---

チームにプロダクト視点を取り入れる

真の PM–EM パートナーになるための最も効果的な方法の一つは、開発の前後に、エンジニアが顧客や利用状況データに触れる機会を増やすことです。

開発前 — 毎回、シンプルな質問をします：

• これは誰のためのものですか？
• どのような課題を解決しようとしていますか？
• うまくいっているかどうかを、どうすれば判断できますか？

これらは PM だけがする質問ではありません。エンジニアなら誰でも、自分が開発するものについて答えられるべき質問です。答えられないなら、仕様はまだ完成していません。

リリースと定着。 コードが本番環境に入った時点で、機能が完成するわけではありません。ユーザーが実際に使うようになって初めて完成です。リリース（コードを書く、デプロイする、告知する）は楽しい部分です。一方、定着（導入、実際の効果）は地味で技術的な作業ではありませんが、重要なのはこちらです。リリース時に、1～2週間後を目安に、開発を担当したエンジニアとデータを確認する時間を予定に入れましょう。この習慣だけで、エンジニアの仕事への考え方が変わります。

ユーザーの実際の行動を理解する。 多くの PM はセッション録画ツール（FullStory、Hotjar、Posthog）を利用できます。エンジニアも録画を見るのを妨げるものはありません。まずは毎月30分の「ムービータイム」を設け、チームが担当する機能に関連する録画を見てみましょう。ユーザーがしていると思っていることと、実際にしていることとのギャップには、いつも驚かされます。

エンジニアを顧客との会話に参加させる。 組織を再編せずにできる、実践的な方法を3つ紹介します：

• 既存の通話に同席する。 PM、営業、または CS が実施する顧客発見の通話に、発言せずに参加させてもらえないか尋ねましょう。話を遮らないと約束します。四半期に1回でも通話に参加すれば、エンジニアの仕事への考え方が変わります。
• サポートチケットの後を追う。 チームが最近修正した問題を経験したユーザーを見つけ、連絡します：「これを修正したエンジニアです。問題が解決したか確認し、ワークフローについてもう少し理解するため、15分ほどお時間をいただけませんか。」 顧客は、思っている以上に快く応じてくれます。
• CS と連携してパワーユーザーを見つける。 CS に、積極的に利用している顧客を紹介してもらいましょう。「X を開発したチームのエンジニアです。お客様にとってより良いものにする方法を学ぶため、15分ほどお話しできませんか。」

どのような顧客との会話でも役立つ3つの質問：

• 「現在、X をどのように解決していますか？」（背景）
• 「この新しいフローをどのように使うか、見せていただけますか？」（使いやすさ）
• 「現在のワークフローで最も不満に感じる点は何ですか？」（課題の検証）

リリース後 — 利用状況データを確認する。 何が使われましたか？何が使われませんでしたか？バグやベロシティだけでなく、振り返りでもこうした内容を共有しましょう。

技術的負債をビジネスの観点で説明する。 エンジニアが「この API には年間4万ドルのコストがかかり、上位3社の顧客からの苦情の原因になっています」と言えるようになれば、「このコードは整理されていません」と言う場合よりも、ロードマップの議論で信頼される意見を出せるようになります。単にスコープに反対する実装担当者ではなくなるのです。

---

さらに詳しく

このスキルで扱うフレームワークの出典や、トピックの詳細をユーザーから尋ねられた場合は、references/sources.mdを読んでください。

---

関連スキル

• roadmap-planning — 真のパートナーシップから、共有する単一のロードマップが生まれます
• managing-urgency — 作り出された緊急性の多くは、PM–EM 間の認識のずれに端を発します
• written-communication — PM やステークホルダーに伝わる形で、技術的な作業を説明する方法
• influence — 部門横断の場でエンジニアリングの優先事項を提案する方法