🤖

AIコーディングエージェントを活用したシン・ウォーターフォール開発

に公開
AI
開発手法
ソフトウェア工学
ウォーターフォール
idea

はじめに

この記事の出発点は、拙稿「ClineとAIエージェント時代のプログラミングに関する所感[1]」の末尾にある「今後の課題と展望」で触れた『AIエージェント時代のシステム開発ライフサイクルが提唱されるかもしれない』という仮説にあります。最近、仕様駆動開発（Spec Kit や Kiro など）が台頭してきた流れを見て、「これは半世紀前にウィンストン・W・ロイス（Winston W. Royce）博士が指摘した望ましい開発プロセスを、AIが現実の運用レベルへと引き上げつつあるのではないか」と思い、本稿で整理するに至りました。

Managing the development of large software systems

1970年、ロイス博士が発表した「Managing the development of large software systems」という論文は、ソフトウェア開発プロセスに大きな影響を与えました。


大規模開発に必要な工程。 Managing the development of large software systems by Dr. Winston W. Royceより

この論文は「ウォーターフォール開発」の起源とされていますが、実際には上図のような単純な直線的ウォーターフォールを推奨したものではありませんでした。むしろロイス博士は、テスト段階で初めて制約や問題が明らかになることのリスクを強調し、その結果として手戻りが発生してコストやスケジュールが大幅に増大する危険性を警告していました。ロイス博士は反復的な開発の重要性を認識しており、単純な直線的なモデルの実装はリスクが高く、失敗する可能性があると述べています[2]。

そこでロイス博士は上図に加えて、以下の5つの追加ステップを提案しました。

  • STEP 1. プログラム設計を最優先する（PROGRAM DESIGN COMES FIRST）: 分析前にプログラム設計を行い、リソース制約や構造的な誤りを早期に検出する。
  • STEP 2. 設計内容の文書化（DOCUMENT THE DESIGN）: 設計を文書化と捉え、仕様や判断根拠を残して後工程の混乱を防ぐ。
  • STEP 3. 二度行う（DO IT TWICE）: パイロット版を作り、主要なリスクを事前に検証してから本番開発に臨む。
  • STEP 4. テストの計画・管理・監視（PLAN, CONTROL AND MONITOR TESTING）: 専門のテスト要員による計画的な検証を行い、単純な誤りを早期に排除する。
  • STEP 5. 顧客を巻き込む（INVOLVE THE CUSTOMER）: 要件・設計・受入の節目ごとに顧客が正式に判断し、認識のズレを防ぐ。


ロイス博士が最終的に提案した5つのステップを総括したまとめ。 Managing the development of large software systems by Dr. Winston W. Royceより

これらのステップを省略すれば大規模開発はほぼ失敗するとロイス博士は警告しました。

AIコーディングエージェントが実現する「シン・ウォーターフォール」

ロイス博士は前述のように単純な直線的開発では大規模システムが失敗に終わると警告して5つの追加ステップを提案しましたが、（誤って広まってしまったがために）これらの追加ステップはなかったことにされてしまっているように思えます。

現代では論文が発表された1970年代とは異なり、ソフトウェア開発に対するコンピュータ資源が安価となっている、かつ、AIコーディングエージェント（以下、単にAI）の台頭により設計の支援やドキュメント作成、プロトタイプの素早い作成、テストコードの生成、顧客向けデモの実装を容易になりました。半世紀前に提案された「リスクを制御しながらソフトウェアを開発する方法」が、AIの力によって実現可能になりつつあると思います。

STEP 1. プログラム設計を最優先する（PROGRAM DESIGN COMES FIRST）

AIとの対話を通じて、設計についての相談が気軽に24時間いつでもできるようになりました。

「この設計でスケーラビリティは大丈夫でしょうか？」
「より保守性の高いアーキテクチャの提案はありますか？」

こうした質問に即座に回答が得られ、複数の設計案を比較検討することができます。また、その場でER図やシーケンス図などを生成してもらう、といった使い方も可能です。

STEP 2. 設計内容の文書化（DOCUMENT THE DESIGN）

AIは適切なコメントやドキュメントを生成してくれます。設計の判断根拠や変更履歴が自然に蓄積されるため、後からの振り返りや引き継ぎが容易になります。後回しにされて忘れられがちなドキュメントがプログラムとほぼ同時期に作成されます。

普段私が使用しているClaude CodeではPlanモードというモードがあり、これを利用して設計方針を納得いくまで議論し、かつ、その結果をドキュメントに残すことも可能です。これにより設計が記録されて後から参照しやすくなります（Planモードのまま「コードを見せて」と依頼すれば実際にファイルを編集する前に実装方針が正しいかをレビューすることもできます）。

STEP 3. 二度行う（DO IT TWICE）

ロイス博士の「二度行う」が、AIによって劇的に実現しやすくなりました。プロトタイプの作成が高速化し、複数のアプローチを試すことが簡単に実現できます。

  1. Vibe Coding段階では、AIが即時的なコードを生成します。
  2. ドキュメント生成段階では、AIがドキュメントを自動で生成します。
  3. 仕様駆動開発段階では、そのドキュメントを基にAIが再構築を支援します。

これにより、探索的実践から仕様駆動への移行が滑らかになり、開発の発散を防ぎつつ整理されたコードベースを維持できます。

STEP 4. テストの計画・管理・監視（PLAN, CONTROL AND MONITOR TESTING）

AIはテスト駆動開発（TDD）を強力にサポートします。実装と同時にテストコードを生成し、開発の初期段階から品質保証が可能であり、リファクタリング時の安全性を確保してくれます。ロイス博士が重視した「早期での問題発見」が、自動テストによって実現されています。

STEP 5. 顧客を巻き込む（INVOLVE THE CUSTOMER）

AIが生成するコードは、プロトタイプ段階でも実際に動作する状態で提供されることが多く、早い段階でステークホルダーにデモを見せることができます。これにより「顧客が本当に必要だったもの」との乖離を早期に発見し、修正することが可能です。サーバーサイドとの連携を伴わないプロトタイプであればすぐにできるため、画面遷移も含めてデモを行うことが可能であり、要件の齟齬を早期に発見できます。

おわりに

「シン・ウォーターフォール」とは、アジャイルの柔軟性を内包しつつも、ロイス博士の提唱した工程管理と設計重視の思想を再評価する開発様式です。つまり、ロイス博士が提唱した「プロトタイプによる反復開発」や「顧客関与」といった要素を含む、アジャイル開発的な反復や顧客関与を含む、ロイス博士の論文本来の開発プロセスを指しています。一般的に同論文が「ウォーターフォール開発の起源」と誤解されがちなため、誤解を正す意図を込めてあえてウォーターフォールという名称を使用しています。

AIはあくまで強力な支援ツールであり、ソフトウェアエンジニアの思考や判断を代替するものではないと考えています。問題発見能力、言語化を含むコミュニケーション能力、批判的思考といった基礎を土台に、要件の理解->設計の判断->品質保証->顧客との合意形成という基本プロセスを反復的に行う必要は依然としてあります。また、AIが生成するコードを常にレビューし続ける必要があるため、コードを読んで理解する能力と集中力がこれまで以上に必要です。

脚注

  1. https://zenn.dev/trysmr/articles/vscode_cline#今後の課題と展望 ↩︎

  2. Winston W. Royce, "Managing the Development of Large Software Systems" (1970). ACM Digital Library, Wikipedia: ウォーターフォール・モデル（歴史） ↩︎

Discussion