--- title: "ウォーターフォールとアジャイル・スクラムの違い｜比較表と使い分け・契約形態の選び方" url: "https://www.issoh.co.jp/column/details/1348/" published: 2023-09-13 updated: 2026-10-12 categories: ["受託開発・システム発注"] publisher: "株式会社一創" --- # ウォーターフォールとアジャイル・スクラムの違い｜比較表と使い分け・契約形態の選び方 ウォーターフォールとアジャイルの違いは、「要件をいつ確定させるか」にあります。ウォーターフォールは着手前に要件を固めて工程を順に進め、アジャイルは短い周期で動くソフトウェアを作りながら要件を確かめます。よく並べて語られるスクラムは、アジャイルを実践するための枠組みの一つで、ウォーターフォールと同列の選択肢ではありません。この記事では、3つの関係を比較表で整理したうえで、IPAのデータに見る日本での採用状況、請負・準委任という契約形態との組み合わせ、どちらを選ぶかの判断基準、現場で起きがちな「ウォータースクラムフォール」の抜け出し方までを、発注する側の視点で解説します。 ## まとめ：ウォーターフォール・アジャイル・スクラムの違いと選び方 着手前に作るものが決まり、途中で変わらないならウォーターフォール、作りながら正解を探すならアジャイルです。アジャイルを選んだうえで、チームの進め方の型としてスクラムを使うかを決めます。 | 観点 | ウォーターフォール | アジャイル | スクラム | | ------- | ---------- | ------------- | ------------- | | 位置づけ | 開発プロセスのモデル | 価値観・原則 | アジャイルの枠組み | | 要件の詳細化 | 着手前に確定 | 作りながら | バックログで継続的に | | 周期 | 全体で1回 | 数週間〜数か月 | 1か月以内 | | 変更への強さ | 弱い | 強い | 強い | | 基準となる文書 | 各社の工程定義 | アジャイル宣言（2001） | スクラムガイド（2020） | | 契約の例 | 工程別に請負・準委任 | 準委任が多い | IPAモデルは準委任 | - **違いの核心**：要件を着手前に確定させるか、作りながら確かめるか。比較軸ごとの違いは下の比較表にまとめています。 - **アジャイルとスクラム**：スクラムはアジャイルの一実装です。アジャイルにはカンバンやXPなど別の枠組みもあります。 - **日本の実態**：IPAの分析データ集2022では、開発モデルが分かる1,377件のうち97.2%がウォーターフォールでした。アジャイルの取り入れも米独より遅れています。 - **契約**：IPAのアジャイル開発版モデル契約は準委任契約を前提にしています。手法と契約がずれると、変更のたびに見積もり交渉が起きます。 - **採用しない条件**：発注側が優先順位を決める担当者を出せないなら、アジャイルは選ばないでください。 ## ウォーターフォール・アジャイル・スクラムの位置づけ 3つの用語は、指している範囲が違います。ウォーターフォールとアジャイルは開発の進め方の考え方で、互いに対になる関係です。スクラムはアジャイルの考え方をチームで回すための具体的なルール集です。 ### ウォーターフォール開発：工程ごとに成果物を確定させる計画駆動 ウォーターフォール開発は、要件定義・設計・製造・テスト・リリースの工程を上流から下流へ順に進め、各工程の成果物を承認してから次へ進む手法です。源流とされるのはWinston W. Royceが1970年に発表した論文ですが、Royce自身は一方向に流すだけの進め方を「失敗を招く」と書き、試作や顧客の関与で補うよう求めていました。論文の中身と工程ごとの成果物、V字モデルは[ウォーターフォール開発とは？工程・V字モデルと契約、向く案件を発注者目線で解説](/column/details/13140/)で詳しく扱っています。 ### アジャイル開発：2001年の宣言が示す4つの価値 アジャイル開発は特定の手順書ではなく、2001年に17人の開発者が公開した[アジャイルソフトウェア開発宣言](https://agilemanifesto.org/iso/ja/manifesto.html)の価値観に沿った進め方の総称です。宣言は「プロセスやツールよりも個人と対話を」「包括的なドキュメントよりも動くソフトウェアを」「契約交渉よりも顧客との協調を」「計画に従うことよりも変化への対応を」の4つの価値を掲げています。プロセスや文書、契約、計画を不要としたのではなく、それらにも価値があると認めたうえで、後に挙げた側をより重んじるという書き方です。 宣言とあわせて公開された[12の原則](https://agilemanifesto.org/iso/ja/principles.html)には、動くソフトウェアを「2-3週間から2-3ヶ月」という短い間隔でリリースすること、ビジネス側の人と開発者がプロジェクトを通して日々一緒に働くことが書かれています。アジャイルの成否を分けるのは、後者の「発注側が毎日関わる」条件を満たせるかどうかです。定義と導入の進め方は[アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説](/column/details/12850/)にまとめています。 ### スクラム：スクラムガイド2020が定める枠組み スクラムは、Ken SchwaberとJeff Sutherlandが1995年のOOPSLAカンファレンスで共同発表した枠組みで、現在のルールは2020年11月版の[スクラムガイド](https://scrumguides.org/scrum-guide.html)が基準です。スクラムチームはプロダクトオーナー・スクラムマスター・開発者の3つの責任で構成され、人数は「通常10人以下」とされています。旧版の「開発者3〜9人」という目安は2020年版で置き換えられました。 開発は1か月以内の固定期間「スプリント」を繰り返し、スプリントの中でスプリントプランニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブを行います。作成物はプロダクトバックログ・スプリントバックログ・インクリメントの3つで、それぞれにプロダクトゴール・スプリントゴール・完成の定義という確約が対応します。役割とイベントの詳細は[スクラム開発とは？進め方・3つの役割・5つのイベントとメリット・デメリットをスクラムガイドで解説](/column/details/2336/)を参照してください。 ## ウォーターフォールとアジャイルの違い｜8つの判断軸の比較表 ウォーターフォールとアジャイルは優劣ではなく、要件の固まり具合と変更の起きやすさで使い分ける関係です。判断軸ごとに並べると次のとおりです。 | 判断軸 | ウォーターフォール | アジャイル | | ------- | ----------- | ---------- | | 要件 | 着手前に確定 | 優先順位順に詳細化 | | 仕様変更 | 変更管理で再見積り | 優先順位を組み替える | | リリース | 最後に一括が典型 | 小さく何度も | | テスト | 終盤の工程に集中 | 反復ごとに実施 | | 顧客の関与 | 要件定義と受入れが中心 | 開発期間中ずっと | | 見積もりの基礎 | 確定した要件 | 体制と期間・優先順位 | | ドキュメント | 工程ごとに厚く作る | 必要な分だけ作る | | 契約の例 | 工程別に請負・準委任 | IPAモデルは準委任 | ### テストと品質の作り込み方の違い ウォーターフォールでは、設計の各段階に対応するテストを終盤の工程でまとめて行います。V字モデルで要件定義と受入テスト、基本設計と総合テストを対応させるのが典型で、品質の証跡を残しやすい反面、設計レビューや試作で要件を確かめておかないと、要件の誤りが受入テストの段階まで見つからないおそれがあります。アジャイルでは動くソフトウェアを短い間隔で作るため、テストも反復の中で行います。スクラムなら、スプリントごとに完成の定義を満たしたインクリメントを作るので、不具合や要件の誤解が数週間単位で表に出ます。テスト工程の種類と対応関係は[システム開発のテスト工程とは？種類・流れとV字モデル・発注者が見る判断軸](/column/details/13445/)で整理しています。 ### 顧客の関わり方と見積もりの違い ウォーターフォールの発注側は、要件定義と各工程の承認、最後の受入テストで判断を下します。要件が確定すれば以降の工程の費用と納期を見積もりやすく、予算を立てやすいのが利点です。ただし契約上の金額と納期がいつ確定するかは契約の組み方によります。工程ごとに契約を分ける場合、製造工程の金額は設計が固まった時点で決まります。アジャイルでは、発注側が開発期間中も優先順位の判断に加わります。スクラムを使う場合は、発注側の担当者がプロダクトオーナーとしてプロダクトバックログの並び順を継続的に管理し、スプリントレビューで出来上がりを確かめます。費用の決め方も契約によりますが、IPAのアジャイル開発版モデル契約のように準委任で体制と期間に対価を払う形では、予算の上限は決められても「全機能をこの金額で完成させる」という保証は付きません。 ## アジャイルとスクラムの違い｜思想と枠組みの包含関係 「アジャイルとスクラムのどちらにするか」という問いは成り立ちません。アジャイルが上位の考え方で、スクラムはそれを実装する枠組みの一つです。アジャイル宣言は大切にする価値を示すだけで、会議体や役割までは決めていません。その手順を明文化したのがスクラムで、IPAのアジャイル開発版モデル契約もスクラムを前提の手法として採用しています。 したがって検討の順序は、まず要件の性質からアジャイルを選ぶかを決め、次にチームの体制からスクラムを使うかを決めます。スクラムを使わずにアジャイルを実践することもできます。 ### スクラム以外のアジャイル手法：カンバンとXP カンバンは、作業をボード上で「未着手・作業中・完了」などの列に並べ、作業中の件数に上限（WIP制限）を設けて流れを止めない方法です。スプリントのような固定の区切りや決められた役割を持たないため、問い合わせ対応や保守のように優先度が日々入れ替わる仕事に向きます。ボードの作り方とリードタイムの測り方は[カンバン方式のタスク管理とは？ボードの作り方とWIP制限・リードタイムの測り方](/column/details/15654/)で解説しています。 XP（エクストリーム・プログラミング）は、Kent Beckが提唱した手法で、短いリリース周期や顧客との協働に加え、テスト駆動開発・ペアプログラミング・継続的インテグレーションといった技術的な実践を含みます。スクラムは開発の技術的な進め方を定めていないため、スクラムで回すチームがXPのテスト駆動開発や継続的インテグレーションを取り入れることもできます。 ## 日本の開発現場での採用状況｜IPAデータに見る実態 「ウォーターフォールはもう古いのか」という疑問には、データで答えられます。IPAの[ソフトウェア開発分析データ集2022](https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf)では、開発ライフサイクルモデルが分かる1,377件のうち、ウォーターフォールが1,339件で97.2%、反復型が29件で2.1%でした。同資料は、2014年度〜2019年度と比べても「あまり差はない」としています。 この数字は、IPAにプロジェクトデータを提供した企業の2016年度〜2021年度の案件を集計したものです。ただし、この結果から日本の受託開発全体の採用比率は判断できません。発注側がアジャイルを検討するなら、開発会社の見積もりや自社の稟議が工程単位の前提で組まれていないかを、契約前に確かめておく必要があります。 アジャイルの考え方そのものの浸透も、米国やドイツとは差があります。IPAの[DX動向2025](https://www.ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html)（2025年2〜3月調査）によると、アジャイルの原則とアプローチを「全面的に取り入れている」と答えた日本企業は、どの部門でも1割以下でした。「一部取り入れている」を合わせても、最も進んでいるIT部門で5割弱にとどまり、米国は各部門とも7割前後、ドイツは6〜7割程度です。日本で「アジャイルを導入したい」と考える発注側は、開発会社の側にも経験の蓄積が少ない可能性を織り込み、体制と実績を確かめてから選ぶ必要があります。 ## 契約形態との組み合わせ｜請負・準委任とIPAモデル契約 手法を決めたら、契約形態を合わせます。手法と契約がずれると、変更のたびに見積もり交渉が発生して開発が止まります。 | 契約形態 | 対価の対象 | 合う手法 | | ---- | ------ | -------------- | | 請負 | 成果物の完成 | ウォーターフォールの製造工程 | | 準委任 | 業務の遂行 | アジャイル、上流工程 | IPAが2020年3月31日に公開した[情報システム・モデル取引・契約書（アジャイル開発版）](https://www.ipa.go.jp/digital/model/agile20200331.html)は、あらかじめ特定した成果物の完成に対価を払う請負ではなく、開発会社が専門家として業務を遂行すること自体に対価を払う準委任契約を前提にしています。アジャイルでは開発の途中で機能の追加や優先順位の変更が起きるため、完成すべき成果物を契約時に特定できないからです。準委任と請負・派遣の違いは[準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説](/column/details/13187/)で整理しています。 準委任でアジャイルを進めるときに注意したいのが偽装請負です。発注側の担当者が開発会社のメンバーに直接作業を指示すると、労働者派遣と判断されるおそれがあります。IPAは同ページで、厚生労働省の「37号告示に関する疑義応答集（第3集）」を参考に進めることを勧めています。指揮命令の線引きは[偽装請負とは：4類型と37号告示の判断基準、SES・準委任で発注側が守る線引き](/column/details/18098/)で解説しています。 ウォーターフォールでも、すべてを請負にするわけではありません。IPAのモデル契約は、作るものがまだ決まっていない要件定義までを準委任、内部設計からシステム結合までを請負とし、工程ごとに契約を分ける多段階契約を採っています。 ## ウォーターフォールとアジャイルの選び方｜スクラム採用の判断と採用しない条件 手法は好みではなく、プロジェクトの性質と発注側の体制で決まります。まず「開発中に要件が変わるか」でウォーターフォールかアジャイルかを決め、アジャイルを選んだ場合に、チームの体制からスクラムを使うかを決めます。 ### ウォーターフォールを選ぶ条件 法令や既存業務で仕様の枠が決まっている基幹システムの刷新、公共系の調達、ハードウェアや外部システムと結合日程を合わせる開発が該当します。要件を着手前に確定できることが前提で、そのうえで工程ごとの設計書・テスト結果を証跡として残す必要がある場合に、ウォーターフォールの利点が生きます。IPAのモデル契約も、要件定義の後に工程ごとの契約で金額を確定させる組み方を示しています。要件が動くのにウォーターフォールを選ぶと、後半の手戻りで日程と費用が膨らみます。 ### アジャイル・スクラムを選ぶ条件 作りながら正解を探す新規事業、利用者の反応で優先順位が変わるWebサービス、市場投入の早さが価値になる開発が該当します。そのうえで、スクラムを使うかは体制で決めます。スクラムガイドはチームの人数を「通常10人以下」としており、プロダクトに必要な技能をチーム内でそろえられること、発注側のプロダクトオーナーにバックログの並び順を決める権限と時間があることが条件です。要件の段階的な決め方は[アジャイル開発の要件定義とは？進め方の5ステップとウォーターフォールとの違い](/column/details/16313/)を参照してください。 次のどれかに当てはまるなら、アジャイルは採用しないでください。発注側が優先順位を決める担当者を出せない、予算の承認に全機能の完成を約束した総額が要る、ビジネス側の担当者が開発者と日常的にやり取りする時間を取れない――この状態で始めると、反復のたびに判断が滞り、会議だけが増えて成果が出ません。失敗の典型は[アジャイル開発が失敗する5つの原因｜失敗率268%の読み方](/column/details/12850/)にまとめています。 ### 要件の一部だけが動くときのハイブリッド 要件のうち、外部連携や帳票のように確定している部分と、画面の使い勝手のように試しながら決めたい部分が混在する案件もあります。この場合は、確定部分をウォーターフォールで、変わる部分をアジャイルで進める分担が現実的です。分けるときは、両者をつなぐ接続仕様（APIやデータ形式）を先に確定させ、結合テストの時期と担当を発注時に決めておきます。スクラム側は、スクラムガイドが求めるとおりスプリントごとに統合済みで使えるインクリメントを作り、確定側との結合を終盤に持ち越さないようにします。組み込み機器のようにハードウェア日程を動かせない案件での切り分けは、[アジャイル開発は組み込みでどこまで使えるか｜ハード制約下の適用範囲と判断基準](/column/details/16839/)で扱っています。確定部分と変わる部分の切り分けから相談したい場合は、[フルスクラッチ開発](/service/system/fullscratch/)の支援内容も参考にしてください。 ## ウォータースクラムフォールの実態と抜け出し方 ウォータースクラムフォール（Water-Scrum-Fall）は、ForresterのDave Westが2011年のレポートで、多くの組織におけるアジャイルの実態として示した呼び名です。[InfoQの紹介記事](https://www.infoq.com/news/2011/12/water-scrum-fall-is-the-norm)によれば、「Water」はITとビジネスの間で行う事前の計画、「Scrum」はその計画を反復的に実現する開発、「Fall」は組織の方針や基盤の制約に縛られた頻度の低い本番リリースを指します。 日本では、請負契約と工程単位の承認プロセスを残したまま開発チームだけスクラムを取り入れると、自然にこの形になります。移行の途中段階としては機能しますが、上流と下流を固定したままでは、変更への適応が中間の開発工程に閉じ込められ、スプリントレビューで出た改善要望も次のリリースまで本番に届きません。 抜け出すには、開発チームの外側にある制約を1つずつ緩めます。順序は次のとおりです。 1. 事前計画を全機能の詳細仕様ではなく、プロダクトゴールと優先順位付きのバックログまでにとどめる。 2. 出来上がりの確認を最後の一括検収に集めず、スプリントレビューで利用者の評価を受けて次の計画に反映する。契約上の検収や本番リリースの承認は、レビューとは別の手続きとして、頻度と方法を合意しておく。 3. 契約を工程別の請負から準委任に切り替え、契約期間と更新の条件は開発の進み方に合わせて個別に合意する。 4. リリースの承認と手順を自動化し、本番反映の頻度を上げる。仕組みは[DevOpsとは？アジャイル・CI/CDとの違いとDORA 5指標での成果の測り方](/tech/details/13538/)で扱っています。 形だけスクラムのイベントを差し込み、計画・契約・リリースを従来のままにする導入はおすすめしません。 ## よくある質問 ### ウォーターフォールとアジャイルはどちらを選ぶべきですか？ 開発中に要件が変わるかで決めます。仕様が着手前に確定し、総額を先に固める必要があるならウォーターフォール、作りながら利用者の反応を見て優先順位を変えたいならアジャイルです。アジャイルを選ぶ場合は、発注側から優先順位を決める担当者を出せることが条件になります。 ### ウォーターフォール型のメリット・デメリットは何ですか？ メリットは、要件確定後の費用と納期を見通しやすく、工程ごとの設計書とテスト結果が証跡として残ることです。デメリットは、利用者が動くものを確かめるのが終盤になり、その段階で見つかった要件の誤りや仕様変更が大きな手戻りになることです。 ### アジャイルとスクラムの違いは何ですか？ アジャイルは2001年のアジャイル宣言に示された価値観の総称で、スクラムはそれをチームで実践するための枠組みの一つです。スクラムは3つの責任・5つのイベント・3つの作成物というルールを持ちます。アジャイルにはスクラムのほか、カンバンやXPといった手法もあります。 ### ウォータースクラムフォールとは何ですか？ 事前の計画とリリースはウォーターフォールのまま、中間の開発工程だけをスクラムで回す進め方です。ForresterのDave Westが2011年のレポートで、多くの組織におけるアジャイルの実態として示しました。移行の途中段階としては使えますが、受入れや契約、リリースの制約も緩めないと、アジャイルの効果は出にくくなります。 ### 請負契約でアジャイル開発はできますか？ できなくはありませんが、成果物の完成を約束する請負は、開発中に作る内容を変えるアジャイルと噛み合いません。IPAのアジャイル開発版モデル契約は準委任契約を前提にしています。準委任で進める場合は、偽装請負にならないよう注意が必要です。厚生労働省の[疑義応答集（第3集）](https://www.mhlw.go.jp/content/001704257.pdf)は、契約の形式ではなく実態で判断するとしています。受注側の管理責任者を窓口に置くだけでなく、受注側の開発者が自律的に判断して作業を進め、作業方法や労働時間の指示は受注側が行う体制にしておきます。 ## 関連記事 - [ウォーターフォール開発とは？工程・V字モデルと契約、向く案件を発注者目線で解説](/column/details/13140/) - [アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説](/column/details/12850/) - [スクラム開発とは？進め方・3つの役割・5つのイベントとメリット・デメリットをスクラムガイドで解説](/column/details/2336/) - [準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説](/column/details/13187/) - [カンバン方式のタスク管理とは？ボードの作り方とWIP制限・リードタイムの測り方](/column/details/15654/) --- 出典: [ウォーターフォールとアジャイル・スクラムの違い｜比較表と使い分け・契約形態の選び方]()（株式会社一創）