多段階契約とは？要件定義・設計・開発で契約を分ける方法とメリット

多段階契約とは？要件定義・設計・開発で契約を分ける方法とメリット

「開発契約を結んだ後に、費用が1.5倍に膨らんだ」——その原因、契約の形にあります

「ベンダーからシステム開発の見積もりを取って、一括契約を結んだ。ところが開発途中で『要件が固まっていないので追加費用が必要』と言われた」「要件定義の段階で曖昧さを残したまま、開発契約にハンコを押してしまった」——システム発注で起きる典型的な失敗パターンです。

• 見積もり時点で要件が固まりきっていないのに、総額契約で締結
• 要件変更が追加費用・納期遅延に直結
• ベンダーは「範囲外」、発注側は「当然含まれる」で押し問答が続く
• 解約しようにも、前払い金の返金をめぐって紛争
• 検収基準も曖昧で、品質トラブルが発生

こうした問題の多くは、「要件定義から運用開始までを1本の契約で締結する」という発注スタイルに起因しています。ITに不慣れな中小企業や建築・設計事務所などでは、ベンダー提示の一括契約書にそのままサインしてしまうケースが少なくありません。

ここで知っておきたいのが「多段階契約」という考え方です。プロジェクトをフェーズごとに分割し、フェーズごとに個別契約を結ぶという発注方法で、近年のシステム開発では主流になりつつあります。

「一括契約のほうが楽で安心」——その誤解が紛争を生みます

多くの発注担当者は、「契約は1本で結んだほうが、手続きが楽で、責任の所在も明確」と考えます。これは一見合理的ですが、IT発注の実態には合っていないのが実情です。

「一括契約にしたら、ベンダー任せで進捗が見えず、気づいたら予算を大幅超過していた」

「要件が決まっていないのに総額見積もりを出させたら、安全マージンが乗って高額になってしまった」

「途中で仕様変更を依頼したら、『契約外です』と突き返され、関係が険悪になった」

システム開発は、建築工事のように仕様書が完全に確定した状態で着工するのが難しい性質を持ちます。要件を詰めていく過程で、新しい発見や変更が必ず発生するため、最初から全工程を確定する一括契約は、構造的に無理があるのです。

一方、多段階契約にすると「各フェーズの完了時点で、次の発注判断ができる」というコントロールが発注側に戻ります。フェーズが進むごとに仕様の解像度が上がり、次フェーズの見積もり精度も向上します。発注側・ベンダー双方のリスクが均等に分散される点が最大のメリットです。

経済産業省が公表しているモデル取引・契約書でも、多段階契約が推奨されており、大手ベンダーでは標準的な発注スタイルとなっています。

多段階契約の考え方と実務を、発注側目線で整理します

本記事では、以下の流れで解説します。

• 多段階契約の基本構造と、フェーズの区切り方
• 一括契約と比較したメリット・デメリット
• 各フェーズの契約形態（請負/準委任）の選び方
• 契約書で押さえるべき実務ポイント
• 発注側が注意すべき落とし穴

契約の形を変えるだけで、プロジェクトの成功確率が格段に上がるというのが多段階契約の要点です。

多段階契約の全体像

多段階契約の具体的な組み方

1. フェーズの区切り方｜基本は5〜6段階

システム開発の多段階契約は、以下のフェーズで区切るのが一般的です。

ここでポイントなのは、**要件定義と基本設計は「準委任契約」、開発フェーズは「請負契約」**が基本形になる、という点です。

要件定義・基本設計の段階では、成果物の仕様が確定していないため、完成責任を負わせるのが実質的に不可能です。無理に請負契約にすると、ベンダーが安全マージンを大きく乗せてくるか、要件を先回りで固定してプロジェクトの柔軟性を奪うか、どちらかになります。

一方、詳細設計〜開発〜テストの段階は、仕様が確定しているため請負契約で完成義務を課すのが合理的です。

2. 一括契約 vs 多段階契約｜メリット・デメリット比較

両者を整理すると、多段階契約のメリット・デメリットは以下のようになります。

多段階契約のメリット

• 各フェーズで中断・方針変更が可能（サンクコストを抑えられる）
• 見積もり精度が段階的に向上（前フェーズの成果物を踏まえて見積もり）
• 要件の変更がフェーズ間で自然に吸収される
• リスクが発注側・ベンダーで適切に分散
• 成果物の検収基準が段階的に精緻化される

多段階契約のデメリット

• 契約手続きがフェーズごとに発生（事務工数増）
• ベンダーを途中で変えにくい（業務ノウハウの引き継ぎコスト）
• 総額が事前に確定しない（予算管理上の不確実性）
• 発注側にもマネジメントの工数が必要

デメリットの多くは、契約書のテンプレート整備と社内ワークフローで軽減できます。特に中規模以上の発注では、メリットがデメリットを大きく上回るのが通例です。

3. 各フェーズの契約書で押さえる論点

フェーズごとに、契約書で注意すべき論点が異なります。

要件定義フェーズ（準委任）

• 業務ヒアリング対象の部署・時間数
• 要件定義書のフォーマットと記載レベル
• 発注側・ベンダー双方の合意プロセス
• 途中解除時の精算ルール

基本設計〜開発フェーズ（請負）

• スコープの詳細な書面化（何が含まれ、何が範囲外か）
• マイルストーンごとの成果物定義
• 検収基準の定量化（機能数・処理性能・バグ許容率）
• 契約不適合責任（2020年民法改正対応）の期間と範囲
• 中間成果物の著作権の取扱い

導入・運用フェーズ（準委任）

• 障害対応のSLA（応答時間・復旧目標）
• 運用期間と更新条件
• 解約時の引継ぎ期間

4. 発注側が注意すべき、5つの落とし穴

多段階契約にも、運用上の落とし穴があります。

落とし穴1｜各フェーズの完了判定を曖昧にしたまま次に進む

要件定義の完了判定を曖昧にすると、開発段階で「要件が不明確」と揉めることになります。各フェーズの完了判定は、書面とサインで明確化してください。

落とし穴2｜フェーズ間の情報引継ぎを怠る

要件定義を担当したベンダーと開発担当ベンダーが異なる場合、引継ぎ不備で手戻りが発生します。引継ぎプロセスを契約書に組み込みましょう。

落とし穴3｜総予算の枠を超える見積もりにずるずる対応する

多段階契約は「各フェーズで見直せる」のがメリットですが、総予算の上限を意識せず進めると、最終的に一括契約以上にコストが膨らむこともあります。プロジェクト全体の予算枠を事前に合意しておきましょう。

落とし穴4｜準委任契約で「成果物責任がない」を誤解する

準委任だから「何でも許される」ではありません。善管注意義務により、プロとしての標準的な遂行義務はあります。進捗報告・メンバーアサインの品質などを契約書で明記することが重要です。

落とし穴5｜発注側のマネジメント工数を甘く見積もる

多段階契約は、発注側のプロジェクトマネジメントが弱いと機能しません。各フェーズで意思決定・合意形成・検収判断が発生します。マネジメント人材の確保が前提となります。

多段階契約の進行ステップ

こんな方にこの多段階契約の考え方が役立ちます

• これから初めてシステム開発を発注する中小企業の経営者
• 過去のIT発注で費用・納期のトラブルを経験した担当者
• 建築・設計事務所や中小工務店で、IT発注を任されて困っている総務担当者
• 社内システムを刷新する際、契約リスクを低減したい情シス責任者
• 外部パートナーとの長期的な関係を築きたい経営企画・IT企画担当者

多段階契約は、契約事務の工数がやや増える一方で、プロジェクト全体のリスクを大きく下げる手法です。特にIT発注に不慣れな会社ほど、メリットが大きくなります。

ベンダー提示の一括契約書にそのまま押印するのではなく、「フェーズを分けて契約しませんか」と提案する——このひと言で、発注側の立場は大きく変わります。優良ベンダーであれば、多段階契約への切り替えに前向きに応じてくれるはずです。

まとめ

多段階契約で安心のプロジェクト推進

多段階契約の要点を整理します。

• フェーズ分割：要件定義・基本設計・詳細設計・開発・テスト・運用の5〜6段階
• 契約形態の使い分け：上流は準委任、開発フェーズは請負
• 見積もり精度の段階的向上：前フェーズの成果物を踏まえて次を発注
• 各フェーズでの完了判定：書面とサインで明確化
• 発注側のマネジメント：プロジェクトコントロール人材の確保が前提

システム開発の契約形態を変えるだけで、プロジェクトの成功確率・費用の予測性・リスクコントロールのすべてが向上します。一括契約の構造的な無理に悩まされてきた中小企業こそ、多段階契約への切り替えを検討する価値があります。

建築・設計事務所や中小工務店のIT発注支援はアトリエ・バイナリ（atelier binary）で承っており、契約書レビューから多段階契約の組み立て、ベンダー交渉、フェーズ管理までを伴走しています。「ベンダー提示の契約書にサインすべきか判断がつかない」「多段階契約を提案したいが、どう交渉すればいいか分からない」といった段階でも、早めに相談いただければリスクを最小化できるケースが多いです。

まずは、現在検討中のシステム開発案件について、「フェーズをどう区切れるか」「各フェーズで準委任/請負のどちらを使うべきか」を紙に書き出してみましょう。その整理だけで、ベンダーとの交渉の質が大きく変わります。