バイブコーディングの試作品が「動いてんじゃん」で終わってしまう問題

画面の上で何かが動き始めると、人は少し安心します。けれども、業務システムの本当の重さは、動き始めたあとに、静かに姿を現すのかもしれません。

※執筆にあたり生成AIとの対話を活用しています。

試作品に見えない試作品

AIに自然言語で指示しながら高速に試作品を生成する、いわゆるバイブコーディングが話題になっています。

ブレッドボードで組んだハードウェアの試作品は、見た目からして「これは試作品だ」と誰にもすぐにわかります。配線はむき出しで、部品も仮置きされていて、ケースにも収まっていない。実用品として使うには、ここからまだ多くの作り込みが必要だということが、見た目だけでも伝わります。

一方、バイブコーディングで生成したソフトウェアは、画面上でそれらしく動いていると、それが試作品だとはなかなかわかりません。この違いが、実は大きな問題を生み出しています。

どちらも実用品として仕上げるためには、まだ多くの要素が不足しています。ハードウェアの試作品であれば「ここを作り込むために投資が必要だ」という説明が比較的受け入れられやすい。しかしソフトウェアの場合は、

「動いてんじゃん」

の一言で、話が終わってしまいがちです。画面が動いている以上、残っているのは微修正と確認作業だけだと思われてしまう。しかし、本当に必要な投資は、むしろその先にあります。

ハッピーパスは、ほんの入口

バイブコーディングがまず生み出しているのは、ハッピーパスです。理想的な条件のもとで、想定どおりに操作され、想定どおりの入力が与えられたときに、正常に動く部分。それ自体には大きな価値があります。ただし、業務で使えるシステムとして完成させるとしたら、それは全体のごく一部にすぎません。

残りの、そして大きな部分は、想定外の操作や入力に対処するいわゆるサッドパスや、繁閑の波があっても性能が揺らがないための負荷耐性、障害時の復旧性、ログや監視、そして「仕事として使用に堪える」システムとしての堅牢性の作り込み——これらは、画面を少し触っただけではほとんど見えません。

「当たり前」の裏側

業務システムにとって、機能が動くことは出発点でしかありません。求められるのは、必要なときに、必要な機能がちゃんと使えること。月末の繁忙でも涼しい顔をして動き続けること。内部でトラブルが起きても、できるだけ利用者に見せずに吸収すること。どうしても「ごめんなさい」と言わざるを得ない事態になっても、その時間を極力短くすること。それが、プロの仕事としての「当たり前」です。

壊れないように作るだけではありません。壊れたときでも破綻しないように作る。間違った操作をされても、被害が広がらないようにする。予想外の状態になっても、原因を追えるようにする。誰かが休んでも、運用が続けられるようにする。

そうした地味で、見えにくく、しかし決定的に重要な部分に、業務システムの品質は宿っています。

海面下の重さ

「氷山の一角」という言葉があります。氷山が海面上に見せているのは、全体のほんの一部です。残りの大部分は、海面下に静かに沈んでいます。

バイブコーディングでできあがった画面は、まさにこの海面上の氷山に似ています。見えている部分はそれらしく、触れば動く。だから、もう完成に近いように見えてしまう。けれど、業務システムの本当の重さは、むしろ海面下にあります。

目に見えない部分について「わかってほしい」と求めるだけでは、なかなか伝わりません。画面が動いている以上、見ている人にとっては「もうできている」と感じられてしまうのも自然なことです。

では、どうすれば伝わるのか。ソフトウェアの海面下にある品質を、どう可視化すればよいのか。良い方法はないものだろうかと、今夜も静かに考えています。