1on1s

1:1

始める前に

まず、EM に関するコンテキストを確認します。

1. .agents/em-context.md があれば読みます
2. 人物の名前が挙がっている場合は、.agents/reports/[name].md を探して読みます
3. そのコンテキストを活用し、すでに触れられている情報は質問しません

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

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

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

回答スタイル

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

基本方針：

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

---

このスキルの使い方

フレームワークを適用する前に、状況を見極めます。

• 次回の1:1に備えたい → 「1:1を効果的にする要素」＋「60/40ルール」
• 1:1が盛り上がらず、状況報告ばかりになっている → 「近況報告、愚痴、緊急事態」のどのタイプかを見極め、それぞれに応じた対応をします
• 部下に何か違和感があるが、原因がはっきりしない → 「診断の手がかりとしての感情」
• 部下との関係がどうもうまくいかない → 「自然に会話が弾まない相手との関係づくり」
• いつもの流れを変える質問がしたい → 「何を変えたいですか？」という質問
• 1:1が踏み込んだ個人的な話になった → 「1:1がセラピーのようになったとき」

特定の人物の名前が挙がっている場合は、回答する前に .agents/reports/[name].md を確認します。コミュニケーションスタイル、関心事、過去の会話について、すでにコンテキストが記録されていることがあります。

---

回答の基本構成

1:1を支援するときは、次の会話ですぐに使える内容を提示します。

1. 状況の見立て： その1:1の本当の目的が、関係づくり、成長、緊張の解消、フィードバック、問題の診断、フォローアップのどれなのかを示します。
2. 議題： 優先順位を付けた3～5個のトピックを挙げます。可能であれば、部下が話したいトピックを最初にします。
3. 質問： 抽象的な分類ではなく、具体的な言い回しを提示します。
4. マネージャーの姿勢： どう耳を傾けるか、どこで一歩踏み込むか、何を避けるかを示します。
5. フォローアップ： 記録すること、約束すること、次回改めて話すことを示します。

ユーザーがテンプレートだけを求めている場合は、まずテンプレートを提示し、説明は簡潔にします。

---

1:1を効果的に行うために

エンジニアを対象とした調査によると、最も価値のある1:1には、いくつかの共通した特徴があります。

毎週行います。 Manager Toolsによる調査（数千人のマネージャーのデータに基づく）では、隔週の1:1は毎週の1:1よりも効果が40％低いことが示されています。月1回の1:1は、1:1を行わない場合よりも効果が低くなります。毎週の1:1だけで、マネージャーの有効性のかなりの部分を占めます。この点について、データは非常に明確です。

継続して行います。 最も大きな失敗は、頻繁にキャンセルしたり、予定を変更したりすることです。エンジニアはそれに気づきます。1:1、ひいては本人が優先事項ではないと伝えてしまうことになります。時間枠を確保して守りましょう。

日々の業務に重点を置きません。 進捗報告には別の場があります。1:1はスタンドアップではありません。キャリア開発、成長、個人的なつながり、グループの場では話さないこと、何に不満を感じているか、何にわくわくしているかについて話しましょう。

個人的なつながりを築くために活用します。 仕事以外の生活について尋ねましょう。詮索するのではなく、純粋な関心を示すのです。相手が話してくれたことを覚えておき、後でまた話題にしましょう。こうして信頼が築かれます。

マネジメントする相手について知っておき、名前を挙げて話せるようにしておきたいことが3つあります。

1. 家族（パートナー、子ども、親）の名前。「お子さんは元気ですか」ではなく、名前を使いましょう。
2. パートナーの仕事。スケジュールや柔軟性、ストレスの度合いに影響します。
3. 趣味と、気分転換のためにしていること。

尋ねるのに遅すぎるということはありません。こうした情報があると、1:1は形式的な業務確認ではなく、自分のことを本当に知ってくれている人との会話になります。

辛抱強く接します。 信頼を築くには時間がかかります。最初の1:1で心を開く人もいれば、何カ月もかかる人もいます。ある開発者は、半年以上たつまでなかなか心を開きませんでしたが、その後、マネージャーとの関係は最も強固なものの一つになりました。一貫して向き合い続けましょう。辛抱強く接することは、やがて実を結びます。

頻度は決めつけず、希望を尋ねます。 多くの人には毎週の1:1が適しています。隔週を好む人もいれば、定期的な時間枠は必要ないと感じる人もいます。報告を受ける相手が実際にどの頻度を希望しているのか尋ねましょう。ほかの既定のやり方にも同じことが当てはまります。ロードマップの話し合いに参加したいとは限らず、チームミーティングで発表したいとも限りません。まず尋ねましょう。

---

診断の手がかりとしての感情

1:1で定期的に尋ねる質問に加えたいものが一つあります。「今週はどんな気持ちでしたか？」

「今週はどうでしたか？」ではありません。これでは進捗状況がわかります。「どんな気持ちでしたか？」と尋ねることで、さまざまな兆候がわかります。

注意したいパターンが3つあります。

反応が早すぎるエンジニア — Slackのメッセージにはすべてすぐに返信し、何かを見逃すと不安になり、些細なことでも謝ります。その根底にある兆候は、周囲をがっかりさせることへの恐れです。放置すると、燃え尽きにつながります。必要なのは、つながりを断ってよいという明確な許可と、いつでも対応できることが価値を意味するわけではないという安心感です。

いつも遅れるエンジニア — 作業にかかる時間を一貫して少なく見積もり、実現できる以上のことを引き受け、自分で設定した期限に間に合いません。その根底にある兆候は、現実の自分ではなく、理想の自分を想定して計画していることです。規律の問題ではなく、見積もりの調整の問題です。責任を問う圧力をかけるのではなく、一緒に作業範囲を見直しましょう。

粗雑なPRを出すエンジニア — 急いで作成した、または不完全に感じられるPRを提出し、コードレビューで防御的になり、行き詰まるまで助けを求めません。その根底にある兆候は、仕事が不完全だと判断されたり、弱点をさらしたりするように感じていることです。必要なのは、未完成の作業を安心して共有し、早い段階でフィードバックを得られる心理的安全性です。

この質問を定期的に尋ね、答えの変化に注意を払って初めて、パターンが見えてきます。

---

1:1がセラピーの場になってしまうとき

あなたはセラピストではありません。心から気にかけつつも、自分が受け止められる範囲には限界を設けましょう。

1:1の話題が自分の役割を超えた領域に入り込んだら、こう伝えます。「話してくれてありがとうございます。力になりたいと思っています。自分に何ができるのか、少し考えさせてください。」 そして、自分でコントロールできること、つまり業務量、チーム内の関係、担当範囲、柔軟性に焦点を当てます。

個人的な事情が深刻なレベルで仕事に影響している場合は、行動を起こす前に人事に相談してください。専門家によるサポートにつなぐべきタイミングと、相手を突き放したと感じさせずにそれを行う方法を理解しておきましょう。

目標は、相手に話を聞いてもらえたと感じてもらうことと、見捨てられたと感じさせないことのどちらかを選ぶことではありません。両方とも実現できます。軸となる問いは、「仕事でどんな調整をすれば、あなたが成果を上げられるでしょうか？」です。

---

自然に生まれないつながりを築く

1:1でなかなか打ち解けられないことがあります。年齢差、文化の違い、性格の不一致、コミュニケーションスタイルの違いなどが原因です。避けるべきなのは、諦めて1:1を事務的なやり取りだけにしてしまうことです。

自然につながりが生まれないときは、努力を減らすのではなく、もっと努力しましょう。

• 自分と似た人なら何を話すかではなく、相手が何を話したいかを見つける
• 相手が話していたちょっとしたことを覚えておき、後でその話題に触れる
• 押しつけがましくならないように個人的な質問をする。質問して覚えておくことには、質問を10個してすべて忘れてしまうより価値があります

「他の人に心から関心を持つことほど、人間関係を築く力になるものはありません。」（Danny Meyer）

---

「何を変えたいですか？」という質問

1:1の定番の質問に加える価値があるのが、次の質問です。「もしあなたが私の立場だったら、チームについて一つだけ変えるとしたら何ですか？」

この質問は、「Xについてどう思いますか？」とは異なる答えを引き出します。ゼロから考える必要があるため、エンジニアはあなたの意見に反応するのではなく、自分で問題を見つけなければならないからです。また、「マネージャーの決定を批判しても大丈夫だろうか」という心理的なフィルターも回避できます。

注意点として、ほとんどのマネージャーはこの質問をしないか、すでに決めている方針について尋ねています。価値があるのは、まだ何も決めていない段階で、心から尋ねることです。

---

エンジニアが嫌がる、EMが抱きがちな思い込み

多くのマネージャーが誰にでも当てはまる好みだと思い込んでいることがありますが、そうとは限りません。決めつける前に尋ねましょう。

1. すべてのエンジニアが、人前で褒められたいと思っている
2. すべてのエンジニアが、より大きな裁量と責任を望んでいる
3. 毎週の1:1が誰にとっても重要である
4. すべてのエンジニアが、人前で話すスキルを伸ばしたいと思っている
5. リモート勤務のエンジニアには毎日のスタンドアップが必要である
6. すべてのエンジニアが、ロードマップの議論に参加したいと思っている

分かっているつもりでも、ただ尋ねてみましょう。正しいこともありますが、重要な点で間違っていることもあります。

---

近況報告、愚痴、そして緊急事態

1:1の多くは、次の3種類のいずれかに当てはまります。どの種類なのかを把握していると、対応の仕方が変わります。

近況報告 — エンジニアが状況を共有します。仕事やプロジェクトの進捗、障害になっていることなどです。最もよくある種類ですが、価値は最も低いことが多いです。1:1のほとんどが近況報告なら、それは1:1ではなくスタンドアップをしていることになります。相手が近況報告を超えた話をできるだけの安心感を作ることが目標です。

愚痴 — 相手は何かを整理する必要があります。チームへの不満、納得できない決定、難しい人間関係などです。ここでのあなたの役割は、すぐに解決することではありません。話を聞き、質問し、相手に話を受け止めてもらえたと感じてもらうことです。「本人に直接話しましたか？」は次の問いとして適切なことが多いですが、相手の話を聞いた後に限ります。傾聴を省くための近道として使ってはいけません。

緊急事態 — 人間関係が壊れている、退職を考えている、重大な出来事があったなど、実際に深刻な問題が起きています。会話の重みが違うので分かるはずです。この場合は、行動を起こす段階に切り替える必要があります。何が起きたのかを理解し、相手が何を必要としているのかを把握し、必ず対応すると約束しましょう。

Randsが示す1:1の最重要ルールは、あなたは相手のために働いているのであって、その逆ではありません。 相手が出席しない1:1は、相手にとって1時間の損失です。あなたがキャンセルするたびに、「あなたは大切ではありません」と伝えていることになります。キャンセルされた事実は、会議を開いていた場合よりも長く記憶に残ります。

---

60/40 のルール

実践的な形式として、時間の60％（30分のうち約18分）をメンバーに割き、残りの40％を取り上げる必要のある話題に使います。

この形式の落とし穴は、マネージャーが「自分の」40％を先に使ってしまい、報告の時間がなくなることです。順序を逆にして、相手から始めましょう。相手の話題を会話の軸にします。あなたの議題はほぼいつでも最後に収まりますが、相手の議題は優先度を下げると収まりません。

この形式をメンバーにも共有しましょう。1:1は主に自分たちの時間だと理解すれば、より準備して臨み、時間を有効に使うようになります。

---

さらに詳しく

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

---

関連スキル

• feedback — 1:1で具体的なフィードバックを準備したり伝えたりする場合
• performance-reviews — 評価サイクルの終了時に行うレビューの話し合いの場合
• team-health — チームの1:1全体に見られる傾向を把握する場合