influence

影響力

始める前に

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

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

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

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

回答のスタイル

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

基本方針：

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

---

このスキルの使い方

• 今後の会話や会議で使える具体的な戦術が必要 → 5 つの手法（状況に合うものを選ぶ）
• 予想される反論や抵抗に直面している → 懸念にラベルを付ける
• 相手が提案に本気で向き合っていない → 「そのとおりです」を引き出す
• 人員増強の要求が却下された、または行き詰まっている → 人員増強の獲得：適切なレイヤーで主張する
• 長期的な影響力を築き、真剣に受け止められたい → ポジショニングの 3 つのレベル
• そもそも社内政治に関わるべきか迷っている → スキルとしての社内政治
• 人間関係における「与える」と「引き出す」の基本的な考え方 → ギバー／マッチャー／テイカー

---

EM として、あなたは常に人を説得しています。経営陣にプロジェクトの承認を求め、リーダーシップに追加リソースを求め、直属の部下にタスクを引き受けてもらい、他チームの協力を同僚に求め、採用候補者に入社してもらい、昇進審査会で賛成してもらいます。挙げればきりがありません。

エンジニアリングマネージャーに特に有効な 5 つの手法を紹介します。

---

回答の基本構成

影響力に関する相談では、ステークホルダー計画を作成してください。

1. 意思決定の目標： ユーザーが何を変えたいのか、承認を得たいのか、または信じてもらいたいのか。
2. ステークホルダーの整理： 誰の合意が必要か、誰が阻止できるか、誰には情報共有だけでよいか。
3. 最適な影響力の行使方法： 該当する手法を選び、それが適している理由を説明する。
4. メッセージ／台本： 次の会話や文書での依頼に使う言い回し。
5. リスク： 社内政治や人間関係の面で裏目に出る可能性があること。

人員増強を求めている場合は、人員を求める主張を始める前に、課題とアプローチについて合意が得られているかを確認してください。

---

1. 根回し（根を回る）

大きな木を移植するために、移動の前に根を一本ずつ丁寧にほぐしておく、日本の園芸技法です。

使う場面： 評価調整の評価を得るときや、同じ会議に複数の関係者が集まる場で、取り組みを推進するとき。

進め方： 本会議の前に、主要な関係者と 1 対 1 で会います。経験と影響力のある人を選びます。それぞれの人が重視するものに合わせて主張を調整します。ある人は技術的な卓越性、別の人は処理能力、さらに別の人はビジネスへの影響を重視するかもしれません。懸念を早めに聞き出し、対処します。本会議が始まる頃には、すでに支持を築いており、議論で意見が対立する可能性も大幅に低くなっています。

---

2. おとり価格

マーケティング手法のひとつです。3つの選択肢を提示し、そのうちひとつをおとりにすることで、望む選択肢が明らかに最適に見えるようにします。

使用する場面： 人員増強の申請、他チームへの協力依頼。

人員増強での使い方： 小・中・大の3つの選択肢を提示し、それぞれ異なる結果を、関係者が重視する観点（スピード、品質、範囲）で評価します。実際に望んでいる選択肢が、他の選択肢と比べて最もお得に見えるように設計します。

逆の使い方： 他チームのマネージャーに協力を依頼するときは、最小の選択肢を実際に必要としている内容にします。そうすれば、相手が承諾しやすくなります。

---

3. 逆心理

望んでいることとは逆のことを提案し、相手が本当に望んでいることをしたくなるようにします。

使用する場面： 有力候補者との採用面談、新しいアプローチを試すことに抵抗があるエンジニア。

採用での使い方： 候補者があなたのチームに入るべきではない、本当の理由を列挙します。これにより、課題に引かれ、自分の力を証明したいと考える人、つまりまさにあなたが求めている人を惹きつけます。

例：「担当領域を守りたい、ひとつの役割だけを担いたいという方は、EngProdに加わらないでください。」

---

4. LMDTFY（こちらで決めておきます）

逆委任です。自分で決定を下したうえで、異議があれば相手が決定権を取り戻せると伝えます。「沈黙は同意です。」

使用する場面： 上司への働きかけ（意思決定を任せてもらう）、部下にリスクの低い判断を任せるとき。

上司に対して： 「この採用を最終決定するつもりです。懸念があればお知らせください。なければ、このまま進めます。」これを続けることで、特定の種類の意思決定について、上司があなたの判断を信頼するようになります。

部下に対して： 意思決定を前に進める方法を教えつつ、監督できる状態を保ちます。「私の勤務時間中にこのリリースをデプロイするつもりです。異議があればメッセージを残してください。」

---

5. 偶然の出会いを仕掛ける

難しい話し合いに適した状況を作るために、意図的に「偶然」を仕掛けます。

使用する場面： 正式な会議では実現しそうにないものの、率直な話し合いが必要なチーム間の摩擦。

方法： 相手がいつ、どこに非公式な場でいるかを調べ、そこに自分も居合わせるようにします。非公式な場では警戒心が和らぎ、予定された会議ではできないような率直な対話が可能になります。成果を保証するものでも、選択を強制するものでもありません。適切な話し合いが実現する可能性を最大限に高めます。

---

スキルとしての政治力

エンジニアリングにおける「政治」は、評判の悪い言葉です。しかし、その意味を取り戻す価値があります。

ここでいう政治とは、実現したいことを実際に実現させることです。それぞれの関係者が何を重視しているかを理解すること。相手に合わせて会話の切り口を変える方法を知ること。力ずくではなく、摩擦を最小限に抑えて抵抗を乗り越えることです。

凡庸なEMは政治を疎みます。有能なEMは政治力を身につけます。このスキル自体に善悪はなく、良い仕事を進めるためにも、悪い仕事を進めるためにも使えます。良い仕事を進めるために活用することが、あなたの役目です。

---

ギバー／マッチャー／テイカー

Adam Grantの著書『Give and Take』によると、人が助け合いや協力に取り組む姿勢は、次の3つに分けられます。

• ギバーは、見返りを期待せずに貢献します
• マッチャーは、見返りに助けてもらえると期待するときに手を貸します
• テイカーは、人間関係から何を得られるかに注目します

直感に反する発見があります。ギバーは最も成績が低い人たちにも、最も高い人たちにも多く見られます。多くの業界では、搾取されるまで与え続けるギバーが、最下層の大半を占めます。一方で、最上層にもギバーが多くいます。それには2つの理由があります。

1. ギバーは、複雑な問題に継続的に関わることになります（人々が助けを求めるため）。その結果、最も速く学べます
2. ギバーが何かを必要とするとき、人々はこぞって助けに集まります。ギバーが誠実な信頼関係を築いているからです

ギバーになりましょう。搾取的な関係には境界線を引きつつ、まずは惜しみなく助ける姿勢を持ちましょう。

---

懸念に名前を付ける

Never Split the Difference（Voss）より：相手が異議を唱える前に、自分からその懸念を言葉にします。

「なぜ今この話が出てきたのかと、気になっているのではないでしょうか。」 「すでに予定が詰まっている四半期に、作業範囲が増えることを懸念されているかもしれません。」 「これが高くつくように聞こえるのは分かっています。」

懸念に名前を付けると、それを和らげられます。言葉にされていない不安を言い当てられると、人は理解されていると感じます。その結果、抵抗が弱まり、こちらが実際に伝えようとしていることに耳を傾けてもらいやすくなります。懸念に名前を付けず、相手に持ち出されてから対応すると、こちらは弁明する立場になります。先に名前を付けておけば、すでに同じ側に立てます。

この手法は、人員増強についての話し合いや、アーキテクチャの提案など、相手が反対する理由を持っている何かを求める場面で特に効果的です。

ただし、注意が必要です。懸念の言い当て方は正確でなければなりません。誤った言い当て方（相手が実際には担当の問題を懸念しているのに、「これにはリスクがあると思われているのではないでしょうか」と言うなど）は、摩擦を減らすどころか生み出してしまいます。確信が持てないときは、「これについて懸念があるのは分かっています」のように、曖昧な表現にとどめましょう。

---

「そのとおりです」を引き出す。「あなたの言うとおりです」ではなく

Never Split the Difference（Voss）より：この二つの返答には、決定的な違いがあります。

**「あなたの言うとおりです」**は、議論ではあなたの勝ちです。話を終わらせるために、望みどおりに言っておきますという意味です。これは心からの同意ではなく、屈服を示します。本当の変化につながることはほとんどありません。

**「そのとおりです」**は、自分の状況をあまりにも正確に要約してくれたので、理解してもらえたと感じますという意味です。心から話を聞いてもらえたと感じたときに返ってくる言葉であり、相手が説得に応じるきっかけになります。

そう言ってもらうには、相手が自分の状況について話していることに耳を傾け、それを正確に要約して返します。相手が思わず同意してしまうほどにです。単なる言い換えではありません。相手が大切にしていること、心配していること、達成しようとしていることを、的確に言葉にするのです。

「つまり、今これに投資すると第3四半期の柔軟性が失われること、そして第3四半期のロードマップには、チームが現実的に対応できる量をすでに超える作業が盛り込まれていることが懸念なのですね。」

相手が「そのとおりです」と言ったときこそ、提案について本格的に話し合う準備が整ったときです。

---

人員を増やすには：適切なレイヤーで議論する

人員増強の申請の多くは、内容が間違っているからではなく、議論するレイヤーが適切でないために失敗します。本当の意見の相違は、もっと大きな問題にあるのに、採用するかどうかを話し合っているのです。

Will Larsonの合意形成の階層に沿って、次の順に進めましょう。

1. 問題について合意できていますか？ 例：「インシデントが多すぎて、開発者の生産性とユーザーの信頼が損なわれています。」経営陣がこの問題の捉え方を共有していなければ、人員増強をどれだけ正当化しても通りません。
2. 大まかなアプローチについて合意できていますか？ 例：「テストカバレッジとオンコール用ツールの改善に投資すべきです。」相手が採用ではなくプロセスの変更を解決策だと考えているなら、まだ認識が一致していません。
3. 現在、チームが適切に実行できていると合意できますか？ インシデントの長期的な傾向、テストカバレッジの推移、開発者アンケートのデータなどの指標を示しましょう。現在のチームに対応能力がないと相手が考えているなら、同じ体制を増やすことが解決策だとは思われません。
4. そのうえで、人員増強を求めます。 ここまで来て初めて、具体的な申請が通りやすくなります。

人員増強の申請が却下されたら、実際にどのレイヤーで意見が食い違っているのかを見極めましょう。意見の相違がレイヤー1にあるのに、レイヤー4でさらに強く主張しても、全員の時間を浪費し、信頼を損なうだけです。

---

ポジショニングの3つのレベル

あなたとチームが人々の心の中でどのように位置づけられているかによって、人員の確保、スケジュールの柔軟性、評価の結果、チーム間の協力など、必要なものを求める際の摩擦の大きさが決まります。

多くのEMは、課題を明確にし、チームを擁護し、期待値を下げることで、リーダーに自分たちの事情を説明して対処しようとします。しかし、それがうまくいくことはほとんどありません。よりよい方法は、同じ土俵で勝負できる立場に上がることです。

レベル1：認知される — 存在感を示す

多くのEMはここでつまずきます。「黙々とよい仕事をする」だけでは、組織の90％にあなたの存在が伝わりません。認知されるために、交流イベントに参加する必要はありません。小さな行動を継続的に積み重ねることが大切です。

• チーム横断のプロジェクトや全社的な議論に参加する
• 他チームの告知にリアクションし、コメントする
• 全員を知っているわけではない会議で、関連する質問をする
• あなたがリリースノートを書くのではなく、チームに書いてもらう

エンジニアについては、成果を公に発信すると昇進が容易になります。エンジニアリング部門以外にも知られている開発者は、本人と直接仕事をしたことのない人からも、承認をより早く得られます。

レベル2：好意を持たれる — 関心を示す

最も過小評価されている手段です。相手の仕事や課題に好奇心を示すと、印象に残り、好感を持たれます。そして好感は、担当範囲の交渉からインシデントの責任追及まで、あらゆることに影響します。

新しい人のルール： 毎週、これまで話したことのない人と少なくとも一度は会話しましょう。エンジニアリング部門の人に限りません。まず個人的な話題から始め、それから相手の仕事や、何に苦労しているかを尋ねましょう。

相手の話を覚えておき、後日その話題に触れましょう。相手が話していた2週間後に「ローンチはどうでしたか？」と聞くのは手間がかからず、確かな好意を生みます。配偶者や子どもの名前を覚えて具体的に尋ねることは、「ご家族はお元気ですか？」と漠然と聞くよりも、相手に注意を払っていることを伝えます。

レベル3：信頼される — 他者の目標達成を支援する

信頼は、自分がどれほど優れているかを説明するのではなく、相手をよく見せ、成功を支援することで築かれます。意外に思えるかもしれませんが、組織で最も成果を上げ、生産性の高い人たちは、最も惜しみなく他者に与える人たちである傾向があります。

これを実践するには、他者が何を重視しているかを知る必要があります。それを知るのがレベル2です。次に、行動に移しましょう。

• サポート： 相手からの依頼を無視したり、プロダクト部門に回したりしないでください。問題を持ちかけられたら、真摯に対応しましょう。相手のメンバーをトレーニングしたり、必要に応じてサポート業務に時間を割いたりします。
• QA： バグ修正を先回りして行いましょう。チケットを起票させたうえで放置してはいけません。新しいツールを使ったイノベーションも支援しましょう。
• HR： 人材育成プロセス、オンボーディングプログラム、採用プロセスの設計を進んで支援しましょう。時間の負担は小さく、返ってくる恩恵は大きいものです。
• 財務： 期限前に依頼されたことを済ませましょう。他の人は誰もが期限に遅れています。ずっと解決したいと思っていた業務上の問題を一つ見つけて解決しましょう。半日だけでも、長く続く好意を生み出すには十分です。

目立たない部門ほど、助けてもらえることに感謝します。こうした関係は、かけた労力に見合わないほど大きな恩恵をもたらします。

---

さらに詳しく

ユーザーがフレームワークの出典を尋ねたり、元の記事を読みたいと希望したり、このスキルのトピックについて詳しい背景を求めたりした場合は、出典となる記事（リンク付き）と書籍の全リストが記載されたreferences/sources.mdを読んでください。

---

関連スキル

• managing-up — 自分のマネージャーに働きかける方法に特化した内容です。働きかけ、信頼性、決定への異議申し立てなどを扱います
• working-with-pm — PMとの関係性や、ロードマップの優先順位に関する合意形成を扱います
• engineer-motivation — レベル1のポジショニングはエンジニアにも当てはまります。エンジニアが認知されるよう支援しましょう