システム開発の支払い条件｜請負・準委任・マイルストーン払いの選び方と設計例

システム開発の発注を検討していると、必ず直面するのが契約の支払い条件の問題です。「請負にしますか、準委任にしますか？」「マイルストーン払いはどうされますか？」——開発会社からこう聞かれたとき、即座に答えられる発注者は多くありません。

支払い条件は経理上の手続きと思われがちですが、実際にはプロジェクトのリスク配分・開発品質・コスト管理に大きく影響します。「請負で一括払い」「準委任で月次払い」の違いを理解していないまま契約すると、仕様変更のたびに追加費用が発生したり、欠陥が出ても保証されなかったりといったトラブルにつながります。

この記事では、システム開発の主な支払い方式（請負の一括払い・マイルストーン払い・準委任の月次払い）の違いを発注者の視点で解説し、どのケースにどの条件が適しているかの判断フレームワークを提供します。さらに、多くの記事が触れていない「マイルストーン払いの具体的な設計方法」まで踏み込んで説明します。

この記事を読み終えると、ベンダーとの支払い条件の交渉において、自社の立場と判断基準を持って対等に話せるようになります。

—Free Download / 資料ダウンロード

システム開発における基本契約書の雛形

この資料でわかること

システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。

こんな方におすすめです

• システム開発を発注する際にどのような基本契約を結ぶのか興味がある
• システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
• システム開発を発注する側にどのような義務が生ずるのか気になる

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

システム開発の支払い条件を理解すべき理由

支払い条件はプロジェクトの成否を左右する重要な要素です。単に「いつ・いくら払うか」を決めるだけでなく、発注者とベンダーの間で「誰がどのリスクを負うか」を決める仕組みでもあります。

支払い条件が変わるとリスク配分が変わる

支払い条件の選択は、プロジェクトのリスクをどちらが負担するかに直結します。

たとえば、「完成後に全額一括払い」という条件では、開発完了まで発注者はお金を払わないため、発注者にとっては資金リスクが低い一方、ベンダーは開発費用を完成まで立て替え続ける必要があります。ベンダーのキャッシュフローへの負担が大きくなるため、中小規模の開発会社では受注を敬遠するケースもあります。

逆に「着手時に全額前払い」では、ベンダーに開発資金の心配がなくなる分、発注者がすべてのリスクを負います。プロジェクトが中断しても資金は戻ってきません。

適切な支払い条件とは、発注者とベンダーのリスクをバランスよく分担できる設計です。

支払い条件の失敗パターン

以下のようなトラブルは、支払い条件の設計が不適切だったことが原因であるケースが多いです。

• 「仕様変更のたびに追加費用が発生した」: 請負契約で要件を一括合意していたが、仕様変更の追加費用ルールが契約書に明記されていなかった
• 「納品後に欠陥が出たが修正費用を請求された」: 検収基準と保証期間が曖昧なまま「完成払い」にしたため、検収後の欠陥修正が別費用扱いになった
• 「開発が中断したが前払い分が戻らなかった」: 着手金を多く払いすぎており、中断時の返金ルールが定められていなかった

これらは支払い条件を適切に設計し、契約書に明記することで防げるトラブルです。

3種類の支払い方式を整理する

システム開発の主な支払い方式は「請負契約の一括払い」「マイルストーン払い」「準委任契約の月次払い」の3種類です。それぞれの特性を発注者の立場から整理します。

請負契約の一括払い（完成検収後に全額支払い）

請負契約は、ベンダーが「完成したシステムを納品する」義務を負う契約です。成果物（システム）の完成が前提であり、完成しなければ報酬は発生しません。

一括払いは「システム完成・検収合格後に全額支払い」する方式です。

マイルストーン払い（工程ごとに分割支払い）

マイルストーン払いは、開発プロジェクトを複数の工程（マイルストーン）に分け、各工程の完了ごとに分割して支払う方式です。請負契約・準委任契約の両方で採用できます。

マイルストーン払いは、現在のシステム開発案件で最もよく採用される支払い方式です。後述のセクションで設計方法を詳しく解説します。

準委任契約の月次払い（稼働時間に応じた定期支払い）

準委任契約は、ベンダーが「システム開発という業務を遂行する」義務を負う契約です。請負契約と違い、成果物の完成責任はありません。エンジニアの稼働時間（工数）に対して報酬が発生します。

月次払いは「月ごとの実績工数に基づき翌月末に支払う」形式が一般的です。

支払い方式の選び方（判断フレームワーク）

「どの支払い条件を選ぶべきか」を判断するための3つの軸を紹介します。

判断軸1: 要件の確定度

最も重要な判断軸は、「プロジェクト開始時点で要件がどの程度確定しているか」です。

要件が確定している場合 → 請負契約（一括払いまたはマイルストーン払い）

業務フロー・画面仕様・データ構造が固まっており、「完成品の定義」が明確な場合は請負契約が適しています。ベンダーに完成責任を持たせることで、品質とスコープを守りやすくなります。

要件が流動的な場合 → 準委任契約（月次払い）

スタートアップのプロダクト開発や、利用者の反応を見ながら方向を変えるアジャイル開発など、仕様が変わる可能性が高い場合は準委任契約が向いています。「完成品の定義」が固まっていない状態で請負契約を結ぶと、追加費用交渉が頻発します。

判断軸2: プロジェクト規模・期間

開発期間が3ヶ月未満の小規模案件であれば、請負の一括払いがシンプルで扱いやすいです。一方、6ヶ月以上の中〜大規模案件では、一括払いはベンダーのキャッシュフロー負担が大きく、その分コストに上乗せされる可能性があります。この場合、マイルストーン払いにより発注者・ベンダー双方の負担を平準化することを推奨します。

判断軸3: リスク許容度とキャッシュフロー

着手金（前払い）を多く払うほどベンダーのキャッシュフロー負担は減り、リスクは発注者側に移ります。着手金を少なくするほど発注者のリスクは下がりますが、ベンダーの受注単価が上がる傾向があります。

発注者のキャッシュフローに余裕があり、ベンダーとの信頼関係が薄い場合は、着手金を抑えてマイルストーン払いにすることでリスクをコントロールできます。

判断フレームワークのまとめ

なお、要件定義フェーズを準委任契約（月次払い）で行い、要件が確定した後の設計・開発フェーズから請負契約（マイルストーン払い）に切り替える「多段階契約」は、多くの中〜大規模プロジェクトで採用されています（Business Lawyers: システム開発における一括契約と多段階契約のメリット・デメリット）。

マイルストーン払いの具体的な設計方法

マイルストーン払いを採用する場合、「どの工程をマイルストーンにするか」「各マイルストーンの金額比率をどう設定するか」「完了基準をどう定義するか」の3点を契約前に決める必要があります。

典型的なマイルストーンの設定例

ウォーターフォール開発の場合、以下の工程をマイルストーンとして設定するのが一般的です。

4つのマイルストーンが標準的ですが、開発規模に応じて3〜5段階に調整します。

各マイルストーンへの金額配分の目安

システム開発の着手金（M1の支払い）は、一般的に開発費用全体の30%程度が相場です（発注ラウンジ: システム開発の着手金とは？）。中規模案件では「着手金30%、中間払い35%、完成後35%」といった3段階の構成がよく使われます。

最終支払い（M4）の比率を高めに設定することで、ベンダーが「早期に仕事を切り上げたい」というインセンティブを持ちにくくなります。

マイルストーンの「完了基準」を契約書に明記すべき理由

マイルストーン払いで最も重要なのは、「各マイルストーンが完了した状態とは何か」を契約書に明記することです。

完了基準が曖昧な場合、たとえば「M2（基本設計完了）はどの状態を指すのか」について、ベンダーは「設計書を提出した時点」と主張し、発注者は「設計書を承認した時点」と考えており、双方の認識が食い違うことがあります。

完了基準として契約書に記載すべき要素は以下です。

• 提出物: 各マイルストーンで何を提出するか（設計書、ソースコード、テスト報告書等）
• 承認フロー: 誰が何を根拠に承認するか（発注者の担当者が書面で承認、等）
• 検収期間: 発注者が提出物を確認する期間（一般的に5〜10営業日）
• 検収基準: 何をもって「合格」とするか（指定した仕様書との整合性確認、等）

支払い条件を交渉する際の注意点

支払い条件を理解した上で、ベンダーとの交渉でどのような点を確認・主張すべきかを解説します。

前払い（着手金）の相場感と交渉の余地

着手金の相場は全体費用の20〜30%程度です。ただし、発注者が初めての取引先である場合やプロジェクト規模が大きい場合は、ベンダー側から30〜50%の着手金を求められることがあります。

着手金を抑えるための交渉ポイントは以下です。

• 分割払いの提案: 「着手金は20%に抑え、代わりに中間マイルストーンを細かく設定する」と提案する
• 実績・信頼の提示: 過去の取引実績や財務情報を開示することで、ベンダーの資金回収リスクへの懸念を軽減する
• ベンダーのコスト構造の理解: 外部パートナー（フリーランス等）への発注費用が多いベンダーは、着手金が多く必要な場合がある。その場合は中間払いのタイミングを早めることで対応できる

仕様変更時の追加費用ルールを事前に決めておく

請負契約では、当初の仕様書に含まれていない変更要求（追加開発・仕様変更）は別途費用が発生します。この追加費用の発生条件と承認フローを事前に定めておかないと、後から「そんなに高くなるとは聞いていない」というトラブルになります。

契約書に記載しておくべき事項は以下です。

• 変更管理プロセス: 仕様変更は必ず書面（変更依頼書）で行い、ベンダーが見積もりを提示した上で発注者が書面承認する
• 変更費用の単価: 追加1人日あたりの単価を契約書に明記しておく
• 軽微な変更の扱い: 「デザインの微調整」「誤字修正」などは無償対応とするか有償とするかを定める

検収期間・検収基準を明確にする

完成払いやマイルストーン払いでは、「検収合格」が支払いトリガーになります。検収期間と基準が曖昧だと、発注者が検収を引き延ばしてベンダーの支払いを遅らせることになり、関係性が悪化します。

一般的な検収期間は5〜10営業日です。期間内に発注者が明示的な不合格理由を通知しない場合は、合格とみなす「みなし合格」条項を設けることも有効です。

まとめ

システム開発の支払い条件を選ぶ際の要点を整理します。

契約形態の選択

• 要件が確定しているなら請負契約。成果物の完成責任をベンダーに持たせられる
• 要件が流動的・アジャイル開発なら準委任契約。柔軟な変更に対応できる
• 長期・大規模プロジェクトは、前半（要件定義）を準委任、後半を請負とする多段階契約も有効

支払い方式の選択

• 小規模・短期（3ヶ月未満）は一括払いがシンプル
• 中〜大規模はマイルストーン払いでリスクを分散する
• アジャイル開発は月次払いで稼働ベースで管理する

マイルストーン払いの設計

• 着手金（M1）は20〜30%が目安。後払いの比率を高めにするとベンダーの完成インセンティブが上がる
• 各マイルストーンの「完了基準」を契約書に明記する

支払い条件はベンダーとの交渉で「発注者が不利になりやすい」部分です。この記事で紹介した判断フレームワークと具体的な設計例を参考に、自社のプロジェクトに適した条件を設計してください。

—Free Download / 資料ダウンロード

システム開発における基本契約書の雛形

この資料でわかること

システム開発を依頼する際にシステム開発会社と締結する基本契約書の雛形をご紹介します。

こんな方におすすめです

• システム開発を発注する際にどのような基本契約を結ぶのか興味がある
• システム開発会社がきちんと契約の取り交わしをしてくれるのか不安
• システム開発を発注する側にどのような義務が生ずるのか気になる

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。