請負と準委任の違いと選び方｜システム開発で炎上しない契約のポイント

「要件未定なのに、無理やり請負契約を結んでしまった…」
「準委任にした途端、ベンダーが完全に指示待ちだ…」
「直前になって『スコープ外』と追加費用で揉めている…」

プロジェクトの最前線で、このような「契約の壁」に阻まれて頭を抱えた経験はないでしょうか？

法律論はさておき、現場のPMにとって契約とは「責任の所在を明確にし、プロジェクトを守るための防波堤」です。キックオフ前に交わした「契約のハンコ」のズレを放置したまま走り出すと、後から手戻りが発生するだけでなく、現場のエンジニアがリカバリーの犠牲となり、プロジェクト自体が致命的なコスト増やスケジュール遅延を引き起こします。

この記事では、教科書的な法律の解説ではなく、厳しい現場の体感に基づく「請負と準委任のリアルな使い分け」と、不確実な開発を乗り切る「ハイブリッド契約（フェーズ分割発注）」の極意を解説します。

【基礎】「請負」と「準委任」の違い｜現場視点で読み解くリアルな実態
【実践】現場が死ぬ「契約の罠」と具体的な回避策
【戦略】炎上を防ぐ「ハイブリッド契約（フェーズ分割発注）」のススメ
【警戒】「善管注意義務」と「契約不適合責任」の本当の怖さ
【まとめ】契約はベンダーを「戦友」にするための防波堤

【基礎】「請負」と「準委任」の違い｜現場視点で読み解くリアルな実態

請負契約とは成果物の完成に責任を持つ契約であり、準委任契約とは業務の遂行に対して善管注意義務を負う契約です。

システム開発の契約は、大きく分けてこの2つに分類されます。これを法務部任せにするのではなく、PM自身が「現場の体感」として腹落ちさせておくことが重要です。

比較項目	請負契約	準委任契約
最大の目的（義務）	成果物の「完成」	業務の「適切な遂行（善管注意義務）」
納品物への責任	あり（契約不適合責任）	なし（※プロとしての責任は問われる）
報酬の対象	完成した成果物	提供した労働力・技術・時間
現場での使いどころ	仕様が明確で固まっているフェーズ（製造・単体テストなど）	仕様が変動する・共に作るフェーズ（要件定義・アジャイルなど）

請負契約のリアル： 「完成」させることが絶対の義務です。作るべきシステムが明確で、仕様がガチガチに固まっている時にしか選んではいけません。
準委任契約のリアル： 完成の義務は負わず、「プロとして恥ずかしくない働き」を約束するものです。アジャイル開発や、発注者と一緒にゼロから作り上げていくフェーズに適しています。

【実践】現場が死ぬ「契約の罠」と具体的な回避策

それぞれの契約形態の特性を無視して発注を進めると、高確率でプロジェクトは炎上します。現場で頻発する3つの典型的な罠とその回避策を見ていきましょう。

罠①：要件未定なのに「予算固定」のための請負契約

「予算を通すために、どうしても金額を確定させたい」という発注者側の都合で、要件定義が終わっていないのに全工程を請負契約にしてしまうケースです。

放置した末路： 開発が進むにつれて仕様の抜け漏れが発覚し、ベンダーから変更管理（CR）と追加費用の嵐が押し寄せます。機能の削り合いと責任のなすりつけ合いで、双方が疲弊しきってしまいます。
回避策： 見えないものに値段はつけられません。要件が未定の段階での一括請負は絶対に避け、後述する「フェーズ分割発注」に切り替える交渉を社内で徹底してください。

罠②：準委任の「提案待ち（指示待ち）」によるプロジェクト停滞

「準委任契約でアジャイルに作ろう」と意気込んだものの、「ベンダーが何も提案してくれない」と嘆くケースです。

放置した末路： 契約上、彼らは「時間」と「スキル」を売っているに過ぎません。発注側が明確な指示を出せないと、ベンダーは完全に「指示待ち」となり、お金だけが溶けていく時間稼ぎの状態に陥ります。
回避策： 準委任であっても、RFPや契約の段階で「ベンダー側PM/PLの役割」を明確に定義し、能動的な技術提案や課題提起をスコープに含めるよう要求してください。

罠③：検収条件の曖昧さが招く「終わらない請負」

請負契約において「何をもって完成（検収）とするか」の定義が曖昧なまま開発をスタートしてしまうケースです。

放置した末路： リリース直前の受け入れテスト（UAT）で「画面のレスポンスが遅い」「この帳票も出せるはずだ」と揉め始め、「それは別料金です」という終わりの見えない泥沼の交渉が始まります。
回避策： RFPおよび契約書の中に、「画面表示は〇秒以内」「テストシナリオ〇〇件をパスすること」など、数字や客観的な基準で測定できる明確な検収条件を必ず明記してください。

【戦略】炎上を防ぐ「ハイブリッド契約（フェーズ分割発注）」のススメ

「最初から最後まで一括請負」という契約は、変化の激しい現代のシステム開発においてはもはやギャンブルです。デキるPMは、開発フェーズごとに契約形態を切り替える「ハイブリッド契約（多段階契約）」を駆使します。

フェーズ	推奨される契約形態	現場PMの狙いとアクション
要件定義〜基本設計	準委任契約	【一緒に悩み、スコープを固める】仕様が未確定なため、専門家の知見を借りながら二人三脚で要件を確定させます。ここで「何を作らないか」を決めるのが勝負です。
詳細設計〜製造〜単体テスト	請負契約	【固まった仕様を効率よく作る】スコープが確定したら、ベンダーの責任において品質と納期を担保させます。発注側は進捗のモニタリングに徹します。
結合テスト〜リリース・保守	準委任契約	【不測の事態に柔軟に対応する】他システムとの連携不具合や、現場からの仕様変更要望など、想定外の事態が多発するフェーズです。柔軟に動ける準委任に切り替えて対応力を高めます。

この「フェーズごとに契約を分ける」という方針を、ベンダー選定時のRFPの段階でしっかりと握っておくことが、プロジェクトをコントロールする最大の鍵となります。

あわせて読みたい： ベンダー選定で失敗しないためのRFPの具体的な書き方や、面談で実力を見抜く「逆質問」のテクニックについては、以下の記事で詳しく解説しています。 RFPの書き方｜ベンダー選定で失敗する5つの罠と回避策【現場PMの実践】

【警戒】「善管注意義務」と「契約不適合責任」の本当の怖さ

契約形態を選ぶ際、それぞれの「責任の重さ」を正しく理解しておく必要があります。

「準委任だから責任がない（完成しなくてもよい）」というのは誤りです。ITベンダーは専門家として、善良な管理者の注意義務（善管注意義務）を負っています。そのため、発注側の要求が明らかにシステム破綻を招く可能性がある場合には、リスクの指摘や改善提案を行うことが求められるケースがあります。実際の裁判でも、こうした対応を怠ったことが善管注意義務違反と評価される可能性が指摘されています。

一方で、請負契約における「契約不適合責任」は非常に強力です。

しかし、「何が契約に適合している状態（完成）なのか」が曖昧なままでは、その責任を適切に追及することは極めて難しくなります。 要件定義や検収基準が不明確な状態では、「契約通りかどうか」の判断自体ができず、結果として発注者とベンダーの間で水掛け論に陥るケースが少なくありません。契約書は万能の魔法ではなく、要件定義と検収基準という「中身」があって初めて機能する武器なのです。