技術力があるのに、なぜか社内で「あの人に聞こう」と思われないエンジニアに、何が足りないのだろうか

結論から言うと、技術力があるのに、なぜか社内で「あの人に聞こう」と思われないエンジニアに、何が足りないのだろうか——変化は思ったより速く、大きかった。生産性の改善は意志力より「仕組みを変えること」で決まる。この記事では、実践してわかったこととすぐ試せるステップをまとめる。

同じチームに、技術力がほぼ同じ2人のエンジニアがいる。しかし、何かわからないことがあるとき、みんなが「あの人に聞こう」と向かうのは、いつも一方だけだ。

もし自分が「聞かれない方」だとしたら、何が違うのだろうか。技術力の問題だろうか。それとも、技術とは別の何かが足りないのだろうか。

この問いを突き詰めると、答えは「伝える力」と「アウトプットの量」と「思考の言語化」という3つに行き着く。この記事では、その3つを変えるために読んだ本を紹介する。「1分で話せ」「学びを結果に変えるアウトプット大全」「ゼロ秒思考」の3冊は、いずれもAudibleで聴ける。通勤中に繰り返し聴くうちに、自分の発信の仕方が少しずつ変わっていった。

※ 30日間の無料体験。いつでも解約可能。

「技術力はあるのに存在感が薄い」エンジニアが陥るパターン

「あの人に聞こう」と思われるエンジニアと、そう思われないエンジニアの違いは、コードの品質だけにあるのではない。むしろ、日常の中でどれだけ自分の考えを外に出しているかという積み重ねが、大きな差を生む。

技術が評価される場面と、発言が評価される場面の違い

エンジニアの仕事には、技術的な正確さだけで評価される場面と、発言の質で評価される場面がある。コードレビューのコメントは前者に近い。しかし、設計会議での議論、スタンドアップでの共有、ドキュメントの読みやすさ、Slackでの返信の明快さは後者に近い。

技術力が高くても、後者の場面で存在感が薄いエンジニアは、「一緒に仕事しやすいか」という評価軸では低く見られやすい。「あの人のコードは信頼できるけど、何を考えているかわからない」という印象は、思った以上に機会損失につながる。

頭の中の知識を外に出さないと、存在しないのと同じ

内向きなエンジニアに多いパターンが、「完璧に整理できたら話す」という姿勢だ。自分の考えを十分に整理してから発言しようとするあまり、発言のタイミングを逃し続ける。会議では沈黙し、Slackでは「確認してから返します」が多くなる。

しかし、チームのコミュニケーションは「完成品」よりも「思考の途中経過」の共有で動いていることが多い。「まだ自信がないけど、こう思っている」という発言が、議論を前に進める。完璧を待つ間に、別の誰かが先に発言し、その人が「あの人に聞こう」と思われる存在になっていく。

「聞かれるエンジニア」と「聞かれないエンジニア」は何が違うのか

「あの人に聞こう」と思われるエンジニアを観察すると、技術力に加えて共通する特徴がある。発言が短くて明確だ。「結論から話す」習慣が身についている。そして、日頃から小さな発信を続けている。

つまり「聞かれるエンジニア」は、技術力が飛び抜けているのではなく、技術をわかりやすく届ける力が育っている。この力は、意識して鍛えなければ自然には身につかない。次の3冊は、その力を鍛えるための起点になった。

「伝わる」話し方は、技術とは別に学ぶ必要がある

技術は学校や業務の中で自然に鍛えられる。しかし「伝え方」を体系的に学ぶ機会は、エンジニアのキャリアの中にほとんどない。プレゼンの機会も少なければ、話し方のフィードバックをもらえる場も少ない。だから意図的に学ばなければ、伝え方はずっと「なんとなく」のままになる。

「1分で話せ」が示した、構造化されていない話の代償

著者の伊藤羊一は、ヤフーアカデミアの学長として多くの人材育成に携わってきた人物だ。この本のタイトルにある「1分」は、文字通り1分間で話を完結させるということではなく、「相手が聞く気を失う前に、最も重要なことを届ける」という姿勢を表している。

この本が繰り返し強調するのは、「結論を最初に言う」という原則だ。エンジニアの発言に多いのは、背景説明から始まって結論が最後に来るパターンだ。技術的な文脈を丁寧に伝えようとするあまり、聴いている側が「で、何が言いたいの？」と感じる前に話が終わってしまう。

ピラミッド構造で話すと、技術の話が格段に伝わりやすくなる

「1分で話せ」が提案するのは、話の構造を「結論→理由→具体例」という順番に並べる、ピラミッド構造だ。設計会議での発言に当てはめると、「このアーキテクチャを選ぶべきだと思います（結論）。なぜなら、将来的な拡張性と運用コストのバランスが最もよいからです（理由）。たとえば、今後ユーザー数が10倍になった場合でも、スケールアウトの設計変更が最小で済みます（具体例）」という形になる。

同じ内容でも、この構造で話すと聴き手の理解のスピードが変わる。会議での発言が短くまとまり、かつ要点が伝わるようになると、チームから「話がわかりやすい」という反応が増えた。それが「あの人に聞こう」という印象の積み重ねにつながる。

「1分で話せ」はAudibleで聴ける。出勤前の15分で聴けるコンパクトな内容で、その日の会議での発言を意識しながら聴くと、アウトプットへの応用がしやすかった。

アウトプットの量が、信頼のストックになる

話し方の構造を変えることと並行して、もう一つ変える必要があったのはアウトプットの「量」だ。どんなに伝え方が改善されても、発信の頻度が低ければ、チームの中での存在感は上がらない。

「完璧なアウトプット」を待っている間に、信頼は積み上がらない

樺沢紫苑の「学びを結果に変えるアウトプット大全」は、アウトプットの量と質の関係を科学的に解説した本だ。この本が最初に提示するのは、「インプット過多・アウトプット不足」という現代人の問題だ。読んだ本、聴いた話、学んだ技術。インプットの量に比べて、外に出すアウトプットがあまりにも少ない。

エンジニアも例外ではない。技術書を読む、勉強会に参加する、新しいフレームワークを試す。インプットは熱心だが、それをチームに共有したり、ブログに書いたり、社内Wikiに残したりというアウトプットが少ない人は多い。頭の中に知識があっても、外から見えなければ「あの人に聞こう」という認知は生まれない。

小さいアウトプットを積み重ねることで、信頼の「口座残高」が増える

この本の中で特に印象に残ったのは、「アウトプットは筋トレと同じ」という考え方だ。筋肉が使うことで育つように、アウトプットする力も使えば使うほど鍛えられる。最初は質が低くても、量をこなすことで質が上がる。

著者はアウトプットを「話す」「書く」「行動する」の3カテゴリに分け、それぞれの頻度を上げることを勧めている。エンジニアの日常に当てはめると、朝会での共有を少し詳しくする、学んだことを社内Slackの技術チャンネルにポストする、週次の振り返りをドキュメントに残す、といった小さな行動が該当する。

これらを意識して続けると、チームから「あの人は情報共有が丁寧だ」という認識が積み上がる。困ったことがあったとき、自然と「あの人に聞こう」という流れになりやすくなる。アウトプットは信頼の口座残高だ。少額でもコンスタントに積み立てることで、残高は着実に増えていく。

技術ブログを書くと、学んだことの定着率が変わる

この本では、アウトプットの最も効果的な形式のひとつとして「ブログを書くこと」が挙げられている。人に説明するために情報を整理する過程が、自分の理解を深める。「インプットのためのアウトプット」という考え方は、技術を学び続けるエンジニアにとって特に有効だ。

社外に公開するQiitaやZennの記事でなくても、社内Wikiへの投稿、Slackへの技術メモ、ノートアプリへの学習記録でも同じ効果がある。書くことで、頭の中の知識が「言語化された資産」に変わる。「アウトプット大全」はAudibleで聴けるため、通勤中に要点を繰り返し取り込みながら、自分のアウトプット習慣を設計するのに役立てた。

書くことで思考が整理され、発言のスピードが変わった

話し方の構造を変え、アウトプットの量を増やした。しかしもう一つ課題が残っていた。「発言しようとすると頭が整理できない」という状態だ。会議中に発言したいと思っても、自分の考えが言葉にならず、気づいたら機会を逃している。

この問題を解決したのが、赤羽雄二の「ゼロ秒思考」だった。

思考が言語化されていないと、発言のタイミングを逃し続ける

「ゼロ秒思考」が提示する問題意識は、多くのエンジニアが直感的に感じているものだと思う。頭の中にはモヤモヤした感覚や断片的な考えがある。しかしそれが言葉になっていないため、発言しようとした瞬間に「どう言えばいいかわからない」という状態になる。

著者の赤羽雄二は、マッキンゼーで14年間活躍したコンサルタントだ。この本の核心は「頭の中のモヤモヤをA4用紙に1分以内で書き出すことで、思考の速度と質が上がる」というメソッドだ。書くことで、言語化されていなかった考えが整理され、次の発言の準備ができる。

「ゼロ秒思考」の1分メモが変えた、会議前の準備

実際に取り入れたのは、会議の前に「この会議で自分が言いたいことは何か」をA4用紙に1分で書き出す習慣だ。箇条書きで3〜5個書くだけでいい。この作業をするだけで、会議中の発言のタイミングをつかめる頻度が上がった。

また、Slackの返信が遅いという自分の傾向も、このメソッドで改善できた。返信を考えるときに「自分はこの件についてどう思うか」を先に書き出してから打ち込むことで、返信の時間が短くなり、内容も明確になった。

書くことが「アウトプットの前準備」になる

「ゼロ秒思考」と「アウトプット大全」は、組み合わせて使うと効果が高い。アウトプット大全が「外に出す量を増やすこと」を勧めるとすれば、ゼロ秒思考は「出す前に頭を整理すること」を教えてくれる。書いて整理し、それを外に出す。このサイクルを繰り返すことで、思考と発信の両方が鍛えられる。

「ゼロ秒思考」もAudibleで聴ける。メソッド自体はシンプルで、聴きながら「今日試してみよう」とすぐ動ける内容だ。1冊通して聴いた後は、特定のチャプターだけ繰り返し聴いて習慣の定着に使っていた。

実際に変えた3つのこと。そして半年後に起きた変化

3冊を読んだ後、日常の中で具体的に変えたことが3つある。その変化とその後に起きたことを記録しておく。

発言は「結論から」を徹底した

「1分で話せ」を読んでから、発言の最初の一文を変えた。「少し複雑な話になるのですが」「背景から説明させてください」という入り方をやめ、「〇〇という判断をおすすめします」「〇〇が問題だと思っています」と結論から始めるようにした。

最初は不自然な感覚があったが、2週間続けると習慣になった。会議での自分の発言が短くなり、かつ伝わりやすくなったという感想をチームメンバーから受けた。「話がわかりやすくなった」という一言が、続けるモチベーションになった。

学んだことを週1回、Slackに流すようにした

「アウトプット大全」から取り入れたのは、週1回、その週に学んだ技術的なことをSlackの技術チャンネルに投稿する習慣だ。長くなくていい。3〜5行の簡単なメモでいい。「今週〇〇を試してみて、こういうことがわかった」というレベルでいい。

最初の2週間は反応が薄かった。しかし1ヶ月続けると、「あれ、どうやってやるの？」という質問が来るようになった。2ヶ月後には、「〇〇ならあの人に聞くといい」という話が出るようになったと、別のチームメンバーから聞いた。アウトプットの積み重ねが、認知を変えていた。

会議の前に「言いたいことメモ」を1分で書くようにした

「ゼロ秒思考」から取り入れたのは、会議の前にA4用紙かメモアプリに「この会議で自分が言いたいこと、確認したいこと」を書き出す習慣だ。所要時間は1分。箇条書きで3個書ければ十分だ。

この準備をするだけで、会議中の発言の頻度が明らかに増えた。言いたいことが事前に言語化されているので、発言のタイミングを逃しにくくなった。また、メモを見ながら話すことで、脱線しにくくなった。半年後には、「あの人は会議でいつも的確な発言をする」という評判が少しずつ広がっていった。

Audibleで3冊を繰り返し聴きながら、発信の型を身につけた

「1分で話せ」「アウトプット大全」「ゼロ秒思考」の3冊は、どれもAudibleで聴ける。

これら3冊を繰り返し聴くことで気づいたのは、「知っている」と「できる」の間にある大きな溝だ。話の構造化も、アウトプットの量を増やすことも、書いて思考を整理することも、頭で理解するのは難しくない。しかし習慣として定着させるには、繰り返しの刷り込みが必要だ。

通勤中に3冊をローテーションして聴き続けることで、「今日の会議でどう発言するか」「今週は何をアウトプットするか」という問いを自然に立てられるようになった。1回読んで満足するより、繰り返し聴いて日常に染み込ませる方が、行動の変化につながりやすい。

Audibleは月額制で、対象タイトルが聴き放題になる。初月無料で始められるため、まず3冊を通勤中に聴くところから試してほしい。

※ 30日間の無料体験。いつでも解約可能。

まとめ：技術力と発信力は、別々に鍛える必要がある

「あの人に聞こう」と思われるエンジニアと、そう思われないエンジニアの差は、技術力だけにあるのではない。日常の中でどれだけわかりやすく、どれだけ頻繁に、どれだけ素早く自分の考えを外に出しているかの積み重ねが、その差を生む。

「1分で話せ」は発言の構造を変えてくれた。「アウトプット大全」はアウトプットの頻度を上げる後押しをしてくれた。「ゼロ秒思考」は発言前の思考の整理を可能にしてくれた。3冊はそれぞれ異なる角度から、「伝わるエンジニア」になるための土台を作ってくれた。

技術力が評価されるには時間がかかる。しかし発信力は、今日から少しずつ変えていける。まず「結論から話す」を1つの会議で試してみることから始めてほしい。

よくある質問