開発会社から「アジャイルで進めたい」「準委任契約をベースに」と提案を受けたものの、社内決裁は「総額いくら・いつ完成」を確定する前提のため、提案をそのまま受け入れていいか判断できない。アジャイルとウォーターフォールの違いや選び方を調べても、概念の比較記事ばかりで自社プロジェクトに当てはめにくい。そんな発注者の方は少なくありません。
多くの比較記事は「定義の違い」「メリット・デメリット」を並列で並べるにとどまり、自社でどちらを選べば社内決裁を通しつつ失敗しないかには直接答えてくれません。発注者が本当に欲しいのは、契約形態の違い、追加費用が発生する条件、社内のリソース投入量といった、稟議書に直接書ける情報のはずです。
本記事では概念の網羅的解説は最小限に抑え、稟議書直結の4観点での違い、4軸マトリクスでの自社プロジェクト診断、アジャイル選択時の関与時間・費用、ウォーターフォール選択時のメリット・デメリットと事前準備、ハイブリッド手法までを発注者の意思決定に直結する観点で整理します。読み終えた時点で、自社プロジェクトに合う手法の根拠を持ち、社内稟議の説明資料を組み立てられる状態を目指します。アジャイル開発の概念をより深く知りたい方は、アジャイル開発とはを別記事で先にご確認ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
稟議書を通すために押さえる4つの違い：契約・費用・確認頻度・関与コスト
両手法の概念や歴史については多くの記事が解説しています。本記事では網羅的解説を割愛し、発注者が稟議書を書くために必要な4観点—(1)契約形態、(2)費用変動、(3)成果物の確認頻度、(4)発注者の関与コスト—に絞ります。
観点 | ウォーターフォール開発 | アジャイル開発 |
|---|---|---|
契約形態 | 請負契約（成果物完成義務） | 準委任契約（業務遂行義務） |
費用変動 | 総額固定。仕様変更で追加見積 | 期間×人月単価。スコープ調整で吸収 |
成果物の確認頻度 | 工程末・受入時に集中 | スプリント（1〜4週）ごとに継続 |
発注者の関与コスト | 要件定義時に集中 | 全期間で継続的に必要 |
観点1：契約形態の違い（請負契約 vs 準委任契約）
ウォーターフォールでは請負契約が一般的で、開発会社が完成義務を負うため発注者から見たリスクは低くなります。アジャイルでは準委任契約が一般的で、開発会社は業務遂行に責任を負いますが特定成果物の完成義務までは負わず、代わりに発注者が期間中の優先順位判断を担います。請負契約に慣れた発注者は、この役割の違いを稟議書に明示してください。
観点2：費用変動の起こり方の違い（総額固定 vs 期間ベース）
請負契約では契約時に総額が確定する一方、要件定義後の仕様変更は追加見積となります。一般的な目安として、規模次第で当初見積の20〜50%が上乗せされるケースもあります。準委任契約では「人月単価×期間」で費用が決まり、期間延長が決まれば追加費用が発生します。稟議書には「最大期間」と「延長条件」を必ず明記してください。
観点3：成果物の確認頻度の違い（一括検収 vs スプリントごと）
ウォーターフォールでは動作するソフトウェアの確認が受入テスト時に集中するため、認識ズレが発覚すると手戻りコストが大きくなります。アジャイルでは1〜4週間のスプリントごとに動くソフトウェアをレビューするため、確認機会は多い一方で判断の手間も継続的に発生します。
観点4：発注者の関与コストの違い（要件定義時集中 vs 全期間継続）
ウォーターフォールでは関与負荷が要件定義に集中し、設計・実装中は週0〜2時間に収まるケースもあります。アジャイルでは関与が全期間にわたり継続し、決裁者・現場側双方で時間を確保し続ける必要があります。具体的な時間目安は次々セクションで詳述します。
両手法のより網羅的な比較を求める方は、ウォーターフォール・アジャイルの詳しい比較もあわせてご覧ください。
自社プロジェクトに合うのはどちら？4軸マトリクスでの判断基準
ここからが本記事の核です。自社に合う手法を選ぶには、開発会社の都合や流行ではなくプロジェクト自体の特性を客観的に評価する必要があります。本セクションでは「要件確定度」「納期固定度」「変更頻度」「リスク許容度」の4軸を高／中／低で評価し、ウォーターフォール寄りとアジャイル寄りの軸数を比較する判断ツールを示します。開発手法 比較の参考材料として、自社プロジェクトに照らしてご覧ください。
軸1：要件確定度（仕様変更が起きる確率）
着手時点で機能要件・画面仕様・データ構造をどこまで確定できるかを評価します。基幹系の更改や法令対応のように仕様が動きにくい場合は「高」でウォーターフォール寄り、新規SaaSやユーザー検証を伴う場合は「低」でアジャイル寄りに振れます。
評価 | 判定の目安 |
|---|---|
高 | 仕様が法令・既存業務で確定。変更余地が少ない |
中 | 主要機能は固まるが、UI・運用の細部に変動余地あり |
低 | 市場検証や利用者反応で仕様が決まる。事前確定が困難 |
軸2：納期固定度（リリース日を動かせるか）
法令対応・取引先のシステム連携・展示会など外部要因で日付が動かせない場合は「高」と評価します。納期固定度が高い場合、スコープを変動させて納期を守れるアジャイルが向く場合と、総額・納期を厳格に確定できるウォーターフォールが向く場合の両方があり、軸1の仕様変動と組み合わせて判断します。
軸3：変更頻度（リリース後の改善サイクル）
リリース後の改善頻度を評価します。年1〜2回のリリースで運用するプロジェクトはウォーターフォール寄り、毎月〜毎週単位で改善を回すプロジェクトはアジャイル寄りに振れます。継続的な開発体制を維持する場合、契約形態と運用体制も含めて検討してください。
軸4：リスク許容度（コンプライアンス・障害許容度）
金融・医療・行政など障害時の影響が極めて大きい領域は、各工程で品質ゲートを設けるウォーターフォールが適合します。一方、社内業務改善ツールや初期検証の新規サービスなど影響を限定できる領域はアジャイルが適合します。リスク許容度が低い領域でアジャイルを採用する場合は、品質保証プロセスを別途設計してください。
4軸マトリクスの読み方とプロジェクト診断例
4軸を評価し、ウォーターフォール寄りとアジャイル寄りの軸数を集計します。3軸以上が一方に寄れば、その手法を主軸とします。同数なら次セクションのハイブリッドを検討してください。
プロジェクト例 | 要件確定度 | 納期固定度 | 変更頻度 | リスク許容度 | 推奨手法 |
|---|---|---|---|---|---|
基幹システム再構築 | 高 | 高 | 低 | 低 | ウォーターフォール |
新規SaaSのMVP開発 | 低 | 中 | 高 | 中〜高 | アジャイル |
社内業務改善ツール | 中 | 低 | 中 | 高 | アジャイル（小規模） |
基幹システム再構築は要件・納期・リスクのすべてがウォーターフォール寄りで、請負契約での総額固定が現実的です。新規SaaSのMVPはスコープ調整しつつ走るアジャイルが向きます。社内業務改善ツールは規模が小さいため軽量なスプリント運用にとどめる選択も可能です。
アジャイルを選ぶ場合に発注者が負担する時間と関与レベル
アジャイルが向くと判断できても、自社で本当に回せるかの見通しを立てなければ稟議書は書けません。本セクションでは、1スプリント（2週間想定）あたりの負担時間と意思決定タスクを役割別に数値化します。アジャイル開発 発注者として最低限確保すべきリソース感の参考にしてください。
1スプリント（2週間）あたりの会議参加時間の目安
会議 | 頻度 | 1回あたり | 発注者の参加目安 |
|---|---|---|---|
スプリント計画 | スプリント開始時 | 1〜2時間 | 必須（PO） |
デイリースクラム | 毎日 | 15分 | 任意（週1〜2回） |
スプリントレビュー | スプリント終了時 | 1時間 | 必須（決裁者・受入確認者推奨） |
バックログ整理 | 適宜 | 1〜2時間 | 必須（PO） |
合計するとプロダクトオーナー（PO：要件の優先順位を決める発注者側の代表者）役で2週間あたり概ね5〜8時間、決裁者・受入確認者で2〜3時間が現実的な目安です。非定例レビュー・優先順位調整も加わるため、稟議書には「POで週3〜4時間、決裁者で週1〜2時間」と余裕を持って記載することを推奨します。スクラムのプロセスやイベント設計は、スクラム開発のプロセス詳細もあわせてご覧ください。スクラム ウォーターフォール 選択の比較でも、スクラムのイベント設計の理解が判断軸を明確にします。
プロダクトオーナーに求められる意思決定の頻度と内容
POが意思決定するのは主に次の3つです。
- バックログ（やるべき作業の一覧）の優先順位付け
- スプリントごとの目標とスコープの確定
- 完成したインクリメント（成果物）の受入可否判断
POが不在、または兼務で時間を取れない場合、開発チームは判断待ちで手が止まります。「PO役を誰が担うか」「決裁ラインをどこまで委譲するか」を契約前に明確化し、稟議書に体制図として記載してください。
受入確認・優先順位調整の社内調整コスト
スプリントレビューでのフィードバックを次スプリントに反映するには、社内関係部署の意見集約が必要です。複数部署が絡む場合、レビュー後1〜2日でまとめる必要があり、調整がボトルネックになりがちです。軽減策は、(a)利用部門代表をスプリントレビューに同席、(b)フィードバック収集ルートの事前決定、(c)POのその場での最終判断権限の付与、のいずれかです。
準委任契約の費用構造と「追加費用」の典型パターン
準委任契約の費用は概ね「人月単価×開発要員数×期間」で計算されます。例えば人月単価120万円のエンジニア3名で6か月稼働する場合、概ね2,160万円が想定範囲です。追加費用が発生する典型パターンは次の3つです。
- スコープ追加による期間延長（PO判断で機能を増やし想定期間で完了しない）
- 開発要員の増員（想定外の課題対応・スケジュール圧縮）
- 想定外の技術的負債対応（既存システム連携の調整等）
稟議書には「想定期間内」の概算と「最大期間（例：想定+30%）」の上限金額をセットで記載してください。
ウォーターフォール開発のメリット・デメリットと、発注者が事前に固めるべき要件
「ウォーターフォールなら楽」というのは誤解です。本セクションではウォーターフォール開発 メリット デメリットを発注者視点で整理した上で、要件定義書・受入基準を発注者側で事前に固める必要性を共有します。これを甘く見ると、後工程で膨大な仕様変更コストが発生します。
ウォーターフォール開発のメリット・デメリットを発注者視点で整理
メリットは、(1)契約時に総額・納期を確定でき稟議書が書きやすい、(2)工程ごとに成果物が定義され進捗が可視化しやすい、(3)請負契約のため発注者の管理工数が比較的少ない、の3点です。中堅企業の社内決裁文化との相性も良く、現実的な選択肢になります。
デメリットは、(1)要件定義後の仕様変更コストが大きい、(2)動くソフトウェアの確認が受入時に集中し認識ズレが発覚しにくい、(3)市場や利用者の声をリリース前に反映しにくい、の3点です。要件が固まりにくい新規サービスでは、これらが失敗リスクになります。
要件定義書で具体化すべき項目
ウォーターフォールで失敗を避けるには、要件定義書で次の3領域を漏れなく具体化してください。
- 機能要件：画面・帳票・処理・データ項目・権限の定義
- 非機能要件：性能（応答時間・同時利用数）・可用性・セキュリティ・運用時間
- 運用要件：監視・バックアップ・障害対応・保守体制・移行手順
特に非機能・運用要件は発注者側で言語化されないまま開発会社に丸投げされがちで、受入時の手戻り原因になります。RFP段階で社内の運用部門・情報セキュリティ部門にレビューを依頼してください。
受入基準（受入テスト）の決め方
受入基準は、発注者が「この条件を満たせば検収する」と宣言できる客観的なチェック項目の集合です。次の3レイヤーで定義してください。
- 機能テスト：要件定義書の各機能が仕様通り動作するか
- 業務シナリオテスト：実際の業務フローに沿った操作が完了できるか
- 非機能テスト：性能・セキュリティ・可用性が要件を満たすか
各レイヤーで合格条件（例：応答時間3秒以内、同時利用100名で安定稼働）を定量的に定義し、契約書または別紙として合意してください。受入基準が曖昧だと検収判断が双方の主観に依存し、トラブル原因になります。
仕様変更時の追加見積プロセスと、失敗しやすい発注者の典型パターン
請負契約では契約時の要件範囲を超える変更は原則として追加見積の対象です。失敗しやすい典型パターンは次の3つで、いずれも「ウォーターフォール＝楽」という誤解から生まれます。
- 要件定義をSIerに丸投げし、社内ヒアリングが浅いまま設計に進む
- 受入基準を曖昧にしたまま契約し、検収時に主観で「使えない」と差し戻す
- 「ちょっとした変更」を口頭で依頼し、追加見積プロセスを回避しようとする
発注者が事前準備に十分な時間を確保することが、結果的に総コスト・総期間を抑えます。
ハイブリッド手法という選択肢：現実的な分割パターン
二択で迷う場合、工程やモジュールで両手法を使い分ける選択肢もあります。本セクションでは現実的な分割パターン2つと、注意点・向かないケースを整理します。
工程別ハイブリッド（要件・受入はウォーターフォール／実装はアジャイル）
要件定義と受入テストはウォーターフォール的に固め、実装フェーズだけアジャイルで進めるパターンです。社内決裁では「総額・納期・受入基準」を確定でき稟議書を書きやすい一方、実装段階の不整合は柔軟に調整できます。契約形態は、要件定義・受入支援は請負、実装は準委任と区分するケースが多くなります。
モジュール別ハイブリッド（フロントエンドはアジャイル／バックエンドはウォーターフォール）
機能領域で分割するパターンです。データベース・認証基盤・既存システム連携などの基盤層はウォーターフォール、ユーザーが直接触れるフロントエンドや業務アプリ層はアジャイルで進めます。基盤の安定性が重要かつフロントエンドで継続的に改善を回したいプロダクトと相性が良くなります。一方で、双方のチーム間連携が密に必要なため、進捗管理・インターフェース設計を担うリーダー役が必要です。
ハイブリッド採用時の注意点と向かないケース
採用時は、(1)契約形態を工程・モジュール別に区分し請負部分と準委任部分を契約書に明記、(2)成果物管理表を1つに統合、(3)双方のチームが同じバックログ・同じ受入基準を参照できるよう運用ルールを揃える、の3点が必要です。向かないのは、(a)規模が小さく分割するメリットがない、(b)開発会社内に両手法経験を持つチームがいない、(c)発注者側に両方を運用する管理リソースが確保できない、ケースです。これらに該当する場合は単一手法の方が安全です。
まとめ
稟議書に必要な4観点で違いを整理し、4軸マトリクスで自社プロジェクトを診断した上で、アジャイル選択時の関与時間・費用、ウォーターフォール選択時の事前準備、必要ならハイブリッドを組み合わせて判断することが、社内決裁を通すための最短ルートです。本記事の判断軸を稟議書の付属資料として整理し、開発会社との交渉でも対等に議論できる状態を作りましょう。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
