設問と適用されるコンテキスト
2人の同僚が対立した際に、実行可能な解決策に至るよう支援した経験を教えてください。その対立が業務にどのような影響を与え、あなたにどのような権限があり、真の意見の相違をどのように見つけ出し、なぜあなたが調停するのが適切であったのか、そしてその後、合意事項が遵守されていることをどのように確認したかを説明してください。
この行動面接の質問は、エンジニアリングマネージャー、チームリード、プロジェクトリード、シニアIC（個別貢献者）を対象としています。現在の公開質問バンクでは、候補者が2人のチームメイト間の対立を調停したことがあるかどうかが明確に問われています。個別の聞き取り、共通の目標の発見、マネージャーを巻き込むタイミングの把握、フォローアップが強いシグナルとして評価されます。この質問は、「チーム内の2人が一緒に仕事を進められない場合、どうしますか？」や「直属の部下同士の対立をどのように処理しますか？」という形で提示されることもあります。
目標は、その場ですぐに全員を和解させることではありません。面接官は、あなたが公平性を保ち、立場（Position）と利害（Interest）を切り離し、組織の境界を尊重し、人間関係の対立を実行可能な業務上の合意へと転換できるかどうかを知りたがっています。これは技術的な決定に関する意見の相違についての質問とは異なります。あなた自身は当事者の一員ではなく、ファシリテーターの立場を利用して自分が望む解決策を押し付けることはできません。
必要に応じて名前や業務の詳細を匿名化した上で、実体験を使用してください。STAR法（Situation：状況、Task：課題、Action：行動、Result：結果）で構成し、行動（Action）に最も多くの時間を割く必要があります。この記事の後半にあるサンプルは完全に架空のものです。すべての人物、プロジェクト、期間、結果の数値はプレースホルダーデータであり、個人の経験として主張するのではなく、実際のデータに置き換える必要があります。
面接官が評価するポイント
第一に、自身の役割の限界を確認したかどうかです。優れた回答では、誰から介入を求められたのか、双方が自発的に参加する意思があったか、自分に利害の衝突がなかったか、業績評価・懲戒処分・最終的なビジネス上の意思決定権を誰が持っていたかを明確にします。「自分が最も合理的だったため、2人を会議室に呼んだ」といった説明は、越権行為や偏見を示すシグナルになります。
第二に、実際の対立原因を診断できたかどうかです。口調、コードレビュー、リリースの順序などを巡る対立の背景には、相容れない目標、事実認識の相違、役割の重複、決定権の曖昧さ、未解決の感情的軋轢などが隠れている場合があります。成熟した回答では、事実を個別に収集し、本人の見解が公平に反映されているかを各自に確認させます。伝聞をそのまま鵜呑みにして判断を下すことはしません。
第三に、公平なファシリテーションが行われたかどうかです。公平であることは受動的であることを意味しません。発言を遮ったり相手を決めつけたりすることを禁じるルールを設け、会話を観察可能な行動と共通の業務目標に集中させ、権力のある人物や声の大きい人物が場を支配するのを防ぎます。当事者が選択肢を洗い出し、評価するのを支援するのであり、自白、謝罪、同意を強制してはなりません。
第四に、合意事項が実行可能であったかどうかです。「より良いコミュニケーションを取る」という合意には、コンテキストも担当者も完了基準もありません。強力な合意には、決定権、ハンドオフの境界、次のアクション、期日、レビューポイント、エスカレーション条件が明記されます。技術的な事実も争点となっている場合は、関係性の妥協によってエンジニアリングの判断を曖昧にするのではなく、短期的な検証テストや客観的な証拠の収集で合意します。
第五に、調停が万能な手段ではないことを理解しているかどうかです。調停は一般に自発的、非公開、かつ将来志向のものですが、守秘義務の範囲は組織のポリシーおよび法的義務に従う必要があります。重大な苦情、懲戒処分の可能性がある事案、脅迫、安全上の問題、差別、ハラスメント、報復行為などを、あなた個人が内々に裁定したり、絶対的な秘密保持を約束して隠蔽したりすることはできません。事実を保全し、権限を持つマネージャー、人事、コンプライアンス、安全管理チャネルを活用してください。具体的なプロセスは組織や管轄区域によって異なります。
最後に、そこから何を学んだかです。介入が遅すぎた、最初の個別ミーティングで誘導尋問をしてしまった、再発の兆候を定義し損ねたといった反省点があっても、最終的に業務が回復したケースはあります。面接官は「コミュニケーションが重要だと学んだ」といった一般的な感想ではなく、次回の行動をどのように改善するかという具体的な是正策を求めています。
回答前に整理しておくべき質問
- あなた自身は当事者、責任を持つリーダー、それとも公平な支援者でしたか？ あなた自身が対立の当事者であった場合、中立的な調停者として振る舞うべきではありません。双方が納得するマネージャーや訓練を受けた人物にファシリテーションを依頼し、その上で自分が解決にどう貢献したかを述べてください。
- 誰があなたの関与を承認・受け入れましたか？ 双方が助けを求めたのか、マネージャーから依頼されたのか、あるいはプロジェクト上の役割として協調関係の回復が求められていたのかを明確にします。正式な権限がないことは強みにもなり得ますが、当事者の同意とエスカレーション経路が明確である必要があります。
- その問題は非公式な調停に適していましたか？ 業務スタイルの違い、誤解、役割のインターフェース、日常的な人間関係の破綻などは適している可能性があります。一方の当事者が同意しない場合、ポリシー上正式な手続きが必要な場合、問題が深刻な場合、または懲戒処分につながる可能性がある場合は、権限を持つ人物がプロセスを決定しなければなりません。
- どのような守秘義務を約束できましたか？ 自身の役割とポリシーで許可されている範囲内でのみ約束し、例外事項は事前に伝えておく必要があります。安全リスク、違法行為、または報告が義務付けられている事案を面接官に対して「秘密にした」と語ってはなりません。
- どのような業務成果に影響が出ましたか？ 遅延、手戻り、意思決定の停滞、レビューの滞り、チームのやり取りなど、実際の証拠を提示してください。「士気が下がった」だけでは曖昧すぎます。
- 協調関係が回復したことを何によって証明しますか？ 握手をしただけでは解決とは言えません。合意されたアクションの完了、次の意見の相違が直接建設的に処理されたこと、業務成果の回復、改善点や残された課題に関する双方からのフィードバックなどが確実な証拠となります。
- 技術的な意見相違のエピソードとどう異なりますか？ この質問への回答は、2者間の関係性と業務インターフェースのファシリテーションに焦点を当てる必要があります。話の大半があるアーキテクチャの正しさを証明することに費やされている場合は、別のエピソードを選択してください。
30秒回答フレームワーク
「[プロジェクト]の際、[同僚A]と[同僚B]の対立により[業務上の成果]が滞っていました。私は[役割]であり、人事権を持つマネージャーではありませんでした。双方の合意を得た上で個別にヒアリングを行い、事実、ニーズ、個人の責任範囲を切り分けました。合同ミーティングでは[共有目標]について合意を形成し、[アクション、担当者、レビュー時点、
エスカレーション条件]を文書化しました。[チェックポイント]の時点で、[業務上の証拠]および[協働を示す証拠]によって関係の回復が確認されました。この経験から[以前に行った具体的な改善]を学びました。」
全体の回答時間は2〜3分程度に収めてください。Situation（状況）とTask（課題）で影響、役割、境界を定義します。Action（行動）の大部分を使って、適性確認、最初に見落としていた事実、そしてなぜその合意が機能したのかを説明します。Result（結果）では業務面と協調関係の両面をカバーしてください。
ステップ別の詳細回答手順
ステップ1：自分が「勝者」にならない実話を選ぶ
双方が正当な懸念を持っており、対立が実際の業務に影響を与え、双方があなたの支援を受け入れ、その後の経過を観察できた経験を選択するのが望ましいです。正式な管理職である必要も、2人を親友にさせる必要もありません。オーナー間のハンドオフを明確にしたシニアエンジニア、職能横断的な対立を調整したプロジェクトリード、2人の部下の協調関係を修復したマネージャーなど、いずれの立場でも適切です。
避けるべき3つのストーリー：口調に関する単発の些細なやり取り、自分自身が当事者の一員であった出来事、または内々に「もみ消した」重大な不正行為。また、分かりやすい悪役が存在するストーリーも避けてください。面接官はヒーロー物語ではなく、判断力、プロセス、限界の認識に関する証拠を求めています。
ステップ2：調停の適性確認を行う
介入する前に、次の5つの質問に答えてください。双方が自発的に参加しているか？ あなたは十分に中立か？ 権力格差によって同意が強制されていないか？ 問題は業務上の関係性と協力体制に関するものか？ ポリシー、懲戒規定、安全基準、法的義務により正式な手続きが求められていないか？
問題が非公式な調停に適していない場合、責任権限を持つ人物が調査、保護措置、または正式なプロセスを決定します。あなたは納期の安定化を図り、客観的な事実を記録し、当事者が正しいチャネルを利用できるようにサポートすることはできますが、調停者として振る舞うのはやめる必要があります。適している場合は、自分が裁判官ではないことを宣言します。合意の責任は当事者自身にあり、既存のビジネス決定権者がその権限を保持します。
ステップ3：個別にヒアリングし、一貫した質問でバイアスを排除する
個別に対話を行うことで、合同ミーティングの前に各自が状況を余すところなく話せるようにします。双方に同じ質問を投げかけます。どのような観察可能な出来事が発生したか？ それはどのような影響を与えたか？ 相手は何を守ろうとしていると思うか？ あなた自身にはどのような責任があるか？ 実行可能な将来像とはどのようなものか？ 合同ミーティングに持ち込んでよい内容は何か？
事実、解釈、ニーズ、要求を明確に切り分けます。「レビューが期限後に完了した」は事実の候補です。「わざと遅らせた」は動機の推測です。「予測可能なハンドオフが必要だ」はニーズです。「前日までにキャパシティを確認してほしい」は要求です。メモを復唱して認識の修正を促します。ミーティング間で感情的な発言を伝え合ったり、すでにどちらかの肩を持っているかのような態度を取ったりしてはなりません。
ステップ4：共通の目標に沿って合同ミーティングをファシリテーションする
冒頭で、参加の自発性、共有の範囲、自身の役割、ミーティングのルールを再確認します。発言を遮られることなく各自に影響を説明させ、その後、相手に聞き取った内容を要約させます。双方が自身の見解を正確に理解されたと納得した段階でのみ、解決策の議論に移行します。
ミーティングを裁判にするのではなく、過去の出来事は共通の事実を確立するためにのみ使います。その上で、「移行ウィンドウの前に信頼性の高いリリース判断を下す」といった共通の目標を明文化し、役割、情報、行動、意思決定の問題を個別に扱います。争点に検証可能な技術的仮説が含まれている場合は、最小限のテスト、エビデンス基準、実際の意思決定者を合意します。ファシリテーターが「足して2で割る」ような妥協案で正しい判断を置き換えてはなりません。
ステップ5：和解を実行可能な業務合意に落とし込む
合意事項には、次の具体的なコンテキスト、各自のアクション、期日やトリガー、意思決定とハンドオフの境界、対応不能時の連絡方法、合同レビューの時期、マネージャーや正式チャネルにエスカレーションする基準を含める必要があります。
双方に自分の言葉で合意内容を復唱させ、それが実行可能かどうかを検証し、書面で共有できる内容を確認します。記録は今後の進め方と各自の責任を明確にするためのものであり、非公式な人事評価ファイルを作成するためではありません。通常の協調合意と正式な人事記録は区別して管理してください。
ステップ6：2種類のエビデンスでフォローアップする
少なくとも業務上のエビデンスと関係性に関するエビデンスの両方を追跡します。業務上のエビデンスには、レビューの再開、納期のブロック解除、手戻りの削減、合意どおりの意思決定の完了などが含まれます。関係性のエビデンスには、当事者が次の意見相違を直接話し合えていること、合意したエスカレーション手順を使用していること、フォローアップ時に双方が残っている課題を率直に共有していることなどが挙げられます。
1回穏やかなミーティングができたからといって、解決したとは言えません。合意に基づいて個別または合同でフォローアップを行います。アクションが実行されたか、権力格差によって誰かが沈黙していないか、対立が単に水面下に潜っただけではないかを確認します。問題が再発した場合は、合意のどの部分が機能しなかったのかを分析します。合意の履行を拒否されたり、業務への影響が拡大したり、正式なリスクが生じたりした場合は、速やかに責任者へ案件を引き渡してください。
ステップ7：STAR(R)で個人の貢献をセルフチェックする
Situation（状況）で客観的な影響を伝えます。Task（課題）で、なぜ自分が介入する責任があったのか、そして自身の権限の限界を説明します。Action（行動）で、適性確認、個別ヒアリング、合同ミーティング、合意形成、フォローアップを網羅します。Result（結果）で業務と関係性のエビデンスを示します。Reflection（学び）で、次回はどのような点をより早く、またはより公平に行うかを述べます。
練習相手に次のような深掘り質問をしてもらいましょう。「なぜあなたがファシリテーターだったのですか？」「最初に見誤っていた点は何ですか？」「片方が拒否した場合はどうしましたか？」「合意事項の各部分の責任者は誰でしたか？」「ミーティングの場だけで形骸的に同意したのではないと、なぜ分かりますか？」すべての回答で役割、事実、タイムラインに一貫性が保たれて初めて、説得力のあるストーリーとなります。
質の高い回答サンプル
以下は、構造を示すためだけに使用される完全に架空のサンプルです。2人のエンジニア、1日、8営業日、6週間、およびすべてのプロジェクト名や成果の数値は、実際のデータに置き換えるべきプレースホルダーです。
「私は顧客データ移行の暫定テックリードを務めていました。ロールバックの発生後、APIオーナーと移行オーナーがお互いの作業のレビューを拒否し始め、リリースの判断が滞っていました。2人のエンジニアおよび以降のすべての期間は置き換えが必要なサンプルデータです。私は彼らの評価マネージャーではありませんでした。まず共通のマネージャーに業務への影響を説明し、双方が同意した場合に限り、私が非公式な対話をファシリテーションできることを確認しました。不正行為の申し立てや参加拒否があった場合は、マネージャーに案件を戻す取り決めとしました。
私は彼らと個別に面談し、同一の質問を使用しました。当初、私はこの対立がロールバック戦略に関する単なる技術的な意見の相違だと考えていました。しかし実際には、承認（Approval）の定義に関する認識が異なっていたことが判明しました。APIオーナーは互換性の確認のみを行っていると考えていたのに対し、移行オーナーは承認をリリース判断の共同責任と解釈していました。さらに公開チャネルでの非難めいた発言が原因で、双方が直接前提条件を確認し合うことを避けるようになっていました。私は双方の見解を整理して修正を促し、解決に無関係な感情的発言は伏せた上で、役割と業務への影響に関する論点を合同ミーティングに持ち込む許可を得ました。
合同ミーティングの場では、私が裁定者ではないことを改めて伝えました。各自から影響を説明してもらい、相手はその内容を要約しました。私たちは共通の目標を『顧客データを保護しつつ、検証可能なリリース判断プロセスを回復する』と設定し、互換性の検証、移行データの検証、リリース権限、コミュニケーション行動を切り分けて整理しました。技術的な選択を人間関係の妥協で決めるべきではないという点で双方が一致したため、ロールバックのリハーサルを実施するスケジュールを組みました。1日という期間は置き換えが必要なサンプル日程です。
合意事項として、APIオーナーが互換性を確認し、移行オーナーがデータ検証を確認した上で、最終決定権を持つリリースオーナーに証拠を提出することを取り決めました。また、レビューのキャパシティを事前に共有すること、公開の場で動機を推測して非難する前に事実と影響を書き出すこと、合意したチェックポイントで解決できない場合は共通マネージャーを巻き込むことを定めました。私はチェックリストとフォローアップ体制を整えましたが、技術的な決定を下したり人事評価を保証したりはしませんでした。
リハーサルによって、手順書から漏れていたロールバックの工程が特定されました。これを修正した後、リリース作業は8営業日後に再開されました（8営業日という数値は置き換えが必要なサンプル結果です）。その後の6週間にわたり、彼らは新たな境界線に沿ってレビューを完了させ、レビュー拒否を交渉の手段として使うことはなくなりました（6週間およびこれらのフォローアップ結果も置き換えが必要なサンプルデータです）。個別のフォローアップにおいて、双方は決定権がより明確になったと述べました。また、マネージャーが早い段階で承認の定義を示していれば、対立の深刻化を防げたかもしれないという指摘もありました。
この経験から、介入のタイミングが遅れたこと、そして人間関係の問題を当初単なる技術的対立と誤認していたことを学びました。次回からは、役割の定義に不一致が見られた最初の兆候の段階で決定権を明確にし、ファシリテーター役を引き受ける前に自発性、守秘義務の範囲、正式なエスカレーション条件を確立するようにします。」
この構成を自身の経験に当てはめる際は、チケット、決定記録、ミーティングメモ、実際のフォローアップから本来の経緯を復元してください。サンプルの人物や数値はすべて削除してください。実際の権限、各当事者から得られた新たな事実、実際の合意内容、検証可能な追跡結果を使用します。信頼できる定量的な数値がない場合は、「その後のどのコンテキストで誰が変化を確認したか」といった具体的な定性エビデンスを使用してください。不自然に整えられた数値を捏造してはなりません。
よくある間違い
- 自分だけを唯一の合理的な人物として描く → 公平性が示されず、作り話のような印象を与えます → 双方が守ろうとしていた正当な懸念と、自身の見解を変えるきっかけとなった事実を述べてください。
- 合意や権限のないまま「調停」を始める → 当事者が組織のヒエラルキーやプロジェクトの圧力により、形だけ従うリスクがあります → 自発性、自身の役割、実際の意思決定者およびエスカレーション先を明示してください。
- いきなり当事者を対面させる → 事実、感情、安全上の境界線が不明確なままです → まず個別にヒアリングを行い、一貫した質問を通じて適性とスコープを確認してください。
- 完全な守秘義務を約束する → 安全確保、法的義務、組織への報告義務と矛盾する恐れがあります → 開始前に、情報共有の範囲と必須エスカレーションの例外事項を提示してください。
- 深刻な苦情を単なる誤解として扱う → 非公式な和解によって証拠が隠蔽されたり、立場の弱い側が強要されたりする危険があります → ポリシーに従い、権限を持つ中立な調査部門や正式なプロセスに引き渡してください。
- 謝罪や中途半端な妥協案を強要する → 技術面や行動面の問題が残ったまま、表面的な服従を生むだけになります → 当事者自身に合意の責任を持たせ、技術的判断は客観的事実で検証してください。
- 「もっとコミュニケーションを取る」で終わらせる → コンテキスト、責任者、レビューの仕組みが存在しません → アクション、責任者、トリガー、チェックポイント、エスカレーション経路を文書化してください。
- オンスケジュールでの納品結果のみを報告する → 他の要因が業務結果を後押しした可能性があり、人間関係の回復を証明することにはなりません → 業務上のエビデンス、協調関係のエビデンス、適切な要因分析を提示してください。
- 失敗や再発に一切触れない → 完璧すぎるファシリテーション劇に見えてしまいます → 介入が遅れた点、合意の中で機能しなかった点、次回なら改善したい点を挙げてください。
フォローアップ質問と回答のポイント
フォローアップ1：一方の当事者が調停を拒否した場合はどうしますか？
参加を強制したり、拒否したことを即座に人事評価のマイナス材料として扱ったりしてはなりません。懸念の原因が公平性、秘密保持、権力格差、あるいはミーティングの形式にあるのかを確認し、組織で承認された別のファシリテーターやチャネルを提案します。それでも辞退された場合は、調停が進められない旨を責任者に伝えます。業務の再配置や正式な手続きは責任者が判断します。業務納期の遅延リスクの管理は継続できますが、合意が成立したと主張することはできません。
フォローアップ2：あなた自身も対立の当事者だった場合はどうしますか？
中立的なファシリテーターを務めることはできないと率直に伝えます。事実、業務への影響、自分自身の責任を整理した上で、双方が認めるマネージャー、プロジェクトオーナー、または訓練を受けた人物にファシリテーションを依頼します。自身がいかに真摯に参加し、制約を受け入れ、合意事項を実行したかを説明してください。個人的な影響力を調停権限と言い換えてはなりません。
フォローアップ3：役職の格差がある場合や、ハラスメント・報復の申し立てが含まれる場合はどうしますか？
まずは関係者の保護と事実の保全を最優先し、ポリシーと報告義務を確認します。権力格差が存在すると、真の自発性が担保されない恐れがあります。深刻な苦情、懲戒処分の可能性がある事案、ポリシー上正式対応が義務付けられている問題は、権限を持つ公平な部門が担当すべきです。その後、関係修復のために調停が役立つかどうかは適切なプロセスと当事者が判断するものであり、個人による非公式な調停が調査の代わりになることはありません。
フォローアップ4：ミーティングでは全員が合意したものの、対立が再発した場合はどうしますか？
合意内容と客観的な出来事に立ち戻ります。アクションが非現実的だったのか、役割が曖昧なままだったのか、実行へのサポートが不足していたのか、いずれかが合意の履行を拒否したのかを特定します。修正可能な部分については当事者同士で見直させます。あらかじめ定めたエスカレーション条件に該当する場合は、責任者に関与を求めます。「調停が成功した」という体裁を守るために再発を隠蔽してはなりません。
フォローアップ5：調停が失敗に終わった経験はありますか？
要因の分析と是正策が具体的であれば、失敗談も説得力のある回答になります。介入が遅すぎた、権力の不均衡を見落とした、抽象的な共通目標を設定してしまった、あるいは日常の協調関係を個別に確認せず納品状況の確認だけで済ませてしまったなどの例があります。効果のないファシリテーションをどの時点で打ち切り、業務とメンバーを守るためにどのようにエスカレーションしたか、次回に向けてどのような適性確認を追加するかを説明します。完璧な結末であることよりも、信頼に足る的確な判断力を持っているかどうかが基準となります。
フォローアップ6：その結果があなた自身の貢献によるものだとどのように証明しますか？
要因を明確に切り分けます。自身が確立したプロセス、各当事者が実行したこと、マネージャーや組織システムが提供したサポートを整理し、単なる相関関係にすぎない結果と因果関係のある結果を区別します。合意されたアクションと以後のやり取りの実績をもって、自身の直接的な貢献を裏付けます。1回のミーティングのおかげでプロジェクト全体が成功したかのような誇張は避けてください。