準委任エンジニアの善管注意義務とは｜成果を引き出す期待値の伝え方

「準委任契約は、成果物の完成を約束しない契約です」。外部エンジニアへの発注準備を進める中で、こうした説明を受けて手が止まった経験はないでしょうか。社内のリソースが足りず、初めて準委任で開発を任せようとしているのに、「成果を保証しない契約で本当に欲しいものが手に入るのか」という不安が消えない。上司に稟議を上げる立場であれば、なおさら慎重になるはずです。

調べてみると、準委任のエンジニアには「善管注意義務」という法律上の義務があると書かれています。しかし、その義務が具体的に何を担保してくれるのかは、契約書の文言を読んでもなかなか判然としません。「専門家として注意して業務を行う義務」と言われても、それが自社の欲しい成果にどうつながるのか、イメージが湧かないのが正直なところでしょう。

過去に外注で「思っていたものと違う」「進捗が見えないまま納期が来た」という経験をしていれば、不安はさらに大きくなります。契約形態の違い（請負と準委任）はざっくり理解できても、「では発注者として何をどう伝え、どう管理すれば成果につながるのか」という肝心の部分が見えてこないのです。

結論からお伝えすると、準委任契約でも、善管注意義務が担保する範囲を正しく理解し、発注者が期待値を適切に伝えれば、期待どおりの成果は十分に引き出せます。重要なのは「契約形態」そのものよりも、「発注者が何をどう伝え、どう関与するか」という運用の部分です。

本記事では、準委任エンジニアの善管注意義務が何を担保し何を担保しないのかを発注者目線で切り分けたうえで、期待値ギャップが起きる構造、そして契約前・キックオフ・発注後の3場面で期待値をどう伝えるかを実務的に解説します。あわせて、発注者が最も誤りやすい「期待値を伝える」と「指揮命令」の境界線も整理します。読み終えたとき、契約前のすり合わせ事項と発注後のマネジメント方法が具体的に見え、自信を持って発注に踏み切れる状態を目指します。

準委任契約のエンジニアに「善管注意義務」がある理由

「成果を保証しない」という言葉だけが独り歩きすると、準委任契約はまるで「やるだけやって結果は問わない」契約のように聞こえてしまいます。しかし、実際には準委任のエンジニアにも法律上の明確な義務が課されています。まずはその全体像を、発注者の目線で整理しておきましょう。

準委任契約とは何か

準委任契約とは、特定の業務（事務）の遂行そのものを目的とする契約です。請負契約との最大の違いは、「成果物の完成義務があるかどうか」にあります。請負契約が「完成した成果物を引き渡すこと」を約束するのに対し、準委任契約は「専門家として誠実に業務を遂行すること」を約束します。

たとえば「3か月で会員管理システムを完成させて納品する」という約束は請負に近い性質を持ちます。一方、「3か月間、開発チームに参画して設計・実装を担い、専門家として業務を遂行する」というのが準委任の発想です。後者では、完成という結果そのものは契約上の必達義務ではありません。だからこそ「成果が保証されない」と説明されるわけです。請負と準委任のどちらで発注すべきか迷う場合は、請負と準委任の違いもあわせてご確認ください。

ただし、ここで誤解してはいけないのが、「完成義務がない=何の義務もない」ではないという点です。準委任には、完成義務とは別の、もう一つの重要な義務が存在します。それが善管注意義務です。

善管注意義務とは

善管注意義務とは、民法第644条に定められた義務で、正式には「善良な管理者の注意義務」といいます。民法第644条は「受任者は、委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う」と規定しています（マネーフォワード クラウド契約「善管注意義務とは？」）。

この「善良な管理者の注意」とは、平たく言えば「その職業・地位にある人として通常期待されるレベルの注意」を指します。エンジニアであれば、一般的なプロのエンジニアであれば当然払うであろう水準の注意をもって業務に当たることが求められる、ということです。報酬を得て専門業務を引き受けた以上、本人の主観的な「精一杯やった」では足りず、客観的なプロの基準に照らして適切な業務遂行が義務づけられます。

注意したいのは、この義務が契約書に書かれているかどうかに関わらず、法律上当然に発生するという点です。準委任契約を結んだ時点で、エンジニアは自動的に善管注意義務を負います。

「成果は保証しないが、プロとしての遂行は保証する」という構造

ここまでを整理すると、準委任契約は「成果物の完成は約束しないが、プロフェッショナルとして適切に業務を遂行することは約束する」という構造になっています。

つまり「結果」は保証されないものの、「結果に至るプロセスの質」は法的に担保されているのです。発注者が抱きがちな「成果を約束しない契約=何も守られない」という不安は、この構造を理解することでかなり和らぎます。エンジニアは、いい加減な仕事をしてよいわけではなく、むしろプロとして最善を尽くす義務を負っているのです。

とはいえ、「プロとして遂行する義務」が具体的に何を意味するのかが分からなければ、発注者として安心はできません。次に、この善管注意義務が実際に「何を担保し、何を担保しないのか」を具体的に切り分けていきます。

善管注意義務が担保するもの・担保しないもの

発注者が本当に知りたいのは、「結局この義務は何を守ってくれるのか」という点に尽きます。ここを曖昧なままにすると、「準委任は何も担保しない」という誤解か、逆に「準委任でも完成まで責任を持ってくれる」という過剰な期待か、どちらかに振れてしまいます。担保される範囲と担保されない範囲を、はっきり対比して理解しておきましょう。

善管注意義務が担保すること

善管注意義務によって担保されるのは、主に次のような「プロとしての業務遂行の質」です。

• 専門家水準の作業: 一般的なプロのエンジニアであれば当然行う技術的配慮・品質確保を怠らないこと。明らかに不適切な設計や、初歩的なミスの放置は義務違反になり得ます。
• 進捗の報告・相談: 業務の進み具合や問題点を発注者に適切に報告し、判断を仰ぐべき場面では相談すること。準委任契約でも、受任者には報告義務（民法第645条）が課されています。
• リスクの早期共有と警告: 進行上の問題やリスクを認識したら、それを抱え込まず早期に発注者へ伝えること。納期に間に合わない見込みや要件の矛盾に気づいた場合、専門家として警告することも遂行の一部です。
• 発注者の意思決定への協力的な関与: 専門家として、発注者が誤った判断をしようとしている場合に適切な助言を行うこと。

これらは「結果」ではなく「プロセス」に関する担保ですが、発注者にとっては非常に重要な意味を持ちます。少なくとも、いい加減な作業・報告なしの放置・問題の隠蔽といった事態は、善管注意義務によって法的に抑止されているのです。

善管注意義務では担保されないこと

一方で、次の点は善管注意義務では担保されません。

• 特定の成果物の完成: 「このシステムを必ず完成させる」という結果そのものは、準委任契約では保証されません。
• 期日までの目標達成そのもの: 「3か月以内に必ずリリースまで漕ぎ着ける」といった結果のコミットも、原則として契約上の必達義務にはなりません。

ここが請負契約との決定的な違いです。担保されるのはあくまで「プロとして適切に遂行したか」であり、「望んだ結果が出たか」ではありません。

両者を表で対比すると、次のように整理できます。

この切り分けが、後ほど解説する「期待値の伝え方」の土台になります。担保されない「結果」の部分こそ、発注者が期待値を伝え、すり合わせ、マネジメントすべき領域なのです。

判例に見るエンジニアのプロジェクトマネジメント的責任

善管注意義務が単なる努力目標ではなく、実際に法的責任として問われ得ることは、判例からも確認できます。準委任契約に基づくIT開発案件において、受任者の善管注意義務違反を認定し、報酬請求が制限されたり損害賠償が問題となったりした裁判例が存在します（IT・システム判例メモ「準委任契約に基づく報酬請求と善管注意義務違反」東京地判令2.9.24）。

ここで押さえておきたいのは、善管注意義務と「プロジェクトマネジメント義務」の関係です。システム開発の裁判例では、ベンダー側にプロジェクトを適切に管理・進行させる義務（プロジェクトマネジメント義務）が認められることがあります。プロジェクトマネジメント義務が主に契約内容や個別の裁判例で具体化されるのに対し、善管注意義務は民法第644条という法律そのものを根拠とし、幅広い業務委託契約に適用される原則です（マネーフォワード クラウド契約「善管注意義務とは？」）。

つまり、準委任のエンジニアは「成果物を完成させる義務」こそ負わないものの、専門家としてプロジェクトを適切に進行させ、問題を放置せず、発注者と協働する姿勢が法的にも期待されているということです。「成果は保証しない」という言葉から受ける印象よりも、実際には発注者を守る仕組みがしっかり働いていると理解してよいでしょう。

なお、個別の案件で何が善管注意義務違反にあたるかは事案ごとの判断になります。具体的な紛争リスクが懸念される場合は、契約内容について弁護士など専門家に確認することをおすすめします。

なぜ準委任で「期待値ギャップ」が起きるのか

ここまでで、準委任エンジニアが善管注意義務という義務を負い、プロとして誠実に業務を遂行することが法的に担保されていることを見てきました。それでもなお、「思っていたものと違う」という結果に終わるケースは少なくありません。義務があるのに、なぜ成果への不安が残るのか。実はここには、契約形態とは別の構造的な理由があります。

期待値ギャップの正体

「思っていたものと違う」が起きる最大の原因は、発注者の頭の中にある成果イメージが、エンジニアに正しく共有されていないことです。

発注者の中には、たいてい「こういうものが欲しい」という暗黙の完成イメージがあります。しかし、そのイメージは多くの場合、言語化も文書化もされていません。一方でエンジニアが業務として受け取るのは、契約書や仕様書に明文化された「業務範囲」だけです。この「暗黙の成果イメージ」と「明文化された業務範囲」の間にあるズレこそが、期待値ギャップの正体です。

エンジニアは善管注意義務に従って、共有された範囲の中で誠実に業務を遂行します。しかし、共有されていない暗黙の期待まで読み取ることはできません。結果として、エンジニアは義務を果たしているのに、発注者は「思っていたものと違う」と感じる――この食い違いは、義務違反ではなく、コミュニケーション設計の問題なのです。

過去の外注で同じ経験をしたことがあるなら、それは多くの場合、エンジニアの能力や誠実さの問題ではなく、期待値が共有しきれていなかったことに起因していた可能性が高いといえます。

準委任だからこそ目的・優先順位の合意が成果を左右する

期待値ギャップは、準委任契約という性質によってさらに増幅されやすくなります。準委任は「手段（業務遂行）を専門家に委ねる」契約だからです。

請負であれば「完成すべき成果物」が契約の中心にあるため、ゴールが比較的明確です。しかし準委任では、何をどう進めるかの裁量がエンジニア側に委ねられます。この裁量は、専門家に最適な判断を任せられるという利点である一方、「何を優先すべきか」「最終的に何を目指すのか」という目的が合意されていないと、専門家としては正しくても発注者の期待とは違う方向に進んでしまうリスクをはらみます。

たとえば「品質を最優先に堅牢な設計を組む」のと「とにかく早く動くものを作って市場の反応を見る」のとでは、エンジニアが取るべき行動はまったく異なります。どちらもプロとして妥当な判断になり得ますが、発注者が後者を望んでいたのに目的を共有していなければ、エンジニアは前者を選ぶかもしれません。これは善管注意義務の問題ではなく、目的と優先順位の合意が欠けていたことによるすれ違いです。

進捗が見えないことへの不安も、ここに重なります。準委任は手段を委ねる契約だからこそ、発注者が中身を把握しにくく、「ちゃんと進んでいるのか」が見えにくい。だからこそ、目的・優先順位の合意と進捗の可視化が、成果を左右する決定的な要素になるのです。

裏を返せば、これらをきちんと設計すれば、準委任でも成果は十分にコントロールできます。次の章では、その具体的な伝え方を3つの場面に分けて解説します。

発注者が期待値を正しく伝える3つの場面

期待値を伝えるという行為は、漠然と「しっかり伝える」と考えても実践できません。伝えるべきタイミングと内容を整理すれば、誰でも再現できる手順になります。ここでは「契約前」「キックオフ」「発注後の定例」という3つの場面に分け、それぞれで何をどう伝えるかを具体的に見ていきます。

契約前 — 業務範囲・目的・成果の測り方を言語化する

最初の、そして最も重要な場面が契約前です。前章で見たとおり、期待値ギャップの根本原因は「暗黙の成果イメージが言語化されていないこと」にありました。だからこそ、契約前に頭の中のイメージを言葉にしておくことが、期待値マネジメントの起点になります。

契約前に言語化しておきたいのは、次の項目です。

• 業務範囲: エンジニアに担ってほしい業務の範囲。「設計から実装まで」なのか「実装のみ」なのか、テストや運用は含むのかを明確にします。
• 目的（何のためのプロジェクトか）: そのシステム・開発が事業上どんな目的を果たすのか。「新規顧客の獲得チャネルを作る」「社内の手作業を自動化して工数を削減する」など、上位の狙いを共有します。
• 優先順位: 品質・スピード・コストのうち、何を優先するのか。トレードオフが発生したとき、どちらを取るべきかの判断軸を伝えます。
• 成果の測り方: 何をもって「うまくいった」と判断するのか。準委任では完成そのものを約束できなくても、「どういう状態を目指すか」を共有しておくことで、方向性のずれを防げます。

これらを口頭だけでなく文書として残しておくことが大切です。文書化することで、エンジニア側も認識を確認でき、後から「言った・言わない」のすれ違いを防げます。

キックオフ — ゴールイメージと制約条件をすり合わせる

契約後、業務が始まる前のキックオフは、文書で伝えた期待値を双方向ですり合わせる場です。契約前の言語化が「発注者からの一方向の発信」だとすれば、キックオフは「エンジニアの理解を確認し、認識を合わせる」場面になります。

キックオフで意識したいのは、次のような問いかけです。

• 「このプロジェクトで最終的に実現したいのは○○です。この理解で認識は合っていますか」
• 「品質とスピードでトレードオフが出たら、今回は△△を優先したいと考えています。技術的に懸念はありますか」
• 「進める中で『これは難しい』『前提が崩れている』と感じたら、早めに共有してください」
• 「現時点で、要件の中で曖昧な部分や、確認しておきたい制約はありますか」

ここでエンジニアから出てくる質問や懸念は、期待値ギャップを事前に潰す貴重な材料です。専門家の視点から「その目的ならこういう方法もある」「その優先順位ならここは削れる」といった提案が出てくれば、それは善管注意義務に基づく協力的な関与でもあります。発注者が一方的に指示するのではなく、目的と制約を共有したうえで手段を一緒に握る――この姿勢が、準委任で成果を引き出すコツです。

発注後の定例 — 進捗を可視化し早期に軌道修正する

業務が始まったら、定例ミーティングなどの定期的な接点を通じて、進捗を可視化し続けます。準委任で「進捗が見えない」という不安を解消する最大の手段が、この定例の運用です。

定例で確認したいのは、単なる作業報告ではありません。「目的に対して、いま正しい方向に進んでいるか」を確認することがポイントです。

• 進んでいる内容と、当初想定とのズレはないか
• 想定外の問題やリスクが出ていないか、出ているなら対応方針はどうするか
• 優先順位の前提が変わっていないか（事業状況の変化で優先度が変わることもあります）

このとき重要なのは、ズレを見つけたら早期に軌道修正することです。準委任は手段を委ねる契約なので、途中で方向を調整する柔軟性が本来の強みでもあります。月に1回しか進捗を見ない運用では、ズレが大きくなってから気づくことになりかねません。週次など短いサイクルで接点を持つことで、小さなズレのうちに修正でき、「最後まで進めたら全然違うものができていた」という事態を防げます。

なお、ここでの「進捗確認」や「軌道修正」は、あくまで目的・成果に対するすり合わせです。作業の手順や時間を細かく指示することとは性質が異なります。この境界線は、次の章で詳しく整理します。

「期待値を伝える」と「指揮命令」の違い（偽装請負を避ける）

期待値を丁寧に伝えようとすればするほど、発注者の頭には新たな不安が浮かびます。「ここまで細かく要望を伝えると、指揮命令にあたって偽装請負になってしまうのではないか」という心配です。この境界線を曖昧にしたまま萎縮してしまうと、必要な期待値の共有まで遠慮してしまい、かえって成果が遠のきます。何を伝えてよく、何を指示してはいけないのかを、はっきり整理しておきましょう。

伝えてよいことと、指示してはいけないこと

準委任契約・業務委託契約では、発注者と受注者は対等な事業者同士の関係です。発注者が受注者の労働者であるかのように、勤務時間や作業手順を直接指揮命令することはできません。指揮命令の実態があると、形式は業務委託でも実質的に労働者派遣・労働契約とみなされ、偽装請負と判断されるリスクが生じます。発注者として許容される指示の範囲を具体的に確認したい場合は、業務委託で適法な指揮命令の範囲もあわせてご覧ください。

ただし、ここで多くの発注者が誤解しがちなのが、「目的や成果について要望を伝えること」まで指揮命令だと考えてしまう点です。実際には、業務委託として正当に伝えてよいことと、指示してはいけないことは明確に分かれます。

ポイントは、発注者が伝えるのは「What（何を達成したいか）」であり、「How（どうやるか）」はエンジニアの裁量に委ねるという線引きです。目的・成果基準・優先順位という「What」を伝えるのは正当な期待値マネジメントであり、むしろ準委任で成果を引き出すために不可欠です。一方、作業の進め方・時間・場所という「How」に細かく介入し始めると、指揮命令=偽装請負のリスク領域に入ります。

偽装請負と判断されないための運用上の注意

線引きを理解したうえで、運用面でも次の点に気をつけると、偽装請負のリスクを抑えながら期待値マネジメントを実践できます。

• 窓口を介してやり取りする: 個々の作業者に直接逐次指示を出すのではなく、業務全体の目的・要望として窓口を通じて伝える形にすると、指揮命令的な関係になりにくくなります。
• 稼働時間ではなく成果・進捗で見る: 「何時間働いたか」を管理するのではなく、「目的に対してどこまで進んだか」で会話する習慣をつけます。これは指揮命令の回避だけでなく、本来の期待値マネジメントの観点からも望ましいやり方です。
• 手段の決定を委ねる姿勢を明示する: 「具体的な進め方はお任せします。目的と優先順位だけ共有させてください」というスタンスを明確にすると、双方が役割を理解しやすくなります。
• 定例は『指示の場』ではなく『すり合わせの場』と位置づける: 前章で触れた定例も、作業命令を出す場ではなく、目的・進捗・リスクを双方向で確認し合う場として運用します。

自社の運用が偽装請負に該当していないかを点検したいときは、偽装請負チェックリストを使って具体的な項目を確認しておくと安心です。このように、期待値を伝えることと指揮命令することは、実は性質がまったく異なります。境界線さえ押さえておけば、偽装請負を恐れて萎縮する必要はなく、むしろ積極的に目的と優先順位を共有していくことが、準委任で成果を引き出す近道になります。

期待値マネジメントを支える契約・発注体制の整え方

ここまで、善管注意義務の理解から期待値の伝え方、指揮命令との境界線までを見てきました。最後に、これらを支える土台として、契約面と人選面で整えておきたいポイントをまとめます。この準備が整えば、準委任での発注に自信を持って踏み切れるはずです。

契約書で確認・合意しておく項目

契約書は、期待値マネジメントを下支えする最初の文書です。準委任契約を結ぶ際、次の項目が明確になっているかを確認しておくと安心です。

• 業務範囲: どこからどこまでを委託するのか。範囲が曖昧だと、後の期待値ギャップの温床になります。
• 報告義務: 進捗や問題点をどの頻度・どの形式で報告してもらうか。善管注意義務に基づく報告は当然行われますが、頻度・方法を契約や運用ルールで具体化しておくと、進捗の可視化が確実になります。
• 善管注意義務の位置づけの確認: 準委任である以上、善管注意義務は法律上当然に発生しますが、双方がその意味（プロとしての遂行は担保されるが成果物の完成は約束ではない、という構造）を理解し合っておくことが、認識のずれを防ぎます。
• 目指す状態・成果の捉え方の共有: 完成義務を負わせるものではなくても、「どういう状態を目指すか」を契約前のすり合わせ文書として残し、契約と紐づけておくと、方向性の確認材料になります。

契約条項そのものの妥当性や、自社の状況に即した条文の設計については、必要に応じて弁護士など専門家に確認することをおすすめします。本記事で示しているのは、あくまで発注者として押さえておきたい運用上の観点です。

期待値を共有しやすいエンジニアの見極め方

そして、見落とされがちですが最も本質的なのが、人選です。どれだけ契約と運用を整えても、期待値を共有しにくい相手では成果は引き出しにくくなります。逆に、目的を理解し、こまめに報告・相談してくれるエンジニアであれば、期待値マネジメントは驚くほどスムーズに進みます。

発注前の面談や経歴確認で、次のような点を見極めると、期待値を共有しやすい人材かどうかが判断しやすくなります。

• 目的を確認しようとするか: 「何を作るか」だけでなく「何のために作るのか」を質問してくる人は、目的ベースで動ける可能性が高いといえます。
• プロセスを言語化できるか: 自分の進め方や判断の根拠を分かりやすく説明できる人は、進捗の可視化もしやすく、すり合わせが噛み合います。
• 報告・相談の姿勢があるか: 過去の案件で、問題やリスクをどう共有してきたかを聞くと、善管注意義務の核となる「報告・相談・警告」の姿勢が見えてきます。
• トレードオフを率直に伝えられるか: 「それは難しい」「この優先順位ならここは諦める必要がある」と率直に言える相手は、期待値ギャップを早期に潰してくれます。

こうした見極めを発注者一社の力だけで行うのは簡単ではありません。実務では、エンジニアと発注企業をつなぐ人材プラットフォームを活用し、経歴やコミュニケーションの傾向を事前に把握したうえでマッチングするケースも増えています。準委任での成果は、結局のところ「目的と優先順位を共有しやすい相手と出会えるか」に大きく左右されます。合う人材に出会うこと自体が、期待値マネジメントの起点になるといってもよいでしょう。

準委任契約は「成果を保証しない契約」ではなく、「発注者とエンジニアが目的を共有し、プロセスの質を担保し合いながら成果に向かう契約」です。善管注意義務という土台を理解し、期待値を正しく伝え、合う人材を選ぶ。この3つが揃えば、準委任は外部の専門性を最大限に引き出す、頼もしい選択肢になります。