updated_at: 2026/5/14
エンジニア組織のステイインタビュー実践ガイド|離職予兆を掴む方法
在職中のエンジニアから本音を引き出すステイインタビューの設計・運用・改善サイクルを実践的に解説
エンジニア組織のステイインタビュー実践ガイド|離職予兆を掴む方法
「辞めます」と言われてから慌てて引き留める。それはもう手遅れです。
エンジニア採用に半年以上かけ、数百万円のコストを投じて獲得した人材が、1〜2年で去っていく。エグジットインタビュー(退職面談)で理由を聞いても、返ってくるのは「キャリアアップのため」という当たり障りのない答え。
この悪循環を断ち切るために注目されているのがステイインタビュー(Stay Interview)です。退職後ではなく在職中に、エンジニアの本音・不満・期待を引き出し、離職の予兆を早期に察知して対処する予防的アプローチです。
米国では2010年代後半から急速に普及し、多くの企業で離職率の改善につながったと報告されています。一方、日本のIT企業ではまだ体系的に導入している組織は少なく、「1on1でやっている」という認識にとどまっているケースがほとんどです。
しかし、ステイインタビューと1on1は目的も設計も異なります。本記事では、エンジニア組織に特化したステイインタビューの設計・運用・改善サイクルを、具体的な質問例とともに解説します。
このページでわかること
ステイインタビューとは何か、1on1やエグジットインタビューとの違い
エンジニア組織でステイインタビューが特に有効な理由
実施頻度・対象者・面談者の選び方
エンジニア向けに最適化した質問テンプレート(15問)
面談で得た情報を組織改善・採用改善に活かすフレームワーク
ステイインタビュー導入の落とし穴と対策
効果測定の指標と改善サイクルの回し方
TL;DR(要点まとめ)
ステイインタビューは「辞めないでほしい」ではなく「何があれば続けたいか」を聞く面談。退職意思が固まる前に、不満や期待を把握して先手を打つ
1on1との最大の違いは「匿名性の担保」と「組織的なデータ活用」。直属の上司ではない第三者が実施し、個人の声を組織課題として構造化する
エンジニアに効く質問は技術環境・成長実感・裁量の3軸。「マネジメントに不満はないか」のような抽象的な質問では本音は出てこない
四半期に1回、全エンジニアを対象に実施するのが理想。最低でも半年に1回、離職リスクの高い入社1年以内のメンバーは月1回
面談結果は必ず90日以内にアクションに変換する。「聞いたけど何も変わらなかった」は信頼を壊す最大の要因
1. ステイインタビューとは何か
定義と基本コンセプト
ステイインタビューとは、現在働いているエンジニアに対して「なぜこの会社で働き続けているのか」「何があれば今後も働き続けたいか」を体系的に聞き出す面談手法です。
ポイントは、退職の意思表示があった後ではなく、在職中に定期的に実施すること。従業員エンゲージメントサーベイがデータを「量」で集めるのに対し、ステイインタビューは「質」で深掘りするアプローチです。
エグジットインタビューとの違い
比較項目 | ステイインタビュー | エグジットインタビュー |
実施タイミング | 在職中(定期的) | 退職決定後 |
目的 | 離職の予防・組織改善 | 離職原因の把握・将来への教訓 |
本音の出やすさ | 中(信頼関係に依存) | 高(もう辞めるので率直になりやすい) |
アクション反映 | 本人に直接還元できる | 次の採用・組織改善に間接的に還元 |
投資対効果 | 高(流出を未然に防げる) | 低(当該メンバーの流出は防げない) |
エグジットインタビューは「過去の検死」、ステイインタビューは「現在の健康診断」と考えるとわかりやすいでしょう。どちらか一方ではなく、両方を運用するのが理想的です。ステイインタビューで予防し、それでも離職が発生した場合はエグジットインタビューで学びを得る。この二重構造が、組織の学習サイクルを回す仕組みになります。
1on1との違い
「うちは毎週1on1やっているから大丈夫」——この誤解は多くの組織で見られます。
比較項目 | ステイインタビュー | 1on1 |
面談者 | 直属上司以外の第三者 | 直属の上司 |
頻度 | 四半期〜半年に1回 | 毎週〜隔週 |
主な話題 | 組織への帰属意識・キャリア展望・不満 | 業務進捗・短期的な課題・フィードバック |
データ活用 | 組織全体のトレンド分析に活用 | 個別マネジメントの文脈で完結 |
心理的安全性 | 第三者だから言えることがある | 上司との関係性がフィルターになる |
エンジニアが上司に対して「このチームの技術的な意思決定プロセスに不満がある」と直接言うのは難しい。しかし、人事や他部署のマネージャーが聞き手であれば、率直に話せるケースは少なくありません。
1on1とステイインタビューは代替関係ではなく、補完関係にあります。1on1の設計方法については別記事で詳しく解説しています。
エンゲージメントサーベイとの違い
「うちは半年に1回サーベイを実施しているから」という声も聞きます。しかし、エンゲージメントサーベイとステイインタビューも、やはり役割が異なります。
サーベイは組織全体の「健康診断」として有効ですが、5段階評価の数値だけでは「なぜその点数なのか」がわかりません。「技術環境への満足度: 2.8」というデータが出ても、それが「使っているフレームワークが古い」のか「CI/CDが遅い」のか「コードレビューの文化がない」のかは判別できない。
ステイインタビューはその「なぜ」を掘り下げる手段です。サーベイで課題の所在を特定し、ステイインタビューで原因を深掘りする。この組み合わせが最も効果的です。
2. エンジニア組織でステイインタビューが特に効く理由
2-1. エンジニアの転職市場は常に「売り手市場」
厚生労働省の「職業安定業務統計」によると、情報処理・通信技術者の有効求人倍率は一般的な職種の平均を大きく上回っており、エンジニアには常に転職の選択肢がある状態です。つまり、不満があれば「我慢する」よりも「移る」を選びやすい。
この前提に立つと、離職の予兆を早期に察知する仕組みは、採用と同等以上に重要です。
2-2. エンジニアは「言語化」が得意だが「自己開示」は苦手
エンジニアは論理的に考え、構造化して伝えることは得意です。しかし、自分の感情や組織への不満を自発的に言語化するのは苦手なケースが多い。
ステイインタビューは「聞かれたから答える」という構造を作ることで、エンジニアが本音を言語化するきっかけを提供します。特にリモートワーク環境では、雑談の中で不満が自然に表出する機会が減っているため、意図的に場を設ける意味がより大きくなっています。
2-3. エンジニアの離職理由は「給与」だけではない
エンジニアが転職を決める理由として上位に挙がるのは以下の要素です。
技術的な成長機会の停滞:同じ技術スタックで同じような開発を繰り返す閉塞感
技術的意思決定への参画度:アーキテクチャ選定やツール導入に発言権がない
コードベースの健全性:技術負債が放置されている、リファクタリングの時間が取れない
開発者体験(DevEx):CI/CDが遅い、ローカル開発環境の構築が煩雑
キャリアパスの不透明さ:IC(Individual Contributor)トラックが整備されていない
マネジメントの質:技術を理解しない上司のもとで働くストレス
評価制度への不信感:技術力が正しく評価されていないという感覚
これらは一般的なエンゲージメントサーベイでは拾いきれない、エンジニア固有の課題です。ステイインタビューであれば、こうした技術的・専門的な不満を具体的に聞き出すことができます。
エンジニアの離職防止の全体像については別記事で詳しく解説していますが、ステイインタビューはその中でも「予防」に特化した手法として位置づけられます。
2-4. 採用コストの回収に直結する
エンジニア1人の採用コストは、人材紹介経由で数十万〜百数十万円、ダイレクトリクルーティングでも数十万円規模が一般的です。これにオンボーディング期間(一般的に3〜6ヶ月)の生産性低下を加えると、1人あたりの入替コストは相当な金額に膨らみます。
ステイインタビューにかかるコストは、1人あたり30〜60分の面談時間と、その分析・対応の工数のみ。費用対効果は圧倒的に高い施策です。
2-5. 「サイレント退職」の早期発見
近年、「静かな退職(Quiet Quitting)」が話題になっています。退職届を出すわけではないが、最低限の業務しかこなさず、心理的にはすでに組織を離れている状態です。
エンジニア組織でのサイレント退職は、以下のような形で現れます。
コードレビューのコメントが激減する(以前は建設的なフィードバックを積極的にしていた)
技術的負債の指摘をしなくなる(「どうせ変わらない」という諦め)
チーム内の改善提案がゼロになる
新しい技術やツールへの関心を示さなくなる
これらは1on1やサーベイでは検出しにくい変化です。ステイインタビューで「最近、チームの改善に対するモチベーションはどうですか?」と直接聞くことで、サイレント退職の兆候を早期に察知できます。
2-6. チーム全体の連鎖退職を防ぐ
エンジニア組織では、1人の退職が連鎖退職を引き起こすケースが少なくありません。特に、テックリードやシニアエンジニアの退職は「あの人が辞めるなら、自分も」という心理を生みやすい。
ステイインタビューを定期的に実施していれば、チーム全体の温度感を把握できます。「最近、周囲のメンバーの様子で気になることはありますか?」という質問で、個人の問題ではなくチーム全体の問題を早期に発見できる可能性があります。
3. ステイインタビューの設計
3-1. 対象者の選定
理想は全エンジニアを対象にすることです。ただし、リソースが限られる場合は以下の優先順位で進めましょう。
最優先(月1回推奨):
入社1年以内のメンバー(最も離職リスクが高い時期)
直近でパフォーマンスが変化したメンバー(上がった・下がった問わず)
高優先(四半期に1回推奨):
テックリード・シニアエンジニア(影響範囲が大きい)
在籍3年以上のベテラン(マンネリ化のリスク)
通常(半年に1回推奨):
その他の全エンジニア
3-2. 面談者(インタビュアー)の選定
ステイインタビューの成否は、誰が聞くかで8割決まります。
推奨する面談者:
人事・HRBP(Human Resource Business Partner)
他チームのEM(エンジニアリングマネージャー)
外部のコーチ・コンサルタント(特にセンシティブな課題が予想される場合)
避けるべき面談者:
直属の上司(利害関係が強すぎる)
経営層(萎縮を招く)
技術理解のない人事担当者(エンジニア固有の課題を理解できない)
最も理想的なのは、技術バックグラウンドを持つHRBP、もしくは別チームのEMです。エンジニアは「技術の話が通じない人に不満を話しても無駄」と感じる傾向があるため、技術的な文脈を理解できる面談者が望ましい。
3-3. 実施形式と環境
基本設定:
時間: 30〜45分(初回は45分、2回目以降は30分が目安)
場所: 1対1の個室、またはオンライン(カメラON推奨)
記録: メモのみ。録音・録画は心理的安全性を損なうため避ける
スケジュール: 業務時間内に実施。「忙しいのに」と思わせない配慮が重要
面談の冒頭で伝えるべきこと:
面談の最初の3分で以下を明確に伝えましょう。これが信頼関係の土台になります。
「この面談はあなたの評価とは一切関係ありません」
「話した内容は、あなたの許可なく上司に個人名付きで共有しません」
「組織全体の改善に活かすために、匿名化した形で分析に使わせてもらう場合があります」
「答えたくない質問はスキップして構いません」
「今日話してくれた内容に対して、2週間以内にフォローアップの連絡をします」
この宣言を毎回省略せずに行うことが大切です。「前回も言ったから」と省略すると、形式的になり信頼感が薄れます。
3-4. 事前準備
面談者は事前に以下を把握しておきましょう。
対象者の入社時期・担当プロジェクト・技術スタック
直近のエンゲージメントサーベイの結果(あれば)
同チームの最近の離職者の退職理由
直属上司からの事前ヒアリング(ただし「こう聞いてほしい」という誘導は避ける)
4. エンジニア向けステイインタビュー質問テンプレート15問
カテゴリ1: 仕事の充実度・やりがい(5問)
Q1. 「最近の仕事で、一番楽しかった・充実していたのはどの瞬間ですか?」
狙い: ポジティブな話題から入ることで心理的ハードルを下げる。何に充実感を感じるかは、その人のモチベーション源泉を知る手がかりになる。
Q2. 「逆に、最近の仕事で一番ストレスを感じた場面はありますか?」
狙い: 具体的なストレス要因を特定する。「忙しかった」ではなく「何が」忙しかったのか、深掘りする。
Q3. 「朝起きて仕事に行くのが楽しみだと思えますか?もし思えないとしたら、何がその障害になっていますか?」
狙い: 日常的なモチベーションレベルを率直に確認する質問。回答の温度感で全体的な満足度がわかる。
Q4. 「今のプロジェクトで、自分の得意なことが活かせていると感じますか?」
狙い: スキルとアサインメントのミスマッチを検出する。エンジニアは得意領域で力を発揮できないと不満を溜めやすい。
Q5. 「もし今のチームの開発プロセスを1つだけ変えられるとしたら、何を変えますか?」
狙い: 開発フロー・ツール・コミュニケーション手法への具体的な不満を引き出す。
カテゴリ2: 技術環境・成長機会(5問)
Q6. 「今の技術スタックに対して、率直にどう感じていますか?使い続けたいですか?」
狙い: 技術的な停滞感や、学びたい技術とのギャップを把握する。エンジニアにとって技術スタックへの不満は転職動機の上位。
Q7. 「この半年で、エンジニアとして成長できたと感じますか?具体的にどんな部分で?」
狙い: 成長実感の有無を確認する。成長実感が薄れると、エンジニアは外に目を向け始める。
Q8. 「技術的なチャレンジや新しいことに挑戦する機会は十分にありますか?」
狙い: ルーティンワークの比率が高まっていないか確認する。イノベーション機会の欠如は離職の強いシグナル。
Q9. 「社内の技術的な意思決定プロセスについてどう思いますか?自分の意見が反映される場はありますか?」
狙い: 技術的裁量への満足度を確認する。トップダウンで技術選定が決まる組織では、シニアエンジニアほど不満を感じやすい。
Q10. 「学習・スキルアップのための時間やリソースは十分ですか?何か足りないものはありますか?」
狙い: 学習支援制度の実効性を確認する。制度があっても使えない(時間がない、申請が面倒)という問題はよくある。
カテゴリ3: 組織・キャリア展望(5問)
Q11. 「1年後、3年後に自分がどんなエンジニアになっていたいですか?今の環境でそれが実現できそうですか?」
狙い: キャリアビジョンと現在の環境のギャップを把握する。このギャップが大きいほど離職リスクが高い。
Q12. 「この会社で働き続ける一番の理由は何ですか?」
狙い: リテンション要因(何が引き留めになっているか)を特定する。この回答が「特にない」「惰性」であれば黄色信号。
Q13. 「もし転職を考えるとしたら、どんな理由がきっかけになりそうですか?」
狙い: 離職のトリガーを事前に把握する。仮定の質問として聞くことで、率直な回答を引き出しやすい。
Q14. 「チームや組織のコミュニケーションで、改善してほしいことはありますか?」
狙い: 人間関係やコミュニケーション上の課題を特定する。マネージャーとの関係、チーム内の情報共有、意思決定の透明性など。
Q15. 「今日話してくれた内容の中で、特に早く対応してほしいことはどれですか?」
狙い: 優先順位を本人に決めてもらうことで、フォローアップの期待値を合わせる。
質問のカスタマイズポイント
上記はテンプレートです。対象者の状況に合わせて以下のようにカスタマイズしてください。
入社1年未満: Q1〜Q5を重点的に。オンボーディングの満足度や、入社前の期待とのギャップに焦点を当てる
テックリード: Q6〜Q10を重点的に。技術戦略への関与度や、メンタリング負荷への不満を聞く
在籍3年以上: Q11〜Q14を重点的に。キャリアの停滞感やマンネリ化への本音を聞く
5. 面談結果の分析と組織改善への活用
5-1. 記録フォーマット
面談結果は以下の項目で構造化して記録しましょう。
満足度スコア(面談者の主観で5段階評価)
離職リスクレベル(高・中・低の3段階)
主な満足要因(上位3つ)
主な不満要因(上位3つ)
本人が望むアクション(具体的な施策や変化)
面談者コメント(言語化されなかった非言語的な印象も含む)
5-2. データの集約と傾向分析
個人の声を組織の課題として構造化するために、以下のフレームワークを使います。
「KEEP / PROBLEM / TRY」分析:
KEEP(維持すべきこと): 多くのエンジニアが満足している要素。これを失うと一気に離職が増える
PROBLEM(解決すべき課題): 複数のエンジニアから共通して出てくる不満。組織的なアクションが必要
TRY(試すべき施策): エンジニア自身から提案された改善アイデア。実現可能性を評価して実行に移す
5-3. アクションプランの策定
面談で得た情報は、90日以内に具体的なアクションに変換することが絶対条件です。
即座に対応可能(1〜2週間以内):
開発ツール・環境の改善(IDE、CI/CD設定の見直しなど)
1on1頻度の調整
プロジェクトアサインの見直し
短期で対応(1〜3ヶ月):
学習時間の確保(20%ルールの導入など)
技術選定プロセスへの参画機会の創出
キャリアパスの明確化と本人への共有
中期で対応(3〜6ヶ月):
報酬制度の見直し
ICトラックの整備
技術負債解消のロードマップ策定
5-4. 採用プロセスへのフィードバック
ステイインタビューの結果は、採用活動の改善にも直結します。
求人票(JD)の改善: エンジニアが入社後にギャップを感じている部分があれば、それは求人票の記載が実態と乖離している可能性がある。「期待していたほど新技術に触れる機会がない」という声が多ければ、JDで技術的チャレンジを過度にアピールしていないか確認する。
面接時のアトラクト改善: 「入社前に聞いていた話と違った」という声がある場合、面接でのアトラクトが実態と乖離している。面接官のトレーニングに反映する。
EVP(従業員価値提案)の見直し: 「この会社で働き続ける理由」として多く挙がる要素は、そのまま採用時のEVPに活用できる。逆に、採用時にアピールしていたが実際には満足度が低い要素は、EVPから外すか改善する。
6. ステイインタビュー導入の落とし穴と対策
6-1. 「何も変わらなかった」問題
最大のリスクは、面談を実施したにもかかわらず何のアクションも取らないこと。エンジニアは「聞かれたから正直に話した→何も変わらなかった」という経験をすると、二度と本音を話さなくなります。
対策:
面談後2週間以内に「聞いた内容のサマリー」と「対応予定のアクション」を本人に共有する
対応が難しい要望については、理由を正直に説明する
四半期ごとにアクションの進捗を報告する
6-2. 面談が「査定」と誤解される問題
エンジニアが「この面談の内容が評価に影響するのでは」と警戒すると、本音は出てきません。
対策:
面談の冒頭で「評価とは無関係であること」「個人を特定する形で上司に共有しないこと」を明示する
実際に面談内容を評価に使わないルールを組織として徹底する
初回は「試験的な導入」として位置づけ、参加を任意にする
6-3. 面談者のスキル不足問題
「なぜ辞めたいの?」のような詰問型の質問をしたり、エンジニアの不満に対して反論・弁明してしまう面談者がいると、制度そのものが形骸化します。
特にありがちなのが、エンジニアが「CI/CDが遅くてストレスです」と言った瞬間に「でも予算の都合で今すぐは対応できないんですよ」と弁明してしまうパターン。面談の目的は「聞くこと」であって「弁明すること」ではありません。まずは受け止め、後日アクションプランとして回答する流れを徹底しましょう。
対策:
面談者向けのトレーニングを実施する(最低2時間、ロールプレイ含む)
面談者のNG行動リストを作成する(反論する、アドバイスを始める、話を遮る、メモに集中して目を合わせないなど)
初期は面談者を2名体制(メイン+オブザーバー)にして相互フィードバックする
面談後に面談者同士で振り返りの時間を設け、「こう聞けばよかった」という改善点を共有する
6-4. エンジニアの「面談疲れ」問題
1on1、目標面談、360度フィードバック、エンゲージメントサーベイ...すでに多くの面談・調査が行われている組織では、さらにステイインタビューを追加することへの抵抗感がある。
対策:
既存の面談と統合できるものは統合する(例: 半期ごとの目標面談にステイインタビューの要素を追加)
ステイインタビューは30分以内に収める
「あなたの声が組織改善に直接つながった」という成功事例を社内で共有し、面談の価値を実感してもらう
6-5. リモートワーク環境での実施の難しさ
フルリモートやハイブリッドワークの組織では、対面での面談機会を設けにくい。オンラインだと非言語的なシグナル(表情、姿勢、声のトーン)を読み取りにくい。
対策:
オンラインの場合はカメラONを推奨(強制ではなく)
チャットベースのステイインタビュー(非同期形式)も選択肢として提供する
出社日がある場合はその日に合わせてスケジュールする
7. エンジニアの離職予兆シグナルとステイインタビューの活用
ステイインタビューは定期的に実施するものですが、以下の離職予兆シグナルが見られた場合は、通常のスケジュールを待たずに臨時実施を検討しましょう。
7-1. 行動面のシグナル
コミットログの減少: 以前と比べてコードのコミット頻度が明らかに落ちている
ミーティングでの発言減少: 技術ディスカッションや設計レビューで積極的に発言しなくなった
残業の急な減少: 以前は自発的に残って開発していたが、定時退社が増えた(ワークライフバランスの改善ではなく、モチベーション低下の可能性)
社内勉強会・LT会への参加停止: 以前は積極的に参加・登壇していたが、最近は参加しなくなった
LinkedInやビズリーチのプロフィール更新: SNSの転職系プロフィールが更新されている(直接指摘するのはNGだが、情報として把握しておく)
有給休暇の突然の増加: 面接のために半休を取得している可能性
7-2. 環境面のシグナル
同チームのメンバーが退職した直後: 「自分も」と考え始めるタイミング
昇給・昇格の見送り後: 期待していた評価が得られなかった場合
プロジェクトの炎上・長期化: 終わりの見えないプロジェクトに疲弊している場合
組織変更・マネージャー交代直後: 新しい環境への適応ストレス
7-3. ステイインタビューでの要注意回答
面談中の以下の回答パターンには特に注意してください。
「特に不満はないです」の連発: 不満がないのではなく、話す気がない可能性が高い
「前職では〜だった」の頻出: 現在の環境への不満を間接的に表現している
「3年後のキャリア」に具体性がない: この会社でのキャリアを考えていない可能性
「転職する理由があるとすれば」への即答: すでに具体的に考えている可能性
8. ステイインタビューの効果測定
8-1. 定量指標
離職率の変化: 導入前後で四半期ごとの離職率を比較する
平均在籍期間の変化: 特に入社1年以内の早期離職率に注目
エンゲージメントスコアの変化: サーベイを併用している場合はスコアの推移を確認
アクション実行率: ステイインタビューで出た課題に対して、何%が90日以内にアクション化されたか
8-2. 定性指標
面談での本音度の変化: 回を重ねるごとに、より具体的で率直な意見が出るようになっているか
面談への参加態度の変化: 「嫌々参加」から「自分から話したいことがある」に変わっているか
マネージャーへのフィードバック品質: ステイインタビューの結果がマネージャーの行動変容につながっているか
8-3. ROIの算出方法
ステイインタビューのROIは以下の式で概算できます。
コスト: 面談時間(1人30分×年4回×対象者数)+ 分析・レポート作成の工数 + 面談者のトレーニングコスト
効果: (導入前の年間離職者数 − 導入後の年間離職者数)× 1人あたりの入替コスト(採用コスト + オンボーディングコスト + 生産性低下コスト)
エンジニア1人の入替コストは、採用費用だけでなくオンボーディングや生産性低下も含めると、年収のかなりの割合に達するのが一般的です。仮に入替コストが200万円、ステイインタビューの実施コストが年間50万円だとしても、1人の離職を防ぐだけでROIは大幅にプラスになります。
9. ステイインタビュー導入ロードマップ
Phase 1: パイロット導入(1〜2ヶ月目)
対象: 5〜10名程度のエンジニア(離職リスクが高そうなメンバーを優先)
面談者: HRBPまたは他チームのEM(2名体制で相互フィードバック)
質問: 本記事のテンプレートをそのまま使用
目標: 面談の進め方を確立し、面談者のスキルを磨く
Phase 2: 本格展開(3〜4ヶ月目)
対象: 全エンジニア
面談者: トレーニングを受けた3〜5名のローテーション
質問: パイロットの結果を踏まえてカスタマイズ
目標: 組織全体の課題を構造化し、最初のアクションプランを策定
Phase 3: 定着・改善(5ヶ月目以降)
四半期ごとに定期実施
面談結果のトレンド分析をレポート化
アクションの進捗を全社に共有(個人が特定されない形で)
面談者のスキルアップ研修を半年に1回実施
各フェーズの具体的なタスクリスト
Phase 1で準備すべきもの:
ステイインタビューの目的・運用ルールを記載した社内ドキュメント(1〜2ページ程度)
質問テンプレート(本記事のものをベースにカスタマイズ)
記録フォーマット(Googleフォームやスプレッドシートで十分)
面談者のトレーニング資料(NG行動リスト、ロールプレイシナリオ)
対象者への事前案内メール(目的、所要時間、任意参加であること)
Phase 2で意識すべきポイント:
パイロットで出た課題(質問の言い回し、時間配分、記録方法)を反映してから展開する
面談者を3名以上に増やし、特定の面談者に負荷が集中しないようにする
最初のアクションプランは「小さく、確実に実行できるもの」を選ぶ。大きな制度変更よりも、開発環境の改善やツール導入など、エンジニアが「変わった」と実感できる施策を優先する
Phase 3で追跡すべき指標:
面談実施率(対象者のうち何%が実際に面談を受けたか)
アクション完了率(面談で出た課題のうち何%が90日以内に対応されたか)
離職率の変化(導入前後の比較)
面談に対する満足度(面談後の簡易アンケート)
10. ステイインタビューを他のリテンション施策と連携させる
ステイインタビューは単体でも効果がありますが、他のリテンション施策と組み合わせることで、より強力な離職防止の仕組みになります。
エグジットインタビューとの連携
ステイインタビューで「技術的な成長機会がない」という声が多いチームから実際に退職者が出た場合、エグジットインタビューで「ステイインタビューで伝えた課題は解決されましたか?」と聞くことで、ステイインタビュー制度自体の改善ポイントが見えてきます。
退職者がステイインタビューで以前から不満を表明していた場合、「聞いたのに対応が遅れた」という運用上の課題が浮き彫りになります。逆に、ステイインタビューでは満足と答えていたのに突然退職した場合は、質問設計や面談者のスキルに課題がある可能性があります。
1on1との連携
ステイインタビューで得た組織的な課題を、匿名化したうえでマネージャーに共有し、日常の1on1で個別にフォローする流れを作ります。
例えば、ステイインタビューで「技術選定への参画機会がない」という声が複数あった場合、マネージャーに「チーム内でアーキテクチャ検討会を月1回開催する」というアクションを提案する。その後の1on1で、メンバーの満足度の変化を確認する、という連携です。
キャリアパス制度との連携
ステイインタビューで「キャリアの見通しが立たない」という声が多い場合、それはキャリアパス制度自体の課題です。ICトラックの整備、スキルマトリクスの策定、昇格基準の明確化など、制度設計の見直しにつなげましょう。
ステイインタビューの回答データは、キャリアパス制度を設計する際の「生の声」として非常に価値があります。「どんなスキルを伸ばしたいか」「どんなポジションに興味があるか」という回答を集約することで、エンジニアが本当に求めているキャリアパスが見えてきます。
報酬制度との連携
「報酬に不満がある」という声がステイインタビューで出た場合、それが「絶対額の問題」なのか「同僚との比較の問題」なのか「市場相場との乖離の問題」なのかを深掘りすることで、報酬制度の改善ポイントが明確になります。
多くの場合、エンジニアの報酬への不満は「金額」だけではなく「透明性」に起因します。「なぜ自分がこの給与なのか」「何をすれば上がるのか」が不明確な組織では、絶対額が高くても不満が溜まりやすい。ステイインタビューでこうした声を拾い、給与レンジの公開や昇給基準の明確化につなげることが重要です。
FAQ(よくある質問)
Q1. ステイインタビューの適切な頻度は?
A. 四半期に1回が理想です。半年に1回でも効果はありますが、変化の速いエンジニア組織では四半期が推奨されます。入社1年以内のメンバーは月1回の実施を推奨します。頻度が高すぎると「面談疲れ」を起こすので、1回30分以内に収めることも重要です。
Q2. 小規模チーム(エンジニア5人以下)でも導入すべきですか?
A. はい、むしろ小規模チームほど1人の離職のインパクトが大きいため、導入する価値があります。ただし、小規模チームでは面談者の選定が難しい(社内に「第三者」がいない)ため、外部のコーチやアドバイザーの活用を検討してください。あるいは経営者自身が面談者になるケースもありますが、その場合は「評価とは無関係」という信頼関係の構築が前提です。
Q3. エンジニアが「面談を受けたくない」と言った場合はどうすべきですか?
A. 参加は任意にしてください。強制すると本音は出てきません。ただし「受けたくない」という反応自体が情報です。その理由を丁寧にヒアリングしましょう。「前回話したのに何も変わらなかった」「忙しくてそれどころではない」など、拒否の理由に組織課題が隠れていることがあります。
Q4. ステイインタビューの結果を上司に共有してもいいですか?
A. 個人を特定できる形での共有は原則NGです。ただし、組織全体のトレンドとして匿名化した形(「チームの50%が技術スタックに不満を感じている」など)で共有するのは推奨します。個別の課題で上司の行動変容が必要な場合は、本人の同意を得たうえで共有しましょう。
Q5. エンゲージメントサーベイを実施していれば、ステイインタビューは不要ですか?
A. 不要ではありません。サーベイは「広く浅く」定量的にデータを集めるのに対し、ステイインタビューは「深く狭く」定性的な洞察を得る手法です。サーベイで「技術環境への満足度が低い」というデータが出ても、具体的に何が問題なのかはわかりません。ステイインタビューで「CI/CDのパイプラインが遅くて毎日30分待たされる」という具体的な課題まで深掘りできます。両方を組み合わせることで、課題の「発見」と「深掘り」を効率的に行えます。
Q6. ステイインタビューで「転職を考えている」と言われたらどうすべきですか?
A. まず、正直に話してくれたことに感謝を伝えてください。次に「何がきっかけですか?」「どうなれば続けたいと思えますか?」と深掘りします。カウンターオファー(条件提示での引き留め)に飛びつくのではなく、根本的な課題を理解することが重要です。課題が組織的に解決可能なものであれば、アクションプランを提示してください。ただし、対応を約束したのに実行しないのは最悪のパターンです。約束したことは必ず実行しましょう。
Q7. ステイインタビューの導入コストはどのくらいですか?
A. 基本的には面談時間の人件費のみです。20人のエンジニアに対して四半期に1回・30分ずつ実施する場合、面談時間は年間40時間(面談者の時間)。これに分析・レポート作成の工数を加えても、年間60〜80時間程度です。外部コーチを使う場合は1回あたり数万円の追加コストがかかりますが、エンジニア1人の離職防止効果(100〜300万円)を考えれば十分に回収できる投資です。
Q8. 面談で出た不満に対応できない場合はどうすべきですか?
A. 正直に「現時点では対応が難しい」と伝えてください。その際、なぜ難しいのか(予算の制約、組織構造の問題、技術的な制約など)を具体的に説明することが重要です。「何もできません」で終わらせるのではなく、「この部分は対応できないが、代わりにこういう形でサポートできないか検討する」という姿勢を見せましょう。エンジニアは合理的な理由があれば納得してくれることが多い。逆に、理由を説明せずに放置するのが最も信頼を損なうパターンです。
Q9. 業務委託やフリーランスのエンジニアにもステイインタビューを実施すべきですか?
A. 契約形態に関わらず、チームに深く関わっているメンバーには実施を検討する価値があります。特に、長期契約の業務委託エンジニアは正社員と同様にチームの中核を担っているケースが多く、突然の契約終了はチームに大きなダメージを与えます。ただし、質問内容は調整が必要です。「キャリアパス」よりも「プロジェクトへの満足度」「コミュニケーションの質」「契約更新の意向」にフォーカスしましょう。
Q10. ステイインタビューの結果を経営層にどう報告すべきですか?
A. 個人を特定できない形で、組織全体の傾向を数値化して報告するのが効果的です。例えば、「エンジニアの60%が技術的成長機会に不満を感じている」「離職リスクが高いと判定されたメンバーが全体の20%」といった形です。経営層が意思決定しやすいように、課題と提案をセットで報告しましょう。「技術的成長機会への不満→学習時間の制度化(20%ルール導入)→月次コスト○○万円→期待効果:離職率X%改善」のように、コストと効果を明示すると予算獲得にもつながります。
まとめ:エンジニアに「ここで働き続けたい」と思わせる組織をつくる
ステイインタビューは、エンジニアの離職を防ぐための「最も費用対効果の高い施策」の一つです。
本記事のポイントを改めて整理します。
ステイインタビューの本質:
エグジットインタビュー(退職後)ではなく、在職中に定期的にエンジニアの声を聞く予防的アプローチ
1on1やエンゲージメントサーベイとは目的・設計が異なり、補完関係にある
直属の上司ではなく第三者が実施することで、本音を引き出しやすくする
導入のポイント:
面談者の選定が成否の8割を決める。技術バックグラウンドを持つHRBPか他チームのEMが理想
質問は「技術環境」「成長実感」「キャリア展望」の3軸で構成する
面談結果は90日以内に必ずアクションに変換する。「聞いたけど何も変わらなかった」は制度を殺す
成功のための3つの条件:
経営層のコミットメント:ステイインタビューで出た課題に予算・リソースを割く意思決定ができること
面談者のスキル:傾聴・深掘り・記録のスキルを持つ面談者を育成すること
継続的な改善:面談の設計自体も四半期ごとに振り返り、改善し続けること
エンジニア採用にかける労力とコストを考えれば、今いるエンジニアの声を丁寧に聞き、環境を改善し続けることが、結果として最も効率的な「採用戦略」になります。
導入のハードルは低い。必要なのは、面談のための30分と、聞いた内容を必ずアクションに変える覚悟だけです。
まずはパイロットとして5人からでも始めてみてください。エンジニアが「ここでは自分の声が聞かれている」と感じた瞬間から、組織は変わり始めます。
ステイインタビューと合わせて、エグジットインタビューの活用やエンゲージメントサーベイの導入も検討してみてください。リテンション施策は単発ではなく、複数の手法を組み合わせることで効果が最大化します。
また、ステイインタビューで得た知見は採用ブランディングやキャリアパス設計にも活かせます。「エンジニアが本当に求めているもの」を理解することが、採用でもリテンションでも成功の鍵です。
エンジニアの定着率に課題を感じている方は、お気軽にご相談ください。techcellarでは、エンジニア採用の戦略設計からリテンション施策の構築まで、一貫したサポートを提供しています。
採用のお悩み、
エンジニアに相談
しませんか?