技術力には自信があるエンジニアが、なぜかチームで力を発揮できない理由はどこにあるのか

ある日、同僚から「田中さんって、なんで設計レビューで毎回空気が重くなるんですかね」と言われたことがある。その言葉は、自分が思っていた以上にダメージが大きかった。コードの品質には自信があった。設計の根拠も、誰よりも時間をかけて考えた。ただ、その場の空気が重くなっていたことに、自分はまったく気づいていなかった。

技術力に自信があるエンジニアほど、「正しいことを言っているのになぜ伝わらないのか」という壁にぶつかることがある。コードは論理で動く。バグには必ず原因がある。だから、技術的に正しいことを正確に伝えれば、チームは動くはずだと思いがちだ。しかし現実は、技術の正確さと人間関係の動き方は、まったく別の原理で動いている。

チームで成果を出し続けているエンジニアが持っているのは、高い技術力だけではない。技術を活かすための「人との関わり方」も、鍛えてきているのだ。これは天性の才能ではない。学べるスキルであり、意識することで確実に変えられる。

この記事では、技術力がありながらもチームで力を発揮できない状態から抜け出すために、実際に変わったきっかけと、思考を変えてくれた3冊の本とともに紹介する。コードの外側にある「チームで機能するための力」を、エンジニアとして意識的に鍛えていくヒントを伝えたい。

結論から言うと、技術力があるのにチームで力を発揮できないエンジニアに足りないのは、多くの場合「相手の立場への関心」と「課題の分離」と「短く伝える力」の三つだ。技術スキルとは別の回路で動くこれらの力を意識的に鍛えることで、チームとの関係は確実に変わる。

「技術で黙らせる」という発想が、チームの停滞を生む

エンジニアの世界では、技術的に正しいことが強さになる。コードで証明できること、ベンチマークで示せること、ドキュメントで根拠を示せること。これらは確かに価値を持つ。だが、この論理がコードの外に出たとき、つまり人間関係の場面に持ち込まれたとき、思わぬ摩擦を生むことがある。

「技術的に正しいのだから、相手が納得するのは当然だ」という前提で話すと、相手は内容より前に「圧」を受け取る。内容がどれだけ正確でも、受け取る側の感情が閉じていれば、言葉は届かない。これは感情論ではなく、人間の情報処理の仕組みの話だ。人は、感情的に安全だと感じた相手からの情報を受け入れやすい。

実際に起きたことを振り返ると、自分が「正しいことを言っている」と確信しているときほど、話し方が一方的になっていたと思う。相手が「それは違う」と感じているとき、その感情を汲み取る前に、「いや、データがこう示している」と返してしまっていた。技術的には正しかった。でも、チームとしての関係は確実に悪化していた。

コードレビューで「指摘の正確さ」より大切なもの

コードレビューは、エンジニアが最も頻繁に他者と技術を介してやり取りする場だ。ここで「指摘の正確さ」だけに注力していると、相手との関係が少しずつ悪化することがある。「このコードはここが悪い」という事実が正確でも、伝え方によって相手が受け取るものはまったく変わる。

「なぜこの設計を選んだのか教えてもらえますか？」という問いかけは、相手の意図を尊重しながら課題を探る問いだ。「この設計だとXXのケースで問題が起きます」は事実の指摘だ。どちらも技術的に同じことを伝えようとしているが、前者は相手の思考を引き出し、後者は相手を守りの姿勢に追い込む。問いかけから始めるレビューは、相手の理解を深め、次のコードの質を上げる。

Audibleで「人を動かす」を聴いてから、コードレビューのコメントの書き方が変わった。相手の立場を先に考えること、批判より問いかけを使うこと、良い点を先に認めてから改善点を伝えること。これらは技術的な知識ではないが、レビューの効果を大きく変えた。

優秀なエンジニアが孤立していくパターン

技術力の高いエンジニアが孤立するパターンにはいくつかの共通点がある。一つは、他者の提案を技術的に否定することへの抵抗感の低さだ。「その実装だとパフォーマンスが落ちる」「そのアーキテクチャは拡張性がない」という指摘は、技術的には正しくても、繰り返されるとチームの中でその人の発言が「来ると思っていた」という空気を作ってしまう。

もう一つは、自分の作業ペースや品質基準をチームの標準として無意識に設定してしまうことだ。自分が高い基準でコードを書けることは強みだが、そのペースや基準を他のメンバーに暗黙的に求めてしまうと、チームの心理的安全性が下がる。「あの人の基準に合わせられない」という感覚がメンバーの中に広がると、質問や相談が減り、チームのコミュニケーション量が落ちていく。

技術力は「正しいコードを書く力」だが、チームで力を発揮するには「正しいことを正しく伝え、相手が動けるよう支援する力」が別途必要だ。この二つを混同したまま、技術力を磨き続けても、チームとしての成果は伸びにくい。

「人を動かす」が教えてくれた、人間関係の根本原則

デール・カーネギーが1936年に著した「人を動かす」（How to Win Friends and Influence People）は、80年以上読み継がれてきた人間関係の古典だ。エンジニアが読む本ではないと感じる人もいるかもしれないが、読んでみると「これはコードレビューの話だ」「1on1のやり方の話だ」と感じる場面が何度も出てくる。

カーネギーが繰り返し強調するのは「相手への真の関心を持つこと」だ。技術的な議論の場では、相手の意見の「正しさ」に注目するが、カーネギーは相手が「なぜそう思っているか」、つまりその人の立場や経験、感情的な背景に関心を向けることが、人間関係の出発点だと言う。この視点を持つだけで、チームとのやり取りの質は変わる。

批判しない、感謝する、相手の関心を考える

カーネギーが提唱する人間関係の原則の中で、エンジニアの日常に直接適用できるものがいくつかある。「批判も非難もしない」「正直で誠実な評価を与える」「相手の関心を考えて話す」がその代表だ。いずれも感情的な配慮のように見えるが、実際には行動の原則として機能する。

コードレビューで相手の実装を批判する前に、まず「この実装にした理由を教えてください」と聞く。ミーティングで提案を却下する前に、「その考え方のどこが面白いか」を一度受け止める。こうした小さな行動の変化が、相手の心理的安全性を高め、チームとしての議論の質を上げる。技術的な正しさは変わらないが、チームとしての動き方が変わる。

Audibleで「人を動かす」を繰り返し聴くうちに気づいたのは、これらの原則が「優しくする」ことではなく「効果的に機能する」ことを目指していることだ。感情的な配慮は、目的のない親切ではなく、チームとして成果を出すための合理的な選択だ、という視点がカーネギーにはある。

チームの技術決定が通りやすくなった理由

「人を動かす」の原則を意識し始めてから、自分の技術的な提案がチームに受け入れられるペースが明らかに変わった。提案の内容が変わったわけではない。伝え方が変わったのだ。

具体的には、技術的な変更を提案するとき、まず「現状の課題」を相手の言葉で整理してから、「こうすることでその課題が解決できると思う」という流れで話すようにした。相手が感じている課題を先に言語化することで、提案が「押しつけ」ではなく「解決策の提示」として受け取られやすくなる。これはカーネギーが言う「相手の欲することを語れ」という原則の実践だ。

「正しいことを言えば通る」という考えは、技術の世界では通用するが、人間の意思決定の場では通用しないことがある。人は、感情的に受け入れられると感じた提案を受け入れやすい。カーネギーの原則は、この人間の特性を踏まえた実践的な技術だ。

アドラー心理学が解いてくれた「チームの難しさ」

岸見一郎・古賀史健による「嫌われる勇気」（ダイヤモンド社）は、アドラー心理学を哲学者と青年の対話形式で解説した一冊だ。タイトルから「自分勝手に生きる本」と思われることがあるが、内容はまったく逆で、人間関係をどう健全に構築するかという実践的な哲学書だ。

この本がエンジニアの仕事に響くのは、「課題の分離」という概念があるからだ。アドラーは「すべての悩みは対人関係から来る」と言い、その解決のカギとして「誰の課題か」を分離することを提唱している。

課題の分離という考え方

課題の分離とは、「これは誰の課題か」を問い、自分の課題と他者の課題を明確に分けることだ。コードレビューでいえば、「自分の課題」はレビューコメントを誠実に書くことだ。そのコメントを相手がどう受け取るか、改善するかどうかは「相手の課題」だ。ここを混同すると、「なぜこんなに親切に書いたのに、また同じミスをするのか」というストレスが生まれる。

チームでの議論でも同じだ。自分の課題は「自分の考えを誠実に伝えること」だ。相手がそれをどう評価するか、採用するかどうかは相手の課題だ。この境界線を引くことで、「自分の提案が通らなかった」というストレスを適切に処理できるようになる。「伝えたけれど採用されなかった。次はより分かりやすく伝えよう」と向き直れるようになる。

課題の分離を意識するようになってから、チームでのやり取りのストレスが明確に減った。「相手がどう動くか」をコントロールしようとするのをやめて、「自分がどう伝えるか」だけに集中することで、エネルギーの使い方が変わった。

貢献感がモチベーションの源泉になる

アドラー心理学のもう一つの核心は「貢献感」だ。人は他者や共同体への貢献を感じているとき、幸福感を得られるとアドラーは言う。チームにおいても、自分の技術がチームの役に立っていると感じられるとき、エンジニアとしてのモチベーションは持続しやすい。

逆に言えば、「自分だけが正しく、他のメンバーのコードはいつも問題がある」という感覚でいると、貢献感ではなく優越感または孤立感に向かいやすい。チームへの貢献感を持つためには、メンバーの強みを見つけ、その成長を支援する視点が必要だ。これは管理職だけに求められることではなく、チームの一員として働くすべてのエンジニアに当てはまる。

自分が「チームのために動いている」という感覚は、結果として自分自身のパフォーマンスを上げる。貢献感は、エンジニアとしての持続的なモチベーションの源泉だ。「嫌われる勇気」はこの視点を哲学的に、そして実践的に与えてくれる。

伝える力の前に、「整理する力」があった

「1分で話せ」（SBクリエイティブ）で伊藤羊一が語るのは、1分で話せない理由のほとんどは「自分の中が整理されていないから」だということだ。相手への伝え方を変える前に、自分の中で伝えたいことを整理する力が必要だ、という主張は、エンジニアの日常に直接刺さる。

1分で話せないのは、自分の中が整理されていないから

ミーティングで技術的な提案をするとき、説明が長くなってしまうことがある。背景から説明して、問題点を整理して、解決策を示して、懸念点を先回りして答えて。気づくと10分話していて、聞いている側の顔は疲れ始めている。

伊藤は「結論から話す」ことを強調するが、その前提として「自分の中で結論が明確になっていること」が必要だと言う。結論が曖昧なまま話し始めると、必然的に説明が長くなり、聞き手は「で、何が言いたいの？」という状態になる。

技術的な説明はどうしても詳細を語りたくなる。でも、聞いている側が知りたいのは多くの場合、「何が問題で、どうすれば解決するか」というシンプルな問いへの答えだ。1分で言えない提案は、まだ自分の中で整理が終わっていないというシグナルかもしれない。

短く伝えることがチームの信頼を作る

「あの人の話は分かりやすい」という評価を得るエンジニアは、情報量が少ないのではなく、聴き手が必要としている情報を的確に届けるのが上手い。これは技術的な知識の量とは関係がない。伝え方の技術だ。

1分で話せる提案ができると、チームの意思決定のスピードが上がる。「まず試してみよう」「もう少し詳細を詰めよう」という判断が早くなる。説明の長さが意思決定のボトルネックになっていた場面が、シンプルな提案によって解消される。

Audibleで「1分で話せ」を通勤中に聴いてから、技術的な提案を社内Slackに書く前に「1分で言えるか」を確認するようにした。書いた内容が1分で読めないと感じたら、削る。削れないものは、まだ整理が足りないということだ。この習慣で、自分の提案の通り率が体感で変わった。

チームで力を発揮するために実践した3つの習慣

考え方を変えるだけでは不十分で、日常の小さな行動に落とし込んでいくことが必要だ。以下の3つの習慣は、コードを書くことと並行して取り組みやすく、効果が出やすいものだ。

• レビューコメントを書く前に「相手の意図を問う形」に変える：「この実装は問題がある」の前に「なぜこの実装を選んだか、背景を教えてもらえますか？」と問いかける。相手の思考を引き出してから課題を共有すると、議論が建設的になる。
• 自分の課題と相手の課題を週に一度リセットする：毎週金曜日に「今週自分がコントロールできなかったこと」を5分でリストアップし、それが「自分の課題」か「相手の課題」かを仕分ける。相手の課題に費やしたエネルギーを可視化すると、翌週から手放しやすくなる。
• Slackやドキュメントの提案を「1分で読める」形にする：技術的な提案を書いたら、まず自分で1分以内に読めるかを確認する。読めない場合は削る。冒頭に「結論：〜」を置き、詳細はその下に書く構成にする。これで、相手の読む負担が減り、反応が早くなる。

この3つは、技術力を下げるものではない。むしろ、技術力を「チームに届ける力」として機能させるための仕組みだ。Audibleで関連する本を繰り返し聴きながら、日常の小さな場面でこの習慣を実践し続けることで、チームとの関係は少しずつ変わっていく。

チームとの関係を変えてくれた3冊（Audible配信あり）

技術系のエンジニアが読むと「自分のことだ」と感じる場面が多い3冊を紹介する。いずれもAudibleで配信されており、通勤中や作業のすき間時間に繰り返し聴ける。

よくある質問

まとめ

技術力があるのにチームで力を発揮できないという状態は、技術力の問題ではないことが多い。相手への関心、課題の分離、短く伝える力。この三つが、技術力をチームに届けるための回路になる。コードは論理で動くが、チームは関係性で動く。この違いを意識するだけで、エンジニアとしての仕事の質は変わる。

カーネギーが語る「相手への真の関心」、アドラーが提唱する「課題の分離と貢献感」、伊藤羊一が言う「整理してから伝える力」。これらは技術スキルとは別の回路で動くが、どれも学べるスキルだ。特別な研修や高価な道具は必要ない。日常の小さな行動の変化と、継続的なインプットが、確実にこれらの力を育てる。

Audibleで通勤中に繰り返し聴くことは、コードを書く時間を削ることなく、チームとの関係を変えるための思考をインプットし続ける方法として有効だ。技術的な知識をアップデートするインプットと並行して、人間関係の原則を繰り返し耳から聴く習慣が、エンジニアとしての総合的な力を上げていく。

「技術力には自信があるのに、チームで力を発揮できない」という感覚があるエンジニアに、今日から一つだけ試してほしいことがある。次のコードレビューで、指摘を書く前に「なぜそう実装したのか」を一度聞いてみることだ。その小さな一歩が、チームとの関係の変化の始まりになる。