自己紹介
株式会社Good Labでエンジニアをしている コータロー です。
日々、Java・SQL・Gitなどの技術情報や、新人エンジニア向けの学習ノウハウ、
AI活用についての情報を発信しています。
Good Labについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト
はじめに：受託案件で「仕様変更が来た時の恐怖」
受託・SESで働いていると、誰しも一度は経験するシーンがあります。
- 結合テスト直前に「やっぱりこの画面、ボタンの位置変えたい」
- リリース前日に「項目を1つ追加してほしい」
- 顧客レビューで「思っていたのと違う」
ウォーターフォール開発の現場で長く働いてきた身としては、こうした「ちゃぶ台返し」を防ぐために、要件定義書・基本設計書・詳細設計書を綿密に積み上げてきました。
ところが、Claude Code を使うようになってから、「もう設計を固めきってから作る必要、そんなにないかも？」 と感じる場面が増えてきました。
この記事では、ウォーターフォール開発と Claude Code を使った反復開発を比較しながら、「どう使い分けると現場で楽になるのか」を、自分の受託案件・個人開発の経験ベースで整理してみます。
補足：本記事はウォーターフォールを否定するものではありません。むしろ、ウォーターフォールの強みを認めた上で、Claude Code を加えると「反復開発のコストが大きく下がる」という観点を共有したい、というスタンスで書いています。
1. ウォーターフォール開発の特徴と弱点
1-1. ウォーターフォールの基本フロー
ウォーターフォールは、上流から下流に向かって工程が滝のように流れる開発手法です。
要件定義 → 基本設計 → 詳細設計 → 実装 → 単体テスト → 結合テスト → システムテスト → リリース
各工程の成果物（要件定義書、基本設計書、詳細設計書、テスト仕様書など）が次工程のインプットになります。
1-2. ウォーターフォールの強み
正当に評価しておきます。ウォーターフォールには明確な強みがあります。
| 強み | 具体的な恩恵 |
|---|---|
| 計画性 | スケジュールと工数の見通しが立てやすい |
| 役割分担 | PM・SE・PG が明確に分かれ、大規模案件でも回しやすい |
| 品質担保 | レビューと工程ゲートで欠陥を上流で潰しやすい |
| 契約適合性 | 一括請負契約と相性が良い（範囲が固まっている） |
| ドキュメント | 後年の保守担当者にとって設計書が"地図"になる |
特に 公共系・金融系・医療系など「仕様を固めきれる領域」 や、チームが大規模で分業が必須の現場 では、依然として強力な選択肢です。
1-3. 弱点：仕様変更に弱い
一方で、誰もが知っているとおりの弱点があります。
- 上流工程の手戻りコストが指数的に増える
- 顧客が「動くものを見るまでイメージが湧かない」場合、要件定義の精度が上がらない
- レビューが書類ベースになり、UI/UX の良し悪しが判断しづらい
- 結合テスト以降に発覚した仕様の食い違いは、設計書の更新も含めて重い
特に 「顧客自身が何を欲しいか言語化できない案件」 で、ウォーターフォールは苦しくなります。
受託の現場で「動くもの見せたら一発で要望が固まったのに、ドキュメントだけだと延々と揉めた」という経験、ある方は多いのではないでしょうか。
2. Claude Code 反復開発とは何か
2-1. 「小さく作って → 動かして → 修正」のループ
Claude Code を使った反復開発は、ざっくり言えば以下のループを高速に回す開発スタイルです。
仮の要件 → AIに実装させる → 動かす → 触る → 違和感を伝える → AIが修正 → 動かす → ...
イテレーション（反復）1回あたりの所要時間は、私の感覚では 数分〜30分程度。
「設計書を書いてレビューを通して、それから実装に入る」というウォーターフォール的な進め方と比べると、フィードバックループが圧倒的に短くなります。
2-2. 従来のアジャイルとの違い
「それってアジャイル開発でしょ？」と思った方、ある意味その通りです。
ただし、これまでのアジャイル開発と Claude Code 反復開発では、実装コストの桁が違う のがポイントです。
| 観点 | 従来アジャイル | Claude Code 反復開発 |
|---|---|---|
| 1イテレーションの実装時間 | 数日〜2週間 | 数分〜数時間 |
| プロトタイプ作成コスト | 高い（人手） | ほぼゼロ |
| 「とりあえず動かす」の心理的ハードル | 中〜高 | 低 |
| ドキュメントとコードの同期 | 人手で頑張る | AIに同時更新させやすい |
「プロトタイプを作るコストが下がった」 ことが、反復開発を現実的な選択肢に変えています。
3. 2つのアプローチを徹底比較
整理のために、ウォーターフォールと Claude Code 反復開発を表で並べてみます。
| 比較軸 | ウォーターフォール | Claude Code 反復開発 |
|---|---|---|
| 仕様の固め方 | 上流で固めきる | 動かしながら育てる |
| 設計書 | 詳細まで書き切る | 必要最小限＋コードが正 |
| 仕様変更への耐性 | 弱い（手戻り大） | 強い（再生成が容易） |
| プロトタイプ | 別工程として確保が必要 | 開発と一体化 |
| 品質担保 | 工程ゲート・レビュー | テスト・型・Lint・AIレビュー |
| ドキュメント整備 | 強い（成果物として明示） | 弱め（意識的に残す必要あり） |
| 大規模案件 | 向く | 単独では不向き、ハイブリッド推奨 |
| 契約形態 | 一括請負と相性◎ | 準委任・ラボ型と相性◎ |
| 学習コスト | 低（既存の慣習） | 中（AIの使い方に慣れが必要） |
図解：フィードバックループの長さ
ウォーターフォール：
[要件定義]──[設計]──[実装]──[テスト]──[顧客レビュー]
└──────────── 数週間〜数ヶ月 ───────────┘
Claude Code 反復開発：
[仮要件]→[実装]→[動作確認]→[修正]→[動作確認]→...
└─ 数分〜数十分 ─┘
このループ長の差が、そのまま 「仕様変更コストの差」 になります。
4. Claude Code で反復開発が現実的になった理由
「反復開発の方が良いのは前から知ってたよ」という方も多いはず。
ではなぜ今、Claude Code がそれを現実的にしたのか。理由は3つあります。
4-1. 実装コストの劇的な低下
これまで「動くプロトタイプを作る」には、最低でも数時間〜数日の実装時間が必要でした。
Claude Code であれば、たとえば SwiftUI の画面1枚なら 数分でプロトタイプが動く ことも珍しくありません。
「とりあえず動かして見せる」が、本当に「とりあえず」のコストでできるようになったのが大きな変化です。
4-2. 修正の再生成コストもほぼゼロ
人手の場合、「やっぱり違う」と言われた時の心理コストは大きいです。
AI なら 「全部捨ててやり直す」が現実的な選択肢になる ため、サンクコストに引きずられにくくなります。
4-3. ドキュメントとコードの同期がしやすい
Claude Code は、コード変更に合わせて README・設計書・テストコードを 同時に更新する指示 が可能です。
従来「コード変えたら設計書も直す」が形骸化しがちでしたが、AI に任せると整合性を保ちやすくなります。
補足：もちろん「AIにドキュメントを任せれば全部OK」ではありません。最終的なレビュー責任は人にあります。あくまで"叩き台を高速に作る"のが AI の役割です。
5. 実践例：個人開発アプリでのイテレーション
5-1. 学習タイマーアプリ（StudyStopwatch）の例
私が個人開発している学習タイマーアプリでは、以下のような流れで開発を進めました。
| イテレーション | 仮要件 | 所要時間（実装＋確認） | 結果 |
|---|---|---|---|
| 1 | とりあえずタイマーが動く画面 | 約20分 | 「ボタンが大きすぎ」と判明 |
| 2 | レイアウト調整＋一時停止追加 | 約15分 | 「履歴も見たい」と判明 |
| 3 | SwiftData で記録機能追加 | 約40分 | 「グラフが欲しい」と判明 |
| 4 | 週次グラフ追加 | 約30分 | だいぶ完成形に近づく |
ウォーターフォール的に「最初から全部設計してから実装」していたら、おそらく 要件定義だけで数日、しかも実装後に「ボタン大きすぎ」「グラフ欲しい」と気づいて手戻り、という結末になっていたはずです。
5-2. ランキング投票アプリ（RankingMake）の例
ランキング投票アプリでは、画面構成が複雑だったため、Claude Code に 「画面遷移のたたき台を3パターン作って」 と依頼しました。
- パターンA：投票→結果即表示
- パターンB：投票→他人の結果を見て→自分の結果を見る
- パターンC：投票→ランキングだけ見る
3パターンを 数十分で動く形 にして、自分で触り比べた結果、パターンBに即決。
ウォーターフォールでこれをやろうとすると、画面遷移書を3パターン書いて、レビューして、それから実装 で1〜2週間は溶けていたでしょう。
5-3. 受託案件での例（一般化）
実際の受託案件では、機密の関係で詳細は書けませんが、たとえば以下のような場面で効きました。
- 管理画面の細かい挙動：顧客と画面共有しながら、その場で Claude Code に修正させて即動作確認
- エラーハンドリングの方針：「全部例外で投げる版」と「Result型で返す版」を両方作って比較
- バッチ処理のリトライ戦略：指数バックオフ／固定間隔／キュー方式を素早く比較検証
「机上で議論する時間 < 動くものを見て決める時間」になった瞬間、生産性は別物になります。
6. 反復開発で気をつけたい落とし穴
良いことばかり書いてきましたが、Claude Code 反復開発にも注意点があります。
6-1. ドキュメントが置き去りになりやすい
コードが正になりがちなので、後年の保守担当者のために 意識的に README・設計メモを残す 必要があります。
Claude Code に「変更内容を README にも反映して」と毎回指示するルールを CLAUDE.md に書いておくと、形骸化しにくいです。
6-2. 「とりあえず動く」で満足してしまう
イテレーションが速いと、テストやセキュリティ観点が後回し になりがちです。
個人開発ならまだしも、受託案件では以下を チェックリスト化 しておくのが安全です。
- 入力バリデーション
- 認可（権限チェック）
- ログ・監査要件
- パフォーマンス（N+1、インデックス）
- テストコードの担保
6-3. 大規模案件には単独では不向き
10人月を超えるような案件では、ウォーターフォール的な工程管理が依然として有効です。
Claude Code 反復開発は 「工程内のミクロな進め方」 として組み込むのが現実的です。
7. まとめ：どう使い分けるか
最後に、私なりの使い分け指針をまとめます。
| 状況 | おすすめのアプローチ |
|---|---|
| 顧客の要件が固まりきっていない | Claude Code 反復開発でプロトタイプ先行 |
| UI/UX が成果に直結する | Claude Code 反復開発 |
| 公共系・金融系・医療系など仕様が固い領域 | ウォーターフォール基調＋AI補助 |
| 大規模・分業が必要 | ウォーターフォール基調＋工程内でAI活用 |
| 個人開発・スタートアップ | Claude Code 反復開発 |
| 既存システムの保守改修 | ハイブリッド（設計書はウォーターフォール、実装は反復） |
ポイントは、「ウォーターフォール vs アジャイル」の二項対立ではなく、「Claude Code が反復開発のコストを下げた」 ということ。
これまで「アジャイルが良いのは知ってるけど、現場ではウォーターフォールしか回せなかった」という方こそ、Claude Code を導入することで 反復開発の選択肢が手に入る はずです。
受託案件で仕様変更が来た時、「うわ、また手戻り…」と頭を抱える前に、Claude Code に「この変更、たたき台で動くものを作って」 と投げてみる。
それだけで、現場の心理的負荷はかなり変わります。
私自身、ウォーターフォールに10年近く向き合ってきた身ですが、Claude Code を使い始めてから、「動かす」という選択肢のコストが下がった ことの恩恵を日々実感しています。
ぜひ皆さんの現場でも試してみてください。
参考
- Claude Code 公式ドキュメント
- Anthropic 公式サイト
- アジャイルソフトウェア開発宣言（公式）
- PMBOK Guide（Project Management Institute）
- Manifesto for Agile Software Development
@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！