feedback

フィードバック

開始前

まず、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の面談まで先延ばしにしません）。
• チーム全体でフィードバックの文化を築く → 「スピードフィードバック」を参照します。
• 評価や文書に記載するフィードバックを書く → まず「明確さ」のセクションを参照し、次に記録する具体的な出来事について尋ねます。
• レポート先のメンバーとの間で、手軽な週次のアカウンタビリティの仕組みを作る → references/extended.md の「週次の宣言」を読みます。
• 自分のチームから率直なフィードバックを得る → 「チームからフィードバックを得る」を参照します。

ユーザーがまだ具体的な出来事を伝えていない場合は、その出来事について尋ねます。 曖昧なフィードバックの入力からは、曖昧なフィードバックしか生まれません。

---

回答の基本構成

フィードバックを支援する際は、マネージャーが実際に口にできる表現を作成します。

1. 意図： フィードバックによって実現したい結果。
2. SBI の草案： 状況、行動、影響を具体的な言葉で示します。
3. 切り出しの一言： 率直でありながら、相手に配慮した会話の始め方。
4. フォローアップの質問： メッセージを曖昧にせず、相手の見方を尋ねます。
5. 次のステップ： 要望、合意、または観察期間を示します。

称賛は具体的にします。改善を求めるフィードバックは、褒め言葉で挟むサンドイッチ法の中に隠しません。

明確さ：曖昧な言葉を避ける

フィードバックで最もよくある失敗は、曖昧さです。「会議で率直すぎます」や「コミュニケーションを改善する必要があります」――これらはフィードバックのように聞こえますが、相手が行動に移せることは何も示していません。また、簡単に受け流されてしまいます。「自分が率直すぎるとは思いません」と。

具体的なフィードバックは事実に基づいており、異論の余地がありません。

不十分な例：「会議で率直すぎます。」 具体的な例：「Christopherとの会議で、彼がReactベースの解決策を提案し始めたときに、あなたは彼の話を遮りました。ほかのアプローチをさらに検討する機会を逃しました。また、その後、Christopherがほかの会議で発言しなくなったことにも気づきました。」

具体的な例では、出来事、影響を受けた人、そしてその後の結果が示されています。相手は事実に異議を唱えることができず、何が起きたかについて向き合うしかありません。

同じ基準を、肯定的なフィードバックにも適用しましょう。「よくやりました」では印象に残りません。「木曜日のインシデントへの対応は、チームがデバッグしている間も落ち着きを保ち、関係者に明確に伝えていた点がよかったです。あのような状況で、まさに必要としている対応です」と伝えれば、記憶に残り、繰り返し実践してもらえます。

フィードバックを伝える前に、下調べをしましょう。 具体的な出来事、具体的な行動、具体的な影響を特定してください。曖昧なフィードバックは親切なのではなく、準備不足なだけです。

---

人前での称賛が誰にとってもよいとは限りません

「人前では称賛し、批判は個別に伝える」というのは、管理職向けの定番アドバイスです。しかし、前半はいつも正しいとは限りません。

チームの前で名指しされることを本当に望まないエンジニアもいます。個別に認めてもらうほうを好む人もいます。Slackで称賛したり、表彰プログラムに推薦したりして、相手を驚かせると、意欲を高めるどころか気まずさを生むことがあります。

決めつけずに、本人に尋ねましょう。1対1のミーティングで「大きな成果を上げたとき、どのように認めてもらうのが好みですか？」と聞くだけで十分です。

---

社会的なサインを伝える

場の空気を読めない人もいます。あなたがそれを得意としているなら、そうでない人をサポートすることも仕事の一部です。

チームメンバーの発言が悪く受け取られたのに本人が気づいていないとき――誰かを不快にさせた、軽視しているように聞こえた、会議でぶっきらぼうに答えたなど――は、個別に伝えましょう。批判ではなく、情報として伝えます。「意図とは違う受け取られ方をしたように思います。私が気づいたことをお伝えしますね。」本人が気づいていないことはよくあります。それを伝えるのが、できる最も有益なことです。

---

行動変容の段階

パフォーマンスや行動の問題を指摘されたとき、フィードバックを受け入れるまでに、通常は次の3段階をたどります。

1. 無視 — 問題の存在を認めません
2. 否定 — 積極的に反論します（「そんなことはありません」／「あなたが間違っています」）
3. 他者のせいにする — 責任をほかに転嫁します

1回の1対1のミーティングで、相手を3つの段階すべてに進められることもよくあります。各段階で適切な対応は異なります。

• 無視／否定の段階：具体的な事実を示します。言い争わず、落ち着いて証拠を提示してください。
• 他者のせいにする段階：そのまま逃げ道にさせないでください。一部は事実だと認めたうえで、本人がコントロールできることへ話を戻します。

目的は議論に勝つことではなく、本人が問題に責任を持てる状態にすることです。

---

褒め言葉で挟むサンドイッチ法の代わりに

褒め言葉で始め、最後も褒め言葉で締め、その間に批判を挟む方法は、二つの点で逆効果になります。最初の褒め言葉は不誠実に感じられます（相手は厳しい指摘に身構えているため）。また、最後の褒め言葉は、新近性効果によって批判を埋もれさせてしまうことがあります。

アダム・グラントが研究に基づいて提案する、より効果的な4つの手順です。

1. フィードバックを伝える理由を説明します。 相手の味方であることを示します。「高い期待を寄せていて、あなたならそれに応えられると分かっているので、これを伝えています。」 自分を信じてくれている人からの厳しい真実は、拒絶しにくいものです。
2. 自分を高い位置に置かないようにします。 力の不均衡を和らげます。「私自身も、厳しいフィードバックをくれる人たちのおかげで成長できました。今度は私がその恩を返そうとしています。」 これにより、フィードバックが脅威に感じられにくくなります。
3. 批判を率直に伝えます。 曖昧にしないでください。具体的なこと、具体的な出来事、具体的な影響を伝えます。
4. 相手に応答を促します。 相手の考えを尋ねます。ただ受け取ってもらうだけでなく、対話に参加してもらいます。

---

厳しいフィードバックの会話を始める

The Making of a Manager（Zhuo）によると、難しいフィードバックの会話の直前は、双方にとって居心地の悪いものです。その不快感は良い兆候です。会話が本物であることを意味します。

気楽なフィードバックの会話では、何も達成できていないことがよくあります。どちらも少しも抵抗を感じないなら、フィードバックが具体性に欠けているか、率直さに欠けているか、実際に重要なことを扱っていない可能性があります。

最初に伝えること：

切り出し方を凝る必要はありません。大切なのは、相手を批判したいのではなく、相手のことを大切に思っているから伝えていると示すことです。

「言いにくいことをお伝えしたいのですが、あなたの今後にとって大切だと思うのでお話ししています。」

あるいは、何が起きているのかをそのまま伝えるだけでもかまいません。「率直なフィードバックがあります。居心地の悪い話かもしれませんが、ここでのあなたの成功を願う気持ちから伝えていると知っておいてほしいです。」

それから、本題を伝えます。 遠回しにしないでください。切り出し方で雰囲気を整えたら、フィードバック自体は明確かつ具体的に、率直に伝える必要があります。力強く切り出した後で内容を和らげてしまっては、目的が台無しです。

沈黙も情報です。 厳しいフィードバックの後に相手が黙っても、焦って沈黙を埋めないでください。考える時間を与えましょう。沈黙は、相手が実際に内容を受け止めていることを意味する場合がよくあります。それこそ、あなたが望んでいたことです。

---

その場で伝えるフィードバック

次の1対1ミーティングまでフィードバックを待つと、その効果の大半が失われます。出来事に近いタイミングで伝えるほど、相手は自分が実際にしたことと結び付けやすくなります。

朝会でのフィードバック — 業務の流れの中で、関連するタイミングかその直後に伝えるフィードバックです。大げさな正式な会話ではなく、率直で短いコメントです。例として、ある開発者がチームメイトのコードレビューを何度も遅らせているとします。朝会（またはその直後に廊下で）このことを伝えるほうが、3日後に、本人が具体的な出来事をほとんど覚えていないかもしれない1対1ミーティングで持ち出すより、はるかに効果的です。

音量のつまみ。 その場で伝えるフィードバックは、大声で強く伝える必要はありません。内容ではなく、口調と声量を抑えることだと考えてください。伝える内容は明確かつ率直に保ち、落ち着いて、騒ぎ立てずに伝えます。短く、敬意を払い、出来事に近いタイミングで伝えるほうが、形式ばって念入りな内容を1週間後に伝えるより効果的です。

タイミングが重要な理由。 人間は（ほかの動物と同じく）、時間が空きすぎるとフィードバックと行動を結び付けるのが難しくなります。数日待つと効果が薄れるだけでなく、チームは正式な場でしかフィードバックを受けないものだと学習してしまい、日々の業務における心理的安全性が低下します。Googleのチームの有効性に関する調査では、心理的安全性が最も重要な要素として特定されており、それに最も大きな影響を与えるのはチームリーダーです。

スピードフィードバック：チームにフィードバックの習慣を根付かせる

正式な評価の場でしかフィードバックを行わないチームでは、対応が遅すぎます。スピードフィードバックは、チーム全体にフィードバックの習慣を根付かせるための、構造化された活動です。

進め方： チームメンバーがペアになり、個別に話せる場所に移動します。それぞれに決められた時間が与えられ、相手にフィードバックを伝えた後、交代します。全員が全員と話すまで、ペアを入れ替えていきます。

目的は深さではなく、習慣化です。 初めのうちは、相手への感謝や貢献を称えることに重点を置きます。チームが慣れてくると、自然に改善の提案も含めるようになります。この活動によって、フィードバックは年に一度の行事ではなく、チームのリズムの一部になります。

5～8人で行うのが最適です。ブレイクアウトルームと共有ボードを使えば、リモートでも実施できます。定期的な1:1のフィードバックに代わるものではなく、それを補うものです。

---

チームからフィードバックを得る

悪いマネージャーには問題がたくさんありますが、そのほとんどは本人も自覚しています。良いマネージャーにある問題は、いくつかあっても目に見えません。パフォーマンスレビューでフィードバックを求めても、たいてい返ってくるのは沈黙か、「すべて順調です！」という言葉です。改善できることは必ずあります。

表面的な回答にとどまらないための方法を3つ紹介します。

1. さまざまな角度から尋ねます。 最初の「思いつきません」をそのまま受け入れないでください。別の方向から、何度も尋ねましょう。「気に入らなかった行動はありますか？」「あなたの成長や、私たちの1:1に関する具体的なことはありますか？」「チーム全体として、もっとうまくできたことはありますか？」質問を変え続けたからこそ、初めて聞き出せる本音もあります。

2. 自分が苦労していることを共有します。 自分の苦手なことを共有すると、相手はあなたを批判しやすくなります。それは率直な評価を歓迎しているという合図になります。チームがあなたの苦労を知る機会がLinkedInへの投稿だけなら、1:1でそうした話をするための心理的な余地はありません。

3. 具体的な状況について尋ねます。 人はあなた個人を批判することには抵抗があっても、プロジェクトや出来事についてなら話してくれます。「どこを改善できますか？」ではなく、「プロジェクトXでは、何をもっとうまくできたでしょうか？」と尋ねましょう。さらに、「同じプロジェクトをもう一度やるとしたら、何を変えますか？」と掘り下げます。本当のフィードバックが得られるのは、2つ目の質問です。

---

さらに詳しく

フレームワークの出典を知りたい場合、原文の記事を読みたい場合、またはこのスキルのトピックについてさらに詳しい背景を知りたい場合は、references/sources.mdを参照してください。出典となった記事（リンク付き）、書籍、教材の一覧が記載されています。

---

関連スキル

• 1on1s — 1:1の場でフィードバックを伝える
• performance-reviews — 評価時に文書で正式なフィードバックを伝える