この冗談が機能するのは、冗談では終わらないから
日本の現場でいうメテオフォール型開発です。終点だけ先に決まり、停車駅は途中で変わり、予算は「何とかする前提」で置かれ、開発側は列車がもうすぐ出ることになっている状態で線路を敷かされる。そういう進め方です。
このミームが面白いのは、現実のチームで本当に何度も起きているからです。
創業者はエッジケースがまだ見えていない機能を先に約束し、プロダクトチームはデザインが進んだ後でオンボーディングフローを描き直し、経営陣は AI が前の画面をあれだけ速く作ったのだから「インテグレーションをもう一つ足すくらい簡単だろう」と考える。路線は変わり続けるのに、締切だけは動きません。
悪い知らせは、どんなアーキテクチャパターンでも人間の非現実的な期待そのものは止められないことです。
良い知らせは、その非現実的な期待がエンジニアリングの停滞に直結する必要はもうない、ということです。
本当に痛いのは期待の問題だけではない
ひどい計画は確かに厄介です。時間を燃やし、圧力を増やし、交渉を何度も発生させる。でも、それだけでは進行は壊れません。
進行を本当に壊すのは、遅れて入ってきた仕様変更の一つひとつがシステム全体のリスクになることです。
これは高速な AI-generated コードベースの典型的な破綻パターンです。最初の版が速く出ると、周囲は次の変更も同じ速度で片付くと思い始めます。そして現実が来る。
- 認証プロバイダを差し替える必要がある
- analytics を optional にしなければならない
- deep link の経路が一つ間違っている
- 一つのスタイリング判断が 40 個の画面に広がっている
- 「小さな」機能が三つの無関係な module を横断している
こうなるとチームが抱えるのは非現実的な期待だけではありません。局所的に変更を吸収できない コードベースそのものも相手にしなければならない。
これが二重課税です。組織の問題だけでも十分に重いのに、技術の問題がそれをさらに悪化させます。
メテオフォール型開発が先に壊すのは脆いコードベース
このミームがエンジニアに刺さるのはそのためです。
誰もが同じパターンを見てきました。
- 地図が固まる前に路線が発表される。
- 実装が始まった後も範囲が広がる。
- 資料の締切だけは据え置き。
- 開発側は「とにかく適応して」と言われる。
システムの boundaries が弱いと、「適応」は実際にはこういう意味になります。
- 誰も設計していない AI-generated abstraction を逆算する
- お互いの内部実装に手を伸ばしている module をほどく
- 触るつもりのなかった場所で起きた regression を直す
- 本当は残すべきではない実装を守るために一週間を失う
その段階ではチームはもうプロダクトを作っていません。締切の下で発掘作業をしているだけです。
この状態は、もう受け入れなくていい。
Autotomy は failure mode を変える
Autotomy は非現実的な見積もりを現実にはしません。もっと役に立つことをします。system を差し替え可能なまま保つのです。
考え方は単純です。ある module が間違っていたり、遅れていたり、もう路線に合っていないなら、切り離して、置き換えて、そのまま進める べきです。
そのために必要なのは、いくつかの譲れない前提です。
- auth、analytics、storage、notifications のような変化しやすいサービスの前に interface を置く
- アプリがどの実装を使うかを一つの composition root で決める
- 画面が vendor details を直接 import しないよう dependency boundaries を張る
- module を入れ替えても振る舞いを守れるよう contract tests と deterministic checks を置く
- optional tools がリリースを左右する基盤のように振る舞わないよう dependency tiers を引く
ここが整っていれば、動き続ける目標はまだ厄介でも存亡に関わる問題ではなくなります。
プロバイダ変更は interface の裏側の差し替えになります。プロダクトの迂回はシステム全体の refactor ではなく局所的な書き直しになります。悪い AI-generated module は、慎重に保存する対象ではなく、削除して差し替える対象になります。
路線が変わっても開発は続けられる
ここが一番実務的な変化です。
Autotomy がないメテオフォール型開発は、こう聞こえます。
「onboarding plan がまた変わったので、auth、profile state、analytics、styling、navigation を全部触る必要があります。何が壊れるか見極めるのに一週間ください。」
Autotomy があると、こう変わります。
「期待はまだ非現実的ですが、変更は局所化されています。必要なのはアプリの作り直しではなく、範囲か期日の再交渉です。」
これははるかにましな失敗モードです。
もちろん納期の約束に異議を唱える必要はあります。リリースを分割することも、路線から停車駅を一つ切ることも、土壇場で追加された支線を断ることもあるでしょう。でも開発組織が二重に苦しむ必要はありません。人間の問題は人間の問題のまま、ソフトウェアの問題は扱える範囲に留められます。
AI の速度はこの問題を軽くするどころか、むしろ重要にする
メテオフォール型開発が今さらに増えている理由の一つは AI coding です。
Cursor や Claude Code が数時間で機能の最初の版を作れるようになると、経営陣はその後の反復も全部同じように速いはずだと思い始める。彼らが見ているのは表面の速さであって、変更コストの構造ではありません。
現実は違います。
AI は実装を埋めるのは得意です。でもプロダクトの現実が変わったときに system を構造的に安全に保つ責任までは持ちません。コードベースに boundaries がなければ、AI の速度は脆さに到達する速度を上げるだけです。
だから私は同じ点に戻ります。AI-native development に対する正しい反応は、もっと楽観的になることではない。もっと差し替え可能にすることです。
速く生成する。boundaries を強制する。決定論的に検証する。路線が変わったら悪い module を削除する。影響範囲を局所に閉じ込める。
幻想の部分は、まだ自分たちで扱わなければならない
どんな framework も計画会議に入っていって、「そのリリース日は想像上のものです」と代わりに言ってはくれません。
Autotomy は優先順位付けも、願望込みのロードマップも、開発開始後に関係者が地図に新しい駅を描き足すことも止めません。
そこは今でもエンジニアとして、そして大人として対応する必要があります。
でも、難しさはそこだけであるべきです。
plan が動くたびに一緒に崩れる codebase を蘇生させる仕事まで抱えるべきではありません。
メテオフォール型開発が組織の天気のように残り続けるなら、それでいい。期待管理のミームとして残せばいい。
Autotomy があれば、それをエンジニアの苦しみのミームにまでしなくて済みます。