アジャイルとウォーターフォールの違い。発注者は責任で選ぶ

見積書には「アジャイル開発」と書かれ、別の会社の提案書には「ウォーターフォール」と書かれています。開発に詳しくない発注者には、毎週画面が出る会社と、数か月後に完成品が出る会社の違いに見えます。

「アジャイル ウォーターフォール 違い」と検索した発注者が選ぶべき基準は、速度ではありません。仕様をいつ決めるか、途中変更の費用を誰が負うか、開発中の優先順位を誰が決めるかです。

僕なら、利用者の反応を見なければ必要な機能が分からない案件にはアジャイルを選びます。法令対応日や移行対象が決まり、完成条件を着手前に書ける案件にはウォーターフォールを選びます。ただし、アジャイルを選ぶなら、発注者も開発中の判断から降りられません。

アジャイルとウォーターフォールの違いは、決める時期にあります

ウォーターフォールでは、要件定義、設計、実装、テスト、移行と工程を進める形が一般的です。発注者は着手前の要件定義に時間を使い、完成物と検収条件を先に合意します。開発会社は合意した範囲を作り、変更が出た場合は影響を見積もります。

アジャイルでは、優先度の高い機能を小さく作り、動く画面や利用者の反応を見て次の範囲を選びます。発注者は最初から全仕様を当てる負担を減らせます。一方で、開発中に何を作り、何を見送るかを決め続けます。

発注者の負担が消える手法はありません。ウォーターフォールは早い段階で決める負担を引き受け、アジャイルは判断を繰り返す負担を引き受けます。

2001年のアジャイルソフトウェア開発宣言は、契約交渉より顧客との協調を、計画への追従より変化への対応を重視しています。同宣言は契約や計画を不要とは述べていません。開発手法の比較試験でも、成功率や開発速度を示す統計でもないため、発注者が契約後も開発会社と協働する姿勢を示した価値宣言として読みます。

ウォーターフォールでも途中確認や段階公開はできます。アジャイルでも予算上限や公開日は置けます。名前だけで二択にせず、仕様、費用、期限のうち、案件の途中で動かせる項目を決める必要があります。

ウォーターフォールでは着手前に仕様と検収条件を詰めます

既存システムの置き換えで、対象業務とデータ移行日が決まっている場合を考えます。給与計算の締め日、会計へ渡す項目、保存する履歴、利用者の役割を着手前に確認できるなら、工程ごとに合意を積み上げる進め方が合います。

ウォーターフォールを選ぶ発注者は、要件定義へ現場担当者を出し、例外処理と受入条件を早い段階で決めます。「今のシステムと同じ」では足りません。廃止する画面、移すデータの期間、連携失敗時の戻し方、利用者が確認するテストまで文章にします。

開発会社の品質確認と発注側の受入判断を分ける手順は、システム開発のテスト工程で確認できます。工程モデルを選ぶ前に、誰がどのテスト結果を見て合否を決めるかまで置きます。

契約書では、工程ごとの成果物、確認期限、検収方法、修正の扱い、仕様変更の申請方法を読みます。発注者が資料や確認結果を渡す期限も必要です。開発会社だけに納期責任を置き、発注者の回答期限を空欄にすると、承認待ちの影響を両社で判断できません。

見積もりを比較するときは、アプリ開発の費用を公開後まで比べる場合と同じく、実装以外の作業も開きます。要件定義、データ整理、利用者による受入確認、公開作業、操作説明、保守開始日が各社の金額に含まれるかを確認します。

弱点は、最初の合意が外れた際の変更が大きくなりやすい点です。要件定義で見落とした利用場面が受入確認で見つかれば、設計や実装まで戻る場合があります。利用者へ見せるまで必要性を判断できない新規サービスでは、着手前に仕様を固めた安心感が、変更をためる原因にもなります。

アジャイルでは開発中も優先順位を決め続けます

新規サービスでは、利用者が登録画面で離脱するのか、検索結果を理解できないのか、公開前には読めない場面があります。アジャイルは、優先度の高い範囲を動かし、確認結果から次の開発内容を変える案件に向いています。

変更を歓迎する姿勢は、機能を無制限に追加できる約束ではありません。新しい機能を上へ置くなら、優先度の低い機能を後ろへ送ります。予算と期限を保つ場合は範囲を動かし、範囲を保つ場合は費用か期限への影響を合意します。

発注側には、事業上の優先順位を決められる人が必要です。開発会社から選択肢が出た際に、売上、顧客対応、法令、運用負荷を見て順番を決めます。現場利用者へ画面を見せる時間、検証用データ、決定内容を残す場所も用意します。

IPAが2020年に公開し、2025年4月8日に更新した情報システム・モデル取引・契約書（アジャイル開発版）は、発注側と開発会社が緊密に協働する前提を示しています。対象はスクラムを採用した外部委託で、個別案件の成功率を測った調査ではありません。全種類のアジャイル開発へ当てはまる契約書でもないため、役割分担を話す土台として使います。

同モデル契約は準委任を前提にしていますが、アジャイルなら必ず準委任、ウォーターフォールなら必ず請負と機械的には決まりません。民法632条、643条、656条は請負、委任、準委任の原則を定めていますが、実際の責任は業務内容、契約条項、運用で変わります。契約名だけで法的な結論を出さず、締結前に弁護士などの専門家へ確認してください。

アジャイルを名乗る開発会社は、三つの場面で見分けます

一つ目は、「アジャイルなので仕様書は作りません」と言われる場面です。変化へ対応するためにも、現在の優先順位、受入条件、設計上の理由、未解決の課題は残す必要があります。議事録も判断記録もなく、担当者の記憶だけで進む開発は、担当交代や契約終了に耐えられません。

二つ目は、発注側の決定者が会議に出ない場面です。現場担当者が毎回持ち帰り、次の開発範囲が決まらなければ、短い周期で画面を見せても判断は進みません。開発会社が事業上の優先順位まで代わりに決める状態は、協働ではなく丸投げです。

三つ目は、範囲、予算、公開日をすべて固定したまま、途中変更だけを自由に求める場面です。追加した機能の代わりに何を外すかを決めなければ、テスト時間、費用、公開日のどこかへ影響が出ます。「柔軟に対応します」という営業文句ではなく、変更時に動かす項目を契約書へ書きます。

候補会社には、直前の開発周期で完成した画面だけでなく、見送った機能と理由も説明してもらいます。優先順位を変えた記録、未完了項目の扱い、契約終了時に渡す設計資料とソースコードも確認します。肩書きより先に危険なサインを見るCTO代行の選び方と同じく、成功画面より、失敗と中止を説明できる会社を選びます。

アジャイルの会議名を並べる会社より、発注者が決める内容と回答期限を提案書へ書く会社を信頼します。反対に、ウォーターフォールを提案する会社でも、変更申請の費用と判断日を説明できるなら、発注後の認識差を減らせます。

アジャイルとウォーターフォールは、未決事項の残り方で選びます

二つの手法で迷ったら、機能一覧の横に「公開日まで固定」「利用者の反応で変更可能」「調査しないと不明」の三列を作ります。固定項目が多く、検収条件まで書ける案件はウォーターフォールへ寄せます。不明な項目が多く、小さく公開でき、発注側の決定者が開発中も参加できる案件はアジャイルへ寄せます。

一つの案件を同じ手法で統一する必要もありません。法令で固定される帳票とデータ移行は先に仕様を決め、顧客向け画面は利用状況を見ながら変える進め方も選べます。ただし、固定部分と変更部分の接続条件、責任者、受入方法は分けて書きます。「ハイブリッド」という名前だけでは、境界の認識差を防げません。

最後に、発注側が開発へ使える時間を書きます。利用者への確認、優先順位の決定、成果物の確認を継続できないなら、アジャイルを選んでも開発会社は判断材料を得られません。反対に、着手前の業務整理へ時間を出せないままウォーターフォールを選ぶと、曖昧な要件が固定見積もりへ入ります。開発が遅いときに三つの時間へ分ける方法を使うと、発注側の回答待ちも含めて確認できます。

明日は、候補会社の提案書と自社の機能一覧を同じ画面で開いてください。固定、変更可能、不明の三列を埋め、誰がいつ答えるかを各行へ追記します。候補会社には、三列を前提に契約範囲、変更方法、会議参加者を書き直してもらいます。

選ぶべき手法は、流行している名前ではありません。自社が着手前に決め切れる範囲と、開発中に決め続けられる範囲を見れば、発注者が負える進め方を選べます。