1on1を毎週設けているのに、退職の申し出は突然やってくる——「もっと早く話してくれればよかったのに」という後悔を、リーダーとして繰り返す場面があります。

「1on1を設けている」と「対話できている」は別のこと

多くのチームで1on1は習慣になりつつあります。週1回30分、カレンダーは埋まっている。ただ実態は進捗確認と相談対応で終わっていることが多い。

よくあるのは、リーダーが「最近どう？」と聞いて、エンジニアが「特に問題ないです」と答えるパターンです。これは対話ではなく、報告の往復です。エンジニアが「何を言っても変わらない」「忙しそうな上司に余計な話はしたくない」と一度でも感じると、本音は永遠に出てこなくなります。

あるHRの調査では、エンジニアが転職を決意する理由の上位は「成長機会の欠如」と「上司・チームとの関係悪化」です。そして多くの場合、その不満は退職の1〜2ヶ月前まで、上司に一切共有されていません。

なぜエンジニアは本音を話さないのか

構造的な理由が3つあります。

フィードバックが一方通行になっている

「もっとドキュメントを書いてほしい」「レビューが遅い」——リーダーからエンジニアへのフィードバックは自然に発生しますが、逆方向の指摘は起きにくい。評価権を持つ相手に問題提起するコストは、想像以上に高い。

「相談」がタスクとして処理される

「週2回のチームへの飲み誘いがしんどい」「設計レビュー前に誰かと壁打ちしたい」——こういった声に対して、「わかった、対応策を考えておく」と即レスするのは一見良さそうに見えます。でもこれでは「また仕事を増やしてしまった」と感じて、次から話すのをやめてしまう。

緊急でない話が積み上がる

将来の技術選択の不安、チームの雰囲気の変化、モチベーションの揺れ——これらは緊急でも重要でもなく見えるけれど、本人にとっては大事なことです。これが話される余白がないと、じわじわ蓄積して急な離職につながります。

対話が生まれる1on1の3つの設計原則

1. 最初の5分は「聴くだけ」と決める

「最近気になってることある？」と聞いて、黙って待ちます。沈黙に耐えずリーダーが話し始めると、エンジニアは「答えを急かされている」と感じる。5分沈黙でも聞き続けることが、「話しても安全だ」という感覚を積み上げていきます。

2. リーダー自身の迷いを先に出す

「今週、自分もこの判断で迷った」「このアーキテクチャ選択、実は自信がなかった」——リーダーが先に不確実さを話すと、エンジニアも「自分も言っていい」と感じます。完璧さを演じるリーダーには、弱音は届かない。

3. 「相談」を即解決しない

問題を打ち明けられたとき、すぐ解決策を出すのをやめます。まず「それはしんどかったね」「どうしたいと思ってる？」と受け止める。エンジニアが欲しいのは、アドバイスより「ちゃんと聞いてもらえた」という感覚であることがほとんどです。1on1の翌日に自分で動き始めるエンジニアは、アドバイスを受けた人ではなく、聴いてもらえた人のほうが多い。

さいごに

1on1を「制度として設ける」ことと、「対話の場として機能させる」ことの間には、大きな差があります。エンジニアが本音を話すかどうかは、テクニックではなく、リーダーが「聴く姿勢」を持ち続けられるかどうかにかかっています。

チームビルディングや開発組織のカルチャーに共感していただけた方、採用についてお気軽にお問い合わせください。