なぜ、あの人は本質をすぐに見抜けるのか？—「筋が良い」エンジニアになるための思考習慣
導入
プルリクエストに出した、自信のある実装。
しかし、シニアエンジニアからのレビューコメントは、自分が全く想定していなかった根本的な問題を指摘していた。
障害調査で何時間もログを睨み続けた末に「これが原因だ！」と報告したのに、「本当にそう？普通はまずこっちを疑わない？」と、あっさり別の可能性を示唆される。
そんな経験を繰り返すうち、ふと不安がよぎる。
「自分は、もしかして『筋が悪い』のかもしれない…」
あなたの周りにもいませんか。単に知識が豊富なだけでなく、問題の本質を瞬時に見抜き、常に最短ルートで答えにたどり着くように見える「筋の良い」エンジニアが。
彼らと自分を分けるものは、一体何なのでしょうか。
それは、天性のセンスや才能ではありません。優れたエンジニアたちが実践している、 再現性のある「思考のプロセス」 です。彼らは、問題に直面したときに、無意識的、あるいは意識的に「最初に何をすべきか」「何をすべきでないか」を知っているのです。
この記事は、過去の私のように「自分の筋の悪さに悩み、でも成長したい」と願う、すべての若手・中堅エンジニアのために書きました。
本記事では、ある外部APIの連携トラブルで「筋が悪い」チームが陥った失敗と、それを「筋が良い」エンジニアならどう解決したかを対比させながら、彼らの思考プロセスを分解していきます。
読み終える頃には、「筋が良い」と評価されるために明日から何を意識すればよいか、その具体的な行動指針があなたの中に生まれているはずです。
第1章: あなたは大丈夫？「筋が悪い」思考に陥りがちな3つの症状
まずは、私たちが陥りがちな「筋が悪い」思考の症状を、ケーススタディを通じて見ていきましょう。自分にも当てはまる点がないか、セルフチェックしてみてください。
症状1: まず「外部」を疑い、犯人探しから始めてしまう
調査にあたったチームは、真っ先に「API提供元で大規模障害が発生しているに違いない！」という結論に飛びつきました。
これは典型的な「犯人探し」の思考です。自分たちがコントロールできない外部に原因を求めることで、問題の所在をいったん外に置こうとします。しかし、これは多くの場合、調査を遠回りさせる原因になります。
□ あなたは… 問題が起きると、まずAPI連携先や外部ライブラリのバグを疑っていませんか？
症状2: 事実を「最初の仮説を補強するため」に見てしまう
チームはエラーログを見て、500エラーが多発していることを確認しました。しかし、彼らはそれを「やっぱり向こうのサーバーが悪い」という最初の仮説を補強するための情報としてだけ使ってしまいました。
「なぜ500が返ってくるのか？」「正常なのにデータが空なのはなぜか？」という一歩踏み込んだ分析をせず、自分たちの都合の良いように事実を解釈してしまったのです。
□ あなたは… 調査の初動でログやデータを確認する際、仮説に合わない情報を無意識に無視していませんか？
症状3: 運用の「基本原則」を無視した仮説を立ててしまう
本当の原因は、「APIの仕様変更（エラーレスポンスの形式変更など）に関する、事前の告知メールやリリースノートをチームが見落としていただけ」でした。
外部サービスを利用する上で「相手の仕様変更を常にキャッチアップし、追従する」というのは、サービス運用の極めて基本的な原則です。この原則を無視して「相手が悪い」と決めつけるのは、貴重な調査時間を浪費する典型的なパターンです。
□ あなたは…「そもそも、この機能が動くための大前提（基本原則）は何だっけ？」と自問する癖がありますか？
第2章: 明日から実践する、「筋が良い」エンジニアの3つの思考習慣
では、「筋が良い」エンジニアは、同じ問題にどう向き合うのでしょうか。彼らが実践している思考習慣は、誰でも真似できる具体的なアクションです。
習慣1: 事実に基づき、「確認できること」から潰していく
「筋が良い」エンジニアは、「相手の障害だ」と決めつける前に、まず自分たちで確認できることをすべて潰します。「API提供元の障害情報ページや開発者ブログに、何か告知は出ていないか？」「過去の告知メールを見落としていないか？」
外部要因を疑うのは、自分たちの管理下にある全ての情報を確認し、内部に原因がないことを証明してからでも遅くはありません。
習慣2: 簡単な「絵」を描いて、関係者と情報の流れを整理する
今回のケースも、登場人物（自社サーバー、APIサーバー）と、リクエストとレスポンスの流れを線で描いてみるだけで、思考が整理されます。
「リクエスト（正常）→ レスポンス（500エラー）」と描くことで、「自分たちのリクエスト自体は、相手に届いているようだ。では、なぜ相手はエラーを返すのだろう？」と、次の具体的な調査ポイント（リクエストの中身は仕様変更後も正しいか？など）に思考を進めることができます。
習慣3: 人に「1分で」説明してみる
自分の考えが行き詰まったら、同僚に「今こう考えているんだけど」と1分で説明してみましょう。うまく説明できなかったり、相手から「なんでそう言えるの？」と素朴な質問をされたりした箇所が、あなたの思考の飛躍点や、思い込みです。人に話すことは、最高の思考のデバッグツールになります。
第3章: その調査、並列つなぎになってない？—チームの思考力を最大化する「直列アプローチ」
個人の思考法を身につけたら、次はチームでの応用です。なぜ、優秀なはずのチームが一人より筋の悪い結論を出してしまうことがあるのでしょうか。それは、チームの思考力が「並列つなぎ」になっているからです。
思考の「並列つなぎ」と「直列つなぎ」
理科の授業で習った、電池のつなぎ方を思い出してください。
- 並列つなぎ: 電池を横に並べるつなぎ方。容量（作業時間）は増えますが、電圧（結論の質）は1個分と変わりません。チーム全員が同じ仮説を検証している状態は、まさにこれです。
- 直列つなぎ: 電池を縦に積むつなぎ方。電圧（結論の質）が電池の数だけパワフルになります。個々の知見を積み上げていくことで、一人ではたどり着けない結論に到達できます。
「筋が良い」チームになるための役割分担
「筋が良い」チームは、意識的に思考を「直列つなぎ」にします。
- 原因不明の段階では「拡散」する: 「自分はアプリログを見ます」「じゃあ私はAPI提供元のリリースノートを確認します」というように、あえて全員が違う角度から調査し、可能性を網羅します。
- 仮説が見えたら「分担」する: 確からしい仮説が見つかったら、役割を分けます。
「調査役」が仮説を深掘りし、その結論を「検証役」が第三者視点で裏付けます。これにより、思い込みによる暴走を防ぎ、結論の確度を飛躍的に高めることができるのです。
あなたがチームにいるときは、「手分けしませんか？」の一言で、チームを「並列」から「直列」に切り替えるきっかけを作ることができます。
まとめ: 「センス」は「習慣」と「謙虚さ」で作られる
「筋が良い」エンジニアとは、生まれつきセンスがある人のことではありません。
- 事実と原則に基づき、
- 思考を整理し、
- チームの知恵を正しく連結させる。
このような思考の「習慣」を、日々の業務で意識的に実践している人のことです。
しかし、もう一つだけ、最も大切なことがあります。それは、 自分の思考が間違っている可能性を常に疑う「謙虚さ」 です。
どんなに優れたエンジニアでも、思い込みや見落としをします。「自分は正しい」と驕った瞬間に、思考は停止し、「筋の悪い」罠に陥ります。新しい事実がわかれば、素直に自分の仮説を修正する。その知的誠実さこそが、「筋が良い」エンジニアであり続けるための、最後の鍵なのです。
この記事で紹介した習慣を、明日から一つでも試してみてください。その小さな一歩の積み重ねが、あなたを、そしてあなたのチームを、周囲から一目置かれる「強いエンジニア」「強いチーム」へと変えていくはずです。
Discussion