業務委託エンジニアの契約形態の選び方｜請負・準委任と発注前の合意事項

業務委託エンジニアへの発注を検討する際、最初に立ち止まる意思決定が「請負契約と準委任契約のどちらを選ぶべきか」という問いではないでしょうか。社内の過去契約を見ると両者が混在しており、明確な選択基準が言語化されていない。法務部に相談しても「業務実態に合わせて事業部で決めてほしい」と差し戻される。そんな状況に置かれている発注担当者は少なくありません。

契約形態の選択を曖昧にしたまま稼働を始めてしまうと、稼働後に「成果物の範囲が想定と違った」「準委任なのに完成責任を求められて困った」といった齟齬が必ず表面化します。揉めごとの根は、稼働中の運用ではなく、稼働を始める前の契約形態の選択にあるケースが大半です。

本記事では、業務委託エンジニア（フリーランス・複業エンジニア）への発注を前提に、請負と準委任の選び方を業務内容と紐づけて整理します。さらに、契約形態を決めた後、稼働開始前に相手と合意しておくべき5項目をチェックリスト形式で提示し、選択段階で陥りがちな判断ミスとその回避策を解説します。

スコープは発注前から契約締結時点までに限定し、稼働開始後の検収運用や品質管理の仕組みは別記事に譲ります。読み終えた時点で、自社の発注内容に合った契約形態を選定でき、キックオフの場で業務委託エンジニアと合意すべき項目を漏れなく持ち出せる状態を目指します。

業務委託エンジニアへの発注で「契約形態の選択」が最初の分岐点になる理由

業務委託エンジニアへの発注で発生するトラブルの多くは、稼働開始後の運用ミスではなく、契約形態を曖昧にしたまま稼働を始めたことに起因します。請負と準委任では「何をもって完了とするか」が根本的に異なるため、契約形態の選択がその後の検収運用・修正対応・報酬支払いのすべてを規定します。

業務委託エンジニアと「個人」前提の特殊性

業務委託エンジニアへの発注は、システム開発会社（ベンダー法人）への外注とは運用粒度が大きく異なります。ベンダー法人に発注する場合、相手側のプロジェクトマネージャーが社内の開発体制を統制し、品質保証部門が成果物をチェックした上で納品物が手元に届きます。

一方、業務委託エンジニア個人への発注では、開発・進捗管理・品質確認のいずれも個人の責任範囲に収まります。発注者側が「相手の社内プロセスに乗っかる」ことができないため、月次レビューや成果物確認の頻度・方法を発注者側があらかじめ設計しておく必要があります。この前提が、契約形態の選択にも影響します。具体的には、ベンダー法人なら請負一択で済むケースでも、業務委託エンジニア個人の場合は「成果物の範囲が事前に固まりきっていない」「要件が稼働中に変動する」といった状況が多く、準委任の方が適切なケースが増えます。

契約形態の選択が後工程をすべて規定する理由

請負契約と準委任契約は、報酬支払いの根拠が異なります。請負は「仕事の完成」が報酬請求権の発生条件であり、成果物が完成・引渡しされなければ報酬を請求できません（業務委託契約の基本｜BUSINESS LAWYERS）。準委任は「事務処理の遂行」が報酬の対象であり、稼働の事実（履行割合型）または合意した成果の達成（成果完成型）が報酬支払いの基準になります。

この違いは、稼働後のすべての運用に波及します。たとえば、修正対応が「請負における契約不適合責任の履行」なのか「準委任における追加業務」なのかで、追加報酬の発生有無が変わります。月次レビューが「進捗確認のための面談」なのか「中間検収」なのかでも、相手が用意すべき資料の粒度が変わります。

つまり、契約形態を選択することは、検収のあり方・修正対応のルール・確認頻度・契約不適合責任の範囲を同時に決定することと等しいといえます。だからこそ、稼働を始める前にここを固めなければ、後工程の運用設計が成り立ちません。

本記事のスコープと稼働後の運用との関係

本記事は「発注前から契約締結時点まで」の意思決定にスコープを絞っています。具体的には、契約形態（請負・準委任）の選び方と、稼働開始前のキックオフで合意すべき項目の整理です。

稼働開始後の検収運用、たとえば中間品質チェックの仕組み、週次月次レビューの進め方、検収時のチェックリスト、社内エンジニア不在時の品質確認方法などは、すでに別記事「業務委託エンジニアの成果物検収・品質管理を仕組み化する方法」でまとめています。本記事で契約形態と事前合意を整えた後、稼働フェーズに入る前に同記事を参照する流れを想定してください。

なお、システム開発の検収プロセス全般については「システム開発の検収」でも解説しています。発注者として知っておくべき検収の合否判断基準を一般論として押さえたい場合は、あわせて参照してください。

業務委託エンジニアの契約形態の選び方（請負／準委任）

業務委託エンジニアへの発注で選択肢となる契約形態は、大きく分けて「請負契約」「準委任契約（履行割合型）」「準委任契約（成果完成型）」の3つです。それぞれで「何をもって完了とするか」が異なり、業務の性質によって適切な選択肢が変わります。

請負契約 — 「成果物の完成」が完了の基準

請負契約は、受注者が「仕事の完成」を約束し、発注者がその完成に対して報酬を支払う契約形態です。完成した成果物が発注者に引き渡されてはじめて報酬請求権が発生します。

請負の最大の特徴は、受注者に「契約不適合責任」が課される点です。これは、納品された成果物が契約の内容に適合していなかった場合（バグ・仕様未達など）、受注者が無償で修補する義務を負う制度です。2020年4月施行の改正民法により「瑕疵担保責任」から「契約不適合責任」に整理され、修補請求・代金減額請求・損害賠償請求・契約解除のすべてが発注者の権利として明文化されました。

向いている業務は、たとえば次のようなものです。

• 仕様が確定している小〜中規模機能の実装（ログイン機能・決済機能の追加など）
• 既存システムからの単発的なデータ移行
• 単発の管理画面・社内ツールの新規開発

これらは「完成形」を発注前に言語化できる業務であり、成果物の範囲を契約書・仕様書で固定できることが請負を選ぶ前提になります。

準委任契約（履行割合型）— 「稼働の事実」が完了の基準

準委任契約の履行割合型は、受注者が一定の事務処理を「善管注意義務」（善良な管理者の注意義務）をもって遂行することを約束する契約形態です。報酬は稼働時間や履行割合に応じて支払われます。

履行割合型では、受注者は「成果物を必ず完成させる責任」を負いません。あくまで「合意した稼働時間内で、専門家として注意深く業務を遂行する」ことが義務であり、結果として成果物が完成しなくても、稼働した時間分の報酬を請求できる構造です（準委任契約の履行割合型とは｜クロスデザイナー）。

業務委託エンジニアの世界では、いわゆる SES 契約（システムエンジニアリングサービス契約）がこの履行割合型に該当します（準委任契約に検収は必要？｜マネーフォワードクラウド会計）。月稼働160時間で月額固定報酬、稼働超過分は時間単価で精算、といった契約条件はその典型です。

向いている業務は、たとえば次のようなものです。

• 要件が稼働中に変動する長期プロジェクト
• 既存システムの保守・運用
• 技術顧問・アドバイザー業務
• アジャイル開発のチーム参画

これらは「完成形」を発注前に固定しづらく、稼働中に優先順位や仕様が変動する業務です。請負で受けようとすると、要件変更のたびに契約変更が必要になり運用が回らないため、稼働ベースで報酬を支払う準委任が適合します。

準委任契約（成果完成型）— 「成果の達成」が完了の基準

準委任契約の成果完成型は、2020年4月の改正民法で明文化された契約形態です。「成果物の引渡し」に対して報酬を支払う構造で、一見すると請負契約に似ています。しかし、受注者が「成果物を必ず完成させる責任」を負わない点が請負と決定的に異なります（準委任契約の成果完成型とは｜Workship ENTERPRISE）。

成果完成型では、合意した成果（たとえば「調査レポートの提出」「設計書の完成」など）が達成されれば報酬が支払われますが、達成できなかった場合の責任の重さが請負ほど厳格ではありません。契約不適合責任に類する仕組みも、契約書で個別に定めない限り当然には発生しないという整理です。

向いている業務は、たとえば次のようなものです。

• 技術調査・PoC（概念実証）の実施
• アーキテクチャ設計書の作成
• 業務フロー分析と提言書の提出

「成果物の形」は事前に決められるが、完成義務を負わせるほど業務範囲を厳格に固定できない（あるいは固定すべきでない）業務が該当します。

業務内容別の推奨契約形態

ここまで整理した3つの契約形態を、業務委託エンジニアへの発注パターンに当てはめると、おおむね次のようなマッピングになります。

このマッピングはあくまで一般論であり、自社の業務実態に照らして判断する必要があります。

判断に迷うケースと選択の優先順位

実務では「請負か準委任か」の判断に迷うケースが頻発します。たとえば「機能開発だが、要件が稼働中に変動しそう」「技術調査の後そのまま実装に入る予定」といった、性質が混在する業務です。

このとき、契約形態を選ぶ優先順位は次のように整理できます。

1. 成果物の明確性: 完成形を契約書・仕様書で明確に固定できるか。固定できないなら請負は避ける
2. 継続性: 単発か継続的か。継続的なら準委任（履行割合型）が運用しやすい
3. 指揮命令の必要性: 稼働中に「やってほしいことを都度指示する」必要があるか。必要なら請負では運用が回らない（指揮命令を業務委託で行うと偽装請負のリスクもあり、後述します）

迷ったときは、「成果物の範囲を発注時点で完全に固定できないなら準委任」と覚えておくとよいでしょう。請負を選ぶには「完成形の言語化」が不可欠であり、それができない時点で請負契約は機能しません。

稼働開始前に業務委託エンジニアと合意すべき5項目

契約形態を決めたら、次は稼働開始前のキックオフで業務委託エンジニアと「実務レベルで合意すべき項目」を整理します。契約書のひな型に書いてある条文ではなく、現場で齟齬を生まないために必要な合意事項です。以下の5項目をチェックリストとして活用してください。

1. 成果物の範囲（コード・ドキュメント・引継ぎ事項の明示）

最も齟齬が生まれやすいのが「何を成果物として納品するか」の認識のずれです。コードだけを成果物と考える発注者と、コード＋設計書＋運用手順書を当然と考える業務委託エンジニアの間でズレが生じると、稼働終盤に「ドキュメントが不足している」「引継ぎが受けられない」といった問題が表面化します。

合意すべき具体的項目は次のとおりです。

• 納品対象のコード（リポジトリ単位なのか、ブランチ単位なのか）
• ドキュメント類（README・設計書・API仕様書・運用手順書のうちどれを含むか）
• 引継ぎ事項（稼働終了時の知識移管の有無・形式・所要時間）
• 著作権の帰属（成果物の著作権を発注者に譲渡するか、利用許諾にとどめるか）

請負契約の場合、これらの範囲が不明確だと「契約不適合責任の対象」も曖昧になり、後の修正対応で揉めます。準委任契約でも、何を稼働の成果として扱うかをすり合わせておかなければ、月次の進捗確認が機能しません。

2. 完了の判断基準（受け入れ条件 Acceptance Criteria の言語化）

「完了とはどういう状態か」を、発注者と業務委託エンジニアが同じ言葉で合意することが不可欠です。具体的には、機能ごとに「受け入れ条件（Acceptance Criteria）」を箇条書きで定義します。

たとえばログイン機能であれば、次のような形です。

• 登録済みメールアドレス＋正しいパスワードでログインできる
• 誤ったパスワードを3回入力するとアカウントがロックされる
• パスワードリセット用のメールが指定アドレスに届く
• ロック解除はメール認証で行える

このように、誰が見ても合否を判断できる粒度で言語化することが重要です。「動くこと」「問題なく使えること」といった抽象的な表現は、稼働終盤の検収で必ず齟齬を生みます。

受け入れ条件の合意は、請負契約では契約不適合責任の起点となり、準委任契約では月次レビューや成果完成判定の判断材料となります。契約形態を問わず、最も力を入れて言語化すべき項目です。

3. 確認頻度とタイミング（週次／月次／プロジェクト完了時のレビュー形式の事前合意）

稼働中の確認頻度を事前に合意しておくことで、稼働終盤の「想定と違った」を防げます。週次・月次でどのような粒度のレビューを行うか、相手にどんな資料を準備してもらうかを決めておきます。

業務委託エンジニアの稼働実態はベンダー法人とは異なるため、発注者側が積極的にレビューの場を設計しなければ、稼働終盤までブラックボックスになりがちです。事前合意は契約書ではなくキックオフの議事録レベルでよいので、稼働開始前に必ず擦り合わせます。

4. 不合格・修正対応のルール（修正範囲・期限・追加報酬の扱い）

「検収で不合格となった場合の修正対応」を事前に合意しておくと、稼働終盤の揉めごとを大幅に減らせます。論点は次の3つです。

• 修正範囲: 受け入れ条件を満たさない場合の修正はどこまで含むか（軽微な調整・仕様変更・要件追加のどこまでが修正対応か）
• 期限: 修正対応の期限はどう設定するか（不合格通知から何日以内に再納品か）
• 追加報酬の扱い: 修正範囲を超える対応（仕様変更・追加要件）が発生した場合、追加報酬をどう精算するか

請負契約の場合、契約不適合責任に基づく修補は無償で行われるのが原則ですが、何が「契約に適合していない」のか、何が「追加要件」なのかは契約書とキックオフでの合意の擦り合わせで決まります。準委任契約の場合は、そもそも修正対応が稼働時間に含まれるのか、別途稼働として扱うのかを明確にする必要があります。

5. 契約不適合責任の期間と範囲（請負）／善管注意義務の確認（準委任）

契約形態ごとに、稼働終了後に発注者が主張できる権利が異なります。請負契約の場合は契約不適合責任、準委任契約の場合は善管注意義務の解釈が論点になります。

請負契約の場合:

• 契約不適合責任の期間（改正民法では「不適合を知ったときから1年以内に通知」が原則。通知後の修補請求・損害賠償請求等の権利行使はその後でも可能。契約書で別途期間を定めることも可能）
• 責任の範囲（修補請求・代金減額・損害賠償・契約解除のうちどれが対象か）
• 免責事項（発注者の指示に起因する不適合は責任を問わない、などの除外規定）

準委任契約の場合:

• 善管注意義務の解釈（業務委託エンジニアが専門家として尽くすべき注意の範囲）
• 報告義務の頻度・内容（稼働報告のフォーマット・提出頻度）
• 中途解約時の精算ルール（履行割合に応じた報酬計算の方法）

これらは契約書のひな型に条文として記載されているはずですが、業務委託エンジニア個人との契約では、ひな型の条文をそのまま使うと業務実態と合わないことがあります。法務部任せにせず、事業部側がキックオフ前に内容を理解し、必要に応じて修正する姿勢が求められます。

契約形態の選択でよくある判断ミスと回避策

ここまでで「請負か準委任か」「事前合意5項目」を整理しましたが、実務では契約形態の選択段階で典型的な判断ミスが発生します。代表的な3パターンとその回避策を解説します。

「成果物が曖昧なまま請負契約を選んでしまう」パターン

最もよくある失敗が、成果物の範囲が固まりきっていない段階で請負契約を選んでしまうケースです。「請負の方が成果物がはっきりするから安心」という発想で選択するケースが多いですが、成果物の言語化が不十分なまま請負を選ぶと、稼働終盤に必ず揉めます。

典型的な経過は次のとおりです。

1. 発注時点で「ECサイトのカート機能を作る」と発注。詳細仕様は稼働中に決める方針
2. 稼働中に発注者側から仕様変更が複数回入る
3. 検収段階で「最初に話した内容と違う」「これは仕様変更だから追加報酬」と業務委託エンジニア側が主張
4. 発注者は「請負なんだから完成義務を果たして」と反論
5. どちらの主張も契約書上は成り立つため、結論が出ない

回避策は、成果物の範囲を契約書または仕様書で固定できない時点で請負を諦めることです。代わりに準委任（履行割合型）を選び、稼働中に仕様を固めながら進める運用に切り替えます。請負を選ぶには「受け入れ条件まで含めて発注前に言語化できる」ことが前提条件であり、それができないなら準委任の方が安全です。

「準委任なのに『成果物の完成』を期待してしまう」パターン

次に多いのが、準委任契約を結んでおきながら、運用上は請負と同じ期待を持ってしまうケースです。「月額80万円も払っているのだから、当然この機能は完成させてくれるはず」という発想で稼働を始めると、月末に「機能の3割しか進んでいない」状態を業務委託エンジニア側に問題視できず、ストレスだけが溜まります。

このパターンが発生する根本原因は、準委任契約の本質「稼働時間の提供」を発注者が理解しきれていないことにあります。履行割合型の準委任では、合意した稼働時間内で善管注意義務を果たすことが業務委託エンジニアの責任であり、特定機能の完成は契約上の責任には含まれません（準委任契約の成果物責任とは｜Workship ENTERPRISE）。

回避策は2つあります。

1. 準委任の本質を理解した上で運用設計を行う: 月次レビューで「稼働時間の使い方が妥当か」「優先順位の判断は適切か」を確認する。完成のスピードは発注者側の優先順位設定の質に依存することを受け入れる
2. 成果完成型の準委任に切り替える: 「成果物の達成」を報酬の条件にしたい場合は、履行割合型ではなく成果完成型を選ぶ。ただし成果完成型でも「完成義務」は請負ほど厳格ではないため、受け入れ条件の言語化が引き続き重要

「指揮命令の必要性を見落とす」パターン（偽装請負リスク）

第3のパターンは、稼働中に発注者から業務委託エンジニアへ「直接指揮命令」を行う必要があるにもかかわらず、業務委託契約（請負・準委任のいずれか）を結んでしまうケースです。これは偽装請負と呼ばれる違法な状態に該当する可能性があり、職業安定法第64条第9号違反として1年以下の拘禁刑又は100万円以下の罰金が科される恐れがあります（偽装請負について｜東京労働局）。

厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」では、業務委託として適法に成立するためには、業務遂行に関する指示・労働時間や休暇の勤務管理を受注者側が自ら行うことなどの要件を満たす必要があるとされています。具体的には、業務委託エンジニアに対して、発注者の社員と同じように「明日はこの作業をやってください」「今日は何時に出社してください」と指示する状態は、偽装請負と判断されるリスクがあります。

回避策は次のとおりです。

1. 稼働中に都度指示が必要な業務は、業務委託ではなく労働者派遣を選ぶ: 厚生労働省の許可を得た派遣会社経由でエンジニアを受け入れることで、直接指揮命令が適法になる
2. 業務委託で進めるなら、業務の単位を「タスク」ではなく「アウトプット」で渡す: 「ログイン機能を◯月◯日までに納品してください」「週次でレビューします」という運用にすることで、直接指揮命令を回避する
3. 勤怠管理を発注者側で行わない: 出退勤時刻・休暇取得を発注者側で管理せず、業務委託エンジニアの裁量に委ねる

業務委託エンジニア個人との契約では、距離感が近くなりがちで、つい指揮命令的な関わりをしてしまうことがあります。契約形態を選ぶ段階で「自社の運用が偽装請負に該当しないか」を必ずチェックしてください。

契約形態と事前合意を整えた後の次のステップ

ここまでで、業務委託エンジニアへの発注における契約形態の選び方と、稼働開始前に合意すべき5項目を整理しました。最後に、本記事の内容を振り返り、次のアクションへの接続を確認します。

契約形態選択と事前合意の振り返りチェック

稼働開始前に、以下のチェックリストで意思決定の整理状態を確認してください。

• 発注内容の業務パターン（機能追加・保守運用・調査・顧問など）が明確になっているか
• 業務パターンに対応する推奨契約形態（請負・準委任の履行割合型/成果完成型）を選定したか
• 成果物の範囲（コード・ドキュメント・引継ぎ事項・著作権帰属）を業務委託エンジニアと合意したか
• 完了の判断基準（受け入れ条件）を機能ごとに言語化したか
• 確認頻度とタイミング（週次・月次・最終レビュー）の運用ルールを合意したか
• 不合格時の修正対応ルール（範囲・期限・追加報酬の扱い）を合意したか
• 契約不適合責任（請負）または善管注意義務（準委任）の解釈を契約書で確認したか
• 偽装請負リスクの観点で、業務委託として適法に運用できる状態か確認したか

これらがすべて整理できていれば、稼働開始の準備は整っています。

稼働開始後の検収・品質管理運用への接続

稼働を開始した後は、設計した運用を実際に回していくフェーズに移ります。週次・月次のレビュー、中間品質チェック、検収時の合否判断といった具体的な運用方法については、姉妹記事「業務委託エンジニアの成果物検収・品質管理を仕組み化する方法」で詳しく解説しています。

同記事では、社内エンジニア不在時の品質確認方法、稼働中に齟齬を早期に発見する仕組み、検収時のチェックリスト、継続的品質管理体制の構築方法まで踏み込んで整理しています。本記事で契約形態と事前合意を整えた後の運用パートとして、稼働開始前に一読しておくことをおすすめします。

業務委託エンジニア活用全体を継続的に成功させるための視点

業務委託エンジニアの活用は、個別案件ごとに「契約形態の選択」と「事前合意」を繰り返すうちに、自社なりの判断基準が蓄積されていきます。1〜2案件の経験で完成形ができることはなく、複数の発注を経て、業務パターンごとの相場感・運用ノウハウが社内に貯まっていく構造です。

そのため、初回の発注で完璧を目指す必要はありません。本記事で示した5項目を「最低限ここだけは合意する」基準として活用し、稼働中に追加で必要だと気づいた合意事項を、次の発注に反映していく姿勢が現実的です。

業務委託エンジニア個人との発注は、ベンダー法人への外注と比べて運用負荷が高く感じられるかもしれません。しかし、特定領域のスペシャリストを必要な期間だけ柔軟に確保できる点では、社員採用やベンダー外注では得られない大きなメリットがあります。契約形態の選択と事前合意の整理という「最初の意思決定」を丁寧に行うことで、稼働中の運用負荷は大幅に下がります。