エンジニアが見落としがちなコミュニケーションの本質
こんにちは！
株式会社ココナラ マーケットプレイス開発部Web開発グループでエンジニアリングマネージャーを務めているアダムです。
こちらは 株式会社ココナラ Advent Calendar 2025 21日目の記事です。
はじめに
私はこれまで様々な現場で開発リーダーやエンジニアリングマネージャーとしてチームに向き合ってきました。
その中で理論的に正しいと信じて伝えたことが、必ずしも相手に伝わるとは限らず
時に思いがけないすれ違いや温度差を生んでしまうこともありました。
この記事では、私自身の過去の失敗も踏まえて学んだ2つの大切な視点をお伝えします。
- ロジックと感情のバランス - 正論は正義ではない
- 理解の階段 - 相手の理解度に合わせて伝える
これらはエンジニアが日々の業務の中で実は見落としがちな点でもあり、
エンジニア以前にビジネスパーソンとして非常に重要なポイントでもあります。
ロジックと感情のバランス
昔、別の会社で大炎上した開発の立て直しを図った時のことです。
当時私は別の事業でプロジェクトマネージャーを務めていましたが、
とても見ていられる状況ではなかったので
経営陣と相談し自ら炎上した事業の技術責任者として異動後、
至急火消しに取り掛かりました。
最初のアプローチ：ロジック重視の失敗
当時炎上した開発では毎日のように大量のHotfixリリースを行い、
そのリリースによってデグレが発生して更に修正を重ねるというとてつもない悪循環に陥っていました。
悪循環を断ち切りサービスの品質悪化を食い止めるために、
毎日数十PRのコードレビューでこれ以上の不具合が発生しないよう大量のフィードバックを行いました。
ただ丁寧にフィードバックしたつもりでも実際メンバーの反応はあまり芳しくありませんでした。
「この箇所は〇〇した方が良いと思います。なぜなら元々の処理に問題があって保守性・拡張性が更に悪くなりかねません」
「はあ、、そうですね。。(わかってはいるんだけどこっちは忙しい)」
という具合です。
うまくいかなかった理由としてはシンプルです。
私は炎上を食い止めるのに必死だったため、ロジック(妥当性)を重視していました。
しかし炎上により忙殺され疲弊している人にとっては、正論は逆効果であり反発したくなるんです。
方向転換：感情を重視したアプローチ
このままだといけないと思い、アプローチを以下のように変更しました。
-
ロジックより感情を重視
- 事業や組織以前にあなたを楽にしたい・助けたいという気持ちを態度と行動で示す
-
他人事ではなく自分事と認識させる
- そもそも自分の正しさと相手の正しさは違う(炎上している中で目的が事業や組織に偏りすぎるとメンバーは他人事と意識する)
具体的には炎上を食い止めるための品質を考慮しつつ、限られた時間でメンバーが納得感をもって対応してくれるギリギリのラインでフィードバックしました。
「今回は時間が無いので、最低限〇〇までやりましょう。ただ最初からこういう風に実装すると自分が楽になるので意識してみてください」
「確かにそこまでならすぐ対応出来るのでやっちゃいますね！」
というフィードバック・レスポンスを日々根気強く繰り返し、技術の最低ラインを底上げする中で少しずつチームの状況が好転するのがわかりました。
メンバーがナレッジを学んで自発的に改善に取り組むようになっていったのです。
学び：正論は正義ではない
この経験から学んだのは、人を納得させるにはロジックと感情のバランスが大切だということです。
- ロジックだけでは、相手の心は動かない
- 感情だけでは、正しい方向に進めない
- 両方のバランスが、人を動かす
エンジニアは論理的思考が得意だからこそ、意識的に感情の側面にも目を向ける必要があります。
「正しいこと」を伝える前に、まず 相手の立場・状況・気持ち を配慮する。
それがコミュニケーションの第一歩だと思います。
理解の階段
もう一つ、私が大切にしてきたコミュニケーションのポイントがあります。
それは 理解の階段(相手の理解度に合わせて伝える) です。
よくあるミスコミュニケーション
人に説明をする時、こんな経験は今までなかったでしょうか？
- 技術的な問題を説明しても、相手によく分からない反応をされる(「結局何が問題なの？」)
- 目的や前提が相手に伝わっておらず、結論を出すまでのプロセスがうまくいかない
これらは相手の理解度を正しく把握できていないことが原因の一つとして挙げられます。
正しいスタンスは「相手は知らない」
✕ 「自分が知っていることは、相手も知っている」
◯ 「自分が知っていることは、相手は知らない」
当たり前に聞こえるかもしれません。
しかし実際には私たちは無意識の内に「これくらいは知っているだろう」と思い込んでいることが多いのです。
理解の階段を渡す3つのステップ
相手に理解してもらうには、理解の階段を渡して楽に登れるよう設計する必要があります。
ステップ1：理解度のゴールを決める
まず、「何のために説明するのか」「何を理解してもらわないと目的が果たせないか」を明確にします。
例えば：
- 意思決定を求める場合: メリット・デメリットと、リスクの理解が必要
- タスクを依頼する場合: 目的・背景が必要
- 報告する場合: 結論と、それに至った経緯の理解が必要
ゴールによって、説明すべき内容は変わります。
ステップ2：相手の現状の理解度を測る
次に相手が今どのレベルにいるのかを把握します。
考慮すべきポイント：
- 相手の人数: 1人なのか、複数人なのか
- 職種: エンジニアなのか、ビジネスサイドなのか
- 立場: 意思決定者なのか、それ以外か
- 説明する内容への関わり方: 日常的に触れているのか、初めて聞く内容なのか
同じ内容でも、相手によって必要な説明のレベルは全く異なります。
ステップ3：ギャップを埋める「階段」を設計する
ステップ1のゴールと、ステップ2の現状のギャップを埋めるために適切な「階段」を用意します。
重要なのは、階段の段差を適切にすることです。
- 段差が大きすぎる: 理解できず、置いていかれる
- 段差が小さすぎる: 時間がかかりすぎる
- 階段が途中で無くなる: 論理が飛躍して理解不能になる
特に注意すべきは、目的・前提・背景の明示です。
これらを無視して話し始めると階段が途中で無くなり、相手は理解できなくなります。
具体例：技術選定の説明
例えば、新しいライブラリの導入を提案する場合：
❌ 悪い例（階段が無い）:
「〇〇というライブラリを導入したいです。△△という機能があって便利なので。」
✅ 良い例（階段がある）:
- 目的: 「現在、パフォーマンス改善が課題になっています」（前提の共有）
- 現状の問題: 「既存の実装では、〇〇の処理に時間がかかっています」（問題の明確化）
- 解決策の提示: 「△△というライブラリを使うのはどうでしょうか」（解決策）
- メリット・デメリット: 「現状時間がかかっている処理を〇％高速化できます。ただし、学習コストと保守性のトレードオフがあります」（判断材料）
- 提案: 「総合的に判断して、導入する価値があると考えています」（結論）
試行錯誤することの大切さ
最初から完璧な「理解の階段」を設計できる人はいません。
大事なのは、日々の業務の中で相手の反応を見ながら、階段の渡し方を調整していくことです。
- 難しそうな顔をしていたら、もう一段手前に戻る
- すでに理解していそうなら、先に進む
- 質問してもらい、理解度を確認する
この試行錯誤そのものが、「あなたに理解してもらいたい」という配慮として相手に伝わり、コミュニケーションが円滑になっていきます。
おわりに
この記事ではエンジニアが見落としがちなコミュニケーションの本質として2つの視点をお伝えしました。
- ロジックと感情のバランス - 正論は正義ではない
- 理解の階段 - 相手の理解度に合わせて伝える
どちらも相手の立場に立って考えるという点で共通しています。
- ロジックと感情のバランス → 相手の気持ちを考える
- 理解の階段 → 相手の理解度を考える
エンジニアは開発の中で様々な職種との連携が求められます。
技術的に正しいことを伝えるだけでなく、それをどう伝えるかがチームの成果につながります。
- フィードバックする前に、「この人は今、どんな気持ちだろう？」と考えてみる
- 説明する前に、「この人は、どこまで知っているだろう？」と考えてみる
その小さな一歩がコミュニケーションを変えるきっかけになれば幸いです。
明日は かわむーさん による「「余力」から「基礎スキル」へ繋ぐ！生成AIで回すコードレビューのループ」です。
ココナラでは積極的にエンジニアを採用しています。
採用情報はこちら。
カジュアル面談希望の方はこちら。
Discussion