バイブコーディングによって、学習の順序が反転する
清水氏はバイブコーディングを、ツールの名前でも特定の作法でもなく、ひとつの工程の技術として定義する。
「自分の頭の中にあるイメージと実際に動くものとの距離を縮めていく工程の技術だということです」
重要なのは距離を縮める手段ではなく、縮める対象のほうだ。清水氏は「自分の頭の中に何があるかということが実は一番大事で、手段は正直何でもよく、一番良いものを使えば良いと考えています」と続ける。
では、従来のコーディングと何が変わったのか。システムの言葉へ翻訳する手間が省けた、という理解は半分しか当たっていない。清水氏が日常的に感じているのは、むしろ逆の効果だ。
「普段バイブコーディングをやっていると非常に感じるのが、私の知らない技術がこんなにあるのだなということです」
例に挙げたのは、Zoomのようなツールを作ろうとしたときの話だ。どのくらい大変なのか見当がつかないまま聞いてみると、使えるオープンソースがあると返ってくる。それを動かすにはRustが要ると言われる。かつてなら、そこで手が止まった。Rustの文法を最初から学び、フレームワークを覚えるところから始めなければならなかったからだ。
ところが今は、「Rustは早いらしいから、じゃあRustで作ってよ」と言えば動くものが出てくる。清水氏はこれを「バイブコーディングの気楽さという意味では一番楽しいところ」と表現する。もちろんトラブルが起きればRustを本腰を入れて学ぶことになるが、その回り道も含めて「自分が新しいものに出会うきっかけになっている」。
学習の順序そのものが反転した、と言い換えてもいい。今は「とりあえず書きました」と提示されたコードが先にあり、意味の分からない箇所だけを切り出してChatGPTに尋ねる。
だからこそ清水氏は、バイブコーディングの対象を非エンジニアやビジネス層に限定しない。「エンジニアこそバイブコーディングをやった方がいいと思います」、清水氏はむしろエンジニアに向けてバイブコーディングを推奨する。
プロダクトを「作れること」と「提供できること」の差
エンジニアこそやるべきだと清水氏が言うのは、経験のある人間にしか見えない潜在的なリスクがあるからだ。「プロダクトの利用者が10人、20人であればいいけれど、これが1000人、1万人、10万人、100万人になった時にどういうオーダーで必要な概念が変わっていくか」。こうした勘所は経験があれば分かるが、初めてプロダクトを開発する際には対応が難しい。
具体的な例がある。清水氏がかつて関わった顧客企業で、社長が大量のコードを書き、「お客様がすごく喜んでいるから、お客様に導入したいのです」と提案されたことがあった。何人くらいの顧客が使うのかと尋ねると、返ってきたのは「今のお客様は100万人ぐらい」という答えだった。
個人のローカルサーバーに100万人が接続することは不可能だ。しかし、その事実を伝えると相手は驚く。「そういうことはよくあります」と清水氏は言う。
同じ断絶は、プロの現場にもあった。清水氏がドワンゴに在籍していた当時、顧客は1日に数万人程度で、1999年としては多いほうだったがWebサーバーで対応できていた。それが1日10万人、100万人へと増えていくと、必要なスタックがまるごと変わる。しかしその感覚がないと、手元で知っている技術のまま組んでしまう。新人をアサインしたりすれば、ある日突然動かなくなる。
この経験があるからこそ「それは無理です」と原理から判断できる、というのが清水氏の見立てだ。裏を返せば、経験のない人間にはその判断ができない。
「その経験がないビジネスパーソンは、プロトタイプまではすぐに作れるかもしれませんが、それを安定的に運用するとか、ましてお金を取って提供するというのは、もう非常に危険だと言えます」
作れることと、提供できることは違う。バイブコーディングが埋めたのは前者までの距離であって、後者との間にある溝はそのまま残っている。
