質問の意図と背景
これは「部下・後輩から上司・先輩へのフィードバック（upward feedback）」に関するエピソードです。ここでの難しさは権力の非対称性にあります。発言した相手のほうがより大きなリスクを負っており、あなたの最初の反応次第で、その人やチームが今後も率直に意見を言ってくれるかどうかが決まります。後輩社員や直属の部下が、あなたの客観的に観察可能な行動に対して異議を唱えた実際のエピソードを1つ選んでください。
面接官が評価するポイント
- 経験年数や役職をフィードバックの質の判断基準にしていないか。
- フィードバックの提供者を報復、周囲への露出、または公の場での無理な同意の強要から守っているか。
- 指摘された事実を客観的に検証し、自身の権限が及ぼした影響に対して責任を負っているか。
- 行動の変化が周囲から見え、かつ継続しているか。
逆質問・前提確認の例
- その相手は直属の部下、後輩の同僚、あるいは別のレポートラインのメンバーでしたか？
- そのフィードバックは個別、公の場、匿名、または第三者を介して伝えられたものでしたか？
- 意思決定、コミュニケーションスタイル、ミーティングでの振る舞い、パフォーマンス管理のいずれに関するものでしたか？
- 相手を特定せずに共有できる客観的証拠にはどのようなものがありますか？
意見を言うことにリスクが伴う程度の権限をあなたが持っていた状況のエピソードを選択してください。一般的な上司から部下へのフィードバックの話では、質問の意図を満たせません。
30秒で伝える回答例
「まず権力関係のギャップを説明し、次に相手から指摘された具体的な行動を述べます。相手に気遣いを求めることなく感謝を伝え、より安全な個別の場で具体例を尋ねました。そして、後輩が正しいかどうかを周囲に聞き回るのではなく、業務記録や会議の議事録を検証しました。確認できた部分の責任を認め、周囲から見える行動を1つ改善し、誰からの意見かは伏せたうえで今後の対応変更をチームに共有しました。その後、改めて個別にその相手と話し、改善が実感できているか、また発言したことで不利益が生じていないかを確認しました。」
ステップ別の詳細解説
1. 発言に伴う心理的コストを即座に下げる
意図を弁明したり、他に誰が同調しているか尋ねたり、管理者自身を慰めさせるような場にしてはいけません。相手に感謝を伝え、観察可能な懸念事項を復唱して確認し、個別のフォローアップの場を提案します。もしフィードバックに不正行為や安全上の問題が含まれている場合は、個人的に情報提供者を調べるのではなく、適切に保護された社内規定のプロセスを利用してください。
2. 情報提供者を特定させずに検証する
成果物、意思決定、会議メモ、または自分自身の繰り返しの行動を調査します。さらなる背景情報が必要な場合は、プロセスに関する中立的な質問を投げかけます。相手の身元を明かしたり、忠誠心を試すようなことをしてはいけません。基準となるのは、その指摘や影響が事実に基づいているかどうかであり、多数派があなたを支持しているかどうかではありません。
3. チームから見える行動を変える
「議論を打ち切ってしまう」という指摘を具体的なアクションに変換します。自分の意見を述べる前に反対意見を募る、議論をまとめる前に最も社歴の浅い参加者に発言してもらう、あるいは未解決の反対意見と担当者を記録に残す、といった対応です。見直しの期日を設定し、コミット前に提示されたリスクの数や、メンバーが決定の根拠を説明できるかどうかといった1〜2個の測定指標を定めます。
4. 状況をフォローし、権限の影響を振り返る
何が判明し、何を変更し、何がまだ不確実であるかをフィードバックの提供者に伝えます。報復や周囲からのプレッシャーが生じていないかを個別に確認します。面接では、自分の感情だけでなく、自身の持つ権限を取り巻く仕組みをその経験によってどのように改善したかを説明してください。
説得力のある回答例
「これは架空の数値を用いた例ですので、実際の数値に置き換えてください。私は6名のプロジェクトチームをリードしていました。計画ミーティングの後、あるジュニアエンジニアから個別に、『あなたが早い段階で好みの設計案を表明してしまうため、他のリスクを指摘しづらくなっている』というフィードバックを受けました。私の最初の思いは時間を節約したかっただけというものでしたが、その意見に感謝し、他のメンバーの意見を聞き出そうとせず、具体的な場面を2点教えてもらいました。
会議メモを振り返ると、4回中3回の会議で制約事項を確認する前に自分の推奨案を述べていたことがわかりました。そこでその後の4回のセッションでは、まずリスクを洗い出し、議論を終える前に最もジュニアな参加者に発言を促し、懸念事項を担当者とともに記録するようにしました。その結果、決定前にチームから出されたリスクはベースライン（例としての1〜2件）から5件に増え、そのうちの1件によってリリース順序が変更されました。エンジニアの名前は伏せてプロセスの変更のみをチームに共有し、1か月後にそのエンジニアと個別に面談して、変化が実感できているか、意見したことで不利益を被っていないかを確認しました。今後は、最初の計画ミーティングの前に反対意見を歓迎するステップをあらかじめ組み込むようにします。」
よくあるミス
- 自分が正しかったことを証明するために後輩の勇敢さを利用する → 柔軟性や受容性がないと判断されます → 実際に変化を起こした事例を選びましょう。
- 誰が同意しているかをチームに尋ねる → フィードバック提供者が特定されリスクに晒されます → 成果物や中立的な観察を通じて検証してください。
- フィードバック提供者を名指しで公に賞賛する → 望まない注目を集めることで率直に意見を言う心理的コストが上がることがあります → 名前を出す前に本人の同意を得てください。
- 曖昧な『心構え』だけを変える → 結果が客観的に観察できません → 繰り返される具体的な行動と見直しの期日を明確に指定してください。
- 劇的すぎる数値をでっち上げる → 信憑性が低下します → サンプルの数値であることを明記するか、実際の証拠を使用してください。
想定される追加質問と回答
フィードバックが部分的にしか正しくなかった場合はどうしますか？
受け入れた観察可能な部分、証拠によって裏付けられなかった部分、そして不確実性を解消するために実施した試行について述べます。役職の上下はその分析に関係ありません。
報復をどのように防ぎましたか？
情報提供者の匿名性を保ち、その反応として業務の割り当てや評価を変えることを避け、通常の基準で意思決定を記録し、後で個別に状況を確認しました。深刻な申し立ての場合は、保護された組織的な通報窓口を利用します。
チーム全体ではなく、あなた自身は何を行いましたか？
自身の初期対応、調査した証拠、改めた行動、そして自ら始めたフォローアップを挙げます。チームの成果は話を補強しますが、個人の行動の代わりにはなりません。
次回はもっと早い段階で何を行いますか？
対立が生じる前にチャネルを構築します。スキップレベル（階層を飛ばした面談）や1on1での問いかけを設定し、自分の意見を言う前に異論を求め、フィードバックがどのように扱われ保護されるかを事前に説明しておきます。