今から20年以上前、まだスマートフォンが存在しない時代のことです。
携帯電話がようやく“情報端末”として使われ始め、インターネットが一部の先進的なユーザーのものから、少しずつ一般の生活に入り込もうとしていた頃、私は携帯向けECモールのベンチャーに関わっていました。
今でこそ、スマホで商品を探し、レビューを見て、ワンタップで注文し、翌日には商品が届く世界は当たり前です。しかし当時は違いました。端末の性能も低い。通信も遅い。画面も小さい。入力も不便。決済環境も未整備。ユーザーの行動も読めない。加盟店の理解も薄い。市場も習慣も、何ひとつ完成していませんでした。
それでも、私たちは確信していました。
いつか携帯端末でモノを買う時代が来る。
店舗に行かなくても、パソコンを開かなくても、手のひらの端末で商品を選び、比較し、買う時代は必ず来る。
だからこそ、その未来に先回りして、携帯ECモールを立ち上げることには十分な意味があると思っていたのです。
当時の私たちには、資本準備金として1億円がありました。
ベンチャーとしては決して小さな金額ではありません。むしろかなり恵まれていた方だったと思います。普通に考えれば、開発費と運営費を確保しながら、一定期間は試行錯誤を続けられるはずでした。アイデアだけで何もできない会社ではなく、ちゃんと挑戦できるだけの資金があった。少なくとも、当時の私たちはそう思っていました。
しかし結論から言えば、その1億円はわずか1年でほぼ溶けました。
開発費、運営費、人件費、外注費、サーバー費、調整コスト、修正コスト。あらゆる費用が積み上がり、想像していたよりはるかに速いスピードで資金は失われていきました。
そして、最後には会社は解散しました。
この話だけを切り取ると、「当時はまだ時代が早すぎた」「市場が未成熟だった」「経営判断に問題があった」「運が悪かった」といった言い方もできるでしょう。もちろん、そうした要素がまったくなかったわけではありません。新規事業には常に不確実性がありますし、どんな挑戦にも市場タイミングや外部環境の影響はあります。
けれど、今振り返って私ははっきり思います。
あの失敗の本質は、単に“早すぎた挑戦”だったことではありません。
本当の問題は、変化が前提の事業を、変化に耐えられない開発構造で動かしていたことにありました。
当時の開発は、とにかく重かった。
いまのように、とりあえずプロトタイプを作ってユーザーに見せる、動かしながら直す、小さく出してすぐ改善する、という発想はまだ一般的ではありませんでした。要件を固め、設計し、開発を依頼し、完成させ、リリースする。大きく作って、大きく出す。そして一度出したものを変えるには、また大きな労力と時間がかかる。それが普通でした。
問題は、その“普通”が新規事業と決定的に噛み合っていなかったことです。
新規事業というものは、最初から正解が見えているわけではありません。むしろ、何が正しいのかがわからない状態で始まります。市場に出して、反応を見て、問題を洗い出し、仮説を修正し、また直していく。その連続でしか前に進めません。つまり、新規事業に必要なのは“最初に完璧に作る力”ではなく、間違いながら高速で改善する力なのです。
ところが私たちは、その最も重要な改善速度を持てませんでした。
問題が見つかる。
直そうとする。
だが、すぐには直せない。
仕様を見直し、依頼し、見積もりを取り、順番を調整し、再度開発し、テストし、反映する。
その間にも、事業は止まらない。費用だけは流れ続ける。
その結果、直す前にまた次の問題が出る。
そして、改善したい箇所だけが増えていく。
この構造の恐ろしさは、表面上は「不具合が多い」「開発費が高い」「売上が立たない」といった個別問題に見えることです。しかし本当に会社を壊したのは、それらひとつひとつではありません。問題を問題のまま抱え込む時間が長すぎたことです。
時間が長いということは、その間に資金が減るということです。資金が減るということは、判断が守りに入るということです。守りに入るということは、改善がさらに遅くなるということです。
つまり、開発の重さは、単なる技術課題ではなく、経営そのものを壊していく構造的な問題だったのです。
私はあの時、目の前で起きたことを単に「ベンチャーの失敗」として処理することができませんでした。
なぜなら、そこで起きていたのはもっと根深い問題だったからです。
それは、新しい事業に挑む企業が、古い開発のやり方に縛られていたということでした。
未来を作ろうとしているのに、未来に必要な速度を持てない。
市場は変わるのに、システムはすぐ変えられない。
顧客の行動は動くのに、提供する体験は固定されたまま。
この矛盾が、事業の成長を止め、最後には会社の命まで削っていきました。
ここで重要なのは、当時の私たちだけが特別に失敗したわけではないということです。
むしろ、あの時代の多くの事業が、同じ問題を抱えていたはずです。
システム開発は高額で、専門家依存で、修正が重く、失敗の代償が大きかった。だから、事業の良し悪し以前に、「変えられないこと」そのものが最大のリスクだったのです。
私はこの経験を通じて、ひとつの確信を持つようになりました。
事業の成否を分けるのは、最初にどれだけ立派な計画を描けるかではない。
どれだけ大きな資本金を集められるかでもない。
本当に大事なのは、想定外が起きたときにすぐ変えられることだということです。
新規事業には、必ず想定外が起きます。
顧客は思った通りには動かない。
現場は設計図通りには回らない。
市場は期待した速度では立ち上がらない。
競合も出る。トラブルも出る。仕様も足りない。導線も甘い。運用も詰まる。
それらを一つひとつ乗り越えていくしかありません。
だからこそ、開発は“作品づくり”であってはならない。
開発は“仮説検証装置”でなければならない。
ところが、昔のシステム開発はそうではなかった。
一度作ると重い。直すのも重い。学ぶのも遅い。
結果として、間違いを小さく済ませられず、失敗がそのまま会社を潰す規模に膨らんでしまう。
それが、あの1億円が1年で消えた本当の意味だったのだと思います。
今、私はあの経験を“過去の苦い思い出”として語りたいのではありません。
むしろ逆です。
あの失敗があったからこそ、いま起きている変化の本質が見えるのです。
なぜ今、バイブコーディング時代の開発革命がこれほど重要なのか。
なぜ「速く作れる」ことが、単なる効率化ではなく、経営そのもののルール変更になるのか。
その原点には、あの日見た“重すぎる開発が会社を潰す現場”があります。
あの頃、もし今日のように、もっと小さく試せて、もっと早く修正できて、もっと安く改善を繰り返せる環境があったなら。
もし、仕様変更が数週間単位ではなく、数時間や数日単位で進められたなら。
もし、事業の仮説をすぐ形にして、すぐ市場にぶつけて、すぐ直すことができていたなら。
あの1億円の使い方はまったく違うものになっていたはずです。
そして、会社の運命もおそらく変わっていたでしょう。
つまり、問題は資金の多寡ではなかった。
問題は、資金を“学びに変える速度”が遅すぎたことだったのです。
1億円があっても足りなかった時代。
いや、正確に言えば、1億円あっても“変えられない構造”の前では無力だった時代。
私はその現場を、身をもって知っています。
そして、だからこそ今、断言できます。
開発の本当の価値は、システムを完成させることではない。
事業を何度でも進化させられる状態を作ることにある。
ここから先の時代、その本質をつかんだ企業だけが勝ち残っていく。
あの日の失敗は、そのことを20年以上も前に私に教えていたのです。