Vibeコーディングと開発者終末論、ジュニア開発者の成長の方向性についての考え
(stdy.blog)- Vibeコーディングが注目されるにつれ、「もう開発者は不要だ」vs「それでもまだ先は長い」という議論も活発になっている
- どちらにも一理ある。AIの進化を見守りつつ、プロダクトエンジニアとして働きながら考えてきたことを整理してみた
- ただし私はAIの専門家ではなく、ただの開発者だ。Vibeコーディングの経験も浅い。それでも他の人たちの意見を聞きたくて、そして不安を感じているジュニア開発者の助けになればと思い、この記事を書いた
実際に体験してみたVibe: ここまでできる vs ここまでしかできない
Vibeコーディングで週末のあいだにアルカッキゲームを作ってみた。7歳の娘と一緒に遊ぼうと思って作った。コーディングの90%をプロンプトだけで進め、実装時間は飛躍的に短縮された（4時間で悪くないクオリティまで完成）
この過程で、「こんな簡単なこともできないの？」という失望感と、「この程度の要求だけでこんなに見事に作ってくれるの？」という驚きを交互に感じた。特に前者は、AIに「自分の言うことを従わせる」ことが簡単ではなかったのが大きい
しかしいずれにせよ、プロンプトを磨き、技術がさらに進歩すれば、「驚き」の比重ははるかに大きくなり、これが確実にジュニア開発者の採用急減を招くと考えている
この感覚を、パレートの法則と製品成熟度の概念で話してみたい
絶望編: 96%のコードはAIが書くことになるかもしれない
製品成熟度を3段階（ゼロ・トゥ・ワン、ワン・トゥ・テン、それ以上）で見るなら、ゼロ・トゥ・ワン段階のコーディングの大半がAIで代替可能になったことに衝撃を受けた
パレートの法則で見ると、開発者が製品開発のために生み出すコードの80%は、このゼロ・トゥ・ワンのための成果物だったのではないかと思う。
- アイデアを実装し、PMFを探る過程で出てくるコード。そしてVibeコーディングによって非開発者でも簡単に作れるコードだ
さらに、ワン・トゥ・テンで必要な80%をうまく定義して分解し、ゼロ・トゥ・ワン水準として処理できると仮定するなら……
- 極端に言えば、コード生産量のおよそ96%（= 0.8 + 0.2 * 0.8）はAIが代替できるのではないかという考え
- Vibeコーディングを紹介したY Combinatorの動画でも、何人かの創業者が「製品コードベースの95%をAIが書いた」と語っていたそうで、妙に数字が一致している
これは、開発者の力量に対する期待値と、MVPレベルの製品に対する期待値を底上げして平準化すると予想している。
- Bootstrap、TailwindCSS以後、フロントエンド開発者にとって「そこそこ良いUIスタイリング」が基本素養になってしまったのと似ている
だとすれば、以前ならゼロ・トゥ・ワン段階の製品を作る開発能力だけでも尊重されていたはずの開発者に対する採用枠が減るのは当然に見える。だからこそ「もう開発者は不要だ」という言葉も誇張ではなくなっている……
……本当にそうだろうか？
希望編: それでもなお開発者にやることは多い
1) 市場規模がはるかに大きくなり、やることも増える
Vibeコーディングの最大の意義は、製品開発の参入障壁を下げることにある
- これまでゼロ・トゥ・ワンのために開発者が手でやっていたことの大半を、コーディングエージェントが極端に少ないコスト（時間・お金・人員）で代替する。
- つまり、開発者がいなくても、アイデア実行-検証サイクルを素早く回せるようになる
したがって、これまで登場できなかったゼロ・トゥ・ワン（あるいはそれ以下）水準の製品が爆発的に多く現れるようになり、「自分も自分のアイデアを形にしてみたい」という人たちもはるかに増える。
これらすべてが、「開発者がお金を稼げる」市場規模を拡大させる効果をもたらす。もともと開発者の顧客ではなかった人たちが、新しい顧客層に変わる。たとえば
- 非開発者、PM、デザイナーが自分のアイデアを実現できるようにするVibeコーディング教育
- Cursorと一緒に90%までは作ったが完成までたどり着けていない製品の仕上げを支援する短期受託
- なんとか作った製品を実際に運用し、継続的な収益化につなげられるようにするコンサルティング
- Vibeコーディングをより上手に、より簡単にするのに役立つさまざまな有料ツールの開発
会社の外でこうした仕事で副収入を得るにせよ、こうした仕事をする企業が生まれるにせよ、市場変化の恩恵を最も大きく受けるのは開発者たちだと見ている
2) 開発者にはコーディング以外にもできること、やるべきことが多い
AIが「コーディング」の90%を代替するとしても、開発者の90%を解雇することはできない
- コーディングが製品開発、さらに言えばプロダクトエンジニアリングに占める比重は、思っているほど大きくないからだ
製品にたった1つの機能が追加されるまでに、ざっくりどのような過程を経るかを見るだけでも、これほど多くの段階がある。
- 問題認識
- 解決アイデアの導出
- 期待効果とコストの見積もり、開発優先順位の決定
- 製品に機能として落とし込むための企画
- UI/UXデザイン
- アーキテクチャ設計
- バックエンド + フロントエンド + インフラの実装
- コードレビュー、自動テスト、QA
- デプロイ、モニタリング、機能の告知、A/Bテスト
- ユーザーフィードバックの収集、運用、改善
Vibeコーディングはこのうち7と8の一部を代わってくれるだけだ。
- 卓越したプロダクトエンジニアであれば、これらすべての段階に一定水準以上で関与すべきだ
- コーディングをAIが代わってくれるからこそ、残りをうまくできる人の価値はむしろ高まる
3) コーディングだけを見ても、依然として意味のある仕事は多い
あえてプロダクトエンジニアリングまで広げなくても、やることは多い
- ワン・トゥ・テンのコーディングの最後の数%を仕上げる仕事も多いし
- 開発者が仕様設計や構造設計、作業分割などを手伝えば、Vibeコーディングにかかるコストも下げられる
そしてワン・トゥ・テンを超える製品では、Vibeコーディングには多くの限界がある
- コードベースが大きくなる -> 限られたコンテキストウィンドウ
- 高いセキュリティ水準を守り、性能を向上させるには専門家の直接介入が必要
- AIが十分に学習できていないであろうライブラリや言語でコーディングするときも同様
- https://ja.news.hada.io/topic?id=19923 でも似た問題が語られている
では、これからジュニア開発者はどうするべきか？
世界が絶望編に向かうにせよ希望編に向かうにせよ、あまりにも速く変わっているのは確かだ。特に採用の門が急激に狭まる状況で、ジュニアたちはどう学び、どう成長すればよいのだろうか？
<卓越した開発者を生み出すものは何か？> の論文を読み、卓越した開発者の5つの中核能力を次のように定義してみた
- 優れたコードを書く
- 根拠に基づく意思決定を練習する
- 同僚の効果的な意思決定を助ける
- 作業の現在価値を最大化する
- 効果的に継続学習する
これらはAI時代にも依然として重要だ。これを希望編と結びつけて考えられる
1) 拡大する市場を積極的に活用する
私ならこんなことをやってみる
- プロンプトエンジニアリングを学ぶ
- 新しく登場するAIアプリを一つずつ試してみる
- どう作業を分解すればコーディングエージェントが自分の要求をうまく満たしてくれるのかを学び、実験する
- 自分の小さな問題を解決するアプリをVibeコーディングで実装して配布してみる
- 非開発者の知人がVibeコーディングをやってみたいと言ったら、（お金をもらって）個別指導してみる
- 知人が実装を仕上げて配布・運用するところまで、（やはりお金をもらって）手伝ってみる
2) プロダクトエンジニアとしての力を身につける
私ならこんなことをやってみる
- 問題認識、アイデア、企画、設計、テスト、運用など製品全体に関心を持つ
- ソロ創業者のようにアプリを制作・運用してみれば、プロダクトエンジニアリングの力は自然と伸びるだろう
- チーム協業を通じて製品改善に取り組みながら、協業力 + プロダクトエンジニアリング力の向上を目指す
私は開発者を採用してオファーレターを書くとき、いつも「あなたにはミニCTOだと思って働いてほしい」という内容を入れていた
- 少なくともあなたが担当するプロジェクトでは、あなたが技術的意思決定の最終責任者だ
- そのプロジェクトを成功させるために必要なあらゆる段階に関与せよ
- 技術的であれ非技術的であれ、同僚が効果的な意思決定と行動をできるよう助けよ
3) 個別技術を深く理解し、コーディングセンスを磨く
個別技術を深く理解する開発者には継続的な需要がある。PMFを超えてユニコーン／デカコーン企業へ向かうには、Make it Right & Fastが必須だからだ。
ここに王道はない。（AIの助けも借りながら）時間を投資して努力するしかない。
- フレームワーク／ライブラリ内部の探究、歴史的文脈の理解、オープンソースへの貢献、ライブラリの自作、バグ追跡／修正、Web標準／性能改善など
同時に、良いコードに対する自分なりの基準を持ち、良いコードを見抜く「コーディングセンス」がいっそう重要になるだろう。AIの誤ったVibeに気づき、止めて、介入しなければならないからだ。
コーディングセンスを育てるには意図的な訓練が必要だ。ここでも時間と努力をかける必要がある
- 良いコードをたくさん見て、自分が書いたコードについてAIでもシニア開発者でも多くのフィードバックを受け、AIや同僚が書いたコードを見ながら「このまま進むとどんな問題が起きそうか」を予想し、実際と比較してみる
11件のコメント
いずれにせよ、ソフトウェアエンジニアリングの実務は大きく変わるでしょう。コードマシンたちの競争力は落ちるでしょうが、実際に製品をEnd-to-Endで作れるエンジニアたちは生き残ると、私は賭けています。
キーボードを打つ作業は減りましたが、AIが作った罠コードを見つける仕事が増えました。
とても意義深く、素晴らしい文章をありがとうございます！
タイプミスでした。しくしく
特に後者は、AIを「自分の言うことに従わせる」のが簡単ではなかったことが大きかったです -> 前者
スタートアップに必要なプロダクトエンジニアリングを深く理解するのも良いですが、むしろ技術を極限まで追求し、磨き上げる道も依然として十分に意義があると思います。シンプルなWebアプリケーションを作る開発はAIに代替されるでしょうが、誰かがKubernetesを考案し、ElasticSearchを設計しなければならないと思います。
そうした中核コンポーネントの設計者の数は限られているので、結局「開発者」という職種の需要が減るのは確かだと思います。
コメントを書いているうちに、私が文章で伝えたかったメッセージが整理されてきました。
私は、個々の企業においては開発者需要はどうあれ減っていく気がする一方で、「開発業務」を必要とする企業、あるいはそれに準ずる事業者・個人の数ははるかに増えるはずなので、開発者のやるべきことは依然として多いと考えていました。
もちろん、それらもまたAIに代替されるかもしれませんが、そこまで行けば代替されない職種のほうがないのではないかと…
ごもっともです！
同意します。今後はAIコーディングが担う作業と、人間が担う設計・レビューに分かれていくと思いますし、プロジェクト全体を理解するAIが登場するまでは共生していくのではないかと思います。
同意します！ もちろんそこでもAIが助けてはくれるでしょうが、バイブだけでは難しいのではないかと思います。
ちなみに、バイブコーディングで作ったゲームはこれです。 https://www.stdy.blog/vibe-go-stone/