AI駆動開発の時代だからこそ、一周回って、ウォーターフォール的にステップを刻んだほうがよいのではないか

AI駆動開発の時代だからこそ、一周回って、ウォーターフォール的にステップを刻んだほうがよいのではないか

1．ウォーターフォールからアジャイルへ移行して、僕が経験したこと

僕は、かつてのウォーターフォール型の開発から、アジャイル、具体的にはスクラムを実践する開発へ移行した経験がある。

確かに、アジャイルによってMVPを作ることは速くなった。まず動くものを作り、ユーザーに見せ、反応を得て、改善する。そのサイクルを短く回せることには価値があった。

しかし、MVPを早く作れることと、本番に耐えられるシステムを効率よく作れることは、同じではなかった。

自分が経験した現場では、ユーザー価値や、目に見える機能、UI・UXの改善に関心が向き、非機能要件が後回しになりがちだった。

ユーザー価値を重視すること自体が問題なのではない。業務で必要な応答時間を満たすこと、必要な処理量を扱えること、安全に利用できること、安定して運用できることも、ユーザーにとって重要な価値である。

ただ、短いサイクルで目に見える成果を出すことに集中すると、そうした条件の検討が十分に行われないことがあった。

最初にシステムアーキテクチャを十分に検討しないまま実装を進めたことで、後から構造を見直す必要が生じ、手戻りが発生した。

データベースのスキーマ、期待レスポンスタイム、想定トランザクション量なども、本番を見据えて検討していなければ、後から実装や構造を変更することになる。

運用要件や運用設計も後手後手になった。動くものを作ってから、誰が運用するのか、何を監視するのか、障害時にどう対応するのか、どう復旧するのかを考えることになった。

その結果、MVPやPoCとしては成立しても、そのまま本番システムへ育てられず、本番開発では全部作り直すことになったケースもあった。

これは、アジャイルという手法が非機能要件やアーキテクチャ、運用設計を不要としている、という話ではない。

僕が問題にしているのは、実装や試作の速さを優先する中で、本番を成立させるための要求や設計が後回しになったことである。

2．実装が速くなっても、開発全体の総工数が減るとは限らない

MVPやPoCによって、顧客が何を求めているのか、技術的に何ができるのかを早く学ぶことには価値がある。

学ぶために意図して作り、結果を得たら捨てる試作であれば、作り直すこと自体が無駄とは限らない。必要のないシステムを本格的に開発せずに済むこともある。

しかし、本番へつなげるつもりで作ったものが、要求や設計の不足によって作り直しになるなら、その手戻りは開発全体の工数として数える必要がある。

僕がここで生産性として問題にしているのは、単にコードを書く速さや、MVPを完成させるまでの時間ではない。

同等の機能・品質・運用条件を満たす本番システムを成立させるために、どれだけの総工数がかかるか、ということである。

実装工程が速くなっても、その後の再設計、書き直し、再テスト、本番化への対応に工数がかかれば、総工数は減らない。

僕の経験では、ウォーターフォールからアジャイルへ移行しても、そうした理由で総工数を低減できないケースが少なくなかった。

「早く試せた」「早く学べた」という効果と、「本番まで含めた総工数を減らせた」という効果は、分けて評価する必要がある。

さらに、本稼働した時点で評価を終えるのではなく、その後の運用・維持・保守・変更にかかる工数も考えたい。

開発時の工数を減らした代わりに、本稼働後の負担が増えるのであれば、システムのライフサイクル全体として効率的になったとは言い切れない。

3．そこで、アジャイルでも最初から要求と設計をきちんと扱うようになった

その経験から、アジャイルであっても、本番を支える要求と設計は最初から検討しよう、となった。

具体的には、次のようなことである。

• データベースのスキーマ：データの構造、関係、整合性をどう設計するか。
• 期待レスポンスタイムと想定トランザクション量：通常時・ピーク時に、どれだけの処理を、どのくらいの時間で行う必要があるか。
• セキュリティ要件：何を守り、誰にどのようなアクセスを認めるか。
• システムアーキテクチャ：これらの要求を満たすために、どのような構成にするか。
• 運用要件・運用設計：誰が運用・保守し、監視、障害対応、復旧、更新をどう行うか。

これらを、動くものができた後に考えるのではなく、最初から要求と設計に含める。 詳細は検証しながら見直すとしても、検討そのものを後回しにしない。

4．最初に設計することと、最初にすべてを固定することは違う

最初から要求や設計を考えると言っても、すべてのシステムに最高水準の性能、可用性、セキュリティを求めるという意味ではない。

その業務に必要な品質と条件を明確にする、という意味である。必要以上に作り込めば、それも無駄になる。

また、最初にすべての要求や将来の負荷を完全に予測し、詳細まで確定して、その後は変更しないという意味でもない。

初期の要求と設計を置き、分からない部分は試作や検証で確かめ、結果に応じて更新する。

DBスキーマも、変更しないことを目指すのではなく、既存データを含めて安全に変更できるようにする。

最初に考えたうえで変更することと、最初に考えず、後から問題が出て作り直すことは違う。

変更に対応できるように設計することと、変更できるから設計しなくてよいと考えることは違う。

5．ノーコード・ローコードにも、同じ懸念を持っている

僕は、ノーコード・ローコードを使って、必要な設計や検証を行わないまま、業務フローの中核を担うシステムを作ることには否定的である。

個人や小さな組織が、自分たちの身近な業務を便利にする用途には価値がある。

ただし、個人や小さな組織向けであれば、何も考えなくてよいという意味ではない。小さな仕組みでも、重要な情報を扱ったり、停止すると業務が止まったりするなら、それに応じた検討が必要になる。

僕が懸念しているのは、簡単に作れることによって、非機能要件や全体設計、運用の検討まで不要になったかのように扱われることである。

さらに、個人や部門ごとの個別最適が積み重なることも問題だと考えている。

昨今のPower Appsやキントーンにも、この観点から同じ懸念を持っている。

簡単に画面を作れること、データを登録できること、身近な業務を自動化できることと、業務フローの中核を担えることは別である。

中核を担わせるのであれば、データ構造、期待レスポンスタイム、想定トランザクション量、セキュリティ、他システムとの連携、障害時の対応、運用・保守の責任まで考える必要がある。

僕は、特定の製品が一律に不適切だと言いたいわけではない。

必要な要求を満たせるのか、適切に設計されているのか、検証されているのか、運用・維持・保守の体制があるのかを確認せず、個人・部門向けの便利さを業務全体へ拡大することに懸念を持っている。

実装のハードルが下がっても、業務システムとして成立させるための設計責任がなくなるわけではない。

6．RPA、エクセルマクロ、ノーツDBにも、重なる構図がある

RPAにも同じ懸念がある。

個々の作業を自動化し、手作業を減らすことには価値がある。しかし、個々の作業が速くなったからといって、業務フロー全体が最適になるとは限らない。

削減できた作業時間だけでなく、新たに増える依存関係、保守、障害対応、運用の負担も考える必要がある。

この構図は、エクセルマクロの乱立問題や、かつてのノーツDB問題と重なると感じている。

個人や部門にとって便利な仕組みが増え、それらがつながり、いつの間にか業務を支える重要な仕組みになる。

そのとき、設計や管理、責任体制が、個人・小組織向けのままでよいのか、という問題である。

小さく始めることや、局所的に改善すること自体を否定しているのではない。全体設計が完成するまで、現場の改善を止めるべきだとも考えていない。

ただし、小さく始めたものが業務の中核になったなら、その重要性に合わせて、全体設計、品質、セキュリティ、運用、維持・保守の体制を見直す必要がある。

既存システムをすぐに改修できないため、暫定的な自動化として、将来の負担を承知で使うこともあるだろう。

そのように負担を理解して使うことと、将来の負担を考えずに拡大することは違う。

局所的な便利さの積み重ねが、そのまま全体最適や持続可能なシステムになるとは限らない。

7．そして、AI駆動開発の時代が来た

アジャイルで試作が速くなり、ノーコード・ローコードで実装のハードルが下がった。そして、AI駆動開発によって、コードを書くこと自体がさらに速く、簡単になった。

しかし、ウォーターフォールからアジャイルへ移行した際に経験した問題が、AI駆動開発でも再び顕在化するのではないかと考えている。

AIによって実装を高速化しても、非機能要件やセキュリティ要件が欠落し、アーキテクチャを検討せず、運用要件・運用設計を後回しにすれば、後から大きな手戻りが発生する可能性がある。

コードを早く生成できても、期待レスポンスタイムや想定トランザクション量を満たさないかもしれない。

データ構造や処理の仕組みが、業務に適していないかもしれない。動作しても、必要なセキュリティを満たしているとは限らない。

本稼働できたとしても、運用・維持・保守に多くの工数を要する可能性がある。

AIに要求整理や設計を手伝わせることはできるとしても、何を要求し、何を検討させ、何を確認するかが曖昧なままでは、その不足が自動的に解消されるとは考えていない。

AIで実装が速くなることと、開発から運用・保守まで含めて効率的になることは、同じではない。

8．vibe codingという言葉にも、問題意識がある

僕は、「vibe coding」という言葉にも違和感を持っている。

「こんな感じで」「いい感じに作って」という雰囲気や感覚で、動くものを作る。それだけで、良いシステムを作れるのか、という疑問である。

ここでいう良いシステムとは、画面がそれらしくできていることや、一度動作したことだけではない。

必要な機能と品質を満たし、想定する負荷の下で動き、必要なセキュリティを確保し、本番で運用でき、維持・保守・変更を続けられるシステムである。

自然言語でAIに指示すること自体が問題なのではない。自然言語でも、要求、制約、設計、検証基準を明確にすることはできる。

AIに設計や実装を手伝わせることと、要求や設計を考えずに任せることは違う。

僕が懸念しているのは、生成されたコードやシステムを十分に理解・検証せず、見た目や動作だけで完成と見なすことである。

個人の試作や、失敗の影響が小さい用途で自由に試すことには価値がある。しかし、その進め方を、そのまま本番の業務システムへ持ち込んでよいのかは別の問題である。

「動いた」「要求を満たした」「安全に使える」「本番で維持できる」は、それぞれ別の確認である。

9．開発プロセスを理解していなくても作れるようになることで、懸念がさらに広がる

AI駆動開発やvibe codingによって、ノーコード・ローコードと同じように、システム開発の専門知識や経験がない人でも、動くものを作れるようになる。

それ自体には価値がある。しかし、きちんとしたシステム開発のプロセスを理解しないまま、本番で使うシステムを作ることには懸念がある。

非機能要件、セキュリティ要件、DBスキーマ、期待レスポンスタイム、想定トランザクション量、アーキテクチャ、運用設計について、検討が不足するだけでなく、そもそも検討すべき事項に気づかない可能性がある。

そのまま本番利用へ進めば、大きな手戻りが発生したり、処理効率のよくないシステムになったり、必要なセキュリティを満たせなかったり、本稼働後の運用・維持・保守工数が高くなったりする可能性がある。

これは、「専門家でない人は作ってはいけない」という話ではない。

必要な知識や経験を、適切なプロセス、レビュー、検証、専門家の関与によって補う必要がある、という話である。

経験のあるエンジニアでも、必要な検討を省略すれば同じ問題は起こり得る。逆に、経験が十分でなくても、必要な確認を行える仕組みや支援があれば、リスクを抑えることはできると考えている。

「誰でも作れる」と「誰でも業務を支えるシステムを成立させられる」は同じではない。

10．だから、AIへの指示をステップバイステップにしたほうがよいのではないか

ここまで考えると、AI駆動開発においては、一周回って、ウォーターフォール的にきちんとステップを刻んだほうがよいのではないか、という考えになる。

これは、単に「工程を省略しないようにしよう」という注意ではない。

AIへの指示そのものを、従来のシステムエンジニアリング、ソフトウェアエンジニアリングで重視されてきた要求・設計・実装・検証のプロセスに沿って、段階化したほうが合理的ではないか、という提案である。

いきなり「このシステムを作って」と指示するのではなく、要求を整理させ、その要求を確認し、設計させ、その設計を確認してから、実装と検証へ進ませる。

僕が考える進め方は、次のようなものである。

第１段階：要求を整理する

何の業務を支えるのか、誰が使うのか、必要な機能は何かを明確にする。

そのうえで、期待レスポンスタイム、想定トランザクション量、可用性、セキュリティ要件、運用要件などを整理する。

何が分かっていて、何がまだ分からないのかも明確にする。分からない部分を、AIに勝手に補わせたまま実装へ進まない。

第２段階：要求を確認する

抜け、矛盾、曖昧な点を確認する。

何を満たせばよいのか、どう確認するのかを明確にする。必要以上の要求になっていないか、重要な要求が抜けていないかも確認する。

第３段階：設計する

確認した要求を基に、システムアーキテクチャ、DBスキーマ、インターフェース、処理の分担、セキュリティ設計、運用・復旧方法を検討する。

要求を満たすために、なぜその構造を選ぶのかを明確にする。

第４段階：設計を確認する

機能だけでなく、性能、処理量、データの整合性、セキュリティ、運用の条件を満たせる設計になっているかを確認する。

分からない部分やリスクの高い部分は、試作や検証で確かめる。必要であれば、要求や設計を見直す。

第５段階：範囲を区切って実装する

確認した要求と設計を入力として、AIに具体的な実装を指示する。

一度にすべてを曖昧に任せるのではなく、担当する範囲、守るべき条件、確認すべき結果を明確にする。

第６段階：要求と設計に照らして検証する

動作するかだけでなく、必要な機能、期待レスポンスタイム、想定トランザクション量、データの整合性、セキュリティ、運用・復旧の条件を満たすかを確認する。

問題があれば、実装の修正で済むのか、設計や要求へ戻る必要があるのかを判断する。

第７段階：本番化し、運用・維持・保守につなぐ

開発時に検討した運用設計が、実際に成立するかを確認する。

監視、障害対応、復旧、バックアップ、リリース、切り戻し、セキュリティ上の対応を含め、本稼働後に誰がどう支えるのかを明確にする。

本稼働後も、利用状況や問題を踏まえて、要求、設計、実装、運用を更新する。

各段階の成果物を確認し、それを次の段階への入力にする。

要求が曖昧なまま設計させたり、設計が曖昧なまま大量のコードを生成させたりしない。AIが作成した成果物についても、次へ進む前に、必要な条件を満たしているかを確認する。

11．「ウォーターフォール的」とは、変更を禁止するという意味ではない

僕がここで言う「ウォーターフォール的」とは、全仕様を最初に固定し、後戻りを禁止するという意味ではない。

要求、設計、実装、検証の依存関係を尊重し、段階ごとに成果物を確認して進むという意味である。

検証によって問題が分かれば、要求や設計に戻って更新する。短い反復の中で、この順序を繰り返すこともできる。

要求・設計・実装・検証を扱うことは、ウォーターフォールだけのものではない。アジャイルでも扱うべきことである。

それでも僕が「一周回って、ウォーターフォール的に」と言うのは、AIによって実装が簡単になった今こそ、いきなり生成するのではなく、前段の成果物を確認してから次へ進む価値を、改めて問い直したいからである。

小さな修正にも、大規模なシステム開発と同じ量の文書や承認を要求したいわけではない。仕事の規模、複雑さ、失敗した場合の影響に応じて、工程や確認の重さは調整する。

僕が王道と呼びたいのは、特定の手法名だけではない。

要求を理解し、それを満たす設計を行い、実装し、検証し、運用につなぐという工学的な考え方である。

その考え方をAIへの指示にも反映するために、ステップバイステップで進めることを、改めて評価したい。

12．そのほうが、総工数もトークン消費も抑えられるのではないか

曖昧な指示でコードを生成させ、後から「違う」「ここを直して」「構造から変えて」と修正を繰り返すより、先に要求と設計を整理したほうが、無駄な生成や書き直しを減らせるのではないか。

要求の再説明、コードの再生成、広範囲な修正、再テストを繰り返すことには、人の工数だけでなく、AIのトークン消費もかかる。

だから、段階ごとに指示し、成果物を確認して進めることによって、手戻りを減らし、総工数と総トークン消費を抑えられるのではないかと考えている。

ただし、要求整理、設計、レビューにも工数とトークンは必要である。そのため、ステップを刻めば必ず総トークンが減る、と断定しているわけではない。

比較すべきなのは、最初のコード生成に使った量だけではなく、同等の機能・品質・運用条件を満たすまでの修正・検証を含めた総量である。

さらに、本稼働後の運用・維持・保守・変更工数も含めて評価したい。

先に考えるためのコストをかけることで、後から直し続けるコストや、運用で支え続けるコストを減らせるのではないか。これが僕の仮説である。

13．研究や実務家の見解を、どう位置づけるか

この問題意識の出発点は僕自身の経験だが、要求や設計を早期に扱い、AIにも工程、役割、中間成果物、検証を組み込むという研究や実務上の考え方と接点がある。

アジャイルにおける非機能要件の研究

A Systematic Literature Review on Implementing Non-functional Requirements in Agile Software Development: Issues and Facilitating Practicesは、アジャイルにおける非機能要件の課題を整理し、プロジェクトの早期から非機能要件に注目することを推奨している。 [link.springer.com]

参照先URL： https://link.springer.com/content/pdf/10.1007/978-3-030-67084-9_6.pdf

これは、「アジャイルだから非機能要件が不要になるのではない」「早期から扱う必要がある」という僕の主張の後ろ盾になる。

INCOSEのアジャイルとアーキテクチャに関する考え方

INCOSE Agile Systems & Systems Engineering Working Groupは、持続的なアジリティを、アーキテクチャによって可能になり、同時に制約される能力と捉えている。 [incose.org]

参照先URL： https://www.incose.org/group/agile-systems-systems-engineering-working-group/

僕はこれを、変化に対応するためにも構造の設計が必要であり、「速く変えられるから設計しなくてよい」ということではない、と受け止めている。

NISTのセキュア開発の枠組み

NIST Secure Software Development Framework（SSDF）は、セキュリティ要求の定義と、それを満たす設計・検証を開発プロセスに組み込む枠組みである。 [nvlpubs.nist.gov]

参照先URL： https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf

セキュリティを実装後の追加対策として扱うのではなく、要求、設計、実装、検証に組み込むという考え方は、僕の問題意識と整合する。

AIに標準作業手順と中間成果物を与える研究

MetaGPT: Meta Programming for A Multi-Agent Collaborative Frameworkは、標準作業手順をAIへのプロンプト列に組み込み、役割を分け、中間結果を検証する方式を扱っている。 [openreview.net]

参照先URL： https://openreview.net/forum?id=VtmBAGCN7o

これは、AIにいきなり実装だけを任せるのではなく、要求、設計、実装、検証の役割と成果物を明確にするという提案に近い。

ただし、この研究の比較では、品質や人工修正回数が改善する一方、総トークンが比較対象より増えた結果もある。 [proceedings.iclr.cc]

したがって、工程を組み込むことの有用性と、総トークンが必ず減ることは、分けて考える必要がある。

責任あるAI支援開発とvibe codingの区別

Simon Willisonは、Not all AI-assisted programming is vibe coding (but vibe coding rocks)で、コードを読まずに受け入れるvibe codingと、責任あるAI支援開発を区別している。

また、性能、セキュリティ、保守性、コスト効率を考えることを、ソフトウェア開発者の仕事として述べている。 [simonwillison.net]

参照先URL： https://simonwillison.net/2025/Mar/19/vibe-coding/?s=09

これは、AIを使うことを否定するのではなく、生成されたものを理解・検証し、本番で支えられる状態にする責任は残る、という僕の主張とつながる。

本番コードでは、理解と設計を先に行うという実践

牛尾 剛さんは、プロダクションのコードで Vibe Coding を使う方法で、既存コードを理解し、AIと設計を相談してから実装させる進め方を紹介している。

曖昧な指示のまま生成を始めるのではなく、先に方向性を確認するという実践である。 [note.com]

参照先URL： https://note.com/simplearchitect/n/nf9bf709c660f

これは、要求や設計を確認してから実装させることによって、無駄な生成や修正を避けたいという僕の考え方に近い。

ただし、実務家の経験に基づく報告であり、あらゆる開発で同じ効果が得られることを証明した比較実験ではない。

仕様先行の有用性と、過剰な工程への注意

Birgitta Böckelerは、Understanding Spec-Driven-Development: Kiro, spec-kit, and Tesslで、AIへ渡す仕様を先に作る考え方の有用性を認めながら、小さな修正に重すぎる工程を要求することや、仕様があってもAIがそれを守るとは限らないことを指摘している。 [martinfowler.com]

参照先URL： https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

この記事はMartin Fowlerのサイトに掲載されているが、執筆者はBirgitta Böckelerである。 [martinfowler.com]

この指摘も重要だと考えている。

僕が提案したいのは、文書や工程を無条件に増やすことではない。仕事の規模やリスクに応じて、必要な要求、設計、確認を行うことである。

また、仕様を作っただけで安心するのではなく、実装結果がそれを満たしているかを検証する必要がある。

研究や意見から、どこまで言えるか

僕は、こうした知見を、自分の問題提起を考えるための後ろ盾として使いたい。

ただし、これらをもって、「ウォーターフォールが常に最も効率的である」「段階化すれば必ず総トークンが減る」と証明されたとは考えていない。

工程や中間成果物、検証を明確にすることの有用性と、特定の開発手法が常に優れていることは別である。

まだ測定されていない効果まで、実証済みの事実として言いたいわけではない。

要求・設計・実装・検証を段階化することには、研究や実務との接点がある。その進め方が本番開発全体の総工数、総トークン、運用保守負担にどう影響するかは、さらに検証したい。

14．僕が提示したい結論と問い

僕は、アジャイルやAIによって、早く試し、早く学び、早く作れるようになることを否定していない。

しかし、実装を高速化することだけでは、開発全体の生産性が上がるとは限らない。

ウォーターフォールからアジャイルへ移行した際に、非機能要件の欠落、初期のアーキテクチャ設計の不足、運用要件・運用設計の後回しによって手戻りが発生し、総工数を減らせなかった。

その問題が、AI駆動開発で再び顕在化するのではないか。

さらに、開発プロセスを理解していなくても動くものを作れるようになることで、ノーコード・ローコード・RPAで感じてきた懸念が、より広く現れるのではないか。

だからこそ、本番システムのAI駆動開発では、一周回って、従来のシステムエンジニアリング、ソフトウェアエンジニアリングの工学的なプロセスに沿い、ウォーターフォール的にステップを刻んだほうがよいのではないか。

非機能要件、セキュリティ要件、期待レスポンスタイム、想定トランザクション量、運用要件を最初から整理する。

それを基に、アーキテクチャ、DBスキーマ、セキュリティ設計、運用設計を行う。

そして、AIへの指示を要求、設計、実装、検証に段階化し、各段階の成果物を確認して進める。

そのほうが、同等の機能・品質・運用条件を満たすための総工数や、本稼働後の運用・維持・保守負担を抑えられるのではないか。総トークン消費への効果も含めて、検証する価値があるのではないか。

これが僕の問題提起である。

コードを書くことが速く、簡単になった今こそ、何を要求し、どう設計し、どう検証し、どう運用するかを理解することが、より重要になるのではないか。

これは、完成した正解として提示する結論ではない。

AIを使うべきか、使わないべきかという議論でもない。現場でシステムを作り、動かし、支える人たちに、自分たちの仕事として考えてもらいたい問いである。