生成AI時代の設計学習とウォーターフォールの再評価

こんにちは、ATOM事業本部のプロダクト開発グループの松尾です。最近、設計業務が増え、「要件・機能仕様を相手に分かりやすく伝えるにはどうしたらいいんだろう？」、「筋の良い技術的な提案って何だろう？」と悩むことが増えてきました。

生成AIの登場で、「コードを書く」部分はAIに任せる部分が確実に増えてきました。その一方で、設計をどこまで自分で押さえておくべきか、あるいはどうやって体系的に学べばいいのかについては、まだ模索している状態だと感じています。

そんな中で、何か1つの指針になりそうな考え方がないか探していたところ、ウォーターフォールモデルを扱った2つの論文・記事に出会いました。

ウォーターフォール型課題での学生の生成AIツール利用状況

これは、ドイツの大学で2024年秋冬に実施された研究です。 38名の学生（参加率78%）を対象に、ウォーターフォール型のプログラミング・プロジェクト（Java + jMonkeyEngine でのゲーム開発）において、生成AIツール（ChatGPT、GitHub Copilotなど）の利用状況を追跡しています。

この研究では、ウォーターフォールを次の4フェーズに分けています。

Preparation
Analysis
Design
Coding & Testing

日本のウォーターフォールの一般的な工程に当てはめると、

技術調査：Preparation
要件定義：Analysis
基本設計：Design
実装・テスト：Coding & Testing

のようなイメージになります。

各フェーズで、生成AIの利用状況と「どれだけ課題達成に役立ったか」を集計した結果がこちらです。

Preparation：58%
Analysis：34%
Design：26%（最低）
Coding & Testing：87%

特にAIの効果が最も低かったのは Design フェーズで、これは「基本設計」に相当する部分です。

DesignフェーズでAIがうまく機能しなかった理由として、論文では次のような点が挙げられていました。

ダイアグラム生成：「詳細度が不十分」「内容が不正確」
アーキテクチャ提案：「トレードオフ分析が浅い」
プロジェクトコンテキスト欠落による不正確性

こうした結果から、複数の選択肢を比較してトレードオフを整理し、それを図として矛盾なく落とし込んでいくような設計まわりの仕事は、現状の生成AIがあまり得意ではないことが分かります。

Waterfall 2.0

www.linkedin.com

こちらは、生成AI（LLM）の登場を前提に「ウォーターフォールをアップデートしよう」と提案している記事です。アジャイル的な短期サイクルだけでなく、フェーズごとに進めるような構造化された進め方も改めて再評価しよう、という立場を取っています。

著者は、従来のウォーターフォールには次のような問題があったとしています。

要件定義後の変更に弱い
各フェーズのドキュメント作成に時間がかかる
ハンドオフ前提のため、大人数のチームが必要

そこで提案されている「Waterfall 2.0」では、生成AIが各フェーズごとに成果物づくりをサポートすることで、ウォーターフォールの持つ工程と役割がはっきりした進め方と、AIの自動化能力を組み合わせようとしています。

具体的には、各フェーズで次のような使い方が想定されています。

Requirements：会議メモからのユーザーストーリー自動生成
Design：ADR（アーキテクチャ決定記録）のドラフト生成、人間が判断と最終決定
Implementation：設計書をコンテキストにしたコード生成
Test：テスト方針をもとにしたテストコード自動生成

ここでポイントになるのが、各フェーズで人間が作成した成果物（基本設計書・テスト戦略・ADRなど）が、そのままAIへのコンテキスト＝プロンプトとして再利用されるという設計です。設計フェーズで「何を作るか」「なぜそう設計するか」を丁寧に詰めておくほど、その後のフェーズでAIが出してくるアウトプットの質も安定していきます。

Designフェーズの重要性

ドイツの研究では、「DesignフェーズではAIの効果が最も低い」という結果を示しました。一方、Waterfall 2.0 の記事では、「だからこそDesignフェーズを人間がしっかり詰めることで、その後のAI効果が最大化される」と述べています。

この2つを合わせて見ると、

Designフェーズは、生成AIが最も苦手
しかし同時に、ここで作った成果物が下流フェーズのAIの性能を左右する

という、生成AI時代の開発フローの中でもかなり特別な位置を占めるフェーズになっていると感じます。生成AI時代において、「設計を学ぶこと」＝「AIに任せられない領域を強くする」＋「AIを最大限活かす土台を作る」 という二重の意味を持ってきているのだと思います。

なぜ学習アプローチとしてウォーターフォールなのか

ここまで見てきたように、Design フェーズ（基本設計）は、人間の設計の質がその後の生成AIのパフォーマンスに強く影響するフェーズとなっています。このDesignフェーズをどう学ぶかを考えたとき、その「型」としてウォーターフォールという枠組みを使うのが相性が良いと感じています。

ウォーターフォールはもともと、

開発プロセスをフェーズに分けて構造化する
各フェーズで作る成果物（要件定義書・基本設計書・テスト設計など）を構造化しておく

という思想で作られています。プロセスと成果物の両方に「型」があるおかげで、

基本設計の前に何を決めておくべきか（要件・制約）
基本設計のあとに何が続くのか（詳細設計・実装・テスト）

といった前後関係や役割分担を、全体像として把握しやすいというメリットがあります。

さらに、設計書やテスト方針が一定の構造で書かれていると、

人間同士でも、「どのタイミングで何を決めたのか」を共有しやすい
生成AIにも「この設計書に沿ってコードを書いて」「このテスト方針に沿ってテストを出して」といった形で、まとまったコンテキストを渡しやすい

という利点が生まれます。

学習の観点で見ると、

「プロセスも成果物も構造化されている」
＝「基本設計を含め、どのフェーズで何を学べばいいかを分解しやすい」

ということでもあります。
どの順番で理解を積み上げれば、基本設計の判断に必要な前提知識が揃うのか、逆に基本設計で決めたことが後工程でどう効いてくるのか、といった関係性をたどりやすいのがウォーターフォールの強みです。

その意味で、ウォーターフォールは「古い開発モデル」というより、基本設計を含む設計・判断を体系的に学ぶためのフレームワークとして、生成AI時代に相性が良いモデルなのではないかと感じています。

まとめ

現場の開発プロセスとしては、アジャイル的な進め方がフィットする場面が多いはずです。その一方で、「どう学ぶか」を考えたときには、ウォーターフォールのようにフェーズがはっきり分かれているモデルの方が、むしろ役に立つ場面が増えていくのではないかと思っています。

どのフェーズでAIがよく効くのか
どのフェーズは人間の判断が欠かせないのか
今の自分は、どのフェーズのスキルを重点的に鍛えるべきなのか

こういったことを整理するための学習のロードマップとして、ウォーターフォールは扱いやすい型だと感じています。

実務ではアジャイル寄り、でも学習の設計にはウォーターフォール寄りの考え方も取り入れる。そんな緩い使い分けをしてみるのも良さそうです。

もし「どこから設計を学べばいいか分からない」という状態であれば、まずはウォーターフォールを1回きちんと辿ってみるところから始めてみるのも、悪くない選択肢かなと思います。

最後までお読みいただきありがとうございました。