アジャイルとウォーターフォール｜受託で揉めないハイブリッド契約の型

ITシステム開発において、長年議論されてきた「ウォーターフォールか、アジャイルか」という二者択一。しかし、近年の複雑化したビジネス環境では、そのどちらか一方だけでプロジェクトを完遂させることは困難です。特に受託開発の現場では、発注側は「予算を確定させたい（請負）」と考え、開発側は「要件変更に柔軟に対応したい（準委任）」と考え、契約の段階で折り合いがつかないケースが多発しています。

本記事では、IT実務者の視点から、両者のメリットを組み合わせた「ハイブリッド契約」の具体的な型と、法的・実務的な注意点を徹底的に解説します。開発現場の混乱を未然に防ぎ、スムーズなDX推進を実現するための完全ガイドです。

アジャイルとウォーターフォールの対立を解消する「ハイブリッド契約」の必要性

これまで多くの受託開発では、ウォーターフォールモデルに基づく「請負契約」が一般的でした。しかし、このモデルには現代のスピード感に合わない致命的な欠陥が露呈し始めています。

なぜ従来のウォーターフォール（請負）だけでは失敗するのか

ウォーターフォール最大の弱点は、「最初に決めた要件が正しい」という前提に立っていることです。数ヶ月、時には年単位のプロジェクトにおいて、市場環境の変化やユーザーニーズの変容を予測しきることは不可能です。請負契約では、要件定義書に記載されていない機能追加はすべて「追加費用」となり、その都度見積もりと契約変更が必要になります。この「変更への心理的・事務的ハードル」が、結果として役に立たないシステムを生む原因となります。

アジャイル（準委任）への移行を阻む「予算」と「責任」の壁

一方で、アジャイル開発（準委任契約）を導入しようとすると、企業の購買部門や財務部門から強い抵抗にあうことが一般的です。その理由は主に以下の2点です。

• 予算の不確定性：完成を保証しない契約に対して、いくら支払うことになるのか上限が見えない。
• 瑕疵担保（契約不適合責任）の不在：準委任契約では、善良なる管理者の注意義務（善管注意義務）は負うものの、完成物に対する不具合修正義務が請負ほど明確ではありません。

この溝を埋めるのが、工程や機能ごとに契約形態を使い分ける「ハイブリッド契約」という考え方です。

【徹底比較】請負契約・準委任契約・アジャイル・ウォーターフォールの違い

実務において、どの契約を選択すべきかを判断するための比較表を以下にまとめました。法的な性質と開発手法の特性を正しく理解することが、トラブル回避の第一歩です。

契約の性質を理解せずにアジャイル開発を進めると、発注側は「お金を払っているのに完成しない」と不満を持ち、受注側は「言われた通りに動いているのに検収されない」と疲弊します。こうした事態を防ぐため、業務の性質を見極める必要があります。

例えば、既存の会計ソフトからSaaSへ移行するような「ゴールが明確な」プロジェクトでは、基本機能をウォーターフォールで固めるのが正解です。詳細は以下のガイドが参考になります。

【完全版】勘定奉行からfreee会計への移行ガイド：機能・費用比較とデータ移行手順の実務

受託開発で揉めないための「ハイブリッド契約」3つの型

実務で導入しやすいハイブリッド契約には、主に3つのパターンがあります。プロジェクトの性質や予算の柔軟性に合わせて選択してください。

【型1】フェーズ分割型（上流：請負 ＋ 下流：準委任）

要件定義や基本設計までの「作るものを決める工程」を請負契約で行い、実際の開発・テスト工程をアジャイル（準委任）で進める手法です。上流工程でスコープの概算を出すため、予算の目安が立てやすいメリットがあります。

【型2】ベース＋オプション型（コア機能：請負 ＋ 追加機能：準委任）

システムとして最低限必要な「MVP（Minimum Viable Product）」を請負で確実に作り、リリース後の機能拡張やユーザー要望への対応を準委任で回す型です。最もリスクが低く、多くのDXプロジェクトで推奨される形態です。

【型3】期間・予算上限付き準委任（キャップ制アジャイル）

基本は準委任契約ですが、「最大予算（キャップ）」と「最低限達成すべきマイルストーン」を契約書に明記します。予算を超えそうになった場合、機能の優先順位を下げてスコープを削ることで、予算超過を防ぎます。これは、Google WorkspaceやAppSheetを活用したスモールスタートのDXとも相性が良い手法です。

Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

実務で使える「ハイブリッド契約」の条項策定ステップ

契約書を作成・確認する際、単に「準委任」とするだけでは不十分です。以下のステップで実務的な取り決めを盛り込みましょう。

ステップ1：RFP（提案依頼書）での役割分担の明確化

ハイブリッド契約において、発注側の「関与」は不可欠です。アジャイル工程が含まれる場合、発注側のプロダクトオーナーが週に何時間ミーティングに参加するか、バックログの優先順位決定権は誰にあるかをRFPの段階で定義します。これを怠ると、後に「丸投げしたのに動かない」というトラブルに発展します。

ステップ2：準委任工程における「善管注意義務」の具体化

準委任契約では「完成」の定義がないため、何を以て「適切に業務を遂行した」とみなすかが争点となります。

• 使用するプロジェクト管理ツール（Jira, Backlogなど）にチケットを起票すること。
• コードレビューのプロセスを定義すること。
• 週次の進捗報告レポートを提出すること。

これらを義務として明記することで、開発品質を担保します。

ステップ3：バックログ管理ツールの選定と権限設定

ハイブリッド型では、請負範囲と準委任範囲が混在します。これらを一つのツールで管理し、ステータスを可視化することが重要です。この際、外部パートナーにどこまでの権限を与えるか、セキュリティ設計も同時に行います。特にSaaSを多用する開発現場では、アカウント管理の不備が重大なリスクとなります。

退職者やプロジェクト離脱者のアカウントが残っている状態は、情報の漏洩だけでなく不正アクセスの温床となります。自動化による対策は以下の記事が詳しいです。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

ステップ4：不具合修正（保守）の責任境界線の定義

「請負で作った機能」にバグが出たのか、「準委任で追加・変更した箇所」に起因してバグが出たのか。この切り分けは非常に困難です。実務的には、瑕疵担保期間（契約不適合責任期間）を短めに設定し、それ以降は保守契約（準委任）へ一本化するなどの設計が現実的です。

ハイブリッド開発を支えるITインフラと管理ツール

契約という「紙」の約束を形骸化させないためには、日々の運用ツールが重要です。

Jira/Asanaを用いた「検収」に代わる進捗定義

アジャイル的な要素が入る場合、従来の「納品書・検収書」による一括検収は馴染みません。代わりに、スプリント（通常1〜2週間）ごとのデモ実施と、ツール上での「Done（完了）」定義を合意の証跡とします。これにより、プロジェクト終盤で「思っていたものと違う」と言われるリスクを最小化できます。

ID管理とセキュリティ：退職者や外部パートナーの権限削除

ハイブリッド契約では、複数のベンダーやフリーランスが関与することも珍しくありません。開発環境（AWS/GCP/Azure）や、GitHub、コミュニケーションツールへのアクセス管理は、もはや手動では限界があります。Entra ID（旧Azure AD）やOktaを用いたシングルサインオン（SSO）の導入を、プロジェクト開始の条件に含めるべきです。

まとめ：変化に強い開発体制を契約から構築する

アジャイルとウォーターフォールの対立は、手法の優劣ではなく「リスクをどちらが、どのタイミングで負うか」という契約の設計ミスから生じることがほとんどです。

全ての要件を最初から決め打ちする「請負」の安心感と、状況に合わせて進化し続ける「アジャイル」の柔軟性。この両取りを目指すハイブリッド契約こそが、現代のシステム開発における「勝てる型」です。まずは、コア機能の範囲を明確にし、小さな単位での準委任から始めてみてはいかがでしょうか。

執筆にあたっての参照元：

独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・代金等算定の在り方に関する調査」および「アジャイル開発版 情報システム・モデル取引・代金等算定の在り方」に基づき、実務的な解釈を加えています。