ベンチャーや新規事業が失敗した話をすると、多くの人はすぐにこう言います。
「結局、開発費が高すぎたんでしょう」
確かに、それは一見もっともらしく聞こえます。
20年以上前の携帯ECモール開発は、いまのような軽いものではありませんでした。システム開発にはまとまった費用が必要で、専門人材も限られ、外注に頼る部分も大きい。だから、資金が先に尽きたと言えば、その説明は表面的には成立します。
しかし私は、あの失敗の原因を単純に「開発費が高かったから」と片づけるのは危険だと思っています。
なぜなら、それでは本質を見誤るからです。
本当の問題は、初期の開発費の大きさそのものではありませんでした。
会社を壊したのは、変更コストの高さです。
もっと言えば、変更のたびに時間もお金も気力も奪われる構造そのものが、事業をじわじわと殺していったのです。
ここでいう変更コストとは、単にプログラムを書き換える料金のことではありません。
仕様変更のたびに発生する再検討、調整、依頼、見積もり、優先順位の変更、社内説明、テスト、確認、反映までのすべてを含みます。
見た目には「機能をちょっと直すだけ」に見えても、実際にはその後ろに多くの関係者と工程がぶら下がっている。
だから、ひとつ改善しようとすると、実装以上に周辺コストが膨らむ。
この“見えない負担”こそが、開発を重くし、事業を鈍らせ、最後には会社の判断まで鈍らせていきました。
例えば、ユーザーの離脱率が高いとします。
原因を調べてみると、登録フォームが長すぎる、画面遷移が複雑、入力項目が多い、決済導線がわかりにくい、そうした問題が見つかる。
改善案も出る。
ところが、そこからが重い。
どこを変えるのか整理し、関連機能への影響を見て、仕様を詰め、依頼し、見積もりを確認し、スケジュールを引き直し、実装を待ち、テストし、反映する。
この一連の流れの中で、最初に見つけた“改善したい気持ち”はどんどん時間に薄められていきます。
しかも、その間にも顧客はその不便なフォームを使い続け、離脱し続けます。
営業は「使いづらい」という声を聞き続けます。
サポートは同じ問い合わせに追われます。
経営は数字の鈍化を見ます。
そして社内には「直したいのに、まだ直らない」というストレスが溜まっていく。
これが変更コストの正体です。
それは会計上の勘定科目だけでは見えない。
しかし確実に、売上機会、組織の士気、意思決定の鮮度、顧客満足を削っていくのです。
恐ろしいのは、変更コストが高い組織では、だんだんと“変えようとすること”自体が減っていくことです。
最初のうちは、現場も経営も「ここを直せばよくなる」と前向きです。
しかし何度も重い変更を経験すると、人は次第に学習します。
どうせすぐには直らない。
また調整が大変だ。
費用もかかる。
今は我慢した方がいい。
今は他の優先事項がある。
そうして、本来なら小さく早く潰すべき問題が、先送りされるようになります。
この状態は非常に危険です。
なぜなら、事業を壊すのは大きなミスだけではなく、小さな違和感を放置する習慣だからです。
ユーザーの使いにくさ。
運用現場の手間。
管理画面の煩雑さ。
顧客対応の詰まり。
ひとつひとつは致命傷に見えなくても、それが積み重なると、事業は確実に重く、遅く、売れにくくなっていきます。
そして、その積み重ねを防ぐ唯一の方法が、変更コストを低く保つことなのです。
私はここで、開発というものを“技術部門の仕事”として切り分けて考えることの危険性を強く感じます。
開発とは、経営そのものです。
なぜなら、何を作るか、何を直すか、どこを後回しにするかは、そのまま経営判断だからです。
そして、経営判断が実装されるまでに長い距離がある会社では、どんなに立派な戦略も実行速度で負けます。
戦略は正しくても、反映が遅い。
顧客理解は進んでも、改善が遅い。
現場は問題を把握しても、修正が遅い。
そういう会社は、頭では理解していても、体が動かない会社です。
市場で勝てるはずがありません。
20年以上前の携帯ECモールの現場で、私はまさにその感覚を味わいました。
問題は見えている。
直すべきポイントもある程度わかっている。
しかし、そこから先が遅い。
直したいのに、直せない。
その間に、また次の課題が出る。
さらにまた別の修正要望が出る。
結果として、改善すべき箇所が渋滞し、事業全体が“未処理の問題の山”に埋もれていく。
このとき初めて私は、開発費の多寡よりも、変更コストの高さこそが会社の命取りになるのだと実感しました。
資本準備金1億円が1年で消えたのも、考えてみれば当然でした。
もしその1億円が、ひとつの仮説を素早く試し、うまくいかなければすぐ別案を打ち、顧客の反応を見ながら次々に改善するために使えていたなら、話は違ったはずです。
しかし現実には、その多くが“直すための待ち時間”と“直すための重い手続き”に吸い込まれていきました。
つまりお金は、成長の燃料として燃えたのではなく、摩擦熱として消えていったのです。
この違いは極めて大きい。
同じ1億円でも、学習速度が高い事業なら、何十回もの仮説検証に変わります。
しかし変更コストが高い事業では、数回の大きな修正だけで尽きる。
前者は失敗しても知見が残る。
後者は失敗しても疲弊だけが残る。
だから私は、経営者が本当に見るべき数字は、初期開発費の見積もりだけではないと思っています。
見るべきなのは、1回の修正に何日かかるか、1回の変更に何人巻き込まれるか、1回の改善にどれだけ気力が削られるかです。
そこにこそ、その事業が生き残れるかどうかの本質が隠れています。
今の時代、この問題は昔より改善されてきています。
AI、クラウド、ローコード、各種開発支援ツール、アジャイルなチーム構成、モジュール化された設計、そして何より“変更を前提にした開発思想”が広がってきた。
だが、だからといって安心してはいけません。
ツールが進化しても、組織の考え方が昔のままなら、結局は同じことが起きます。
仕様を固めすぎる。
承認が多すぎる。
現場と開発が遠すぎる。
改善の優先順位が経営とずれる。
すると、技術的には速くできるはずのことが、組織構造の重さによって遅くなってしまう。
つまり、変更コストの怪物は今でも姿を変えて生き続けているのです。
だからこそ、バイブコーディング時代の意味は大きい。
それは単にコードを書く速度が上がることではありません。
“変えたいと思った瞬間に変えられる距離”を短くすることです。
経営の意思と現場の改善が、もっと近い場所でつながる。
仮説が出たら、すぐ形になる。
違ったら、すぐ戻せる。
必要なら、その日のうちに別案を試せる。
ここまでくると、開発はもはや後工程ではなく、経営そのものの一部になります。
会社を壊すのは、大きな失敗だけではありません。
じわじわと積み上がる変更コストです。
そして逆に、会社を強くするのも、小さな変更を軽く何度も回せる構造です。
私はあの日、1億円が1年で消える現場で、その真逆を見ました。
だからこそ今、はっきり言えます。
開発革命とは、人件費を削る話ではない。
外注費を減らす話でもない。
本質は、変更コストという見えない怪物を、経営から追い出すことなのです。
それができた企業から、次の時代の新規事業は別物のように強くなっていく。
バイブコーディング時代の価値は、そこにあります。