1on1で話すことがないエンジニア|2つの原因と話題の作り方
「話すことがない」には2種類ある
1on1の直前になると「今日、何を話せばいいんだろう」と頭が真っ白になる経験はないでしょうか。「話すことがない」という悩みを抱えるエンジニアは少なくありませんが、その原因を一括りにしてしまうと、的外れな対処をしてしまいます。「話すことがない」には、まったく性質の異なる2つのタイプが存在します。この章ではまず、自分がどちらに近いかを確認してください。タイプによって必要なアクションが正反対になるため、ここでの自己診断が記事全体の読み方を決めます。
本当に何もない状態——関心が言語化できていない
日々の業務をこなすことに集中しているうちに、「困っていること」や「上司に聞きたいこと」が意識の表面に出てこなくなる状態です。「業務はうまく回っている。問題もない。だから話すことがない」という等式が成立しているタイプと言えます。
このタイプの根本にあるのは、関心や気づきが言語化される前に業務のフローに吸収されてしまっていることです。コードを書き、レビューをこなし、タスクを消化する毎日の中で、「今自分はどんな技術的な興味を持っているか」「この仕事を通じて何を伸ばしたいか」といった問いに向き合う時間が取れていません。話題の種が存在しないのではなく、種が言語化される前に埋もれているのです。後半の章では、業務の具体から話題を掘り起こす方法を説明します。
あるのに言えない状態——心理的安全性の問題
もう一方のタイプは、言いたいことや聞きたいことは実際にあるが、1on1という場で口にできないという状態です。「こんな小さいことを相談してもいいのか」「この話をしたら評価が下がるかもしれない」「上司を困らせてしまうかもしれない」——そういった抑圧が、言葉が出てくる直前で止めてしまいます。
このタイプに「話題リスト」を渡しても根本的な解決にはなりません。話題を提案しても、それを言い出せない理由はコンテンツの不足ではなく、場の安全性にあるからです。自分がこちらのタイプに近いと感じた方は、後の章「関係性の警告サイン」を特に丁寧に読んでください。話せない状態が続いている場合、それは関係性の健康度を示すサインとして捉える必要があります。
エンジニアが1on1で話しにくい構造的な理由
「1on1がうまく話せないのは、自分のコミュニケーション能力が低いからだ」と感じているエンジニアは多いと思いますが、それは誤解です。話しにくさは能力の問題ではなく、エンジニアという職種の認知スタイルと、一般的な1on1フォーマットのミスマッチから生じる構造的な問題です。この構造を理解するだけで、1on1への向き合い方が変わります。
「具体・コード・タスク」で動く職種特性
エンジニアは日常的に、問題を具体として捉え、コードやシステムという形で解決します。「このバグはどこに原因があるか」「このAPIはどう設計するか」——常に具体の文脈の上で思考が動いています。
この職種特性は強みですが、1on1の場では別の側面が出ます。「最近どうですか?」「キャリアはどう考えていますか?」といった抽象的なオープンクエスチョンに対して、即座に答えることが難しくなるのです。エンジニアの思考回路は、まず文脈(チケット・コード・ログ)があってから動き始めるため、何の文脈もない問いに突然答えるのは、それ自体がコストの高い処理です。
「最近どうですか?」式の問いに答えるのが苦手な理由
「最近どう?」という問いは、答えの前提となる文脈を話す側が自分で用意する必要があります。この処理はエンジニアが普段の業務でやっていないことです。業務では問題が先にあり、エンジニアはそれを分解して解決します。問題のない状態でゼロから「最近の状態」を言語化するのは、専用の準備がないと難しい作業です。
これは能力の問題ではなく、認知スタイルの問題です。解決策は「抽象的な問いに答える訓練をする」ことではなく、「エンジニアが話しやすい入口を使う」ことです。次の章以降では、その入口の具体的な作り方を説明します。
技術的な話を1on1に持ち込んでいい
「1on1はキャリアや人間関係の話をする場であり、技術的な話はチームMTGや設計レビューでやるもの」という思い込みが、エンジニアの話題の選択肢を無意識のうちに狭めています。しかし、この思い込みは誤りです。技術的な話は1on1で積極的に使える話題です。
コードレビューで受け取ったコメントについて「なぜこの設計が推奨されるのか理解できていない」という疑問、今週取り組んだPRで一番悩んだ実装上の判断、チームで採用を検討している技術の選定で感じている迷い——これらはすべて、1on1の話題として正当です。むしろ、エンジニアにとってはこういった技術の具体から入るのが最もスムーズに話が展開します。
技術的な話題は、そのままキャリアや成長の話に接続することもできます。「今回の設計判断を通じて、アーキテクチャの領域をもっと深めたいと思った」という流れは、技術の話から始まってキャリアの話へと自然につながる展開の一例です。「技術の話をしていいですか」とわざわざ断る必要はありません。自分の仕事の現場から出てきた話題であれば、1on1の素材として十分に機能します。
コード・タスクから話題を作る実践
「何を話せばいいかわからない」という状態に直接答えるなら、直近の業務を話題の入口として使う方法が最も即効性があります。エンジニアには常にコード・タスク・レビューという具体的な素材があります。それを振り返る問いさえ持っていれば、話題は自然に出てきます。
「今週一番時間がかかった実装はどこか」「先週もらったレビューコメントで印象に残っているものは何か」「今のプロジェクトで技術的に一番面白いと感じている部分はどこか」——こういった問いは、エンジニアにとって即座にイメージが浮かぶ種類のものです。答えるためにゼロから文脈を作る必要がなく、目の前の業務がそのまま話題になります。
キャリアの話に展開させたいときは、「そのスキルをこれからどう深めたいか」「このプロジェクトで伸びていると感じている能力はあるか」という問いを続けることで、業務の具体からキャリアの軸へと自然につなげることができます。
キャリア・成長につながる話題の作り方
1on1でキャリアの話をするというと、「5年後のビジョン」や「転職するかどうか」といった大きな話をしなければならないと感じるエンジニアが多いようです。しかし実際には、日常の業務から逆算して話題を作ることが可能です。
「今のプロジェクトで自分が伸ばせているスキルはどれか」「次に触りたい技術領域はあるか」「今の役割で身についていないが、身につけたいと感じていることはあるか」——これらは半年先・1年先を見据えたキャリアの問いですが、現在の仕事と直接結びついているため、言語化のハードルが低くなります。
1on1でキャリアの話が出ないことを「自分はキャリアビジョンを持っていないから」と自責するエンジニアもいますが、多くの場合は「問いの立て方が大きすぎる」だけです。今日の業務を入口にして、少し先の自分に向けた話題を作ることが、キャリアの対話への現実的な入り方です。
「話すことがない」が続くとき——関係性の警告サイン
「話題はあるが1on1で何ヶ月も話せていない」という状態が続いているとき、それはコンテンツの不足ではなく関係性の問題を示している可能性が高いです。この視点を持つことが、状態を変えるための最初のステップです。
「話すことがない」状態が長期間続いている場合、「良い話題を見つければ解決する」という発想で対処しても根本は変わりません。話題があっても言い出せない理由が関係性にあるなら、話題の補充は問題に触れていないからです。「この人に本音を話しても安全か」という判断が先にあり、その判断が「安全でない」側に傾いているとき、話題があっても口には出ません。話すことがない状態を「コンテンツの問題」と「関係性の問題」に切り分けて診断することが必要です。
関係性の健康度チェックリスト
以下の問いに対して「はい」と答えられるかどうかで、関係性の健康度を確認できます。
- 上司に失敗やミスをそのまま報告できているか
- 「これを聞いてもいいか」と迷わずに質問を出せているか
- 業務の不満や違和感を口に出したことがあるか
- 将来の不安や迷いを1on1で話したことがあるか
- 自分の意見が上司の見方と違うとき、その違いを表明できているか
「はい」と答えられる項目が少ない場合、「話すことがない」の原因は関係性の問題として取り組む必要があります。話題の問題ではありません。
心理的安全性を上げる具体的な行動
関係性の問題として診断された場合、一度の1on1で大きく変えることよりも、小さい行動の積み重ねが効果的です。
まず、小さい自己開示から始めることを勧めます。「今週のこの実装、少し迷いました」「このレビューコメント、最初は意図がよくわかりませんでした」——業務上の小さな本音を出すことから、場の空気は少しずつ変わります。次に、「1on1の前に話題を一つだけメモする」習慣を作ることです。一つ決めておくだけで冒頭の沈黙を防げます。さらに踏み込める場合は、「1on1で何か話してほしいテーマがあれば教えてください」と上司に直接聞くことも有効です。
マネージャー向け:エンジニアから話を引き出す質問術
このセクションは、部下のエンジニアが1on1でなかなか話してくれないと感じているエンジニアマネージャー向けです。「話してくれないのはなぜか」という疑問の答えの多くは、問いの立て方にあります。エンジニアは「最近どうですか?」には答えにくいですが、業務の具体を入口にした問いには答えやすい特性があります。問いの設計を変えるだけで、1on1の密度は大きく変わります。
業務ベースの問いかけパターン集(エンジニア専用)
業務の具体をトリガーにした問いを使うと、エンジニアが答えやすい文脈を最初から用意できます。以下は実際に使えるパターンです。
- 「直近のPRで一番時間がかかった実装はどこでしたか?」
- 「今週のコードレビューで、自分の設計と違う方向性のコメントはありましたか?」
- 「今のスプリントで、見積もりより難しかったタスクはありましたか?」
- 「最近触った技術やライブラリで、面白いと思ったものはありますか?」
- 「今のプロジェクトで『ここはもっとこうしたい』と感じている部分はありますか?」
- 「最後にデプロイしたとき、気になったことや緊張した部分はありましたか?」
- 「最近、技術的に迷った判断はありましたか?どちらを選びましたか?」
- 「この半年で自分の中で一番成長した部分はどこだと思いますか?」
- 「チームのコードベースで、もっとこうなったらいいなと思う箇所はありますか?」
- 「今の技術スタックで、もっと深く学びたいものはありますか?」
「なぜ」より「何が」「どうだった」から入ることで、答えやすさが大きく変わります。
NG例と修正案
エンジニアに対してやりがちな問いかけのミスを、具体的な対比で示します。
| NGパターン | 問題点 | 修正案 |
|---|---|---|
| 「最近の調子はどうですか?」 | 文脈ゼロで答えの前提がない | 「今週のタスクで一番手応えがあったのはどれですか?」 |
| 「5年後どうなりたいですか?」 | 時間軸が長すぎ、現場の実感から遠い | 「今の仕事でもっと深めたいスキルはありますか?」 |
| 「何か問題ありますか?」 | 「問題を言わなければならない」という圧を生む | 「難しいと感じたこと、何かありましたか?」 |
| 「評価のために何が必要か考えていますか?」 | 評価への言及が心理的プレッシャーになる | 「今期取り組んでいることで、手応えを感じているものはありますか?」 |
1on1を続ける根拠——そもそも何のための時間か
1on1を「面倒くさい」「意味がない」と感じるとき、多くの場合その1on1は業務報告になっています。業務報告は日報やチャットでもできるため、専用の時間を取る意味が薄れてしまいます。
1on1は業務報告の場ではなく、上司との関係の基盤を少しずつ積み上げる時間です。話せなかった週があっても、継続すること自体に意味があります。普段から積み上げていない関係は、緊急時・評価時・重要な相談が必要になったときに機能しません。今日の1on1がうまくいかなくても、続けることで関係の地盤が少しずつ変わっていきます。


