システム開発の手法｜ウォーターフォールやアジャイルなど主な型の比べ方

2026年2月26日

＠SOHO編集部

この記事のポイント

✓V字モデルなど主な型ごとに
✓メリットとデメリットで比べます
✓案件に合う手法の選び方と

システム開発の手法を調べると、ウォーターフォール、アジャイル、スクラム、スパイラル、プロトタイピングと、たくさんの名前が出てきます。初めてプロジェクトの担当になった人や、開発会社に仕事を頼む立場になった人、フリーランスとして開発の案件に加わる人にとって、「結局どれを選べばいいのか」「自分のチームの進め方は何と呼ぶのか」が分からないまま話が進んでしまうのは不安なものです。

開発の手法は、どれが優れているかではなく、案件の性質に合うかどうかで選ぶものです。作るものが最初からはっきり決まっていて、途中で変わりにくい案件と、作りながら中身を決めていく案件とでは、合う手法がまったく違います。この記事では、主な開発の手法を、進め方、向いている案件、メリットとデメリットで比べ、案件に合う手法の選び方と、手法に合わせた進捗管理の道具の選び方までを順番に整理します。カンバンとガントチャートの両方を同じ場所で使えるプロジェクト管理の道具として、「Pinateca」にも触れます。

開発の手法とは何を決めるものか

開発の手法とは、システムやソフトウェアを作るときに、どの順番で、どのくらいの単位で作業を進めるかを決めた型のことです。開発モデルと呼ばれることもあります。

システム開発には、どの手法でも共通して行う作業があります。

要件定義。何を作るか、どんな機能が必要かを決めます
設計。要件をどんな仕組みで実現するかを決めます
実装。設計に沿ってプログラムを書きます
テスト。作ったものが要件どおりに動くかを確かめます
リリースと運用。使える状態にして、使われながら直していきます

手法の違いは、この作業を「全体で1回ずつ順番に行う」のか、「小さな単位で何度もくり返す」のかにあります。全体を1回で順番に進めるのがウォーターフォールの考え方で、小さな単位でくり返すのがアジャイルの考え方です。そのほかの手法の多くは、この2つの間に位置するか、どちらかの弱点を補う工夫として生まれました。

開発の手法を知っておくと、プロジェクトの関係者と同じ言葉で話せるようになります。開発会社から「この案件はアジャイルで進めます」と言われたときに、毎週どんな打ち合わせがあり、いつ何が出来上がるのかを想像できれば、頼む側も準備ができます。フリーランスとして案件に加わる人にとっても、手法によって求められる動き方が違うので、案件を受ける前に確かめておくべきことが分かります。

ウォーターフォール。工程を順番に進める型

ウォーターフォールは、要件定義から設計、実装、テスト、リリースまでの工程を、上から下へ水が流れるように順番に進める手法です。システム開発の会社を紹介する事業者の解説は、次のように説明しています。

ウォーターフォール型開発は、要件定義・外部設計・内部設計といったシステム開発の各工程を、上流工程から下流工程へ順に行っていく手法です。「完了したら次の工程に進む」という、分かりやすい開発手法であり、システム開発の経験が少ない方もイメージしやすいでしょう。出典: hnavi.co.jp

外部設計とは、利用者から見える画面や操作の設計のことで、内部設計とは、プログラムの中の仕組みの設計のことです。ウォーターフォールでは、それぞれの工程の終わりに成果物（要件定義書や設計書）を作り、関係者が確認してから次の工程に進みます。

ウォーターフォールのメリット

全体の計画を最初に立てるので、費用と期間の見通しを立てやすい
工程ごとに成果物が残るので、進み具合を確かめやすく、担当者が替わっても引き継ぎやすい
工程ごとに担当を分けやすく、大人数のプロジェクトでも役割をはっきりさせられる

ウォーターフォールのデメリット

前の工程に戻ることを想定していないので、途中で要件が変わると、大きな手戻りと追加の費用が生じる
実際に動くものを見られるのが後半になるため、出来上がってから「思っていたものと違う」と分かることがある
テストが最後にまとまるので、問題が見つかったときに直す時間が足りなくなりやすい

ウォーターフォールが向いている案件

作るものが最初からはっきり決まっていて、途中で変わりにくい案件に向いています。法律や制度で決まった処理を行う業務システム、既存のシステムを同じ機能のまま作り直す案件、安全性が重視されて変更の手続きが厳しい案件などです。発注する側が予算と納期を最初に確定させる必要がある場合も、ウォーターフォールのほうが契約を組み立てやすくなります。

V字モデル。テストを設計と対にする型

V字モデルは、ウォーターフォールを発展させた手法です。工程の流れをV字の形に並べ、左側に要件定義から詳細な設計までの工程を、右側にそれぞれの工程に対応するテストを並べます。

たとえば、要件定義には受け入れテスト（発注者が求めたとおりに使えるかを確かめるテスト）、基本設計にはシステムテスト（全体が設計どおりに動くかを確かめるテスト）、詳細設計には結合テスト（部品を組み合わせて動くかを確かめるテスト）、というように、設計の段階ごとに、何をもって完成とするかを先に決めておきます。

設計の段階でテストの観点まで決めるので、テストの抜けを防ぎやすく、品質を重視する案件で使われます。ただし、ウォーターフォールと同じく、途中の変更には弱い手法です。

アジャイル。小さく作ってくり返す型

アジャイルは、システム全体を一度に作るのではなく、機能を小さな単位に分け、短い期間で計画、設計、実装、テストをくり返しながら作っていく手法の考え方です。アジャイルという言葉は、2001年に開発者たちがまとめた「アジャイルソフトウェア開発宣言」に由来します。宣言では、次の4つの価値が示されています。

プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。出典: agilemanifesto.org

宣言は続けて、左側のことがらにも価値があると認めながら、右側のことがらにより価値をおくとしています。つまり、計画や文書を軽んじるのではなく、変化に合わせて作るものを見直すことを、より大切にするという考え方です。

アジャイルのメリット

短い期間ごとに動くものができるので、早い段階で使ってみて、方向を直せる
途中で要件が変わっても、次の短い期間の計画に反映しやすい
優先度の高い機能から作るので、限られた予算でも価値の大きい部分を先に使い始められる

アジャイルのデメリット

最初に全体の範囲を決めきらないので、最終的な費用と期間の見通しを立てにくい
発注する側も、優先順位を決めたり、出来上がったものを確かめたりする役割を担う必要があり、関わる手間が大きい
進め方がチームの力量に左右されやすく、くり返しの中で方向が定まらないまま時間がかかることがある

アジャイルが向いている案件

作りながら中身を決めていく案件に向いています。新しいサービスを立ち上げて、利用者の反応を見ながら機能を追加していく案件、市場の変化が速く、半年先に何が求められるか分からない案件などです。

スクラム。アジャイルを進める代表的な枠組み

アジャイルは考え方の名前で、実際にチームでどう進めるかを決めた具体的な枠組みがいくつかあります。その代表がスクラムです。スクラムの公式のガイドである「スクラムガイド」は、スクラムの中心となる期間であるスプリントについて、1か月以内の決まった長さにすると定めています。スプリントとは、チームが計画を立て、作り、確かめるまでを1回行う区切りの期間のことです。

スクラムでは、次のような役割と場が決められています。

プロダクトオーナー。作るものの価値に責任を持ち、何から作るかの優先順位を決める人
スクラムマスター。チームがスクラムをうまく進められるよう支える人
開発者。実際に作る人たち
プロダクトバックログ。作るものの候補を優先順位の順に並べた一覧
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ。スプリントの始まりの計画、毎日の短い打ち合わせ、終わりの成果の確認と進め方の振り返りの場

スクラムを支える道具として、プロジェクト管理のツールにはスクラム向けのボードを備えたものがあります。たとえば、Atlassianの「Jira」の案内では、スプリントの期間について、一般的には2週間と説明されています。2週間や1週間といった短い期間で区切ると、チームは毎回の終わりに出来上がったものを見せられ、発注する側は早い段階で方向を確かめられます。

そのほかの主な手法

ウォーターフォールとアジャイルのほかにも、よく名前の挙がる手法があります。

XP（エクストリーム・プログラミング）

XPは、アジャイルの考え方に沿った手法の1つで、技術的な実践を重視するのが特徴です。2人で1台の画面を見ながらプログラムを書くペアプログラミング、プログラムを書く前にテストを書くテスト駆動開発、こまめに全体を組み合わせて動くかを確かめる継続的インテグレーションなどの実践がよく知られています。変更に強いプログラムを保つための工夫が多く、スクラムと組み合わせて使われることもあります。

スパイラルモデル

スパイラルモデルは、計画、リスクの分析、開発、評価をひとまとまりとし、それをらせんのようにくり返しながら、システムを少しずつ大きくしていく手法です。くり返しのたびにリスクを洗い出して対策を考えるのが特徴で、規模が大きく、不確かな要素の多い案件で使われてきました。くり返す点はアジャイルと似ていますが、1回ごとに計画とリスクの分析をしっかり行う点で、ウォーターフォールの考え方も取り入れています。

プロトタイピング

プロトタイピングは、本格的に作る前に、画面や操作の試作品（プロトタイプ）を作って発注する側に見てもらい、意見を反映してから本開発に進む手法です。完成形を言葉だけで伝えるのが難しい案件で、「思っていたものと違う」という食い違いを早い段階で防げます。ただし、試作品を作る分の手間と費用がかかります。また、試作品がそのまま使えると誤解されないよう、試作品の目的を関係者で共有しておくことが大切です。

カンバン

カンバンは、作業をカードにして、「未着手」「進行中」「完了」のような列に並べ、作業の流れを目で見えるようにする進め方です。スクラムのようにスプリントで区切らず、同時に進める作業の数に上限を設けて、流れが滞っているところを見つけて直していきます。保守や運用のように、作業が次々と入ってくる仕事と相性のよい進め方です。

DevOps

DevOpsは、開発の手法というより、開発を担うチームと運用を担うチームが協力して、作る、届ける、使われ方を見て直す、までを短い周期で回し続けるための考え方と取り組みの総称です。開発のDevelopmentと運用のOperationsを合わせた言葉です。テストやリリースの作業を自動化し、小さな変更をこまめに利用者へ届けられるようにするのが特徴で、アジャイルで作ったものを、早く安定して使ってもらうための仕組みとして取り入れられています。

手法を組み合わせる進め方

実際の現場では、1つの手法をそのまま使うより、案件に合わせて組み合わせることが多くあります。代表的な組み合わせ方を3つ挙げます。

1つ目は、上流をウォーターフォール、下流をアジャイルで進める形です。全体の要件と基本設計は最初に固めて予算と期間の大枠を決め、画面の細かい作り込みや使い勝手の調整は、短い期間でくり返して仕上げます。発注する側が予算を確定させたい一方で、細部は作りながら決めたい、という案件で使われます。

2つ目は、プロトタイピングで方向を決めてから、アジャイルで作る形です。最初に試作品で完成の姿を関係者で共有し、その後の本開発をスプリントで進めます。新しいサービスで、関係者の頭の中にある完成の姿がばらばらな場合に向いています。

3つ目は、スクラムで計画を区切りつつ、日々の作業はカンバンで流す形です。スプリントの計画と振り返りの場はスクラムに従い、スプリントの中の作業の進み具合は、カンバンボードで列を動かしながら管理します。

組み合わせるときは、どの部分をどの手法で進めるのかを、関係者全員が同じように理解していることが欠かせません。境目があいまいなままだと、要件をいつまで変えてよいのか、誰が何を承認するのかで食い違いが生まれます。

主な手法の比べ方

ここまでの手法を、比べやすいように表にまとめます。

手法	進め方	変更への強さ	向いている案件
ウォーターフォール	工程を順番に1回ずつ	弱い	要件が固まっている業務システム
V字モデル	設計とテストを対にして順番に	弱い	品質を重視する案件
アジャイル（スクラム）	短い期間でくり返す	強い	新しいサービスの立ち上げ
XP	技術的な実践を重ねてくり返す	強い	変更の多いソフトウェア
スパイラル	リスクの分析を挟んでくり返す	中くらい	大規模で不確かな要素の多い案件
プロトタイピング	試作品で確かめてから本開発	中くらい	完成形を言葉で伝えにくい案件

表を見ると分かるように、変更に強い手法ほど、最初に全体の費用と期間を決めにくいという関係があります。どちらを重視するかで、選ぶべき手法が変わります。

手法によって作る書類が違う

開発の手法によって、プロジェクトの中で作る書類や記録も変わります。手法を選ぶときは、どんな書類を誰が作り、誰が確かめるのかもあわせて考えておくと、進め方の食い違いを防げます。

ウォーターフォールでは、工程ごとに成果物となる書類を作ります。要件定義の工程では、作るシステムに必要な機能や性能をまとめた要件定義書を作ります。設計の工程では、画面や操作の流れをまとめた基本設計書と、プログラムの中の仕組みをまとめた詳細設計書を作ります。テストの工程では、何をどう確かめるかをまとめたテストの計画書と、結果の報告書を作ります。それぞれの書類を発注する側が確かめ、承認してから次の工程に進むので、書類の質がそのままプロジェクトの質を左右します。

アジャイルでは、細かな設計書を最初にすべて作ることはせず、作るものの候補をプロダクトバックログという一覧にまとめて、優先順位の順に並べます。一覧の1つ1つは、「利用者として、〇〇ができるようにしたい。それは△△のためだ」のように、誰が何のために使う機能なのかを短い文で書くことがよくあります。この書き方はユーザーストーリーと呼ばれます。スプリントごとに、一覧の上から作るものを選び、出来上がったものを確かめながら、一覧の中身と順番を見直していきます。

アジャイルでは書類を作らない、と考えるのは誤解です。アジャイルソフトウェア開発宣言も、包括的なドキュメントに価値がないとは言っていません。動くソフトウェアにより価値をおくという考え方であって、運用に必要な手順書や、ほかの人が引き継ぐための説明は、アジャイルでも必要に応じて作ります。

よくある誤解

開発の手法については、いくつかの誤解がよく見られます。

1つ目は、「アジャイルなら計画は要らない」という誤解です。アジャイルでも、スプリントごとに計画を立て、何を作るかを決めます。全体の大まかな方向と、いつ頃までに何を使えるようにしたいかという見通しも必要です。計画を一度で固めず、くり返しの中で見直していくのがアジャイルの特徴であって、計画を立てないわけではありません。

2つ目は、「ウォーターフォールは古い手法だ」という誤解です。要件が固まっていて変わりにくい案件や、費用と期間を最初に確定させる必要がある案件では、今でもウォーターフォールが合っています。新しいか古いかではなく、案件に合うかどうかで選ぶものです。

3つ目は、「アジャイルにすれば早く安くできる」という誤解です。アジャイルは、価値の大きい機能から先に使い始められるという意味では早く成果を得られますが、全体を作り終えるまでの期間や費用が必ず小さくなるわけではありません。途中で作るものを見直す分、最初に思い描いていた機能がすべて揃うとは限らないことも、あらかじめ理解しておく必要があります。

4つ目は、「手法を決めれば進め方は決まる」という誤解です。同じスクラムでも、スプリントの長さ、打ち合わせのやり方、確認の基準はチームごとに違います。手法の名前を決めたあとも、自分たちの案件に合わせて進め方を具体的に決めておくことが大切です。

発注する側が準備しておくこと

開発会社やフリーランスに開発を頼む立場の人は、手法を選ぶ前に、次のことを整理しておくと話し合いが進みやすくなります。

作りたいものの目的。何のために作るのか、誰が使うのか、使うことで何が良くなるのかを言葉にしておきます
必ず必要な機能と、あれば嬉しい機能の区別。予算や期間が足りないときに、どこから削るかの判断材料になります
予算と期限の幅。上限の予算と、いつまでに使い始めたいかを伝えておくと、受ける側は合う手法を提案しやすくなります
開発の途中で関われる時間。毎週の確認に参加できるのか、工程の区切りだけ確認できるのかで、合う手法が変わります

これらを整理した書類を提案依頼書と呼ぶことがあります。提案依頼書とは、発注する側が作りたいものの目的や条件をまとめ、受ける側に提案を求めるための書類のことです。大きな案件でなくても、この4点をメールにまとめて伝えるだけで、受ける側から、手法を含めた具体的な進め方の提案を受けやすくなります。

案件に合う手法の選び方

開発の手法は、どれが一番よいと言い切れるものではありません。システム開発の会社の解説も、次のように書いています。

これだけ開発手法がたくさんあると、「結局どの手法が一番いいの？」という感じる方も少なくないでしょう。ですがシステム開発は、案件別に予算や納期などが大きく異なるため、「最も良い方法」を断言しにくいのです。出典: hnavi.co.jp

案件に合う手法を選ぶときは、次の4つの問いに答えてみます。

作るものは最初からはっきり決まっているか。決まっていて変わりにくいならウォーターフォール、作りながら決めるならアジャイルが候補になります
予算と納期は最初に確定させる必要があるか。確定させる必要が強いなら、ウォーターフォールのほうが契約を組み立てやすくなります
発注する側は、開発の途中でどれだけ関われるか。毎週の確認や優先順位の判断に時間を割けるなら、アジャイルの強みを生かせます。割けないなら、工程の区切りで確認するウォーターフォールのほうが負担は小さくなります
品質の確認にどれだけ厳しさが求められるか。厳しい確認が求められるなら、V字モデルのようにテストを設計と対にする手法が合います

実際の案件では、1つの手法だけで進めるとは限りません。全体の要件定義と基本設計はウォーターフォールで固め、画面の細かい作り込みはアジャイルで進める、というように組み合わせることもよくあります。大切なのは、関係者全員が「この案件はどう進めるのか」を同じように理解していることです。

手法に合わせて進捗管理の道具を選ぶ

開発の手法が決まったら、進み具合を管理する道具を選びます。手法によって、見たいものが違うからです。

ウォーターフォールでは、工程ごとの期間と締め切り、工程どうしの重なりを見たいので、ガントチャートが中心になります。ガントチャートとは、作業を縦に並べ、それぞれの期間を横棒で示した工程表のことです。アジャイルやカンバンでは、作業の流れと、今どの作業が止まっているかを見たいので、カードを列に並べるカンバンボードが中心になります。

よく使われる道具には、それぞれ得意なことがあります。

Trello。カードを列に並べるカンバンボードの道具として広く使われています。公式の料金ページでは、無料プランはワークスペースあたり10コラボレーターまでと案内されています
Jira。Atlassianが提供する、ソフトウェア開発のチーム向けの道具です。スクラム向けのボードなど、スプリントで区切って進めるための機能を備えています
Backlog。ヌーラボが提供する、課題の管理とガントチャートを備えた国産の道具です。公式ブログでは、2027年1月1日からプランが新しくなり、現在のプランの新規契約は2026年12月31日で終わること、フリープランのユーザーの上限が10名から5名に変わることが告知されています。これから使い始める人や、フリープランで使っている人は、告知の内容を確かめてから選びます

道具選びで悩みやすいのが、手法を組み合わせる案件です。全体の工程はガントチャートで、細かい作業はカンバンで管理したいのに、道具が分かれていると、同じ作業を2か所で更新することになり、どちらかが古くなりがちです。

このような案件で、カンバンとガントチャートを同じ場所で使いたい場合は、プロジェクト管理の道具「Pinateca」が選択肢になります。公式サイトでは、カンバン、ガント、カレンダー、リストなど8種類のボードとチャットが最初からすべて使えると案内されています。ボードは作るときに種類を選び、あとから追加することもできるので、全体の工程はガントボード、日々の作業はカンバンボード、というように同じ案件の中で見方を使い分けられます。料金ページによると、5人までのフリープランは0円で、8種類のボードすべてを使えます（ボードは10個まで）。人数とボードの数に上限のないスタンダードプランは、1人あたり月額500円（年払いなら1人あたり月額400円、税抜）です。Trelloから移る場合は、エクスポートしたファイルを読み込むことで、ボードやカード、ラベル、添付を取り込めると案内されています。

Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

どの道具を選ぶ場合も、無料の範囲で実際の案件の一部を入れて試し、チームの誰もが迷わず更新できるかを確かめてから決めると、導入してから使われなくなる失敗を防げます。試すときは、管理を担う人だけでなく、毎日カードを動かす開発者やデザイナーにも使ってもらい、更新の手間が負担にならないかを聞いておきます。道具は、毎日使う人が無理なく続けられることが、何よりの選ぶ基準です。

フリーランスとして開発の案件に加わるときに確かめること

フリーランスのエンジニアやデザイナーとして開発の案件に加わるときは、手法によって働き方が変わるので、受ける前に次の点を確かめます。

1つ目は、どの手法で進めるかです。アジャイルで進める案件では、毎日の短い打ち合わせや、スプリントの終わりの確認の場に参加することが求められます。打ち合わせの時間帯が自分の働ける時間と合うかを確かめます。

2つ目は、契約の形です。ウォーターフォールの案件では、決まった成果物を納めることを約束する請負の形が多く、アジャイルの案件では、決まった期間、作業に参加することを約束する準委任の形が多く見られます。請負は成果物を仕上げる責任を負い、準委任は作業を適切に行う責任を負う、という違いがあります。どちらの形かで、途中で仕様が変わったときの扱いが変わるので、契約書で確かめます。

3つ目は、変更の扱いです。ウォーターフォールの案件で途中に仕様が変わったとき、追加の費用や期間をどう決めるかを、最初に取り決めておくと、あとでもめずに済みます。

アプリの開発の案件でどのような仕事があり、どのような力が求められるかは、アプリケーション開発のお仕事で確かめられます。

開発の現場を長く見てきた立場から

在宅ワークとフリーランスの仲介を2004年から続けてきた運営者として見ていると、開発の案件がうまく進むかどうかは、手法の名前より、発注する側と受ける側が「どう進めるか」を最初に言葉にして合意しているかどうかで決まることが多いと感じます。アジャイルで進めると決めたのに、発注する側が途中の確認に時間を割けず、最後にまとめて見て「違う」と言う。こうした行き違いは、手法の選び方ではなく、手法に合わせた関わり方の合意が足りないところから生まれています。

もう1つ見えてきたのは、仲介の会社が間に入らない直接の取引ほど、同じ予算で依頼主は多くの作業を頼めて、受ける側の手取りも厚くなるという構造です。手数料0%で直接取引できる場では、スプリントごとに小さく発注し、出来上がりを見ながら次を頼む、というアジャイルに近い頼み方も組み立てやすくなります。

生成AIを組み込んだアプリの開発のように、作りながら中身を決めていく案件は、これから一層増えていくと見られます。そうした案件の仕事の中身は、AIチャットボット・アプリ開発のお仕事で紹介されています。まずは、自分が関わる案件を4つの問いに当てはめ、どの手法が合うかを関係者と話し合うところから始めてみてください。