AI駆動開発とウォーターフォールと運用設計を想像する
少し前にこちらの記事が流れてきたので、考えていることを書く。論拠は何もない雑文。
AI駆動開発における設計業務
2025年初頭にClaude Codeを触り始めて早々に感じたのは「コーディング作業がバッチ設計みたいになっている」ことだった。きっと20世紀のエンジニアがIBMのコンピュータ向けにパンチカードを設計している気分はこんな感じだったのかなあ、と思った。再び建築設計に近づいている、と言ってもいい。
（少なくとも初期の段階において）AIコーディングは質が高くなくても圧倒的に高速であるため、人間が開発速度のボトルネックになることがわかった。よってAIにどれだけ任せきれるかを考えることになる。すると今でいうループエンジニアリングみたいな発想に至る。なるべく開発工程において、いかに人間を介入せずにAIだけで機械的に判断・開発・レビューが回すことができるのか。開発プロセス自動化、つまり自動化の自動化設計＝メタ自動化設計（？）みたいなことをする。
このとき従来に比較して、コーディングよりも
- 達成目的を明確にすること
- 正確にデータや指標やアウトプットを定義すること
- 再現性を担保した形で機械的にレビューできる枠組みをつくること
- 将来的に柔軟なソフトウェア/インフラアーキテクチャを設計すること
といったシステム/プロセス設計作業が重要になる。こうした設計の良し悪しで、そのプロダクトがAIの実力を最大化できるかが決まる。だからこそ既存のいまいちなアプリケーションをAI駆動開発化することは難しい。設計から見直す必要があるから。
上から下への流れのこと
「効率的によりよく作る」というザ・工学的な観点において、ソフトウェアの開発作業よりも事前の設計作業の比重が非常に大きい。そのことが必然的にウォーターフォール的な開発プロセスを導くように思われる。
そもそもアジャイルは包括概念であるため、なくなる/なくならないという二元論で話せない。まあテスト駆動開発や振り返り技法、ユーザストーリーマップのような個別プラクティスは引き続き使われるだろう（名前が変わるかもとは思う）。スプリントやスクラムがどうなるかはよくわからないが、ウォーターフォールが駆逐する可能性もあるのでは。グレシャムの法則（「悪貨が良貨を駆逐する」）のような感じで。
あくまでぼくの理解としては、という但し書きの上で。アジャイルソフトウェア開発宣言に宿る”お気持ち”は、「エンジニアリング何も知らん上流で設計されて、下流でただ開発するだけって枠組みマジ最低」だと思っている。しかしその抵抗に対する揺れ戻しが起きるのではないか、と感じている。
ここでぼくが言うウォーターフォールは全体の流れのイメージのことで、個々のステップ定義とかV字モデルとかのことでない。その前提で、人間がフラットに考えるとまずウォーターフォール的なプロセスが立ち現れると思っている。プロセスもまたシステムの一部であり、組織構造（秩序）の写像としてあるから。
マルクスが現状整理として”資本主義”と名づけたようなもので、ウォーターフォールは人間社会の中に存在する。その点、アジャイル開発の方が非直感的で設計主義的だろう。だから組織構造がアジャイルの障壁になるし、だからアジャイル開発のことをみな永遠に理解できずにいる。
ループ運用エンジニアリングへの希望の光（はないか）
とはいえ、そうした開発工程のウォーターフォール化が起きたとして、良い側面もあるかなと思う（思いたい）。
最初の仕事がインフラ運用だったので運用設計にずっと関心がある。アプリ開発をしながら、いつも運用設計でうまくいかなくて悩んでいる。そこで時折思うのが、実のところ「アジャイル開発ってやつが運用設計の障害なのではないか」ということ。
上から下へ、プロジェクト計画立てて→予算つけて→設計して→構築して、って流れの方が比較的ちゃんと運用設計フェーズ踏むじゃん、などと思ってしまう。長期にわたるコスト計算ががっつり必要になるからで、それはもちろん開発規模の大きさの問題でしょう？と言われるのはわかる。のだが、まあ「小さく始めようぜ」という大きな思想が運用設計を雑にしている側面はあるのではと思う。
「そこでDevOpsだろ」というのはぼくもそう思うし、DevOps大好きっ子クラブなつもりである。その上で、現実感としてはなかなか難しいなと思ってきた。実際にDev=Opsでないときにそれができるかとか。会計処理を鑑みた組織構造の問題とか、そもそもその両立が真にできる人間がどの程度いるのかとか。クラウド化などによってインフラ設計もやたら幅広くなった印象もあって、一体誰だったらまともにできるのか本当にわからなくなってきた。
ループエンジニアリング設計の一環として、初期の段階で運用設計をしないといけない。人の手をかけずにAIにぐるぐると改修・改善ループを回させ続けるためには・・・運用監視が必要、ログが必要、アラート定義が必要、柔軟なインフラアーキテクチャ設計が必要、そのためのスキル設計が必要、検知・改善パイプラインが必要・・・となるのであれば、それは良いことだな〜と思うところはある。
・・・まあ、そうはいっても今も昔も運用設計は無視されるだけ、とも思う。そもそも運用を考えるということ＝未来を想像すること自体、非直感的で、実に設計主義的で、人間の能力の限界に触れている気がいつもしてはいる。
というかまあ、ね
まあなんかぐずぐず話していたけれど、結局のところ、上流のステークホルダーの視点において「開発や運用のエンジニアリングを考える時に集約される固定的ツール（＝社内AI標準）がある」ってことが影響大きいのかもしれない。それが一番、工程をウォーターフォールに変える要因かもなあと思う。
「ひとまずAIを使ってなんかいい感じにして」みたいなこと。きっとコンピュータが出てきたときも「ひとまずコンピュータっていうすごいやつを使ってなんかいい感じにして」みたいなことが言ってたのではないか。
エンジニアたちが独りよがりにアジャイルとかクラウドとか小難しいこと言ってて、外野から見てITってわけわかんないってなってた時期が長かった。しかしこれからはなんかよくわからんが絶対すごくて必要なことがわかってる”AI”を旗印にして、多くの人々が雑に認識を揃えることができる。上下の認識が揃ってしまうからこそ、秩序の形式をそのまま反映して上から下へ流れていくことになる。
・・・とかなんとかいいつつ、いやまあ、こんな想像はむしろ外れてくれて良いのですけれども、と思ってはいる。