アジャイルとウォーターフォールの違い｜使い分けの判断基準と進め方

アジャイル開発とウォーターフォール開発の違いは、「決める順番」にあります。 ウォーターフォールは要件をすべて決めてから作り、アジャイルは短い周期で作りながら決めます。どちらが優れているかではなく、案件の要件確定度と変更の起きやすさで選ぶものです。この記事では比較表と判断基準、発注側が陥りやすい失敗を解説します。

2つの開発手法の違い

ウォーターフォールでは工程を後戻りしない前提で進むため、要件定義の質がプロジェクト全体の成否を決めます。各工程の成果物をレビューして次へ進むため、WBSによる計画と進捗管理が機能しやすいのも特徴です。

どちらを選ぶかの判断基準

1. 要件が固まっているか — 法対応や既存システムの置き換えのように「作るものが決まっている」案件はウォーターフォールが素直です。「何を作れば売れるか」から検証する案件はアジャイルが向きます
2. リリース後に変更が起きるか — 一度作って数年運用する業務システムか、市場の反応を見て毎月変えるサービスかで選択が変わります
3. 発注側が定期的に関与できるか — アジャイルは発注側が優先順位を決め続けることが前提です。担当者が月1回しか時間を取れない体制では機能しません
4. 検収と支払いの形をどう組むか — 総額固定の請負契約はウォーターフォールと相性がよく、アジャイルは準委任契約で期間ごとに検収する形が一般的です

スクラムの基本構造

アジャイルは2001年の「アジャイルソフトウェア開発宣言」に示された価値観の総称で、実践するためのフレームワークがいくつかあります。最も広く使われているのがスクラムです。

スクラムガイド(2020年版)では、次の要素が定義されています。

スプリント(反復の単位)は1か月以内の固定長で、デイリースクラムは15分と定められています。発注側が押さえるべきなのは、プロダクトオーナーの役割が発注側にあることです。何を優先して作るかを決める人が不在だと、スクラムは形だけになります。

ウォーターフォールでも計画は更新する

ウォーターフォールは「計画どおりに進める手法」と誤解されがちですが、計画を更新しないという意味ではありません。工程が進めば実績が出るので、その都度スケジュールに反映します。

アジャイルの場合も計画がないわけではなく、全体のロードマップは持ったうえで、直近の周期だけ詳細化します。「詳細な計画を立てる範囲を、どこまで先にするか」が両者の実務上の違いです。

よくある失敗

• 手法だけ導入して意思決定の体制を変えない — 毎週レビューを設定しても、決裁者が出てこなければ判断待ちが積み上がるだけです。手法より先に「誰が優先順位を決めるか」を決めます
• ウォーターフォールで要件定義を急ぐ — 後工程の手戻りコストが最も大きい手法なので、要件定義を短縮すると総コストは増えます。急ぐべきは開発工程ではなく合意形成です
• アジャイルを「仕様書を作らない」と解釈する — 動くソフトウェアを重視するのは、ドキュメントを禁止する意味ではありません。運用に必要な資料は別途必要です
• スプリントの長さを頻繁に変える — スプリントは固定長だからこそ、ベロシティ(1周期で消化できる量)が測れます。長さを変えると比較できなくなります

どちらの手法でも、ベンダーに発注する前段では要件と条件の整理が必要です。提案依頼の進め方はRFP(提案依頼書)の書き方、社内承認の通し方は稟議書の書き方を参照してください。工程表を実際に引いてみるなら、WBS作成ツールのテンプレートから始めるのが早道です。