システム開発の手法は、ウォーターフォール・V字モデル・アジャイル（スクラム）・スパイラル・プロトタイプ・ハイブリッドの6つを押さえれば、発注の場面で困ることはほとんどありません。ただし、手法の名前と特徴を覚えるだけでは選べません。手法を変えると、発注側が出す時間・見積もりの形・契約・検収のやり方まで一緒に変わるからです。
この記事は、これからシステム開発を外注する企業の担当者・責任者に向けて書いています。読み終えると、次のことがわかります。
- 主な開発手法6種類の違い（一覧表つき）
- 手法によって変わる「発注側の仕事」と、見積もり・契約・検収の形
- 自社の案件に合う手法を決める4つの判断軸と、作る側から見た失敗パターン
この記事の要点
Photo by Austin Distel on Unsplash
- 手法は「工程の回し方」で、契約形態や体制とは別の軸。「アジャイル＝準委任」「ウォーターフォール＝請負」はよくある組み合わせですが、自動的に決まるものではありません。
- アジャイルは発注側の関与が前提の手法。スクラムでは、発注側（プロダクトオーナー）が1か月以内のスプリントごとに計画・レビューへ参加します。IPAのアジャイル開発版モデル契約も、ユーザー企業の主体的な関与と相応の負担を前提にしています。
- 選び方は4軸で決める。要件の確定度・発注側が出せる関与・予算の決め方・リリースの切り方です。
- 失敗の多くは手法そのものではなく、手法と契約・体制の組み合わせのズレから起きます。
システム開発の手法とは｜契約形態・体制とは別の軸
Photo by Kaleidico on Unsplash
システム開発の手法（開発手法・開発プロセス）とは、要件定義・設計・実装・テストといった工程をどの順番で、どの単位で回すかの決め方です。工程そのものの意味はシステム開発の工程と全体の流れで整理しているので、ここでは「回し方」の違いに絞ります。
発注の場面で混乱しやすいのは、手法と次の2つがよく一緒に語られるためです。
| 軸 | 何を決めるか | 代表例 |
|---|---|---|
| 開発手法 | 工程の回し方 | ウォーターフォール、アジャイル、プロトタイプ |
| 契約形態 | 何に対して対価を払うか | 請負（完成に対して）、準委任（業務の遂行に対して） |
| 体制 | 誰がどれだけの期間関わるか | プロジェクト単位のチーム、ラボ型（期間で専属チームを確保） |
3つは関係していますが、別々に決めるものです。たとえば「ウォーターフォールで進めるが、要件定義だけは準委任にする」「アジャイルで進めるが、体制はラボ型にする」といった組み合わせは実務でよくあります。契約形態の選び方は要件の確定度で変わる請負と準委任の選び方で詳しく扱っています。
主なシステム開発の手法6種類の一覧と比較
Photo by Campaign Creators on Unsplash
まず全体像を一覧で示します。「発注側の関与」と「見積もりの形」は、上位の解説記事ではあまり触れられていませんが、発注の判断にはこの2列が最も効きます。
| 手法 | 進め方 | 要件変更への強さ | 発注側の関与 | 見積もりの形 | 向いている案件 |
|---|---|---|---|---|---|
| ウォーターフォール | 工程を順に一方向へ | 弱い | 要件定義・設計承認・受入テストに集中 | 総額で出しやすい | 要件が固まっている業務システム、法令対応 |
| V字モデル | ウォーターフォール＋工程ごとに対応するテスト | 弱い | 同上＋テスト観点の合意 | 総額で出しやすい | 品質要求が高い基幹系 |
| アジャイル（スクラム） | 1か月以内の短い周期で計画〜リリースを反復 | 強い | 期間中ずっと（優先順位の判断役が必要） | 期間×体制で出す | 新規サービス、要件が変わりやすい案件 |
| スパイラル | 機能を分け、設計〜評価を繰り返して完成度を上げる | 中 | 各周回の評価に参加 | 周回ごと・段階的に出す | リスクの大きい機能を先に検証したい案件 |
| プロトタイプ | 試作を見せて要件を確定してから本開発 | 中（試作段階で吸収） | 試作の確認・フィードバック | 試作と本開発を分けて出す | 画面や操作のイメージが固まっていない案件 |
| ハイブリッド | 前半を試作・反復、後半を計画的に進めるなど組み合わせ | 中〜強 | 前半に厚く、後半は承認中心 | フェーズごとに分けて出す | 業務システムの刷新、要件の一部だけ不確実な案件 |
ウォーターフォール
要件定義→基本設計→詳細設計→実装→テスト→リリースと、工程を順番に進めて原則として前に戻らない手法です。各工程の成果物（要件定義書・設計書）が明確なので、進捗と費用の管理がしやすく、総額の見積もりを出しやすいのが最大の利点です。
裏返すと、要件定義が終わった後の変更は「手戻り」として費用と期間に跳ね返ります。発注側の負担は要件定義と設計承認、最後の受入テストに集中します。
V字モデル
ウォーターフォールの派生で、設計の各段階に対応するテストを置く考え方です（要件定義↔受入テスト、基本設計↔総合テスト、詳細設計↔結合・単体テスト）。「何をどこで検証するか」を設計段階で決めるため、品質を重視する基幹系でよく使われます。発注側にとっては、要件定義の段階で受入テストの観点を合意しておくことが重要になります。受入テストの進め方は受入テスト(UAT)の進め方と検収の判断基準にまとめています。
アジャイル（スクラム）
短い周期で計画・設計・実装・テスト・リリースを繰り返し、動くものを見ながら優先順位を入れ替えていく手法の総称です。代表的なフレームワークがスクラムで、スクラムガイド（2020年版）では次のように定められています。
- スプリント（反復の単位）は1か月以内の固定長
- スプリントプランニングは、1か月のスプリントなら最大8時間
- スプリントレビューは、1か月のスプリントなら最大4時間
- 開発者が毎日行うデイリースクラムは15分
要件変更に強い一方で、「何を先に作るか」を決める役（スクラムではプロダクトオーナー）が発注側に必要です。この役を立てられないと、アジャイルの利点はほぼ消えます。
スパイラル
システムを機能単位に分け、設計・実装・評価のサイクルを何周も回しながら完成度を上げていく手法です。技術的に不確実な部分（外部連携や性能など）を先に検証できるため、リスクの大きい案件に向きます。周回ごとに評価と次の計画が入るので、見積もりも段階的になります。
プロトタイプ
本開発の前に、画面や操作の試作品（プロトタイプ）を作って発注側に確認してもらい、要件を固めてから本開発に入る手法です。「実物を見ないと判断できない」という状況に強く、要件定義の精度を上げる手段として使われます。試作はあくまで確認用で、本番品質ではない点に注意が必要です（後述の失敗パターン④）。
ハイブリッド
複数の手法を組み合わせる進め方です。よくある形は次の2つです。
- 前半プロトタイプ・後半ウォーターフォール：試作で画面と業務フローを固め、確定した要件で計画的に作る
- 基盤はウォーターフォール・業務画面はアジャイル：変えにくい部分（データ構造・外部連携）は計画的に、変わりやすい部分（画面・帳票）は反復で作る
業務システムの刷新など「大半は決まっているが、一部が不確実」な案件では、純粋なウォーターフォールやアジャイルよりもハイブリッドが現実的なことが多いです。
手法で変わる「発注側の仕事」｜関与の量と時期
手法を選ぶとき、最も見落とされやすいのが発注側の工数です。上位の解説記事は作る側の工程の違いを中心に説明していますが、発注側から見ると「いつ・誰が・どれだけ時間を出すか」が手法ごとに大きく違います。
| 手法 | 発注側が出すもの | 関与が集中する時期 | 発注側に必要な人 |
|---|---|---|---|
| ウォーターフォール / V字 | 要件の確定、設計書の承認、受入テストの実施 | 序盤と終盤 | 要件を決められる業務責任者、受入テストの担当者 |
| アジャイル（スクラム） | 優先順位の判断、スプリントごとの確認とフィードバック | 期間中ずっと | 判断を任されたプロダクトオーナー（兼務では回りにくい） |
| スパイラル | 各周回の評価と、次に検証する範囲の判断 | 周回の区切りごと | 評価できる業務・技術の担当者 |
| プロトタイプ | 試作へのフィードバック、要件の確定判断 | 序盤（試作期間） | 実際に使う現場の担当者 |
| ハイブリッド | 前半は反復のフィードバック、後半は承認と受入 | 前半に厚く | 前半はプロダクトオーナー役、後半は承認者 |
アジャイルの発注側負担については、IPA（情報処理推進機構）のアジャイル開発版モデル契約も、ユーザー企業がプロダクトの方向性と内容を決めるために主体的かつ積極的に関与する必要があり、相応の負担を伴うと明記しています。そのうえで、契約の前に目的・体制・アジャイルへの理解をお互いに確認する「契約前チェックリスト」を用意しています。
作る側から見た実感として、手法の選択で最初に確認すべきは「発注側にプロダクトオーナーを立てられるか」です。ここが「難しい」なら、要件変更に強いアジャイルを選んでも、判断待ちで開発が止まります。その場合は、プロトタイプで要件を固めてからウォーターフォールで作るほうが、結果的に早く終わります。
手法で変わる見積もり・契約・検収の形
手法は、見積書の形と契約の組み方にも直結します。見積書を比べるときは、金額の前にこの対応を確認してください。
| 手法 | 見積もりの形 | 組みやすい契約 | 検収（成果の確認）の単位 |
|---|---|---|---|
| ウォーターフォール / V字 | 機能一覧と工数から総額を算出 | 要件定義は準委任、設計以降は請負が多い | 工程の成果物と、最後の受入テスト |
| アジャイル（スクラム） | 期間×チーム体制（月額）で算出 | 準委任（IPAのアジャイル版モデル契約も準委任が前提） | スプリントごとの報告・レビュー（完成責任ではなく業務遂行に対価） |
| スパイラル / プロトタイプ | 試作・検証フェーズと本開発を分けて算出 | 試作は準委任、本開発は内容が確定すれば請負も可 | フェーズごと |
| ハイブリッド | フェーズごとに分けて算出 | フェーズごとに契約を分ける（多段階契約） | フェーズごと＋最終の受入テスト |
ここで押さえておきたいのは、アジャイルでは「最初に総額を確定する」こと自体が手法の考え方と合わないという点です。IPAのアジャイル版モデル契約は、あらかじめ特定した成果物の完成に対して対価を払う請負ではなく、専門家として業務を遂行することに対価を払う準委任を前提にしています。発注側が予算を管理する手段は「総額の固定」ではなく、期間と体制の上限を決め、スプリントごとに優先順位で範囲を調整することになります。
アジャイルを外注するときの契約形態の詳細はアジャイル開発を外注するときの契約形態の選び方、見積書の内訳の読み方はシステム開発の見積もりの見方と算出方法を参照してください。
自社に合う手法を決める4つの判断軸
手法は「どれが優れているか」ではなく、案件の条件で決まります。次の4軸で自社の状況を確認してください。
| 判断軸 | ウォーターフォール寄り | アジャイル寄り | 中間（プロトタイプ・ハイブリッド） |
|---|---|---|---|
| ① 要件の確定度 | 業務も画面も決まっている | 作りながら決めたい | 業務は決まっているが画面・操作が曖昧 |
| ② 発注側が出せる関与 | 序盤と終盤なら時間を出せる | 判断役を期間中ずっと立てられる | 序盤に集中して時間を出せる |
| ③ 予算の決め方 | 稟議で総額の確定が必要 | 月額×期間の予算枠で動ける | 試作分だけ先に確保できる |
| ④ リリースの切り方 | 一括で切り替える必要がある | 小さく出して改善できる | 一部を先行リリースできる |
使い方は単純で、4軸のうち3つ以上が同じ列に入れば、その手法を第一候補にします。列がばらける場合は、ハイブリッドで「どこまでを反復、どこからを計画的に」の境界を決めるのが現実的です。
よくある組み合わせを3つ挙げます。
- 社内の業務システムを作り直したい・稟議で総額が必要：①は中間、②は序盤に集中、③は総額必須 → プロトタイプで要件を固めてからウォーターフォール
- 新規のWebサービスで、市場の反応を見ながら育てたい：①②④がアジャイル寄り → アジャイル（スクラム）＋準委任。予算は月額の上限で管理
- 法令対応で期限と仕様が決まっている：①③④がウォーターフォール寄り → ウォーターフォール（V字）。受入テストの観点を要件定義で合意
要件の確定度を上げる進め方は、要件定義の進め方（5ステップと成果物）で手順を解説しています。
自社の案件にどの手法が合うか、判断に迷ったら
シンシアでは、要件が固まっていない段階から、手法・契約形態・体制の組み合わせをご相談いただけます。見積もりの前に「どこまでが決まっていて、どこからが不確実か」を一緒に整理するところから始められます。
作る側から見た、手法選びの失敗パターン5つ
受託開発の現場で、手法が原因に見えるトラブルの多くは、実際には手法と契約・体制の組み合わせのズレから起きています。
- 固定価格の請負で「アジャイルで」と頼む。範囲も価格も固定なのに変更は自由、という状態は成り立ちません。結果として変更のたびに追加見積もりが発生し、アジャイルの利点が消えます。反復で進めたいなら、期間×体制で契約し、範囲を優先順位で調整する形に揃えます。
- プロダクトオーナーが不在のアジャイル。判断役が兼務で忙しく、スプリントレビューに出られない、優先順位が決まらない。開発側は待つか推測で進めるしかなく、手戻りが増えます。
- 要件が固まらないままウォーターフォールの設計に入る。「設計しながら決めればいい」で進めると、設計承認後の変更がすべて追加費用になります。決まっていない部分が大きいなら、先にプロトタイプで固めます。
- プロトタイプをそのまま本番に流用する。試作は確認のための作りで、性能・セキュリティ・保守性を前提にしていません。流用するなら、その前提で作り直す費用を最初から見積もりに入れておきます。
- ハイブリッドで境界を決めない。「前半は柔軟に、後半は固定で」と言いながら、どの時点で要件を確定し契約を切り替えるかを決めていないと、前半の変更がそのまま後半の固定価格に流れ込みます。フェーズの境界と、境界で確定する成果物を契約前に決めます。
開発会社への依頼で起きやすい問題全体は、システム開発の依頼で失敗しない注意点でまとめています。
生成AIの普及で、手法の選び方はどう変わるか
ここからは作る側としての見解です。生成AIを使った開発支援が広がり、画面の試作や小さな機能の実装にかかる時間は以前より短くなっています。その結果、プロトタイプで要件を確かめるコストが下がり、ウォーターフォールの前段に「動く試作で確認する」工程を入れやすくなりました。ハイブリッドの選択肢が、以前より現実的になっています。
一方で、変わらないこともあります。何を作るかを決める判断、検収の基準、契約上の責任の分け方は、生成AIでは短くなりません。むしろ実装が速くなるぶん、発注側の判断の遅れがボトルネックとして目立ちやすくなります。仕様を先に文章で固めてからAIと実装を進める考え方については、仕様駆動開発を作る側の目線で見た記事で詳しく書いています。
FAQ：システム開発の手法でよくある質問
システム開発の手法はいくつありますか？
分類の仕方によって数は変わりますが、発注の場面で押さえておけばよいのは、ウォーターフォール・V字モデル・アジャイル（スクラム）・スパイラル・プロトタイプ・ハイブリッドの6つです。DevOpsは開発と運用を一体で回す考え方で、手法というより運用まで含めた体制の話として扱われることが多いです。
ウォーターフォールとアジャイルの一番の違いは何ですか？
要件を「最初に確定する」か「作りながら決める」かです。そこから、見積もりの形（総額か、期間×体制か）、契約形態（請負が多いか、準委任が前提か）、発注側の関与（序盤と終盤か、期間中ずっとか）まで違いが広がります。
中小企業の業務システムにはどの手法が向いていますか？
稟議で総額の確定が必要で、専任のプロダクトオーナーを立てにくい場合が多いため、プロトタイプで画面と業務フローを固めてからウォーターフォールで作るハイブリッドが現実的なことが多いです。ただし、4つの判断軸で確認してから決めてください。
アジャイルで開発すると費用は安くなりますか？
安くなるとは限りません。アジャイルは「同じものを安く作る」手法ではなく、「価値の高い順に作り、不要なものを作らない」ことで無駄を減らす手法です。予算は月額×期間の上限で管理し、優先順位で範囲を調整します。
アジャイルで請負契約は結べますか？
不可能ではありませんが、範囲と価格を固定する請負は、作りながら範囲を変えるアジャイルとは相性がよくありません。IPAのアジャイル開発版モデル契約は準委任を前提にしています。なお、準委任でアジャイル開発を行う場合の偽装請負のリスクについて、IPAは厚生労働省が公開した疑義応答集を参考にするよう案内しています。
開発手法は途中で変えられますか？
変えられますが、手法を変えると見積もりの形と契約も変わるため、フェーズの区切りで切り替えるのが原則です。途中で変える可能性があるなら、最初から多段階契約（フェーズごとの契約）にしておくと切り替えやすくなります。
手法は発注側と開発会社のどちらが決めるものですか？
開発会社が提案し、発注側が合意して決めるのが一般的です。ただし、手法によって発注側の関与の量が大きく変わるため、「自社がどれだけ時間を出せるか」は発注側から先に伝えるべき情報です。
まとめ｜手法は「発注側が出せるもの」から逆算して選ぶ
システム開発の手法は、名前と特徴を覚えるだけでは選べません。手法を変えると、発注側の関与・見積もりの形・契約・検収の単位まで一緒に変わります。要件の確定度・発注側が出せる関与・予算の決め方・リリースの切り方の4軸で自社の状況を確かめ、手法と契約・体制の組み合わせを揃えることが、失敗を避ける近道です。
次に読むべき記事：
参考文献・出典
- Ken Schwaber & Jeff Sutherland「スクラムガイド（2020年11月版・日本語）」 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
- The Scrum Guide（英語版） https://scrumguides.org/scrum-guide.html
- IPA（情報処理推進機構）「情報システム・モデル取引・契約書（アジャイル開発版）」 https://www.ipa.go.jp/digital/model/agile20200331.html
- IPA「情報システム・モデル取引・契約書」 https://www.ipa.go.jp/digital/model/index.html
