新規事業に関わったことのある人ほど、よくわかるはずです。
事業は、始める前がいちばん美しく見えます。
構想段階では、課題も整理され、価値提供も明確に思え、ターゲットも描ける。競争優位も説明できる。売上計画も引ける。将来像も語れる。会議室の中では、すべてが筋の通った話に見えることさえあります。
しかし、現実の市場は会議室の外にあります。
そして市場に出した瞬間から、計画は現実に試されます。
すると、驚くほど多くのことが想定通りに進きません。
ユーザーは思った導線で動かない。
重要だと思った機能が使われない。
逆に軽く見ていた部分で離脱が起きる。
加盟店側の運用負荷が高すぎて回らない。
管理画面がわかりにくい。
問い合わせ対応に工数がかかる。
表示速度が遅い。
登録フローが長すぎる。
決済の心理的ハードルが高い。
スマホ前夜の携帯端末では、画面表示ひとつ取っても、理論通りにいかないことばかりでした。
ここで重要なのは、これらを「予想外のトラブル」と見るか、「新規事業の当然の現象」と見るかです。
私は今では、後者でなければいけないと考えています。
新規事業とは、最初から正解を持っている人がその通りに実行する仕事ではありません。
新規事業とは、市場に出しながら正解を見つけていく営みです。
つまり、リリース後に問題が出ること自体は失敗ではない。
むしろ、それが出ない方が不自然なのです。
ところが、多くの企業はこの前提を頭では理解していても、実際の開発構造がそれに対応していません。
「最初から問題は出る」と言いながら、開発の組み方は「問題が出ない前提」で設計されている。
「市場を見ながら改善する」と言いながら、実際には改善のたびに要件整理、承認、見積もり、順番待ち、実装、テストという重たい工程が発生する。
「アジャイルに行こう」と口では言っていても、実態は旧来型の分業と承認構造のまま。
これでは、いくら新規事業を語っても、本質的には動けません。
20年以上前に私が経験した携帯ECモールも、まさにそうでした。
未来を作るつもりで始めたのに、開発の仕組みそのものは“未来向き”ではなかった。
問題が見つかるたびに直そうとする。だがすぐには直せない。
すぐ直せない間にも、顧客は離れ、加盟店は不満を持ち、社内は焦り、コストだけが流れる。
その結果、問題そのものよりも、「問題を抱えたままの時間」が会社を消耗させていきました。
ここで改めて強調したいのは、本当の敵は不具合そのものではないということです。
本当に怖いのは、その不具合を小さなうちに潰せないことです。
導線に問題があること自体よりも、導線を直すのに1か月かかることの方が危険なのです。
登録フォームが複雑なこと自体よりも、フォーム改善の意思決定から反映までに数週間かかることの方が致命的なのです。
機能不足より、機能追加が重いことの方が深刻です。
なぜなら、前者は市場の学びとして価値がありますが、後者はその学びを次につなげる力そのものを奪うからです。
新規事業では、問題が出るのは当然です。
顧客の反応も、競合の動きも、運用上の詰まりも、すべてが仮説検証の材料になります。
問題が出ることは悪ではありません。
悪なのは、それを見つけても直せないこと。
もっと言えば、直せる頃にはすでに状況が変わっていて、改善が“過去への対応”になってしまうことです。
市場は待ってくれません。
顧客も待ってくれません。
組織の士気も待ってくれません。
なのに、開発だけが昔の時間感覚で動いている。
このズレが、どれほど多くの新規事業を内部から壊してきたか。
私は、あの時代の現場を思い出すたびに、その本質は今も変わっていないと感じます。
たとえば、多くの経営者は「開発にはお金がかかるものだ」と思っています。
もちろん、その認識は一面では正しい。
しかし、もっと正確に言えば、問題は“開発そのもののコスト”より“改善の遅さが生む損失”です。
開発が遅い会社では、ひとつの改善の遅れが、そのまま売上機会の損失になります。
顧客の不満が長く残る。
現場の疲弊が積み上がる。
営業は売りづらくなる。
問い合わせ対応は増える。
社内では「まだ直らないのか」が積み重なる。
つまり、開発の遅さはエンジニアリングの問題に留まらず、事業全体の摩擦係数を上げてしまうのです。
そして、この摩擦が最も重くのしかかるのが新規事業です。
既存事業ならまだ、ある程度の顧客基盤も、収益の土台も、運用ノウハウもあります。少々の遅れがあっても吸収できる余地があります。
しかし新規事業は違う。
収益もまだ不安定。運用も未整備。顧客理解も不足。成功パターンも確立していない。
そんな事業にとって、改善の遅さは“少しの非効率”ではなく、生命線そのものの損耗です。
だから私は、新規事業における開発の価値を「立派なシステムを作ること」だとは思っていません。
むしろ逆です。
大事なのは、壊しやすく、直しやすく、試しやすい状態を作ることです。
今日の仮説が明日には変わる。
昨日必要だった機能が、今日には不要になる。
市場が見せた反応に応じて、優先順位が入れ替わる。
そうした変化を前提にすると、最初から巨大で完璧なものを作る発想自体が危うい。
完成度より可変性。
美しさより更新性。
初期の正しさより、継続的に正しくなれる構造。
それこそが、新規事業に必要な開発思想です。
20年以上前、私たちはそこにたどり着けませんでした。
未来を見ていたのに、開発思想はまだ未来に追いついていなかった。
だから、何か問題が起きるたびに、事業が前進するのではなく、事業が削られていったのです。
本来、問題は改善の起点になるべきでした。
しかし実際には、問題が出るたびにコストが膨らみ、時間が失われ、組織が疲弊していった。
この違いは決定的です。
そして今、ここに大きな転換点が来ています。
バイブコーディング時代の本質は、単にAIでコードを書くことではありません。
その本質は、事業に合わせてシステムを呼吸させられることです。
以前なら数週間かかっていた改善を、数日、数時間の単位に圧縮できる可能性が出てきた。
以前ならエンジニアの工数待ちだった変更を、もっと軽やかに回せるようになってきた。
以前なら「仕様を固めてから」でなければ動けなかったものが、「仮で出して見てから考える」こともできるようになってきた。
これは開発効率の改善に見えて、実際には新規事業の前提そのものを変える出来事です。
新規事業は、完成品で勝つのではありません。
市場と対話しながら、未完成なものを何度も進化させて勝つのです。
そしてそのとき、最大の武器になるのは技術力の高さだけではなく、変更を恐れない構造です。
不具合は出ます。
想定外も起きます。
うまくいかないことも当然あります。
問題はそこではない。
問題は、それを見つけた後の自分たちが、どれだけ早く、どれだけ軽く、どれだけ何度でも変えられるかです。
新規事業の本当の敵は、失敗ではありません。
本当の敵は、失敗を学びに変えられないこと。
そして、その原因の多くは、修正できない構造にあります。
あの時代に私はそれを痛感しました。
だからこそ今、私は強く思います。
開発革命とは、開発が速くなる話ではない。
事業が失敗から立ち上がる速度を上げる話なのだと。