「今回のシステム開発は、見積の段階と最終請求で金額が大きく変わらないようにしたい」。経営会議でそう指摘され、契約形態の見直しを検討し始めた発注担当者は少なくありません。過去に一括発注で追加費用が膨らみ、経営陣への説明に苦労した経験があると、次のプロジェクトでは何らかのリスク低減策を組み込みたいと考えるのが自然です。
そうした状況で選択肢に上がるのが「多段階契約（フェーズ分割発注）」です。要件定義・設計・開発といった工程ごとに個別の契約を締結する方式で、独立行政法人情報処理推進機構（IPA）が公表する「情報システム・モデル取引・契約書（第二版）」でも推奨されています。しかし、多段階契約に踏み切ろうとすると社内から「事務作業が増えて回らない」「かえって費用が読めなくなるのでは」といった反論が出やすく、ベンダーからも「工程ごとに契約を切ると受注機会が途切れて困る」と敬遠されがちです。
そこで本記事では、多段階契約と一括発注を7項目で比較したうえで、自社プロジェクトに多段階契約を採用すべきかを判断する4つの軸、工程の切り方の実装パターン、社内稟議とベンダー交渉を通すための実務ステップまでを、発注者の意思決定を支援する視点で解説します。「メリット・デメリットを俯瞰する」ためではなく「今回のプロジェクトで多段階契約を採用するかを決め、社内とベンダーを動かす」ための一枚岩の情報として活用してください。
システム開発における個別契約書の雛形
この資料でわかること
システム開発を依頼する際にシステム開発会社と締結する個別契約書の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのような個別契約を結ぶのか興味がある
- システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
- システム開発を発注する側にどのような義務が生ずるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
システム開発の多段階契約とは？定義と背景を整理
まずは多段階契約の定義と、なぜ推奨されるようになったのかという背景を最小限で整理します。細かい法律論には深入りせず、発注者が意思決定するために必要な範囲に絞ります。
多段階契約の基本的な定義
多段階契約とは、システム開発の各工程（要件定義・外部設計・内部設計・開発・テスト・運用など）ごとに個別の契約を締結していく発注方式です。工程ごとに契約書を分けて締結するため、前工程の成果物を確認したうえで次工程の契約に進むかどうかを都度判断できます。これに対して一括発注（一括契約）は、企画フェーズで確定した要件をもとに、全工程を1本の契約で締結する方式です。
多段階契約では、各工程の性質に応じて契約類型（請負契約または準委任契約）を使い分けるのが実務上の一般解です。要件がまだ確定していない要件定義工程は準委任、成果物の定義が明確な開発・テスト工程は請負、というように工程ごとに最適な契約類型を選べる点が、一括発注にはない特徴です。
フェーズ分割発注・段階契約との呼称の違い
「多段階契約」「フェーズ分割発注」「段階契約」「分割契約」など、実務では複数の呼称が並行して使われています。細かなニュアンスの差はあるものの、いずれも「工程ごとに個別契約を締結する」という点で概ね同じ発注方式を指しており、社内稟議やベンダー交渉の場では相互に置き換えて理解して差し支えありません。
ただし、社内文書やRFPに記載する際は用語を1つに固定しておくと、法務部門・調達部門・ベンダーとの認識齟齬を防げます。以降、本記事では「多段階契約」に統一して表記します。
なぜ多段階契約が推奨されるようになったのか
多段階契約の考え方が公的な指針として整理された初出は、経済産業省が2007年4月に公表した「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第一版＞」に遡ります（経済産業省 情報システム・モデル取引・契約書＜第一版＞）。同第一版は、重要インフラ・企業基幹システムの受託開発を主な想定範囲として、企画から保守運用までを工程ごとに個別契約で締結する方式（多段階契約・マルチベンダー方式）を規定した点が特徴でした。
その後、2020年12月にIPAが公表した「情報システム・モデル取引・契約書（第二版）」は、2020年施行の改正民法への対応と、セキュリティ仕様策定プロセスの追加を主な目的として第一版を更新したもので、多段階契約の枠組み自体は第一版から引き継がれています（IPA 情報システム・モデル取引・契約書（第二版））。ユーザ企業とITベンダーの双方にメリットが偏らない中立的な契約書作成の指針として、工程ごとに個別契約を締結する方式を前提に整理されている点は、第一版・第二版に共通する特徴です。
背景には、一括発注方式で「開発の下流工程で要件の曖昧さが発覚し、追加費用の請求や紛争に発展する」ケースが繰り返し発生してきた経緯があります。要件確定度が低い時点で全工程を1本の契約に押し込むと、その後の要件変更や解釈相違のリスクをすべて契約書の内側で吸収せざるを得ず、発注者・ベンダーのどちらか一方が過大な負担を抱える構造になりやすいという問題意識が、モデル契約書の背景にあります。
一括発注（一括契約）との違いを7項目で比較
多段階契約と一括発注の違いを、発注者の意思決定に直結する7項目で比較します。「どちらが優れているか」ではなく「自社プロジェクトのどの項目が重要か」を識別するための表として活用してください。
比較項目 | 多段階契約 | 一括発注（一括契約） |
|---|---|---|
契約構造 | 工程ごとに個別契約（3〜7本程度） | 全工程を1本の契約 |
見積根拠 | 工程ごとに前工程の成果物をもとに再見積 | 企画フェーズで確定要件をもとに一括見積 |
費用確定度 | 各工程の直前まで確定しない（工程単位では確定） | 契約時点で総額が確定（ただし変更は追加見積） |
工程間の変更柔軟性 | 高い（次工程契約の締結前なら方針変更が容易） | 低い（変更は追加見積・契約変更の対象） |
事務負荷 | 大きい（契約締結・稟議・検収を工程回数分実施） | 小さい（1回で完結） |
支払タイミング | 工程完了ごとに支払（分割払いに近い） | 契約時・中間・納品時など契約書で規定 |
リスク分担 | 工程単位でリスクを遮断（下流の遡及紛争が起きにくい） | 発注者・ベンダーどちらかに集中しやすい |
契約構造の違い
多段階契約では、要件定義工程で1本、外部設計工程で1本、というように工程数ぶんの契約書を締結します。契約数が増える分、法務部門・調達部門の稟議回数も比例して増えるため、事務負荷は無視できない論点です。
一方の一括発注は契約書が1本で済むため、社内の契約実務は最小化されます。契約締結後は工程進行のたびに新規契約を締結する必要がなく、意思決定は最初の1回に集中します。
費用確定度と見積根拠の違い
一括発注は契約時点で総額が確定するため、予算確保と経営報告のしやすさに優位性があります。ただし、契約時点で確定しているのは「契約書に記載された要件を満たすシステム」の金額であり、要件変更が発生すれば追加見積の対象となります。過去に「一括発注で追加費用が膨らんだ」経験がある場合、その多くは要件変更に伴う追加見積が原因です。追加費用の発生パターンと防止策の実務論点は、追加費用の発生を避ける発注実務 で詳しく解説しています。
多段階契約では、各工程の契約時点で「その工程分の費用」だけが確定します。前工程の成果物（要件定義書・外部設計書など）が明確になった段階で次工程の再見積を行うため、見積の精度が工程を追うごとに上がっていきます。総額の予見性は下がる代わりに、各工程の見積精度は高くなるという構造です。
事務負荷・意思決定回数の違い
多段階契約は、工程ごとに「見積依頼→稟議→契約締結→検収→次工程発注」というサイクルを繰り返します。3分割型なら3回、工程ごと分割型なら7回前後この稼働が発生する計算になり、社内稟議で「事務作業が増えて回らない」と反対されやすいのはこのためです。
対策としては、稟議承認プロセスを工程分割に対応した簡易フローに再設計する、法務部門と契約書ひな型を事前に合意しておく、といった準備が必要になります。この論点は本記事「社内稟議とベンダー交渉を通すための実務ステップ」で詳しく扱います。
多段階契約のメリット・デメリットを実務観点で整理
比較表で全体像を掴んだうえで、多段階契約を発注者視点で採用したときのメリット・デメリットを、社内稟議で問われる論点に沿って整理します。
発注者にとってのメリット
1. 見積精度の向上
要件定義書・設計書といった前工程の成果物を根拠に次工程の見積を作成できるため、契約時点での見積精度が高くなります。企画フェーズの粗い要件で全工程の総額を見積もる一括発注に比べ、各工程の見積は「実際に確定した要件」に対応するため、契約後の追加見積が発生しにくい構造です。
2. 工程ごとのリスク遮断
次工程の契約を締結する前に、前工程の成果物を検収し、当初の想定と乖離があれば方針を修正できます。要件定義工程で「当初想定より業務要件が複雑だった」と判明した場合、設計工程の契約は再見積・スケジュール見直しを行ったうえで締結するため、リスクが下流工程に伝播する前にコントロールできます。
3. 要件変更への柔軟性
工程間の切れ目で仕様変更を反映しやすいため、企画時点で要件を完全に固めきれないプロジェクトでも進行できます。特にDX案件や新規事業システムなど、開発中に業務要件そのものが変化する可能性があるプロジェクトでは、工程ごとの再見積という仕組みが要件変更を吸収する余地を生みます。
4. 請負・準委任の使い分けが可能
工程ごとに契約類型を選べる点も実務上の大きなメリットです。要件がまだ流動的な要件定義・企画工程は準委任契約で「作業した工数」に対して報酬を支払い、成果物定義が明確な開発・テスト工程は請負契約で「成果物の完成」を対価とする、といった使い分けが可能です（Sun* 請負・準委任契約の違い解説）。IPAのアジャイル開発版モデル契約書も、この使い分けを前提に準委任契約を軸に整理されています。
発注者にとってのデメリット
1. 事務負荷の増加
前述のとおり、工程数ぶんの契約締結・稟議・検収が発生します。社内の契約実務リソースが逼迫している状況では、この事務負荷が現実的なボトルネックになります。
2. 費用累増リスク
各工程で再見積を行うため、当初の想定総額よりも累積費用が膨らむ可能性があります。特に要件定義工程で「想定より要件が複雑」と判明した場合、後続工程の再見積で費用が積み上がる展開になりやすい構造です。ただし、一括発注でも要件変更による追加見積は発生するため、多段階契約特有のリスクというよりは「費用超過が可視化されやすい構造」と捉えるのが実態に近いといえます。
3. 工程間のベンダー交代リスク
多段階契約は各工程で契約を独立して締結するため、理論上は工程ごとに異なるベンダーに発注することも可能です。しかし、要件定義工程を担当したベンダーと開発工程を担当するベンダーが異なると、要件の意図の引き継ぎコストが発生し、成果物の品質にも影響が及ぶ懸念があります。ベンダー交代を前提にしないのであれば、事前に「同一ベンダーへの継続発注を前提とするが、成果物次第で継続判断する」旨をベンダー側と合意しておく必要があります。
4. 契約継続の不確実性（ベンダー側視点の裏返し）
工程完了時点で次工程の契約を締結しない権利が発注者にあるということは、ベンダー側からは「途中で契約が打ち切られるリスクがある」ように見えます。この非対称性が、後述する「ベンダーが多段階契約を敬遠しがち」な理由の根本にあります。
ベンダー側の視点：なぜベンダーは多段階契約を敬遠しがちか
発注者にとって合理的な多段階契約が、ベンダー側からは必ずしも歓迎されないのはなぜでしょうか。理由は主に3つあります。
第1に、受注機会の連続性が担保されないため、要員計画（アサインするエンジニアの手配・スケジュール確保）が立てにくくなります。一括発注であればプロジェクト期間全体の要員を最初にアサインできますが、多段階契約では次工程の契約が締結されるまで要員の確定的な手配が難しいのが実態です。
第2に、工程完了時に検収不合格や次工程契約の見送りが発生した場合の売上機会損失が大きいことです。事業計画上、想定していた売上が確定しないリスクを抱えることになります。
第3に、契約締結・見積作成の事務作業がベンダー側にも工程数ぶん発生することです。営業・法務コストが増えるため、価格の面でこれを上乗せする形になる（工程ごと見積の合計が一括見積を上回る）ケースもあります。
これらの懸念を交渉で解消する具体的な方法は、本記事「社内稟議とベンダー交渉を通すための実務ステップ」で扱います。
一括発注のメリット・デメリットを実務観点で整理
一括発注は多段階契約の対比として語られがちですが、状況によっては一括発注のほうが合理的な選択になります。「多段階契約が絶対に正しい」わけではなく、判断基準を持って選ぶことが重要です。
発注者にとってのメリット
1. 費用予見性の高さ
契約時点で総額が確定するため、経営報告・予算策定・稟議での説明のしやすさは一括発注の最大の強みです。「システム開発費として○○円を計上する」という明確な数字を示せるため、経営陣・経理部門との調整コストが最小化されます。
2. 事務効率
契約書は1本、稟議も1回、検収基準も契約書内で一元管理されます。社内の契約実務リソースが限られている場合、この事務効率は無視できない優位性です。
3. 単一責任の明確化
全工程を1本の契約で発注するため、成果物の責任所在が単一のベンダーに明確化されます。工程間の責任分界（要件定義の不備なのか、設計の不備なのか、開発の不備なのか）で紛争になりにくく、成果物に問題があれば発注元は同一ベンダーに補修を求められます。
発注者にとってのデメリット
1. 見積バッファの発生
企画フェーズの粗い要件で全工程の総額を見積もるため、ベンダー側は不確実性に備えたバッファを見積に上乗せする傾向があります。バッファの分だけ総額が実態より膨らみやすく、結果として「多段階契約の累積総額と一括発注の総額がほぼ同じ」というケースも実務では珍しくありません。
2. 要件変更の困難さ
契約締結後に要件変更が発生した場合、変更内容が契約書の範囲内かどうかの解釈で争いが発生しやすく、範囲外と判断されれば追加見積の対象となります。要件が固まりきっていない段階で一括発注すると、後続工程で要件変更が続発し、追加見積の交渉に時間を取られる展開になりがちです。
3. 下流工程の遡及紛争リスク
開発工程やテスト工程で「要件定義の記述が曖昧だった」「設計に不備があった」と判明した場合、遡って要件定義・設計工程の責任を問う紛争に発展しやすい構造があります。IPAがモデル契約書で工程分割を推奨する背景には、この遡及紛争の頻発への問題意識があります。
システム開発における個別契約書の雛形
この資料でわかること
システム開発を依頼する際にシステム開発会社と締結する個別契約書の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのような個別契約を結ぶのか興味がある
- システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
- システム開発を発注する側にどのような義務が生ずるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
多段階契約と一括発注、どちらを選ぶべきか判断基準
ここまでの比較を踏まえ、自社プロジェクトにどちらを採用すべきかを判断するための4つの軸を提示します。競合記事の多くは「大規模なら多段階」「予算重視なら一括」といった抽象論で終わりがちですが、本セクションでは4軸で自社プロジェクトを評価したうえで、判断チャートに落とし込みます。
判断軸1: プロジェクト規模と期間
開発費用と開発期間はもっとも直感的な判断軸です。目安として以下のように整理できます。
- 開発費用 3,000万円未満・開発期間 6ヶ月未満: 一括発注が現実的。事務負荷に見合うリスク低減効果が得られにくい
- 開発費用 3,000万〜1億円・開発期間 6〜12ヶ月: どちらも成立。他の軸で判断
- 開発費用 1億円超・開発期間 12ヶ月超: 多段階契約が有力。要件変更の可能性・下流工程紛争のリスクが規模に比例して増大するため
規模が大きいプロジェクトほど「1回の意思決定ミスが後で挽回不能な損失につながる」ため、工程ごとの検収・方針修正の機会を持てる多段階契約の価値が相対的に高くなります。
判断軸2: 要件確定度
企画段階で要件がどの程度確定しているかも重要な軸です。
- 要件がほぼ確定している（既存システム刷新・パッケージ導入等）: 一括発注が適する。要件が動かないため多段階契約の柔軟性メリットを享受しにくい
- 要件が部分的に確定している（一般的な基幹システム更新）: 多段階契約が適する。要件定義工程で確定させたうえで設計以降を進める分割型が現実的
- 要件が流動的（新規事業システム・DXプロジェクト等）: 多段階契約が必須。一括発注では契約範囲の解釈で紛争が発生する可能性が高い
「要件が固まっているかどうか」の自己評価は難しいですが、企画書に「業務フローが完成しているか」「対象データ項目が洗い出されているか」を確認することで、要件確定度をおおよそ把握できます。
判断軸3: 社内の契約実務リソース
多段階契約の事務負荷を吸収できる社内体制があるかどうかも実務上の重要な判断軸です。
- 法務部門・調達部門に余力がある: 多段階契約の事務負荷を吸収可能
- 法務部門・調達部門が兼務体制: 契約締結のたびに待ち時間が発生し、工程間の切れ目でスケジュール遅延が積み上がる懸念。事前に契約書ひな型を合意しておく等の準備が必須
- 法務・調達専任者がいない: 一括発注の事務効率を優先せざるを得ないケースが多い。ただし外部の弁護士活用で補完する選択肢もある
判断軸4: ベンダーの多段階契約対応経験
同じ多段階契約でも、対応経験のあるベンダーとそうでないベンダーでは、実行できる契約設計の質が大きく変わります。
- 多段階契約の実績が豊富なベンダー: 工程分割・契約書ひな型・見積の刻み方まで実務が確立しており、発注者側の負担も相対的に軽い
- 多段階契約の実績が少ないベンダー: 契約書作成・見積の刻み方に工数がかかり、進行中に混乱が生じるリスク。事前にベンダーの経験値を確認することが重要
- 多段階契約に消極的なベンダー: 一括発注前提の見積スタイルから抜け出せず、多段階契約に見せかけた「実態は一括発注」になりやすい。RFP段階で意思確認が必要
判断チャート（4軸の組み合わせ）
上記4軸を組み合わせて、選択方針を整理すると以下のようになります。
プロジェクト特性 | 推奨される契約形態 | 補足 |
|---|---|---|
小規模・要件確定・社内リソース少 | 一括発注 | 事務効率を優先。追加費用の発生を避ける発注実務で補完 |
中規模・要件部分確定・社内リソース中 | 多段階契約（3分割型） | もっとも標準的な組み合わせ |
大規模・要件流動・社内リソース有 | 多段階契約（工程ごと分割型） | 全工程で個別契約。IPAモデル契約書に忠実 |
中規模・要件流動・ベンダー未熟 | 多段階契約（2分割型） | まず要件定義を切り出し、設計以降を再判断 |
大規模・要件確定・社内リソース少 | 一括発注 or 2分割型 | 要件が固まっているなら事務効率を優先しても紛争リスクは限定的 |
自社プロジェクトが上記のどのパターンに近いかを判定することで、方針の初期案を持てます。次のセクションで、具体的な工程の切り方（分割パターン）を詳しく見ていきましょう。
多段階契約におけるフェーズ分割の実装パターン
「多段階契約を採用する」と決めた後の実務論点は「工程をどう切るか」です。IPAのモデル契約書は工程ごとに契約を分ける方式を基本としつつ、実務では以下3つの分割パターンがよく採用されます。
パターンA: 2分割型（要件定義／設計以降）
- 契約数: 2本
- 切り方: 要件定義工程で1本、外部設計以降を1本
- 事務負荷の目安: 一括発注の1.5〜2倍程度
- 適するプロジェクト: 要件確定度が中程度の中規模プロジェクト。要件定義のリスクだけを切り出したい場合
もっとも軽量な多段階契約です。要件定義工程を独立させることで「要件がどこまで複雑か」を確定させたうえで、設計以降の見積を精度高く行えます。事務負荷が最小限に収まるため、多段階契約の初回導入時にもよく選ばれます。
パターンB: 3分割型（要件定義／設計／開発以降）
- 契約数: 3本
- 切り方: 要件定義・外部設計・内部設計以降の3工程で分割
- 事務負荷の目安: 一括発注の2〜3倍程度
- 適するプロジェクト: 中規模〜大規模プロジェクトの標準構成
もっとも汎用的な分割パターンです。要件定義と外部設計をそれぞれ独立契約とし、内部設計以降を1本にまとめる構成が一般的です。要件定義・設計の各工程で成果物を検収してから次工程に進めるため、下流工程での手戻りリスクを大きく低減できます。
パターンC: 工程ごと分割型（IPA モデル契約書相当）
- 契約数: 5〜7本
- 切り方: 企画・要件定義・外部設計・内部設計・開発・結合テスト・総合テスト・運用の各工程ごとに独立契約
- 事務負荷の目安: 一括発注の4〜6倍程度
- 適するプロジェクト: 開発費用1億円超の大規模・高リスクプロジェクト
IPAモデル契約書の想定にもっとも近い構成です。工程ごとにリスクを遮断できる一方、契約締結・稟議・検収の稼働が集中的に発生するため、専任の契約管理担当者を配置しないと運用が破綻します。大企業の大規模基幹システム更改案件などで採用される構成です。
各パターンにおける請負・準委任の使い分け
分割パターンを決めたら、各工程でどちらの契約類型を採用するかも合わせて決定します。実務上のよくある使い分けは以下のとおりです。
工程 | 一般的な契約類型 | 理由 |
|---|---|---|
企画・要件定義 | 準委任 | 成果物の定義が難しく、作業ベースで評価するほうが実態に合う |
外部設計 | 準委任 or 請負 | 設計書の完成をもって成果物と定義できれば請負も可能 |
内部設計・開発・テスト | 請負 | 成果物の定義が明確なため、完成責任を明確化する請負が適する |
運用・保守 | 準委任 | 継続的な作業に対して工数ベースで支払う運用が一般的 |
要件定義工程を請負契約にしてしまうと、「要件定義書に何を書けば完成なのか」の解釈で紛争になりやすいため、要件定義は準委任契約が実務の一般解です。工程ごとの契約類型と、支払い設計・分割払いの具体的な運用イメージは システム開発費用の支払いタイミングと分割払いの実務 も併せて確認すると理解が深まります。
社内稟議とベンダー交渉を通すための実務ステップ
契約形態を決めても、社内の合意形成とベンダーの理解を得られなければ実行に移せません。以下、意思決定後に必要な3つの実務ステップを整理します。
社内稟議書に書くべき4つの論点
社内稟議で多段階契約を通すには、以下4つの論点を先回りで押さえておくことが有効です。
1. 多段階契約を採用する理由
「なんとなくリスクが減りそう」ではなく、前述の4軸（プロジェクト規模・要件確定度・社内リソース・ベンダー成熟度）に基づく評価結果を根拠として明記します。「本プロジェクトは開発費用1.2億円・要件流動度が高く、要件定義工程での確定作業が下流工程の精度に決定的な影響を及ぼす」といった具体的な理由が求められます。
2. 事務コスト増加への対策
「事務作業が増えて回らない」という社内反論への打ち返しとして、以下のいずれかまたは複数を稟議書に盛り込みます。
- 法務部門と契約書ひな型を事前に合意し、工程ごとの契約締結を差分修正のみで完了させる
- 稟議承認プロセスを工程分割用に簡易化する（例: 総額○○円以内の次工程契約は部長決裁で完結）
- 契約管理担当者を1名アサインし、工程間の事務を一元管理する
3. 費用累増リスクの制御方法
各工程契約前の再見積で費用超過が判明した場合の対応ルールを明記します。「工程完了時点で当初想定総額の110%を超過した場合、経営会議に上程したうえで継続判断する」といった閾値と手続きの合意が有効です。
4. 撤退条件
「工程完了時に次工程契約を締結しない権利」を発注者が持つことは多段階契約の重要な特徴ですが、実務では撤退条件を事前に明文化しておくことが重要です。「要件定義工程の成果物が○○の基準を満たさない場合、次工程契約は締結せず、当該時点までの支払で契約を終了する」といった撤退条件を、ベンダーとの契約書にも同期させて記載します。
ベンダー候補への提案順序
ベンダー交渉は、以下の順序で進めるのが実務的です。
- RFP段階で多段階契約の意向を明示: 提案依頼書に「本プロジェクトは多段階契約（○分割型）で発注する意向」と記載し、この前提で提案・見積を求める
- 見積依頼で工程分割を要求: 見積書は工程ごとに明細を分けた形式で提出を求める。総額のみの見積は受け付けない
- 契約交渉で個別条件を詰める: 工程間の連続性条項・撤退条件・成果物帰属など、個別論点をベンダーと合意していく
RFP段階で多段階契約の意向を明示することで、多段階契約に消極的なベンダーを早期に判別できます。「多段階契約に対応可能」と回答しつつ実質的に一括発注前提の見積を出してくるベンダーは、契約実行段階で問題が発生しやすいため、RFP段階での意思確認は重要です。
ベンダーの懸念を解消する交渉トーク
ベンダーが多段階契約を敬遠する理由（受注機会の不連続性・売上機会損失リスク・事務作業増）に対して、発注者側から以下のような交渉トークを持っておくと合意形成しやすくなります。
- 受注機会の連続性担保: 「工程間で客観的な検収基準を満たせば次工程を継続発注する運用とし、恣意的な打ち切りは行わない」旨を契約書または覚書に明記する
- 工程完了時の評価基準の透明化: 検収基準・評価項目を工程契約に添付し、ベンダー側が「何を満たせば継続発注されるか」を予見可能にする
- 事務負荷の分担: 契約書ひな型は発注者側が提供し、ベンダー側の契約作成負荷を最小化する
「多段階契約はベンダーにとって不利な契約」ではなく「双方のリスクを工程単位で分担する枠組み」であることを、発注者側から具体策で示すことが交渉成功の鍵です。
多段階契約の契約書作成で押さえるべき論点
契約書作成の詳細は法務部門・弁護士との連携が必要ですが、発注者が交渉テーブルで確認すべきチェックリストとして、以下4つの論点を押さえておきましょう。契約書全般の実務ポイントは システム開発における契約書のポイント（発注者向け） も参照してください。
工程間の連続性条項
各工程契約が独立しているとはいえ、実務では次工程の契約締結を前提とした運用が一般的です。次工程の契約締結を保証する条項（優先交渉権条項）を設けることで、ベンダー側の受注連続性への懸念を軽減できます。ただし、優先交渉権を強く設定しすぎると発注者側の撤退権が弱まるため、両者のバランス設計が重要です。
中途解除条件と違約金の設計
工程完了時点で次工程契約を締結しない場合の扱い、および工程進行中に契約を中途解除する場合の条件を明文化します。中途解除時の違約金・成果物の引き渡し義務・機密情報の返還といった論点を、契約書のなかで具体的に定めておく必要があります。
各工程での成果物帰属・検収基準の明確化
工程ごとに成果物（要件定義書・設計書・ソースコード等）の帰属先と検収基準を明確に定義します。特に「途中工程で契約が終了した場合、途中までの成果物の帰属はどちらか」という論点は、契約途中の関係解消時に紛争の火種になりやすい箇所です。
下流工程で瑕疵が発覚した場合の遡及請求権
開発工程やテスト工程で「要件定義の記述が曖昧だった」と判明した場合の、要件定義工程への遡及請求の可否を契約書で明確化します。多段階契約は工程ごとにリスクを遮断する仕組みである一方、実務では「要件定義書の記載不備が下流工程の追加工数を生んだ」ケースで紛争が発生することがあります。遡及請求の範囲と手続きを事前に定めておくことで、紛争発生時の対応がスムーズになります。
まとめ：自社の意思決定に落とし込むための3ステップ
多段階契約と一括発注のどちらを採用するかは、抽象的な優劣論ではなく「自社プロジェクトの特性に合った選択」の問題です。本記事の内容を、明日から取れるアクションとして以下3ステップに集約します。
ステップ1: 判断軸で自社プロジェクトを評価する
プロジェクト規模・要件確定度・社内リソース・ベンダー成熟度の4軸で、企画中のプロジェクトを評価します。判断チャートに当てはめて、多段階契約と一括発注のどちらが有力かの初期案を持ちます。
ステップ2: 分割パターンを選ぶ
多段階契約を採用する場合、2分割型・3分割型・工程ごと分割型のどれを選ぶかを決定します。プロジェクト規模と社内リソースを軸に、事務負荷とリスク遮断のバランス点を選びます。同時に、各工程の請負・準委任の類型を仮決めしておきます。
ステップ3: 社内稟議とベンダー交渉に移す
稟議書には、採用理由・事務コスト対策・費用累増対策・撤退条件の4論点を盛り込みます。ベンダー交渉はRFP段階で意向を明示するところから始め、見積依頼で工程分割を要求し、契約交渉で個別条件を詰めるという順序で進めます。
契約形態の選択は、システム開発プロジェクトの成否を左右する意思決定の1つです。本記事の内容を土台に、自社プロジェクトの状況を評価したうえで、社内・ベンダーの双方を動かす一枚岩の判断材料として活用してください。
関連情報
システム開発の発注実務に関する具体的な判断材料をお探しの方は、お役立ち資料一覧 から自社の状況に合う資料をご覧いただけます。契約形態の意思決定・見積の見方・発注者側チェックリストなど、稟議書作成に活用できる資料を公開しています。
契約形態の選定や発注方針に関して個別のご相談をご希望の方は、お問い合わせフォーム からご連絡ください。企画フェーズの整理段階からご相談いただけます。
システム開発における個別契約書の雛形
この資料でわかること
システム開発を依頼する際にシステム開発会社と締結する個別契約書の雛形をご紹介します。
こんな方におすすめです
- システム開発を発注する際にどのような個別契約を結ぶのか興味がある
- システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
- システム開発を発注する側にどのような義務が生ずるのか気になる
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 多段階契約と一括発注のどちらも成立する中規模案件では、最終的に何を決め手にすればよいですか？
社内の契約実務リソースとベンダーの多段階契約対応経験を優先軸にしてください。法務・調達部門に余力がなく、対応経験が豊富なベンダーも見つからない場合は、規模や要件確定度に関わらず一括発注寄りの判断が現実的です。
- 多段階契約にすると、結局は一括発注より総額が高くなるのでしょうか？
一概には高くなりません。一括発注は要件の不確実性に備えた見積バッファが上乗せされやすく、多段階契約の累積総額とほぼ同水準になったり、逆に下回ったりするケースも実務では珍しくないため、総額だけで契約形態を判断しない方が賢明です。
- ベンダーが多段階契約に消極的だった場合、その案件は諦めるべきですか？
諦める必要はありません。RFP段階で意向を明示したうえで、検収基準の透明化や契約書ひな型の発注者側提供といった交渉トークで懸念が解消できるかを確認し、それでも難色を示す場合のみ候補から外すという順序で判断してください。
- 初めて多段階契約を導入する場合、どの分割パターンから始めるのが安全ですか？
事務負荷がもっとも小さい2分割型（要件定義／設計以降）から始めるのが安全です。契約回数が少なく法務・調達部門への説明もしやすいため、運用に慣れたうえで3分割型や工程ごと分割型への移行を検討してください。
- 社内に契約書のひな型がない場合、何を土台に準備すればよいですか？
IPAが公表する「情報システム・モデル取引・契約書（第二版）」を土台にしてください。法務部門と事前にひな型を合意しておけば、実際の工程ごとの契約締結を差分修正のみで完了させられ、稟議のたびにゼロから作成する手間を省けます。
