「成長の近道は、他人のPRを読むこと」米マイクロソフト・牛尾 剛が考える、バイブコーディング時代の必須スキルとは？
今やGitHub CopilotをはじめとするAIツールが、日々のコーディングを助けてくれる時代になった。しかしその一方で、「AIに頼るばかりで、本当に実力が身に付いているのだろうか？」と、漠然とした不安を感じているエンジニアは少なくないだろう。
米Microsoftのエンジニア・牛尾 剛さんもまた、自身の生産性に深く悩み、「開発スピードがくっそ遅い」と感じていたという。そんな彼のモヤモヤを取り払ったのが、コードを書くよりもまず他人のPRを徹底的に読む「ディープコードリーディング」という学習法だ。
「自分が成長しないのは、書いてないからじゃなく、読んでないからだった」と語る牛尾さん。バイブコーディング時代、エンジニアにとって「読む力」がなぜ重要となるのだろうか……？
米マイクロソフト
Azure Functionsプロダクトチーム シニアソフトウェアエンジニア
牛尾 剛さん（@sandayuu）
1971年、大阪府生まれ。米マイクロソフトAzure Functionsプロダクトチーム シニアソフトウェアエンジニア。シアトル在住。関西大学卒業後、日本電気株式会社でITエンジニアをはじめ、その後オブジェクト指向やアジャイル開発に傾倒し、株式会社豆蔵を経由し、独立。アジャイル、DevOpsのコンサルタントとして数多くのコンサルティングや講演を手掛けてきた。2015年、米国マイクロソフトに入社。エバンジェリストとしての活躍を経て、19年より米国本社でAzure Functionsの開発に従事する。ソフトウェア開発の最前線での学びを伝えるnoteが人気を博す。書籍『世界一流エンジニアの思考法』（文藝春秋）は10万部を突破し、ITエンジニア本大賞2025特別賞も受賞
目次
なぜ「書いても、書いても」成長を実感できなかった？ひたすら「読む」ことで、初めて「自信」を得たトップエンジニアの「速さ」の源は「理解力」にあったこれからのエンジニアは、「書く」ために「読む」
なぜ「書いても、書いても」成長を実感できなかった？
周りの優秀な同僚たちと比べて、自分の開発スピードはあまりにも遅い。いや、くっそ遅い。このコンプレックスは、自分のエンジニア人生にずっと付きまとってきました。
「どうすれば、あの人たちみたいに速く、しかも質の高いコードが書けるんやろう？」
自分なりに考えて出した答えはシンプルで、「もっと頑張って、もっと速く書くしかない」というもの。とにかく手を動かし、量をこなす。それが成長への唯一の道だと。
「三流でもいいは甘えだった」牛尾 剛が米マイクロソフトで痛感した、妥協を捨てる覚悟https://type.jp/et/feature/28100/
ところが、2025年の春先、その考えが覆される決定的な事件が起こったんです。
当時、趣味で作っていたAIアプリがきっかけで新しい役割を与えられていた自分は、慣れないリポジトリで成果を出そうと必死でした。そんな中、数週間かけて新機能を実装し、プルリク（PR）も無事にマージされ一安心……したのも束の間、ある同僚から衝撃的な一言が。
「牛尾、そのコードはもう使われていない古いアーキテクチャ（デッドコード）の上に書かれてるぞ」
自分がかけた時間も労力も、全部ムダだった……。目の前が真っ暗になるとは、まさにこのこと。
結局のところ、自分に足りなかったのは、「速さ」でも「努力」でもなかった。決定的に欠けていたのは、「システム全体の理解」。どんなに素晴らしいコードを、どんなに時間をかけて書いたとしても、その土台となる文脈の理解がなければ、その努力は一瞬で無に帰してしまう。
「ただがむしゃらに書く」ことの危うさと、その前に何か重要なステップが抜け落ちていることを痛感した出来事でした。
ひたすら「読む」ことで、初めて「自信」を得た
そこで自分は、アプローチを180度変えることに。焦点を「いかに速く書くか」から、「いかに深く、正確に読むか」へと移したのです。
まず取り組んだのは、問題となっていたリポジトリの主要開発者2名に絞り、彼らのPRを最初の一つ目から順番に、全て読んでいくこと。これが、「ディープコードリーディング」です。
これはその名の通り、ただ流し読みするのではありません。一つのPRに対し、「100%完全に理解する」ことだけを目標に定めます。例えば、最初のPRを読むのに、自分は丸2日間を費やしました。
具体的には、GitHub Copilot AgentのようなAIツールを、専属の家庭教師のように活用します。コードを一行ずつ追いながら、少しでも疑問に思ったことは、全てAIにぶつけていきました。
「このクラスの命名には、どういう意図がありますか？」
「このメソッドが呼び出されるまでの、一連の流れを教えてください」
スピードは完全に無視しました。重要なのは、自分の頭の中に、そのコードが動く様子を寸分の狂いもなく思い描けるようになることです。
このように徹底的に「読む」ことに集中すると、それまで気付けなかったものが見えてきます。
まず、システムの解像度が一気に上がりました。
あるPRを最初から最後まで丁寧に読み込んだだけで、そのリポジトリのアーキテクチャや設計の意図が、驚くほどはっきりと頭に入ってきたのです。以前は理解に苦労していた別のPRも、差分を追うだけで「なぜこの変更が必要なのか」が自然と読み取れるようになり、学習効率が格段に上がりました。
もうひとつ見えてきたのは、判断の軸です。
多くのPRを読んでいくうちに、「このチームでは、どれくらいの粒度でPRを出すのが自然か」といった、コードには書かれていない暗黙の作法や前提が見えてきました。そして、自分のPRがなかなかレビューされなかったのは、機能の問題ではなく、単にPRが大きすぎてレビューしにくかっただけなんだと気付きました。
理解が深まると、コードの良し悪しだけでなく、開発プロセス全体の流れをふまえて判断ができるようになります。それは、自分にとって大きな変化であり、自信にもつながりました。
トップエンジニアの「速さ」の源は「理解力」にあった
「ディープコードリーディング」は、伸び悩んでいた自分にとっての、大きなブレイクスルーでした。そして、この気付きを得た後、改めて周りのトップエンジニアたちを見渡してみたところ、彼らの本当の強みがどこにあるのかがはっきりと見えてきたのです。
例えば、自分の同僚にはニックという、チームの誰もが「彼はすごい」と口を揃えるエンジニアがいます。以前、自分が解決できない問題についてニックに尋ねたことがあります。
彼は「ちょっと待って」と言うと、その場でコードを調べ始め、すぐに的確な答えを教えてくれました。「どうしてそんなことまで知っているんだ？」と驚いて聞くと、彼は平然とこう言ったのです。
「いや、知らなかったよ。今、このC#のコードを読んだだけだ」
かつて一緒に働いていたバラも、全く同じでした。周りから「オラクル」と呼ばれるほど何でも知っている彼を、自分は長年の経験で全てを記憶しているのだとばかり思っていました。しかし、彼も知らないことに直面すると、やはりその場でコードを読み、「ああ、これはこういう仕組みになっている」と即座に理解していたのです。
彼らの凄みは、決して「コードを打ち込む速さ」や「膨大な知識の記憶」ではありません。その本質は、どんなコードでも即座に読み解き、システムの構造を把握する「高速な理解力」にあるのだと確信しました。
どんなに馴染みのないコードベースであっても、彼らはその場で「読む」ことで、設計思想やデータの流れ、影響範囲といった文脈を素早く自分の頭の中にインストールしてしまう。だからこそ、次に何をすべきか、どこに手を入れるべきかという「的確な判断」が、即座に下せるのです。
彼らが書く美しいコードや的確な修正は、その圧倒的な「理解力」という土台の上にある、いわば氷山の一角に過ぎない。自分が目指すべき道は、この「理解する力」を鍛え続けることなのだと、はっきりと見えた瞬間でした。
これからのエンジニアは、「書く」ために「読む」
トップエンジニアたちの本質が「高速な理解力」にあるのだとすれば、私たちもまた、その力を鍛えることで成長できるはずです。
そこで重要になるのが、仕事の進め方そのものを変えること。バイブコーディング時代は「とにかく書かせる → 試す → 修正する」といった流れになりがちです。ですが、本当に価値のある仕事をするためには「まず読んで理解する → 的確に判断・設計する → AIに指示するか、最小限のコードを書く」というサイクルが求められます。
この考え方は、「私たちが自分自身をどう捉えるか」という話にも繋がります。自分はよく、「プログラマー」と「デベロッパー」という言葉を分けて考えます。「プログラマー」の仕事がコードを書くことそのものだとすれば、「デベロッパー」の仕事は、ソフトウエアで問題を解決し、価値を創造することです。
デベロッパーにとって、コーディングは目的ではなく、あくまで数ある手段の一つ。その視点に立てば、AIは自分の仕事を奪う脅威ではなく、むしろ「理解」や「判断」を助け、能力を拡張してくれる最高のパートナーとなり得ます。
自分が成長できなかったのは、「書いていなかった」からではありませんでした。「読んでいなかった」からです。
もし、かつての自分と同じように成長の壁を感じているのなら、まずは気になるプルリクエストを一つ、AIと一緒にじっくりと読んでみることから始めてみてはいかがでしょうか。
撮影／桑原美樹 取材・文／今中康達（編集部）