[速習] システム開発契約 第2回 開発手法と契約の適合性 - ウォーターフォールとアジャイルの使い分け

第1回では、ソフトウェア開発における主要な契約形態について解説しました。労働者派遣契約、SES契約、請負契約、サブスクリプション契約それぞれの特徴と、なぜ同じ規模のプロジェクトでも契約形態によって見積もり金額が2倍以上変わるのかを説明しました。

第2回となる本記事では、開発手法と契約形態の適合性について深く掘り下げます。特に、なぜスタートアップやB2C向けサービス開発ではアジャイル開発が選ばれ、どのような契約形態と組み合わせるべきなのか、投資家との関係も含めて詳しく解説します。また、アジャイル契約における受入基準の設定方法（Definition of Done¹と契約条項のリンク）についても実践的な内容を提供します。

開発手法の本質的な違いを理解する

ウォーターフォールモデルの深層

ウォーターフォールモデルは、その名の通り「滝」のように上流から下流へと工程が流れていく開発手法です。この手法が日本の大企業や官公庁で今でも主流である理由は、その予測可能性と管理のしやすさにあります。

ウォーターフォール開発では、プロジェクトの最初に全体像を詳細に設計します。建築に例えるなら、まず完成図面を描き、基礎工事から始めて、構造を作り、内装を仕上げていくような流れです。各工程で作成される成果物（要件定義書、基本設計書、詳細設計書など）は、次の工程の入力となり、品質の担保と進捗の可視化を実現します。

図1: ウォーターフォール開発の工程と成果物

ウォーターフォールが特に適している領域は、要件が明確で変更が少ない基幹業務システムです。例えば、銀行の勘定系システム²では、法規制や業務ルールが明確に定まっており、これらを確実にシステムに実装することが求められます。このような場合、最初に全体設計を固めて、それを着実に実装していくウォーターフォールのアプローチが最適です。

また、ウォーターフォールでは各工程の完了時に成果物の検収を行うため、請負契約との相性が非常に良いのです。発注者は各工程の成果物を確認することで、プロジェクトが正しい方向に進んでいることを確認でき、受注者は段階的に責任を果たしていくことができます。

要点まとめ：ウォーターフォール開発

• 工程が直列的で予測可能性が高い
• 各工程で明確な成果物を作成
• 要件が明確な基幹システムに適している
• 請負契約との相性が良い

アジャイル開発の本質とスタートアップとの親和性

アジャイル開発は、2001年に発表された「アジャイルソフトウェア開発宣言」³に基づく開発手法の総称です。この宣言では、「包括的なドキュメントよりも動くソフトウェアを」「計画に従うことよりも変化への対応を」といった価値観が示されています。

アジャイル開発の最大の特徴は、短い期間（通常1-4週間）で動くソフトウェアを作り、それに対するフィードバックを受けて次の開発に活かすという反復的なプロセスです。これは特にスタートアップのような、市場のニーズが不確実で、素早い仮説検証が必要な環境において威力を発揮します。

図2: アジャイル開発の1スプリントサイクル

要点まとめ：アジャイル開発

• 短期間での反復的な開発
• 動くソフトウェアを重視
• 変化への柔軟な対応が可能
• スタートアップやB2C向けサービスに適している

なぜスタートアップはアジャイルを選ぶのか

スタートアップがアジャイル開発を選択する理由は、そのビジネスモデルと資金調達の仕組みに深く関わっています。スタートアップは限られた資金（ランウェイ）⁴の中で、投資家に対して事業の成長可能性を証明する必要があります。この「証明」のためには、実際に動くプロダクトとそれを使うユーザーの反応が不可欠です。

例えば、スマートフォンゲームの開発を考えてみましょう。最初から完璧なゲームを作ろうとすると、1年以上の開発期間と数億円の開発費が必要になるかもしれません。しかし、スタートアップにはそのような余裕はありません。代わりに、最小限の機能（MVP: Minimum Viable Product）⁵でまずリリースし、ユーザーの反応を見ながら改善していくアプローチを取ります。

投資家の視点から見ると、このアプローチには大きなメリットがあります。まず、少額の投資で市場の反応を確認できます。もしユーザーの反応が良ければ追加投資を行い、反応が悪ければ早期に撤退や方向転換（ピボット）⁶ができます。これは投資リスクを最小化する賢明な戦略です。

B2C向けサービスにおけるアジャイル開発の実践

スマートフォンゲーム開発の実例

スマートフォンゲーム開発は、アジャイル開発が最も成功している分野の一つです。その理由を、実際の開発プロセスを通じて説明しましょう。

あるスタートアップが新しいパズルゲームを開発するケースを考えます。従来のウォーターフォール的なアプローチでは、まず完全な企画書を作成し、全ステージを設計し、すべての機能を実装してからリリースすることになります。しかし、これでは市場に出るまでに1年以上かかり、その間に競合他社に先を越される可能性があります。

図3: スマートフォンゲームのアジャイル開発とKPI測定

このアプローチの利点は、わずか2ヶ月で市場の反応を確認できることです。もし継続率⁷が期待を下回れば、ゲームバランスの調整や新機能の追加を素早く行えます。実際のユーザーデータに基づいて改善するため、成功確率も高まります。

データドリブンな開発と投資家への価値証明

スタートアップが投資家に対して最も説得力を持つのは、実際のユーザーデータです。アジャイル開発では、各スプリントごとに新機能をリリースし、その効果を数値で測定します。

例えば、あるソーシャルゲームアプリでは、以下のような指標を毎週測定し、改善しています。

Daily Active Users (DAU)⁸：毎日アプリを使用するユーザー数。これは最も基本的な指標で、サービスの規模を示します。

継続率（Retention Rate）：新規ユーザーが翌日、7日後、30日後にもアプリを使い続ける割合。優れたアプリでは、Day1継続率が40%以上、Day7継続率が20%以上とされています。

Average Revenue Per User (ARPU)⁹：ユーザー1人あたりの平均収益。これは収益性を示す重要な指標です。

Lifetime Value (LTV)¹⁰：ユーザーが生涯にわたってもたらす収益の推定値。LTVが顧客獲得コスト（CAC）¹¹を上回ることが、ビジネスの持続可能性を示します。

これらの指標を改善するために、A/Bテスト¹²を頻繁に実施します。例えば、チュートリアルの改善により Day1継続率が5%向上すれば、それは将来の収益に大きな影響を与えます。このような具体的な改善を投資家に報告することで、追加投資を引き出すことができるのです。

開発手法と契約形態の最適な組み合わせ

ウォーターフォール開発と請負契約の相性

ウォーターフォール開発と請負契約の組み合わせは、日本のシステム開発において長年にわたって実績を積み重ねてきた「黄金の組み合わせ」と言えます。この組み合わせが優れている理由を詳しく見ていきましょう。

図4: ウォーターフォールと請負契約の適合性

ウォーターフォール開発では、プロジェクトの開始時点で最終的な成果物の姿が明確に定義されます。これは請負契約において「何を作るか」を明確にするという基本的な要件と完全に一致します。また、各工程で作成される設計書などの中間成果物も明確に定義できるため、段階的な検収も可能です。

実際の大規模プロジェクトでは、全体を一括請負するのではなく、工程ごとに分割して契約することも一般的です。例えば、要件定義フェーズは準委任契約で実施し、その成果を基に基本設計以降を請負契約で実施するという方法です。これにより、要件の不確実性によるリスクを軽減しつつ、実装フェーズでは確実な成果物の納品を保証できます。

要点まとめ：ウォーターフォール×請負契約

• 要件と成果物が明確に定義可能
• 段階的な検収による品質保証
• 固定価格での予算管理が可能
• 大規模・基幹システムに最適

アジャイル開発と準委任契約の親和性

アジャイル開発と準委任契約の組み合わせは、変化の激しい現代のソフトウェア開発において最適な選択肢です。この組み合わせの利点を具体的に説明します。

アジャイル開発の本質は「変化を歓迎する」ことです。スプリントごとにユーザーフィードバックを受けて、次の開発内容を決定していきます。これは、最初から成果物を固定する請負契約とは根本的に相容れません。一方、準委任契約では、専門的な技術力を提供することが契約の目的であり、具体的な成果物は固定されません。

図5: アジャイル開発における準委任契約の流れ

実際の契約では、3ヶ月や6ヶ月といった期間で基本契約を結び、2週間ごとのスプリントで作業報告と次スプリントの計画確認を行います。この方式により、発注者は必要に応じて開発の方向性を調整でき、不要になれば契約を終了することもできます。

スタートアップにとって、この柔軟性は非常に重要です。資金調達の状況や市場の反応に応じて、開発規模を拡大・縮小できるからです。例えば、シードラウンド¹³で調達した資金で最小限のチームで開発を始め、プロダクトマーケットフィット¹⁴が確認できたらシリーズA¹⁵の資金で開発チームを拡大する、といった戦略が可能になります。

要点まとめ：アジャイル×準委任契約

• 変化への柔軟な対応が可能
• スプリント単位での契約管理
• 開発規模の調整が容易
• スタートアップの成長に合わせた拡張性

危険な組み合わせ：アジャイル開発×請負契約の落とし穴

アジャイル開発を請負契約で実施しようとすることは、実務上最も避けるべき組み合わせです。なぜこの組み合わせが危険なのか、実際のトラブル事例を交えて説明します。

ある企業が、新しいECサイトをアジャイル開発で構築することを決定しました。発注側は「アジャイルなら早くて安い」という誤解があり、受注側も受注欲しさに請負契約を受けてしまいました。契約書には「アジャイル開発手法を用いてECサイトを構築する」とだけ記載され、具体的な機能要件は「開発中に決定する」とされていました。

プロジェクトが始まると、問題が次々と発生しました。発注者は「アジャイルなのだから、どんな要望も柔軟に対応してくれるはず」と考え、毎スプリントで大幅な機能追加を要求しました。一方、受注者は「請負契約なので、当初想定した範囲を超える要求には応じられない」と主張しました。

結果として、プロジェクトは泥沼化しました。最終的には裁判にまで発展し、「完成」の定義が曖昧だったため、双方が多大な損失を被ることになりました。

図6: アジャイル×請負契約の構造的問題

アジャイル契約における受入基準の実践的設定

Definition of Doneと契約条項のリンク

アジャイル開発において、「完成」の定義は非常に重要です。スクラムでは、これを「Definition of Done（DoD）」¹⁶と呼びます。準委任契約においても、各スプリントの成果物に対する受入基準を明確にすることで、品質を担保できます。

Definition of Doneの契約書への反映例：

第X条（スプリント成果物の定義）
1. 各スプリントにおける「完成」の定義は以下の通りとする：
   a) 機能要件：プロダクトバックログに記載された機能が動作すること
   b) コード品質：コードレビューが完了し、コーディング規約に準拠していること
   c) テスト：単体テストのカバレッジが80%以上であること
   d) ドキュメント：必要なAPIドキュメントが更新されていること
   e) デプロイ：ステージング環境で動作確認済みであること

2. 上記の基準を満たさない成果物は、次スプリントでの改修対象とする。

このようにDoDを契約に組み込むことで、アジャイル開発でも一定の品質基準を保証できます。

スタートアップの成長フェーズに応じた契約戦略

スタートアップは成長フェーズによって、資金状況も開発の目的も大きく変わります。それぞれのフェーズに応じて、最適な契約形態を選択することが重要です。

シード期：アイデアを形にする段階

シード期のスタートアップは、まだアイデア段階か、簡単なプロトタイプがある程度です。この段階での開発目的は、投資家に対してアイデアの実現可能性を示すこと、そして初期の仮説を検証することです。

この段階では、開発リソースも限られているため、フリーランスエンジニアや小規模な開発会社との準委任契約が一般的です。契約期間も1-3ヶ月と短く、月額固定の契約が多いです。例えば、フルスタックエンジニア¹⁷1名を月額100万円（税別）で契約し、3ヶ月でMVPを開発する、といったケースです。

重要なのは、この段階では完璧なプロダクトを作ることではなく、アイデアが技術的に実現可能であることを証明し、初期ユーザーからフィードバックを得ることです。そのため、柔軟に開発内容を変更できる準委任契約が最適です。

アーリー期：プロダクトマーケットフィットを探る段階

シードラウンドで数千万円の資金調達に成功したスタートアップは、本格的な開発フェーズに入ります。この段階での目標は、プロダクトマーケットフィット（PMF）を見つけることです。つまり、「人々が本当に欲しがるものを作る」ことです。

この段階では、3-5名程度の開発チームを組成することが一般的です。契約形態は引き続き準委任契約ですが、より構造化された形になります。例えば、スクラムチームとして、プロダクトオーナー、スクラムマスター、エンジニア3名という体制で、2週間スプリントを回していきます。

【アーリー期の典型的な開発体制】
- プロダクトオーナー（社内）：1名
- スクラムマスター（外部）：1名 × 120万円/月（税別）
- シニアエンジニア（外部）：1名 × 130万円/月（税別）  
- エンジニア（外部）：2名 × 100万円/月（税別）
- デザイナー（外部）：0.5名 × 90万円/月（税別）

月額合計：約590万円（税別）
6ヶ月契約：3,540万円（税別）

この体制により、2週間ごとに新機能をリリースし、ユーザーの反応を見ながら製品を改善していくことができます。PMFが見えてきたら、次の資金調達（シリーズA）に向けて、成長指標を改善していきます。

グロース期：スケールを目指す段階

シリーズAで数億円を調達したスタートアップは、いよいよ本格的な成長フェーズに入ります。この段階では、開発体制も大幅に拡大し、複数のチームが並行して開発を進めることになります。

興味深いことに、この段階になると、一部の機能については請負契約も選択肢に入ってきます。なぜなら、コア機能が固まり、追加する機能の仕様も明確になってくるからです。例えば、決済機能の追加、管理画面の開発、レポート機能の実装などは、要件を明確に定義して請負契約で外注することも可能です。

図7: グロース期における契約形態の使い分け

この段階での契約管理のポイントは、機能や領域によって最適な契約形態を使い分けることです。変化の激しいユーザー向け機能は準委任契約で柔軟性を保ち、バックエンド機能や管理機能など要件が明確な部分は請負契約でコストを抑える、といった戦略が有効です。

投資家視点での開発管理

スタートアップが投資家から継続的な支援を受けるためには、開発の進捗と成果を適切に報告することが不可欠です。アジャイル開発は、この点でも優れています。

投資家が最も重視するのは、以下の3つの要素です。

1. トラクション（勢い）の証明
トラクションとは、ビジネスが順調に成長していることを示す証拠です。ユーザー数の増加、エンゲージメントの向上、収益の成長などが含まれます。アジャイル開発では、2週間ごとに新機能をリリースできるため、常に新しい成長の証拠を提示できます。

2. 資金効率（バーンレート）
バーンレート¹⁸は、月々どれだけの資金を消費しているかを示す指標です。投資家は、限られた資金でどれだけの成果を出せるかを重視します。準委任契約では、必要に応じて開発規模を調整できるため、資金効率を最適化できます。

3. 学習と適応の速さ
スタートアップの成功は、いかに早く市場から学び、製品を改善できるかにかかっています。アジャイル開発のイテレーティブなアプローチは、この学習サイクルを最速化します。失敗も早期に発見でき、方向転換（ピボット）の判断も迅速に行えます。

実際の投資家向けレポートでは、以下のような情報を含めることが一般的です。

【月次投資家レポート例】
1. KPIサマリー
   - MAU：先月比 +23%（45,000 → 55,350）
   - 継続率：Day7が2ポイント改善（18% → 20%）
   - ARPU：320円（目標達成率 80%）

2. 開発進捗
   - 完了機能：プッシュ通知、友達招待機能
   - 進行中：課金システムの改善（完了度 60%）
   - 次スプリント：ソーシャル機能の追加

3. A/Bテスト結果
   - オンボーディング改善：継続率 +5%
   - 課金導線の最適化：CVR +0.3%

4. バーンレート
   - 今月：850万円（開発費 600万円、その他 250万円）
   - ランウェイ：14ヶ月

5. 次月の重点施策
   - LTV向上施策の実装
   - 海外展開の準備開始

契約形態の移行タイミング

スタートアップが成長するにつれて、契約形態も進化させていく必要があります。すべてを準委任契約で続けることは、ある段階から非効率になります。

準委任から請負への部分的移行

プロダクトが成熟してくると、コア機能の大きな変更は少なくなり、安定性や性能の向上が重要になってきます。この段階では、以下のような基準で一部の開発を請負契約に移行することを検討できます。

請負契約への移行を検討すべき機能：

• 6ヶ月以上大きな変更がない機能
• 仕様が業界標準に従っている機能（決済、認証など）
• パフォーマンス改善やリファクタリング作業
• 管理画面やレポート機能など内部向け機能

一方で、以下の部分は準委任契約を維持すべきです。

• ユーザー体験に直接関わる機能
• A/Bテストを頻繁に行う機能
• 競合優位性の源泉となる機能
• 新規事業や実験的な機能

ハイブリッド型の契約管理

成熟したスタートアップでは、複数の契約形態を組み合わせたハイブリッド型の開発体制が一般的です。例えば、ある成功したゲーム会社では以下のような体制を取っています。

図8: 成熟期におけるハイブリッド契約体制

このような体制により、それぞれの領域で最適な契約形態を選択し、全体として最も効率的な開発を実現しています。

まとめ

第2回では、開発手法と契約形態の適合性について詳しく解説しました。ウォーターフォール開発は予測可能性が高く、請負契約との相性が良いため、大企業の基幹システムなど要件が明確なプロジェクトに適しています。一方、アジャイル開発は変化への対応力が高く、準委任契約と組み合わせることで、スタートアップやB2C向けサービスの開発に最適です。

しかし、ここで重要な点を付け加えなければなりません。アジャイル開発が真に効果を発揮するためには、マネージャーやチームメンバー全員が高いスキルレベルを持つエンジニアである必要があります。

攻殻機動隊の荒巻課長の名言「我々の間には、チームプレーなどという都合のよい言い訳は存在せん。有るとすればスタンドプレーから生じる、チームワークだけだ。」は、まさにアジャイル開発の本質を突いています。各メンバーが自律的に判断し、高いレベルで行動できるからこそ、結果として素晴らしいチームワークが生まれるのです。これは、詳細な設計書と役割分担に基づくウォーターフォール開発とは対照的なアプローチです。

特にスタートアップにおいては、限られた資金と時間の中で投資家に価値を証明する必要があるため、アジャイル開発による素早い仮説検証が不可欠です。2週間ごとに新機能をリリースし、実際のユーザーデータに基づいて改善を続けることで、プロダクトマーケットフィットを見つけ、事業を成長させることができます。ただし、これを実現するには、技術的な判断を即座に下せる優秀なエンジニアチームが不可欠であることを忘れてはいけません。

また、アジャイル開発においても、Definition of Doneを契約条項に反映させることで、品質を担保できることを示しました。これにより、柔軟性と品質の両立が可能になります。

重要なのは、プロジェクトの性質と目的に応じて、適切な開発手法と契約形態を選択することです。そして、選択した開発手法に適したチーム編成を行うことも同様に重要です。アジャイルを選択するなら、「スタンドプレーから生じるチームワーク」を実現できる精鋭チームを組成する必要があります。事業の成長に応じて、契約形態も柔軟に進化させていく必要があります。画一的なアプローチではなく、状況に応じた最適な選択が、プロジェクトの成功につながります。

1. Definition of Done（DoD）：スクラムにおいて、プロダクトバックログアイテムが「完成」したと見なされるための基準。品質を担保するための重要な合意事項。 ↩

2. 勘定系システム：銀行の預金、為替、融資などの基幹業務を処理するシステム。24時間365日の安定稼働が求められ、わずかなバグも許されない。 ↩

3. アジャイルソフトウェア開発宣言：2001年に17名のソフトウェア開発者によって作成された宣言。「個人と対話」「動くソフトウェア」「顧客との協調」「変化への対応」を重視する。 ↩

4. ランウェイ：スタートアップが現在の資金で事業を継続できる期間。通常は月次のバーンレートで資金を割って計算する。例：資金1億円÷月間支出1,000万円＝10ヶ月のランウェイ。 ↩

5. MVP (Minimum Viable Product)：実用最小限の製品。ユーザーに価値を提供できる最小限の機能を持った製品で、仮説検証のために使用される。 ↩

6. ピボット：スタートアップが当初の事業計画から方向転換すること。市場の反応を見て、より成功可能性の高い方向へ舵を切る戦略的な判断。 ↩

7. 継続率：新規ユーザーが一定期間後もサービスを利用し続ける割合。Day1（翌日）、Day7（7日後）、Day30（30日後）で測定することが一般的。 ↩

8. DAU (Daily Active Users)：1日あたりのアクティブユーザー数。サービスの規模と健全性を示す最も基本的な指標。MAU（月間）、WAU（週間）もある。 ↩

9. ARPU (Average Revenue Per User)：ユーザー1人あたりの平均収益。総収益÷アクティブユーザー数で計算。サービスの収益性を示す。 ↩

10. LTV (Lifetime Value)：顧客生涯価値。1人のユーザーがサービスを利用する全期間で生み出す収益の推定値。LTV > CACが事業成立の条件。 ↩

11. CAC (Customer Acquisition Cost)：顧客獲得コスト。新規ユーザーを1人獲得するのにかかる平均コスト。マーケティング費用÷新規ユーザー数で計算。 ↩

12. A/Bテスト：2つ以上のバージョンを同時に試して、どちらがより良い結果を生むかを統計的に検証する手法。UIの改善や機能の最適化に使用。 ↩

13. シードラウンド：スタートアップの最初期の資金調達ラウンド。通常は数百万円から数千万円規模で、プロダクト開発と初期の仮説検証に使用。 ↩

14. プロダクトマーケットフィット（PMF）：製品が市場のニーズに合致している状態。ユーザーが製品を積極的に使い、他者に推奨する状態を指す。 ↩

15. シリーズA：スタートアップの本格的な成長段階での資金調達。通常は数億円規模で、PMF達成後の事業拡大に使用される。 ↩

16. Definition of Done（DoD）：スクラムにおいて、プロダクトバックログアイテムが「完成」したと見なされるための基準。チーム全体で合意し、品質を担保する。 ↩

17. フルスタックエンジニア：フロントエンド、バックエンド、インフラまで幅広く対応できるエンジニア。スタートアップの初期には特に重宝される。 ↩

18. バーンレート：スタートアップが月々に消費する資金額。ランウェイの計算に使用される重要な経営指標。 ↩