BLOG

準委任契約とは ― システム開発での使いどころと、請負契約との違い

「準委任は成果物がないと聞いた。お金を払って何も残らないのでは」「請負にしたいと言ったら、要件が決まっていないので準委任でと言われた。不利な契約ではないのか」。契約の形をめぐるご相談で、準委任契約はもっとも誤解の多い言葉です。

準委任契約は、業務を適切に行うことに対して報酬を支払う契約です。成果物が出ないわけではなく、「決めた成果物の完成を約束しない」だけです。要件を探りながら進める工程や、使いながら改善していく開発では、この形のほうが実態に合います。

この記事では、準委任契約とは何か、請負契約と何が違うのか、システム開発のどの工程に向いているのか、そして起きやすい失敗と避け方を、両方の契約で開発を行っている当社の視点で整理します。

システム開発の工程のうち、要件定義と運用は準委任、仕様が固まった後の設計から開発・テストまでは請負で契約する。工程ごとに契約を分けるのが基本

この記事を書いた人

wesionaryTEAM 編集チーム

株式会社wesionaryTEAMのプロジェクトマネージャーとエンジニアで構成する編集チームです。業務システム開発、AI導入支援、DX推進の案件で日々得ている知見をもとに、検討中の方が判断に使える情報を、事例と数字を添えてお届けします。

準委任契約とは

準委任契約は、民法656条に根拠があります。委任契約(民法643条)は法律行為を他人に委ねる契約で、法律行為でない事務の委託にその規定を準用するのが準委任です。システム開発は法律行為ではないため、開発会社に業務を委ねる契約は準委任になります。

受任者である開発会社は、民法644条により「善良な管理者の注意」をもって業務を行う義務を負います。専門家として通常期待される水準で仕事をする義務であり、手を抜いてよい契約ではありません。

報酬には2つの型があります。業務を行った時間や期間に応じて支払う履行割合型と、業務によって得られる成果に対して支払う成果完成型です。後者は2020年4月施行の改正民法で条文に明記されました(民法648条の2)。成果完成型であっても請負とは異なり、成果の完成そのものを約束する契約ではありません。

請負契約との違い

準委任契約請負契約
報酬の対象業務の遂行仕事の完成
完成責任なしあり
不具合への責任善管注意義務の範囲契約不適合責任
途中の解除各当事者がいつでも可能発注側は損害を賠償して可能

請負契約は、民法632条のとおり仕事の完成に対して報酬を支払う契約です。完成しなければ報酬を請求できず、納品物が契約の内容に適合しなければ、発注側は追完や報酬の減額を求められます。請負開発とはで詳しく整理しています。

途中の解除も違います。準委任は民法651条により各当事者がいつでも解除できます(相手に不利な時期の解除には損害賠償が必要です)。請負は民法641条により、発注側は完成前にいつでも解除できますが、開発会社の損害を賠償する必要があります。

どちらの契約でも、発注側が開発会社のエンジニアに直接業務の進め方や労働時間を指示すると、いわゆる偽装請負として労働者派遣法に違反するおそれがあります。厚生労働省の疑義応答集は、この判断は契約の形式ではなく実態で行われ、準委任でも同じだとしています。

「成果物がない」は誤解です

準委任契約でも、要件定義書、設計書、動くソフトウェアといった成果物は出ます。違いは、それらが「決めた仕様どおりに完成したこと」に対して報酬を払うのか、「専門家として適切に業務を行ったこと」に対して払うのかです。

言い換えると、準委任で発注側が買っているのは、不確実な状況で判断しながら進める専門家の時間と能力です。何を作るかが決まっていないのに完成を約束させると、開発会社はリスク分を上乗せするか、範囲を狭く解釈するしかありません。準委任は、その無理をなくすための形です。

その代わり、何に取り組むかの優先順位は発注側が持ち続ける必要があります。ここを手放すと、時間だけが過ぎる契約になります。

システム開発で準委任が向いている工程

  • 要件定義。何を作るかを決める工程は、決める前に完成を約束できません。要件定義を準委任で行い、固まった仕様をもとに開発を請負で見積もる進め方が一般的です。
  • アジャイル開発。短い周期で作っては確かめる開発は、途中で優先順位が変わります。IPAの「情報システム・モデル取引・契約書(アジャイル開発版)」も、準委任契約を前提にしています。
  • 試験導入(PoC)と実用最小限の製品(MVP)。検証の結果で次に作るものが変わるため、固定の成果物を約束する形になじみません。
  • 運用と保守、内製化の支援。期間を決めて専門家が伴走する業務は、準委任の典型です。

反対に、仕様書がそろっている作り直しや移行のように、作るものが決まっている工程は請負が向きます。

準委任の費用はどう決まるか

履行割合型では、体制(人数と役割)と期間で金額が決まります。月額で人数分を支払う形が多く、1人あたりの単価は役割と経験で変わります。見積もりでは、誰がどのくらいの割合で関わるかを確認してください。

成果完成型では、合意した成果(たとえば要件定義書一式、検証結果の報告書)に対して金額を決めます。請負に近く見えますが、成果の完成そのものを約束する契約ではないため、何をもって成果とするかの定義が重要になります。

いずれの型でも、期間と予算の上限、超えそうなときの相談の手順を決めておくと、費用が見えないまま進む事態を避けられます。

準委任で起きやすい失敗と、避け方

  • 時間だけが過ぎる。目的を決めずに人を確保すると、動いているのに前に進まない状態になります。期間ごとに「何が分かれば次に進めるか」を決め、終わりの条件を先に置いてください。
  • 直接指示をしてしまう。発注側の担当者が、開発会社のエンジニアに作業の順番や残業を直接指示すると偽装請負のおそれがあります。要望は発注側の責任者から開発会社の責任者へ伝え、進め方の判断は開発会社に残します。厚生労働省の疑義応答集は、密に連携し助言や提案をし合っても、対等な関係のもとで受注側が自律的に判断していれば偽装請負にはあたらないとしています。
  • 報告が見えない。何にどれだけ時間を使ったかが分からないと、費用の妥当性を判断できません。週次の報告と、残っている作業の一覧を契約に含めてください。
  • 終わり方を決めていない。準委任には「完成」がないため、何が分かれば、何ができれば終わりかを決めていないと、区切りがつきません。期間の終わりに判断する項目を、契約時に書いておきます。
  • 範囲が広がり続ける。準委任は変更に強い反面、歯止めがありません。期間と予算の上限、見直しのタイミングを最初に決めます。

工程ごとに契約を分ける

準委任か請負かは、プロジェクト全体で一つに決める必要はありません。経済産業省とIPAの「情報システム・モデル取引・契約書」は、工程ごとに契約を結ぶ多段階契約の形を採っています。

当社がよく提案するのは、要件定義を準委任で行い、仕様が固まった設計から開発・テストを請負で契約し、公開後の運用と改善を再び準委任で続ける組み合わせです。決まっている部分には完成の責任を、決まっていない部分には柔軟さを、それぞれ割り当てます。

なお、ここでの説明は一般的な整理です。個別の契約については、契約書の文面と、必要に応じて専門家の確認をお願いします。

よくあるご質問

準委任契約では、不具合があっても直してもらえないのですか?

直してもらえます。開発会社は善管注意義務を負っており、専門家として通常期待される水準を下回る仕事には責任が生じます。ただし請負の契約不適合責任とは根拠が異なるため、不具合対応の範囲は契約書で確認してください。

準委任とSESは同じですか?

SES(システムエンジニアリングサービス)は、エンジニアの稼働を提供するサービスの呼び名で、契約の形としては多くが準委任です。準委任はより広い言葉で、要件定義の支援や運用保守も含みます。

準委任契約で、発注側が開発者に直接要望を伝えてもよいですか?

要望や情報の共有はかまいませんが、作業の進め方や労働時間を直接指示すると偽装請負のおそれがあります。役割と窓口を契約時に決めておいてください。

準委任の費用はどう決まりますか?

人数と期間(履行割合型)、または合意した成果(成果完成型)で決まります。月額で人数分を支払う形が多く、見積もりの前提になる期間と体制を確認してください。

準委任で始めて、途中から請負に切り替えられますか?

切り替えられます。要件定義を準委任で行い、仕様が固まった時点で開発を請負として見積もり直す進め方は一般的です。

まとめ

準委任契約は、業務の遂行に対して報酬を支払う契約で、成果物の完成を約束しない代わりに、決めながら進める工程に向いています。成果物が出ないわけではなく、優先順位の判断を発注側が持ち続けることが条件です。

要件定義や改善の工程は準委任、仕様が固まった開発は請負、と工程で分けるのが基本です。どの工程をどの形で進めるか、無料見積相談で担当PMが一緒に整理します。

関連する記事とページ

出典

この記事の監修者

永田 一郎代表取締役

ヤフー(Yahoo! JAPAN)のエンジニア出身。スタートアップ、大手事業会社にて18年以上にわたり、toC/toB向けの新規事業開発、業務DX化など、多種多様なプロジェクトに従事。エンジニアとして自ら開発に携わる一方、体制構築やマネジメント、事業設計、仮説検証にも関わり、事業の立ち上げとグロースを幅広く体得。これまでに三回の事業売却を経験。共創でより効果的にプロダクトをつくり、アイディアをマーケットで検証できることを確信し、共創プラットフォームを提供するため wesionaryTEAM を創業。