システム開発契約の選び方｜請負・準委任を比較

システム開発の契約は、仕様と完成条件を事前に固められるなら請負、要件探索や継続改善を含むなら準委任が基本です。契約名だけで判断せず、成果物・検収・変更手続き・責任範囲・知的財産権まで確認し、工程ごとに使い分けると発注リスクを抑えられます。

• 請負・準委任の違いと選び方
  • 請負契約と準委任契約の比較
  • 案件別に向いている契約方式
• 費用相場・期間と見積もりの確認方法
  • 準委任契約の費用目安
  • 請負契約の費用目安
  • 工程別の期間目安
  • 見積書で確認する項目
• 契約前に決めるべき項目と確認チェックリスト
  • 成果物と完成条件
  • 仕様変更の手続き
  • 不具合と仕様変更の区別
  • 知的財産権とデータの扱い
  • 契約書の確認チェックリスト
• 失敗しない発注手順と開発会社の見極め方
  • 発注までの5ステップ
  • 開発会社へ質問したい項目
  • 開発会社の比較表
  • よくある失敗と回避策
• まとめ
• よくある質問
  • Q1. 請負契約と準委任契約では、どちらが安いですか？
  • Q2. アジャイル開発は請負契約にできますか？
  • Q3. 要件定義の途中で準委任から請負へ変更できますか？
  • Q4. 要件が固まっていない場合、何を準備して相談すればよいですか？

請負・準委任の違いと選び方

結論として、請負契約は「決めた成果物を完成させること」を依頼する契約、準委任契約は「専門業務を適切に遂行すること」を依頼する契約です。どちらが優れているかではなく、発注時点で仕様をどこまで確定できるかによって選びます。

システム開発の相談では、「請負なら追加費用が発生しない」「準委任なら完成責任が一切ない」と理解されているケースがあります。しかし、実際の費用と責任は、契約書、仕様書、見積書、議事録などを含めた合意内容で決まります。

請負契約と準委任契約の比較

なお、準委任契約は派遣契約ではありません。発注者が開発会社の担当者へ日々の作業方法や勤務時間を直接指示するのではなく、原則として開発会社側の責任者を通じて依頼・調整します。契約名が準委任でも、実態が労働者派遣に近ければ別の問題が生じる可能性があるため、指示系統も確認が必要です。

案件別に向いている契約方式

実務では、全工程を一つの契約に統一する必要はありません。たとえば、要件定義（＝作るものを決める工程）は準委任、仕様確定後の開発は請負、公開後の改善は再び準委任とする方法があります。このような工程別の使い分けは、発注者と開発会社の双方が負担する不確実性を減らせます。

費用相場・期間と見積もりの確認方法

契約方式だけで開発費用は決まりません。費用を左右するのは、必要な人数、担当者のスキル、開発期間、機能数、外部サービスとの連携、セキュリティ要件、仕様変更の可能性などです。

準委任契約の費用目安

準委任契約では、「人月（＝1人が1か月稼働する作業量）」を基準に月額を計算することが一般的です。以下はシステム開発を外注する場合の一般的な目安であり、専門性、稼働率、会社規模、契約期間によって変動します。

たとえば、エンジニア2人とPMが月50％稼働する体制なら、月額はおおむね190万〜330万円程度が一つの目安です。クラウド利用料、外部サービス利用料、デザイン費、テスト端末費などが別途必要になる場合があります。

準委任契約では、月額だけでなく「その体制で何を達成する予定か」を確認してください。人数が多くても、会議や引き継ぎに時間がかかれば、必ずしも成果が増えるとは限りません。月ごとの目標、優先順位、完了した作業、残課題を確認できる運用が重要です。

請負契約の費用目安

請負契約の見積金額は、想定工数に管理費、テスト費、品質保証、仕様の不確実性などを加えて算出されます。小規模な追加機能なら数十万〜数百万円、複数画面や外部連携を含むシステムなら数百万〜数千万円以上になることがあります。

ただし、「請負だから安い」「固定価格だから予算を超えない」とは限りません。仕様書に含まれない追加要望は別料金となり、変更が重なると当初予算を超える場合があります。また、仕様が曖昧な案件では、開発会社が変更リスクを見込んだ金額を提示するため、初期見積もりが高くなることもあります。

発注側では、契約金額とは別に10〜20％程度の予備予算を検討しておくと、事業上必要な変更や公開後の修正へ対応しやすくなります。これは追加費用が必ず発生するという意味ではなく、開発中に判明する業務要件や利用者の要望へ備えるための管理上の目安です。

工程別の期間目安

中規模以上の開発、複雑なデータ移行、多数の外部システム連携がある案件では、1年以上かかることもあります。契約方式とは別に、発注者側の確認、データ準備、社内承認、利用部門との調整に必要な期間も工程表へ入れてください。

見積書で確認する項目

見積金額を比較するときは、次の項目が含まれているか確認します。

• 対象となる機能、画面、利用者、データの範囲
• 要件定義、設計、開発、テスト、公開支援の内訳
• PMやデザイナーを含む体制と稼働率
• 打ち合わせ、議事録、進捗報告にかかる費用
• 対応ブラウザ、OS、端末の範囲
• 外部サービス、クラウド、ライセンスの利用料
• データ移行の対象件数と変換・確認方法
• セキュリティテストや性能テストの有無
• 検収後の不具合対応期間と条件
• 仕様変更時の単価、見積方法、承認手順
• 交通費などの実費、消費税、支払条件
• 保守運用が開発費に含まれるか

相見積もりでは、同じ依頼資料を各社に渡さなければ、価格差の理由を正しく判断できません。比較方法はシステム開発の相見積もり｜取り方と比較方法でも詳しく解説しています。

契約前に決めるべき項目と確認チェックリスト

システム開発の契約では、金額と納期だけでなく、完成条件、変更手続き、知的財産権、契約終了時の引き継ぎまで決めることが重要です。特に請負契約では、「何をもって完成とするか」が曖昧だと検収時に認識が分かれます。

成果物と完成条件

成果物には、稼働するシステムだけでなく、ソースコード、設計書、テスト結果、操作マニュアル、環境設定情報などがあります。必要なものを列挙し、納品形式と保管場所も決めます。

検収（＝納品物が契約条件を満たすか発注者が確認する手続き）については、次の内容を明文化してください。

• 検収期間は何営業日か
• 誰が、どの環境で確認するか
• 合格条件となるテスト項目は何か
• 軽微な不具合が残る場合に検収できるか
• 発注者から回答がない場合の扱い
• 不合格の場合の修正期限と再検収方法

「問題なく使えること」のような抽象的な表現だけでは、完成条件として十分とはいえません。主要な業務シナリオ、処理件数、応答速度、対応端末など、客観的に確認できる条件へ落とし込みます。

仕様変更の手続き

開発中の変更を完全になくすことは困難です。重要なのは、変更を禁止することではなく、費用・納期・品質への影響を確認してから合意する手続きを設けることです。

一般的には、次の順序で変更を管理します。

1. 発注者または開発会社が変更内容を記録する
2. 開発会社が工数、費用、納期、影響範囲を提示する
3. 発注者が実施、延期、見送りを判断する
4. 双方の責任者が書面や管理ツール上で承認する
5. 見積書、仕様書、工程表へ反映する

口頭やチャットだけで依頼すると、無償対応なのか追加費用が必要なのかが不明確になります。小さな変更でも一覧へ記録し、月次または節目ごとに予算への影響を確認しましょう。

不具合と仕様変更の区別

不具合は、合意した仕様どおりに動かない状態です。一方、仕様変更は、合意後に挙動や機能を変えることです。

たとえば、仕様書で「会員登録後に確認メールを送る」と合意しているのに送信されなければ不具合です。契約後に「メールにクーポンを付けたい」と追加する場合は、通常は仕様変更となります。

契約不適合責任（＝納品物が契約内容に合っていない場合に受注者が負う責任）の期間や対応範囲も確認します。すべての事象が無期限・無償で修正されるわけではないため、対象期間、通知方法、免責条件を契約書へ記載します。

知的財産権とデータの扱い

発注者が見落としやすいのが、ソースコードやデザインなどの知的財産権です。開発費を支払っただけで、すべての権利が自動的に発注者へ移るとは限りません。

次の点を確認してください。

• ソースコードの著作権を譲渡するか、利用許諾とするか
• 権利が移る時期は納品時か、代金完済時か
• 開発会社が以前から保有する部品やノウハウの扱い
• OSS（＝一定の条件で利用・改変できる公開ソフトウェア）のライセンス
• 画像、フォント、外部APIなど第三者素材の利用条件
• 発注者データの所有権、保管場所、返却・削除方法
• 契約終了後にソースコードと設計情報を受け取れるか

将来、別の会社へ保守や改修を依頼する可能性があるなら、ソースコードだけでなく、開発環境の構築手順、アカウント一覧、データベース定義、リリース手順も必要です。

契約書の確認チェックリスト

• 契約形態が請負・準委任のどちらか明記されている
• 業務範囲と対象外の作業が区別されている
• 成果物、納品方法、完成条件が具体的である
• 検収期間、合格条件、再検収方法が決まっている
• 仕様変更の申請、見積もり、承認方法がある
• 発注者側の資料提供や確認期限が明記されている
• 遅延時の連絡、対応、責任分担が決まっている
• 契約不適合責任の期間と範囲を確認した
• 知的財産権と第三者ライセンスの扱いを確認した
• 再委託の可否と管理責任が明記されている
• 情報セキュリティ、秘密保持、個人情報の条件がある
• 中途解約時の精算方法と成果物の引き渡し条件がある
• 保守運用の範囲と料金が開発契約から分けられている

契約内容は案件や取引条件によって異なります。高額案件、個人情報を扱う案件、権利関係が複雑な案件では、必要に応じてシステム開発契約に詳しい弁護士へ確認してください。

失敗しない発注手順と開発会社の見極め方

開発会社を選ぶときは、希望する契約方式に応じた管理能力を確認します。請負では要件の具体化と品質管理、準委任では進捗の透明性と優先順位の調整力が特に重要です。

発注までの5ステップ

1. 目的と制約を社内で整理する

最初に、システムで解決したい課題、利用者、必要な時期、予算上限、必須機能を整理します。すべての仕様を完成させる必要はありませんが、「必須」と「できれば必要」を分けておくと、適切な契約方式を選びやすくなります。

依頼内容を文書化する場合は、RFPの作り方｜システム開発の依頼準備も参考にしてください。RFPは提案依頼書のことで、発注の背景や要望、提案してほしい内容を開発会社へ伝える資料です。

2. 不明点と変更可能性を洗い出す

仕様が決まっていない箇所、技術調査が必要な箇所、社内合意が取れていない箇所を一覧にします。不明点が多い状態で全体を請負契約にすると、開発会社はリスクを価格へ上乗せするか、多数の前提条件を設けることになります。

3. 工程ごとの契約方式を決める

調査・要件定義・設計・開発・保守を分け、工程ごとに請負と準委任のどちらが適切か検討します。最初は1〜2か月の準委任契約で要件を整理し、その成果を基に開発部分の再見積もりを依頼する方法も有効です。

4. 見積もりと提案を同じ条件で比較する

価格だけでなく、前提条件、対象外、体制、品質管理、変更手続き、引き継ぎ条件を比較します。安い見積もりでも、テスト、プロジェクト管理、データ移行などが含まれていなければ、最終費用は高くなる可能性があります。

5. 契約前に責任者同士で認識を合わせる

営業担当者だけでなく、実際に担当するPMや責任者と面談します。見積書と契約書を読み合わせ、曖昧な表現を残さないようにします。合意事項は議事録へ記録し、契約書や仕様書との優先順位も決めてください。

開発会社へ質問したい項目

• この案件に推奨する契約方式と、その理由は何ですか
• 契約前に確定すべき要件はどこまでですか
• 未確定事項は見積もり上どのように扱っていますか
• 実際に担当するPMとエンジニアの経験は何ですか
• 進捗、課題、消化工数はどの頻度で共有されますか
• 仕様変更が発生した場合、誰がどのように見積もりますか
• 品質基準とテスト範囲はどのように決めますか
• 担当者が交代する場合の引き継ぎ方法はありますか
• 契約終了時に何を引き渡してもらえますか
• 公開後の不具合対応と保守はどの契約になりますか

「できます」という回答だけでなく、進め方、成果物、判断基準まで具体的に説明できる会社を選びましょう。発注のご相談を受ける立場では、契約方式を先に決めつけるより、未確定事項を整理したうえで工程別の契約と見積もりを提示できるかが重要だと考えています。

開発会社の比較表

配点は案件に応じて変えて構いません。個人情報や決済情報を扱う場合はセキュリティ、新規事業なら提案力と変更対応を高く評価するなど、事業上の重要度を反映させます。

よくある失敗と回避策

最安値の請負見積もりだけで選ぶ

対象外の作業が多い見積もりは、契約後に追加費用が増える可能性があります。金額ではなく、同じ範囲・品質・条件に換算して比較してください。

仕様が曖昧なまま全体を請負契約にする

開発途中で認識差が見つかり、追加費用や納期変更につながります。未確定部分は先に準委任で調査するか、請負の対象から切り分けます。

準委任契約で成果目標を設定しない

毎月稼働していても、事業上の進展を判断できなくなります。月次の目標、優先順位、完了条件、報告内容を決めてください。

発注者が開発会社の担当者へ直接細かく指示する

指示系統が曖昧になるうえ、契約と実態が合わない問題につながる可能性があります。開発会社側のPMや責任者を窓口にします。

契約終了時の引き継ぎを決めていない

ソースコードがあっても、環境情報やリリース手順がなければ、別会社がすぐに保守できないことがあります。契約開始時に引き渡し物とアカウントの所有者を決めましょう。

自社案件で請負・準委任のどちらが適切か判断できない場合は、未確定事項と工程を整理したうえでご提案します。開発のご相談はこちらからお問い合わせください。

まとめ

• 仕様と完成条件を固められる案件には請負契約が向いています
• 要件探索、技術調査、アジャイル開発、継続改善には準委任契約が向いています
• 一つの方式に統一せず、要件定義は準委任、開発は請負など工程別に使い分けられます
• 契約方式だけで費用は決まらず、体制、期間、機能、品質、変更可能性が金額を左右します
• 見積書では対象範囲、前提条件、対象外、変更時の単価、テスト、保守費用を確認します
• 契約前に成果物、検収、仕様変更、契約不適合責任、知的財産権、終了時の引き継ぎを決めます
• 開発会社は価格だけでなく、要件整理、進捗管理、変更管理、品質管理の具体性で比較します
• 契約書の名称だけでなく、実際の業務内容、責任、指示系統が一致していることが重要です

よくある質問

Q1. 請負契約と準委任契約では、どちらが安いですか？

一概には決まりません。仕様が明確なら請負で総額を管理しやすい一方、仕様が曖昧な請負はリスク費用や追加見積もりが増える場合があります。準委任は月額を把握しやすいものの、開発期間が延びれば総額も増えます。金額だけでなく、不確実性に合った契約方式を選ぶことが重要です。

Q2. アジャイル開発は請負契約にできますか？

可能ですが、一般的には準委任契約のほうが変更へ対応しやすいです。アジャイル開発は、短い期間ごとに優先機能を開発・評価する方法であり、最初から全仕様を固定しないことがあります。請負にする場合は、期間ごとの成果物、完成条件、変更方法を明確にする必要があります。

Q3. 要件定義の途中で準委任から請負へ変更できますか？

可能です。要件定義を準委任で進め、仕様、画面、データ、テスト条件が固まった段階で、開発工程を請負として再見積もりする方法があります。契約を切り替える条件、成果物、再見積もりの時期を最初に合意しておくと円滑です。

Q4. 要件が固まっていない場合、何を準備して相談すればよいですか？

解決したい業務課題、想定利用者、希望時期、予算の目安、必須機能、現在の業務資料を準備してください。詳細な仕様書は必須ではありません。未確定事項を開示し、要件整理の進め方と費用を開発会社へ提案してもらうことが重要です。