Waterfall in 15 Minutes or Your Money Back
先日、友人と軽く近況報告をしていたら、雑談がいつの間にか AI 支援コーディングの深い沼にハマっていった。ワークフローやチーム体制、そして私たちが大事にしてきた「ものづくりの誇り」がどう揺れるかまで掘り下げることに。古いコード基盤の書き直しから、自動テストがプログラミングの本質をどう変えるかまで話題は広がり放題だった。
その会話を granola で文字起こしし、o1-pro に突っ込んで「ブログ記事にして」と頼んだら、なかなかの仕上がり。自分の考えもしっかり反映されていた。
何人かの友人に送ったら「さらに回したい」と言うので、もう公開するしかない。ではどうぞ!
これはいいリマインダーだけど、もし完璧すぎてクセのないメールが届いたら──たぶん AI が書いてるよ。[笑]
15 分でウォーターフォールが完了 ― できなきゃ全額返金!
新常識:「コード品質って本当に重要?」
長いあいだ私たちはコードを“職人の作品”として語ってきた。貴重なフロー状態(いわゆる“ゾーン”)に入り、ロジックを彫刻のように磨き上げ、手づくりのバグ修正を携えて勝利する──そんな美学だ。ところが今や、コード生成ツール(LLM:大規模言語モデル)が数分で機能を量産する新しいパラダイムが静かに忍び寄っている。
この速度に戸惑い、「きれいなコード」の基準が揺らぐのを嫌がる人もいる。堅牢なテストスイートや TDD でさえ、一行ずつ吟味するというより「ボットに自分で確かめさせる」儀式になりつつある。
コード品質が急降下する? その可能性はある。だが同時に、静的解析・形式検証(formal verification)・全面的なテストカバレッジといった過剰に守りを固めたコード設計も加速中。AI エージェントが何かを壊しても即座に拾えるよう、CI/CD パイプラインと厳密なチェックこそ今もっとも欠かせない。
15 分ウォーターフォール

かつて「ウォーターフォール vs. アジャイル」は善悪の対立軸で、アジャイルこそ正義とされていた。ところが皮肉にも、コード生成は私たちをマイクロなウォーターフォールサイクルへ押し戻しつつある。AI が迷わないよう仕様を緻密に書き、ボタンを押し、生成を待ち、レビューする。見た目は反復的でも、実際は計画→実装→レビューの塊を順番にこなす──これが「15 分ウォーターフォール」だ。
真の魔法は同時多発的にエージェントを走らせられること。1 つの AI が機能をつくる横で、別の AI がドキュメントを書き、さらに別の AI がテストをかじる。もはや昔ながらの直列ウォーターフォールではなく、ドーピング級の並列処理だ。
チーム文化はどう変わる?
エンジニアリングチームを率いているなら、経営層から「AI で生産性を上げよう」と迫られる一方、現場の熱量に濃淡があるのを感じているはず。プロンプトだけで新機能を組み上げるメンバーもいれば、職人気質を守りたいメンバーもいる。
うまく回すコツは次のとおり。
小さく試す
低リスクの社内ツールやサイドプロジェクトを選び、好奇心旺盛なエンジニアに AI コーディングを思い切りやらせる。モデルを信用し過ぎたらどうなるかを体験し、どう収拾するかを学んでもらう。メンバーをローテーションする
「AI コーディング専用」サイドプロジェクトを用意し、1〜2 週間ずつメンバーを入れ替える。得た知見を本流のコード基盤へ持ち帰ってもらう。ドキュメントに本腰を入れる
AI エージェントは驚くほど明快な仕様を要求する。コード生成自体は安いが、LLM を正しい方向へ導くには綿密な設計が必要だ。史上最高レベルの仕様書とアーキテクチャ図をリポジトリに置いておこう。ローテーション時に真価を発揮する。
フロー状態は過大評価かもしれない
多くの開発者が“ゾーン”に入る感覚に憧れてコーディングを始めた。しかし AI コーディングは必ずしも没入を要求しない。1 時間かけてプロンプトをセットし、AI が裏でコードを吐き出すのを眺め、ときどき承認や微修正を入れる──そんなサイクルだ。
このギャップに戸惑う人もいるが、子育て中だったりタスクを抱え込んでいる人には解放感がある。AI の出力を確認→日常に戻る→動くスニペットへ戻る。このコンテキストスイッチで「静かな長時間」がなくても成果を出せることに気づく。
これで“ピークプログラマー”到来?
「AI がコードを書くならエンジニアは余る」という声もある。単純な機能開発や API 接続なら、確かに人数は減るかもしれない。だが一方で、セキュリティ、コンプライアンス、テストカバレッジ、アーキテクチャといった新しい複雑さも生まれている。
これから輝くのは“戦略的エンジニア”だ。複数の AI ツールをオーケストレーションし、品質を監視し、スケールするシステムを設計する。プロダクトマネージャー、アーキテクト、QA、開発者を少しずつ兼ね、プロンプトを組み立て、テストを定義し、LLM が見落とすエッジケースを捌く──そんなロールが主役になる。
現場からのプロチップ
まず手動でプロジェクトを作り、次に AI をオンにする
たとえば iOS アプリなら、最初に Xcode でプロジェクトを初期化し、雛形ファイルを生成しておく。こうしておけば、AI が「無いはずのファイルを勝手に作る/既存を上書きする」といった混乱を防げる。短く明快なプロンプトを試す
「コードを良くして」のひと言が、長大な指示書に匹敵することもある。モデルごとに制約の少なさが効くケースを探ろう。“チェックポイント”ワークフローを徹底する
こまめにgit commit -m "It passed the tests, I guess!"
。AI は直すのと同じ速さで壊す。頻繁なコミットが安全網だ。AI の過剰テストを間引く
AI はfor
ループが回るかまでテストしたがる。無意味なテストを整理し、パイプラインを軽く保とう。あらゆることをドキュメント化する
AI に巨大な「実装ガイド」を吐かせよう。それは自分の助けになるだけでなく、次のパスで AI 自身の手がかりにもなる。
まとめ

この業界はかつてない速さで変わっている。フロー状態の神聖視や、丹念に手書きしたコードを祝う文化は、きっと懐かしい風景になる。だが創造性が死ぬわけではない。これからは“戦略的オーケストレーション”──何を作るか、どう説明するか、どう炎上させずに済ませるか──が主戦場だ。
最終的にプロダクトを勝たせるのは、コードを力技で叩き込むことではない。ユーザーが愛する体験を設計できるかどうかだ。週末で Instagram を 10 バージョン作れる時代、勝負を決めるのはコードの優雅さではなく、心をつかむかどうか──それはプロダクトとデザインの問題で、純粋なエンジニアリングだけでは測れない。
ようこそ、新しいウォーターフォールへ。15 分サイクルで、AI という無限のジュニアエンジニアを従え、パイプラインはハイパードライブ状態。奇妙で、素晴らしく、ときに恐ろしい世界だが、このダンスを覚えるしか道はない。
なんて不思議な世の中だろう。これからもっとヘンになりそうだ。さあ、掘っていこう。
ご注意: この投稿は主にAIによって生成されました。投稿内でその旨が開示されているはずです。LLMによって生成されたものではありますが、自分の考えを正確に反映していると思っているため公開しています。