システム開発の要件定義を外注するとき、「準委任と請負のどちらで契約すべきか」「準委任のデメリットや、発注側がやってはいけないことは何か」を判断したい発注担当者向けに、契約形態の違いと失敗しない契約設計を実務目線で解説します。
この記事でわかること
- 要件定義に準委任契約が選ばれる理由（請負との根本的な違い）
- 準委任・請負・委任・派遣（SES）の違いをわかりやすく整理
- 準委任（履行割合型・成果完成型）と請負の3者比較
- 準委任契約のデメリットと、発注側がやってはいけないこと（偽装請負・指揮命令）
- 契約書に盛り込むべき条項とよくある失敗例
結論：要件定義は準委任契約（特に履行割合型）が基本です。 ただし、要件がある程度固まり成果物を明確に定義できる場面では、請負契約や成果完成型が向くこともあります。発注側で迷ったら「完成形を契約時点で確定できるか」を判断軸にすると整理しやすくなります。なお、契約・条文の最終的な解釈は弁護士など専門家への確認を前提にしてください。
要件定義フェーズに準委任契約が使われる理由
Photo by Austin Distel on Unsplash
結論から言うと、要件定義フェーズに準委任契約が選ばれる主な理由は次の3点です。 ①要件定義は完成形を事前に確定しにくいため請負契約の「完成義務」になじまない、②仕様変更や追加検討が頻繁に発生するため柔軟な対応が求められる、③発注側とベンダーが協力しながら要件を作り上げるプロセスに、準委任の「業務遂行義務」が適している。
要件定義は「完成物」を事前に確定しにくい
システム開発の要件定義フェーズでは、ヒアリング・業務分析・要件の整理といった作業を通じて、はじめて「何を作るか」が明確になっていきます。プロジェクト開始時点では、発注側自身も最終的な要件定義書の内容を具体的に描けないケースが大半です。
請負契約は「仕事の完成」を目的とする契約形態であり、成果物の内容があらかじめ明確に定義されていることが前提になります。要件が固まっていない段階で請負契約を結んでしまうと、「何をもって完成とするか」が曖昧なまま進行し、後々トラブルの原因になりやすいです。
準委任契約なら仕様変更に柔軟に対応できる
準委任契約は、成果物の完成ではなく「業務の遂行」を目的とする契約です。ベンダーは善管注意義務（善良な管理者として期待される水準の注意を払う義務）を負いながら業務を進めますが、最終的な成果物の完成を保証するわけではありません。
この特性が、要件定義フェーズとの相性をよくしています。途中で業務範囲が変わっても、都度合意の上で対応範囲を調整しやすく、発注側とベンダーが協力しながら要件を固めていくプロセスに適しています。
準委任契約と請負契約の基本的な違い
Photo by James Harrison on Unsplash
準委任と請負の違いをひとことで言うと、「業務の遂行そのものに対価を払う」のが準委任、「成果物の完成に対価を払う」のが請負です。 要件定義のように完成形が読みにくい作業は準委任、仕様が固まった開発・テストは請負、という使い分けが基本になります。以下で具体的な違いを項目ごとに見ていきます。
完成義務の有無
請負契約では、ベンダーは合意した成果物を完成させる義務を負います。一方、準委任契約では成果物の完成義務はなく、定められた業務を誠実に遂行することが求められます。
報酬の発生タイミング
請負契約では、原則として成果物の完成・納品をもって報酬が発生します。準委任契約（特に履行割合型）では、業務を遂行した時間・工数に応じて報酬が発生するのが一般的です。
瑕疵担保責任（契約不適合責任）の扱い
請負契約では、成果物に欠陥（契約不適合）があった場合、ベンダーは修補・損害賠償などの責任を負います（民法上の契約不適合責任）。準委任契約では、成果物の完成を保証しないため、この責任は原則として発生しません。ただし、業務遂行上の過失があれば、善管注意義務違反として損害賠償を請求できる場合があります。
| 比較項目 | 請負契約 | 準委任契約 |
|---|---|---|
| 目的 | 成果物の完成 | 業務の遂行 |
| 完成義務 | あり | なし |
| 報酬発生 | 成果物の完成・納品時 | 業務遂行に応じて（型による） |
| 契約不適合責任 | 原則あり | 原則なし |
| 善管注意義務 | あり | あり |
| 仕様変更への対応 | 変更契約が必要になりやすい | 比較的柔軟に対応しやすい |
請負と準委任の違いをさらに掘り下げたい場合は、請負と準委任の違いをわかりやすく解説もあわせてご覧ください。
委任契約と準委任契約の違い
「委任」と「準委任」は混同されがちですが、対象とする業務が異なります。委任契約は弁護士への訴訟代理など「法律行為」を委託する契約、準委任契約は要件定義・設計・運用など「法律行為ではない事務（事実行為）」を委託する契約です。システム開発で交わされるのは原則すべて準委任契約であり、両者の法的性質（善管注意義務など）はほぼ共通します。実務では「準委任＝専門的な作業を任せる契約」と理解しておけば十分です。
開発全体の費用感や要件定義費の相場とあわせて検討したい場合は、要件定義の費用相場と見積書の見極め方もご覧ください。
準委任・請負・派遣（SES）の違い
Photo by Cytonn Photography on Unsplash
外注の契約形態を整理するとき、準委任・請負と並んで混同されやすいのが労働者派遣（いわゆる人材派遣）と、実務でよく使われるSES（システムエンジニアリングサービス）です。最大の違いは「誰が作業者に指揮命令をするか」にあります。
- 準委任・請負：作業者への指揮命令はベンダー（受託側）が行う。発注側は直接指示できない。
- 労働者派遣：作業者への指揮命令は発注側（派遣先）が行う。派遣元との契約に基づき、発注側が業務指示できる。
SESは契約上は準委任に分類されることが多く、エンジニアの労働力・稼働を提供する形態ですが、指揮命令はあくまでベンダー側にあるのが原則です。ここを誤解して発注側が常駐エンジニアに直接指示を出すと、後述する偽装請負と判断されるリスクがあります。
| 比較項目 | 準委任 | 請負 | 労働者派遣 |
|---|---|---|---|
| 契約の目的 | 業務の遂行 | 成果物の完成 | 労働力の提供 |
| 指揮命令を行う側 | ベンダー | ベンダー | 発注側（派遣先） |
| 完成義務 | なし | あり | なし |
| 発注側の直接指示 | 不可 | 不可 | 可（派遣契約の範囲内） |
「どこまで発注側が関与してよいか」を契約形態に合わせて設計することが、トラブル回避の起点になります。準委任・請負・派遣の線引きについては、業務委託（請負・準委任）の違いと使い分けでも整理しています。
準委任契約の2種類：履行割合型と成果完成型
Photo by Mario Gogh on Unsplash
2020年の民法改正により、準委任契約は「履行割合型」と「成果完成型」の2種類が明文化されました。
履行割合型とは
業務を遂行した割合に応じて報酬が発生する形態です。たとえば「月40時間のヒアリング・分析業務を月額100万円で委託する」といった形で、時間や工数が報酬の基準になります。途中で業務が中断された場合も、遂行済みの部分に応じた報酬を請求できるのが特徴です。
シナリオ例： 要件定義の初期フェーズで、業務フローの整理やステークホルダーへのヒアリングを月次で依頼するケース。作業の進捗に応じて毎月請求が発生し、スコープが変わっても柔軟に対応できます。
成果完成型とは
特定の成果物が完成した時点で報酬が発生する形態です。請負契約に近い性質を持ちますが、契約不適合責任は原則として発生しない点が異なります。
シナリオ例： 要件定義書の初版ドラフトを納品することを条件に報酬が発生する契約。成果物の完成が報酬の条件になるため、ベンダー側のアウトプット責任が明確になります。
要件定義ではどちらを選ぶべきか
一般的には、要件定義の初期段階では履行割合型が選ばれることが多いです。要件が流動的な段階では、成果物の定義自体が変わる可能性があるため、業務遂行に応じた報酬体系の方がリスクを分散しやすいためです。
一方、要件定義の後半で「要件定義書の完成版を納品する」という形で成果完成型に切り替えるケースもあります。プロジェクトの性質や発注側の管理体制に応じて選択するのが実務的なアプローチです。
履行割合型・成果完成型・請負の3者比較
要件定義フェーズで検討する3つの契約形態を、発注側の判断軸で整理すると次のようになります。
| 比較項目 | 準委任（履行割合型） | 準委任（成果完成型） | 請負 |
|---|---|---|---|
| 報酬の基準 | 投下した工数・時間 | 定めた成果物の完成 | 成果物の完成・納品 |
| 完成義務 | なし | なし（成果物の達成は条件） | あり |
| 契約不適合責任 | 原則なし | 原則なし | あり |
| 仕様変更への強さ | 高い | 中 | 低い（変更契約が必要） |
| 費用の見通し | 見えにくい（上限管理が必要） | 比較的見えやすい | 見えやすい |
| 向くフェーズ | 要件定義の初期・アジャイル | 要件定義書の確定納品 | 詳細設計以降 |
準委任と請負、どちらで契約すべきか迷っている方へ
シンシアでは、要件定義フェーズの契約形態の選定や、契約書に盛り込むべき条項（成果物定義・報告義務・著作権の帰属など）の整理を支援しています。準委任型の伴走支援で要件整理から開発まで一気通貫の体制もご提案できます。
準委任と請負、どちらを選ぶべきか（判断のステップ）
「結局どちらがいいのか」を迷ったときは、契約時点での要件の固まり具合を起点に、次の順序で判断すると整理しやすくなります。
- 完成形（成果物の範囲・仕様）を契約時点で具体的に確定できるかを確認する。確定できないなら準委任、確定できるなら請負・成果完成型が候補になります。
- 確定できない場合は、準委任（履行割合型）を基本に、月次・スプリント単位で工数の上限を合意する。
- 「要件定義書の完成版を納品してほしい」など、特定の成果物だけは確実に受け取りたい場合は、準委任（成果完成型）で成果物の達成を報酬条件にする。
- 要件が固まり詳細設計・開発に進む段階では、請負へ切り替え、完成義務と契約不適合責任で品質を担保する。
つまり「準委任が基本だが、完成形を確定できる範囲は請負・成果完成型に寄せる」というのが発注側にとって扱いやすい設計です。判断に迷う場合は、フェーズごとに契約を分け、移行条件をあらかじめ合意しておくと、後段のトラブルを避けやすくなります。
要件定義で準委任契約を結ぶ際の注意点
Photo by Anastassia Anufrieva on Unsplash
成果物の定義を曖昧にしすぎない
準委任契約は成果物の完成を保証しないとはいえ、「何を作業するか」「どのようなドキュメントを提出するか」を契約書や作業範囲定義書（SOW）に明記しておくことが重要です。成果物の定義が曖昧なまま進むと、「ヒアリング議事録だけで終わった」「要件定義書の体裁が想定と全く違った」といったトラブルにつながりやすくなります。
ベンダーの善管注意義務を確認する
準委任契約でもベンダーは善管注意義務を負います。この義務は「その業務の専門家として期待される水準の注意を払う」ことを意味します。具体的には、明らかに実現不可能な要件を黙認せず指摘する、リスクを発見した場合に報告するといった行動が含まれます。
契約書に「報告義務」「助言義務」の条項を盛り込んでおくと、双方の期待値のズレを防ぎやすくなります。
次フェーズへの契約切り替えタイミングを明確にする
要件定義が完了した後、基本設計・詳細設計・開発フェーズへ移行する際に契約形態を切り替えることが多いです。このタイミングを曖昧にしておくと、「要件定義が終わったのに準委任のまま開発が始まってしまった」「いつ請負契約を締結するか合意できていない」といった問題が起きやすくなります。
フェーズの完了条件（例：発注側の要件定義書承認）と、次フェーズの契約締結手続きのスケジュールをあらかじめ合意しておくことを推奨します。
契約書に盛り込んでおきたい主な条項
準委任契約で発注側のリスクを抑えるには、最低限、次のような条項を契約書やSOWで明確にしておくと安心です。あくまで一般的な実務上のチェックポイントであり、個別の契約内容は弁護士など専門家への確認を前提にしてください。
- 業務範囲（スコープ）：対象とする作業の範囲と、範囲外となる作業の扱い
- 成果物・提出物の定義：作成するドキュメントの種類・粒度・フォーマット
- 報酬と支払い条件：履行割合型／成果完成型の別、工数の上限、追加作業時の精算方法
- 報告・連絡義務：進捗報告の頻度、リスク発生時の連絡ルール
- 著作権・成果物の権利帰属：要件定義書などの著作権を発注側に譲渡するか、利用許諾にとどめるか
- 再委託の可否：ベンダーが第三者に作業を再委託できるかどうか
- 契約期間と更新・解約条件：フェーズ移行時の契約切り替え手続き
準委任契約のデメリットと、発注側がやってはいけないこと
準委任契約は柔軟性が高い一方、発注側が理解しておくべきデメリットと、契約上「やってはいけない」行為があります。ここを押さえないと、費用の膨張や法的リスクにつながります。
準委任契約のデメリット
- 最終的な完成が保証されない：ベンダーは業務遂行義務を負いますが、成果物の完成義務はありません。「期日までに要件定義書が必ず完成する」という保証を契約で担保したい場合は、成果完成型や請負を検討する必要があります。
- 費用の見通しが立てにくい：履行割合型は工数に応じて費用が発生するため、スコープが膨らむと費用も増えます。月次・スプリント単位での工数上限の合意が欠かせません。費用構造の基本はシステム開発の人月単価とは？職種別相場と見分け方で解説しています。
- 発注側の関与が前提：協働で要件を固める契約のため、発注側がヒアリングやレビューに時間を割けないと、品質も進捗も低下します。
偽装請負・指揮命令に注意（やってはいけないこと）
準委任契約で最も注意すべきが偽装請負です。準委任・請負では、発注側がベンダーの作業者に対して直接的な指揮命令（業務の進め方や勤怠の指示）を行ってはいけません。指揮命令は労働者派遣や雇用にあたる行為であり、これを契約形態と一致させずに行うと偽装請負と判断され、法的リスクを負います。
- やってはいけない例：発注側がベンダー常駐者の作業時間・残業を直接管理する／日々の作業指示を個別に出す／自社社員と同じように業務を割り振る
- 望ましい運用：作業範囲・成果物・スケジュールは契約とSOW（作業範囲定義書）で合意し、進行はベンダー側の責任者経由で調整する
発注側が指揮命令を伴う密な協働体制を求める場合は、準委任の枠組みを正しく用いたラボ型開発（準委任・SES・アジャイルとの違い）の活用も選択肢になります。
準委任契約で発注側はどこまで指示できるか
「直接指示できない」と聞くと、発注側はベンダーに何も伝えられないのか、と不安になるかもしれませんが、そうではありません。指揮命令にあたらない範囲であれば、発注側はベンダー側の責任者を通じて十分に意向を反映できます。
- 問題になりにくい関わり方：要件・優先順位・期待する成果物を伝える／成果物のレビューとフィードバックを行う／定例会で進捗や課題を確認する／ベンダー側の責任者と調整する
- 問題になりやすい関わり方：個々の作業者に対して作業手順や時間配分を直接指示する／勤怠・残業を発注側が管理する／作業者を自社の指揮系統に組み込む
ポイントは「何を・いつまでに（What/When）」は発注側が示してよいが、「誰が・どうやって（Who/How）」はベンダー側に委ねる、という線引きです。詳細は準委任契約の注意点と発注側の関わり方も参考になります。
よくある失敗例
- 成果物の定義が曖昧：「要件定義書を作る」としか合意せず、粒度・項目・フォーマットを決めなかったため、想定と異なるドキュメントが納品された。
- 契約切り替えの遅れ：要件定義が終わっても準委任のまま開発に突入し、完成責任の所在が不明確なまま炎上した。
- 上限工数の未設定：履行割合型で工数上限を決めず、ヒアリングが長期化して費用が当初想定の2倍に膨らんだ。
こうした失敗の多くは、要件定義の品質と契約設計の甘さに起因します。開発全体で起きがちな失敗の全体像はシステム開発が失敗する7つのパターンも参考にしてください。
フェーズ別の契約形態の使い分け例
Photo by Paper Textures on Unsplash
要件定義・基本設計は準委任、詳細設計以降は請負
システム開発プロジェクトでよく見られる契約構成として、上流工程（要件定義・基本設計）を準委任契約、下流工程（詳細設計・開発・テスト）を請負契約とする分け方があります。
上流工程は不確実性が高く、発注側とベンダーが協力して成果物を作り上げるプロセスが中心になります。一方、詳細設計以降は要件が固まった状態で進めるため、成果物の完成を保証する請負契約が適しています。
ただし、基本設計の段階でも要件の変動が大きいプロジェクトでは、基本設計まで準委任で進めるケースもあります。一律のルールはなく、プロジェクトの性質に応じた判断が求められます。
アジャイル開発における準委任契約の活用
アジャイル開発では、スプリントごとに機能を積み上げていくため、最終的な成果物を事前に確定することが難しいです。このため、アジャイル開発全体を準委任契約（履行割合型）で進めるケースが増えています。
スプリントごとに作業内容と工数を合意し、完了後に報告・請求するサイクルを繰り返す形が一般的です。発注側は進捗を細かく確認できる反面、最終的なコストが見えにくくなるリスクもあるため、予算の上限管理や定期的なスコープ見直しの仕組みを設けることが重要です。アジャイル外注時の契約の選び方はアジャイル開発の外注で使われる契約形態で詳しく解説しています。
契約・条文の最終的な解釈や個別案件への当てはめは、必ず弁護士など専門家に確認することをおすすめします。本記事は一般的な実務上の考え方を整理したものであり、特定の契約内容を保証するものではありません。
次に読むべき記事
FAQ：要件定義の準委任契約に関するよくある質問
要件定義は準委任と請負のどちらがいいですか？
要件が流動的で完成形を契約時点で確定しにくい要件定義フェーズでは、準委任（特に履行割合型）が基本的に向いています。一方、要件が固まり成果物を明確に定義できる段階や、詳細設計以降は請負が向きます。「準委任が基本だが、完成形を確定できる範囲は請負・成果完成型に寄せる」という設計が発注側にとって扱いやすい考え方です。
要件定義フェーズに請負契約を使うとどんなリスクがありますか？
要件が固まっていない段階で請負契約を締結すると、「何をもって完成とするか」が不明確なまま進行するリスクがあります。仕様変更のたびに変更契約が必要になり、発注側・ベンダー双方の負担が増えやすいです。また、完成義務を負うベンダーが過度に慎重になり、柔軟な提案がしにくくなるケースもあります。
請負契約のデメリットは何ですか？
請負契約は完成形が固まっていないと向きません。仕様が確定しない段階で結ぶと、変更のたびに変更契約や追加見積もりが必要になり、コストと調整負担が増えます。また、完成義務があるためベンダーがリスクを価格に織り込みやすく、初期見積もりが高くなる傾向もあります。要件定義のように内容が流動的なフェーズでは、準委任の方が適していることが多いです。
準委任と請負の違いを一言で言うと何ですか？
準委任は「業務の遂行」に対価を払う契約、請負は「成果物の完成」に対価を払う契約です。準委任には成果物の完成義務がなく、請負には完成義務と契約不適合責任があります。完成形が読みにくい要件定義は準委任、仕様が固まった開発・テストは請負が向く、という使い分けが基本です。
準委任契約と派遣契約はどう違いますか？
最大の違いは「作業者に指揮命令する側」です。準委任ではベンダー（受託側）が作業者を指揮し、発注側は直接指示できません。労働者派遣では発注側（派遣先）が派遣契約の範囲内で作業者に直接指示できます。準委任で発注側が常駐エンジニアに直接指示を出すと、偽装請負と判断されるリスクがあるため注意が必要です。
準委任契約で発注側はどこまで指示できますか？
「何を・いつまでに（要件・優先順位・期限・期待する成果物）」は発注側が示してよく、レビューやフィードバック、定例会での進捗確認も問題ありません。一方で「誰が・どうやって（作業手順・時間配分・勤怠管理）」を個々の作業者に直接指示するのは避け、ベンダー側の責任者を通じて調整します。
要件定義は発注側の責任ですか？
要件定義は発注側とベンダーの協働で進めますが、「何を実現したいか」という業務要件の方向づけは発注側の責任です。準委任契約ではベンダーが成果物の完成を保証しないため、発注側がヒアリングやレビューに関与しないと要件の精度が落ちます。技術的な整理・ドキュメント化はベンダーが担い、業務知識と意思決定は発注側が担うのが基本的な役割分担です。
準委任契約の具体例にはどのようなものがありますか？
システム開発では、要件定義のヒアリング・業務分析、基本設計、運用保守、技術コンサルティング、アジャイル開発の伴走支援などが準委任契約の代表例です。いずれも「成果物の完成」ではなく「専門的な業務の遂行」に対して報酬を支払う点が共通しています。
要件定義は発注側とベンダーのどちらが主体で進めるべきですか？
準委任契約では、発注側とベンダーが協働で進めるのが前提です。業務知識や要望は発注側が、技術的な整理・ドキュメント化はベンダーが担うのが一般的な役割分担です。発注側がヒアリングやレビューに十分関与しないと、要件の精度も進捗も落ちやすくなります。
準委任契約で要件定義書を作成した場合、成果物の所有権はどちらになりますか？
一般的には、契約書に著作権・所有権の帰属を明記しておく必要があります。明記がない場合、著作権はベンダー側に残るリスクがあります。発注側が要件定義書を自由に利用・改変したい場合は、著作権の譲渡または利用許諾の条項を契約書に盛り込むことを検討してください。
準委任契約でもベンダーに責任を問えますか？
成果物の完成に関する責任は問いにくいですが、善管注意義務違反があった場合は損害賠償を請求できる可能性があります。たとえば、明らかなリスクを報告せずに業務を進めた、専門家として不適切な判断をしたといったケースが該当しうります。ただし、立証には一定のハードルがあるため、トラブルを防ぐには契約時の報告義務・作業範囲の明確化が有効です。
要件定義が終わったら自動的に請負契約に切り替わりますか？
自動的には切り替わりません。フェーズが変わるたびに新たな契約を締結するか、基本契約に個別契約を追加する形で対応するのが一般的です。要件定義フェーズの完了条件と次フェーズの契約締結スケジュールをあらかじめ合意しておくことが重要です。
準委任契約の履行割合型と成果完成型はどう使い分ければよいですか？
要件が流動的で作業範囲が変わりやすい初期段階では履行割合型、要件定義書の完成版納品など成果物が明確に定義できる段階では成果完成型が向いています。プロジェクトの進捗に応じて途中で切り替えることも可能です。
要件定義の準委任契約で費用が膨らんだ場合、どう対処すればよいですか？
履行割合型では工数に応じて費用が発生するため、スコープが広がると費用が増えやすいです。対策としては、月次・スプリント単位で作業内容と工数の上限を合意する、定期的な進捗報告で費用の見通しを確認する、追加作業が発生した際は都度合意を取るといった管理プロセスを設けることが有効です。
アジャイル開発でも準委任契約は使えますか？
使えます。むしろアジャイル開発との相性は高く、スプリントごとに作業範囲と工数を合意しながら進める形が広く採用されています。ただし、発注側がスプリントレビューや進捗確認に積極的に関与できる体制を整えることが、プロジェクトを健全に進める上で重要です。
なお、契約・条文の最終的な解釈や個別案件への適用は、弁護士など専門家への確認をおすすめします。
