準委任契約でも納品物を定義すべき？トラブルを防ぐ契約書の書き方

準委任契約でも納品物を定義すべき？トラブルを防ぐ契約書の書き方

「準委任だから納品物は曖昧でいい」——その思い込みが、後の揉めごとの火種になります

「準委任契約って、成果物を約束しない契約ですよね？だったら納品物を契約書に書く必要はないのでは？」

システム開発を発注する中小工務店・設計事務所の方から、よくこうした質問を受けます。確かに、準委任契約は**「成果物の完成を約束しない契約」**と法律上は説明されます。しかし、その言葉を文字通り受け取って契約書の納品物欄を空欄のまま進めてしまうと、プロジェクトの終盤や支払いの段階で深刻なトラブルを引き起こすことになります。

• 「作業は終わったと言われたが、何をもって『終わった』と言えるのか分からない」
• 「月々の報告書はもらっていたが、成果物らしきものが手元に残っていない」
• 「ベンダーが撤退したあと、何が納品されたのか確認する術がない」
• 「要件が変わったときに、どこまでが契約範囲内なのか揉めた」
• 「システムの不具合が見つかったが、修正義務の範囲でひと悶着あった」

これらはすべて、準委任契約の「納品物定義があいまい」だったことが原因で起きるトラブルです。

本来、準委任契約であっても「業務の成果として受け渡されるもの」は存在します。そこを曖昧にしたまま契約を結ぶのは、建設業に例えるなら**「図面も仕様書もなしに職人さんに『いい感じに作っておいて』と頼む」**のと同じくらい無謀なことです。

「準委任＝納品物なし」という誤解が、中小工務店・設計事務所のDX案件を漂流させています

この誤解は、システム開発に不慣れな発注者ほど陥りやすい罠です。

中小工務店・設計事務所の経営者や管理者の方から、こんな相談をよく受けます。

「準委任契約で半年間プロジェクトを進めてきましたが、ふと振り返ると『結局、何ができあがったんだろう？』という状態です。月々の稼働報告は受けていましたが、形に残るものが手元にほとんどありません」

「契約終了時に『ここまでが契約範囲です』と言われたのですが、自社で使いたかった機能が含まれていなかった。『そんな約束はしていない』と言われ、追加費用を請求されました」

これらは、準委任契約における**「納品物の定義不足」が引き起こす典型的な事例**です。

準委任契約には、民法上**「履行割合型」と「成果完成型」**の2種類があります。2020年の民法改正でこの区分が明確化されましたが、多くのベンダーや発注者はこの違いを正確に理解していません。そのため、契約書では履行割合型なのに、発注者は成果完成型のつもりで合意してしまう——という認識のズレが、トラブルの最大の原因になっています。

さらに深刻なのは、IT業界の慣習として「準委任契約書のテンプレート」に納品物欄がほとんどないことです。「稼働報告書の提出」程度しか書かれていない雛形を使い、その結果として「何を受け取ったら完了とみなすか」が誰にもわからない状態で進行してしまうのです。

**建設業界の感覚で言えば、「請書」はあるのに「施工図面」も「仕様書」も存在しないまま工事を進めるようなもの。**完成検査のしようがなく、引き渡しの段階で揉めるのは当然の帰結です。

準委任契約でも納品物を定義すれば、トラブルの9割は未然に防げます

結論から言えば、準委任契約であっても「納品物を契約書に明記する」ことは可能であり、むしろ必須です。

「準委任契約は成果物の完成を約束しない」というのはあくまで法的な責任範囲の話であって、「納品物を定義してはいけない」という意味ではありません。契約書に**「業務遂行の過程で作成・提出されるもの」を列挙しておく**ことで、プロジェクトの境界線を明確にし、トラブルのほとんどを未然に防ぐことができます。

この記事を読み終えれば、あなたは**「納品物欄が空白の準委任契約書」を見た瞬間に危険信号を察知できる**ようになり、自社を守るために契約書に盛り込むべき具体的な条項を把握できるようになります。

準委任契約でも納品物を定義することでトラブルを防げる仕組み

準委任契約における納品物定義——実務で使える契約書の書き方

まず押さえるべき「履行割合型」と「成果完成型」の違い

準委任契約における納品物の定義を考える前に、民法上の2つの類型を理解しておく必要があります。

建設業界に置き換えると： 履行割合型は**「常用（日当）で職人さんに現場作業を手伝ってもらう契約」、成果完成型は「調査報告書の作成を発注する契約」**に近いイメージです。同じ「準委任」という名前でも、報酬発生のロジックがまったく異なります。

中小工務店・設計事務所が発注するDX案件の多くは、履行割合型の準委任契約で締結されます。 しかし、だからといって「納品物が不要」になるわけではありません。履行割合型でも、業務の過程で作成された成果物（ドキュメント・コード・設定ファイルなど）は発注者に引き渡されるのが通常です。この「過程の成果物」を契約書に明記することが、トラブル予防の第一歩です。

準委任契約書に必ず盛り込むべき8つの条項

納品物定義を含めて、準委任契約書で必ずチェックすべき条項は8つあります。ひとつずつ解説します。

条項1：業務内容の具体的な記載

「本件業務の内容」を抽象的な表現で済ませないことが重要です。

悪い例：「施工管理システムの開発支援業務」 良い例：「工事台帳管理機能の要件定義、画面設計、DB設計、実装、単体テスト、結合テスト、および当該成果に関するドキュメントの作成」

業務範囲が具体的であるほど、「これは業務範囲内か？」という揉めごとが起きにくくなります。

条項2：納品物（提出物）の明示

履行割合型であっても、業務遂行の過程で作成される書類・データを「提出物」として明示します。

例：

• 要件定義書（確定版）
• 基本設計書・詳細設計書
• ソースコード一式（リポジトリへのコミット）
• データベース設計書
• テスト計画書・テスト結果報告書
• 月次稼働報告書
• 議事録（定例会議ごと）
• 運用手順書・管理者マニュアル

ポイント： 「提出物」という言葉を使うと、成果完成型との混同を避けながら「受け渡されるもの」を明確にできます。ベンダーが「準委任だから納品物は定義できない」と言ってきたら、「提出物リスト」として交渉してみてください。

条項3：業務の完了条件

「いつをもって業務が完了したとみなすか」を明記します。

例：「第X条に定める提出物のすべてが受託者から委託者に引き渡され、委託者がその内容を確認した時点をもって、本件業務の完了とする」

この条項がないと、「作業は終わった」と「まだ終わっていない」の水掛け論になります。

条項4：報酬の支払条件と検収

履行割合型の場合、月次の稼働報告書の受領をもって月次報酬の支払条件とするのが一般的です。ただし、「月次報告書に最低限記載すべき項目」を契約書で定めておくことが重要です。

月次報告書の必須項目例：

• 当月の実作業時間（メンバー別・タスク別）
• 当月の実施内容の具体的な記述
• 作成・更新された提出物の一覧
• 課題・リスク・次月の予定

条項5：善管注意義務の内容

準委任契約におけるベンダーの義務は**「善良なる管理者の注意義務（善管注意義務）」**です。この内容を具体化する条項を入れておくと、業務品質の担保につながります。

例：「受託者は、情報システム開発の専門家として、一般的に期待される技術水準・品質基準に従い、善良なる管理者の注意をもって本件業務を遂行するものとする」

条項6：知的財産権の帰属

準委任契約でもっとも揉めるのが知的財産権です。特に、開発したプログラムの著作権がどちらに帰属するかは明確にしておきます。

発注者としての理想形：「本件業務の遂行過程で生じたプログラム、ドキュメントその他の成果物に関する著作権（著作権法第27条および第28条の権利を含む）は、対価の支払をもって委託者に移転する」

中小工務店・設計事務所の経営者が見落としがちなポイントですが、ここを曖昧にするとシステムの改修・移管ができなくなるため、必ず確認してください。

条項7：秘密保持義務

工事台帳・顧客情報・原価データなど、中小工務店・設計事務所が扱う情報は極めて機密性が高いです。

秘密保持の対象範囲、有効期間（契約終了後○年間など）、情報の返還・破棄義務を明記します。

条項8：契約解除と再委託

• 中途解約の条件：何日前に通知すればよいか、精算方法はどうするか
• 再委託の可否：ベンダーが業務の一部を第三者に委託してよいか、事前承諾が必要か

この2つが明確でないと、ベンダー側の体制変更やプロジェクト終了時に揉める原因になります。

よくあるトラブル事例と、契約書での対処法

実際に中小工務店・設計事務所のDX案件で起きた典型的なトラブル事例を紹介します。

事例1：「成果物らしきものが残っていない」問題

状況： 半年間の準委任契約で施工管理システムの改修を依頼。月次報告は受けていたが、契約終了後に社内で引き継ごうとしたら、ドキュメントがほとんど存在しなかった。

対処法： 契約書の**「提出物」条項に設計書・仕様書・運用マニュアルを明記**しておく。月次報告書の必須項目に「当月更新されたドキュメント一覧」を入れる。

事例2：「契約範囲の解釈違い」問題

状況： 「工事台帳のデジタル化」という業務内容で契約したが、発注者は「原価管理との連携」まで含まれると思っていた。ベンダーは「そこは別契約」と主張し、追加費用を請求。

対処法： 業務内容欄を**「含むもの／含まないもの」の両方で記載**する。建設工事の特記仕様書に近い発想です。

事例3：「要件変更の費用負担」問題

状況： プロジェクト途中で現場から追加要望が出た。準委任契約なので柔軟に対応してもらえると思っていたが、ベンダーから「工数オーバー分は追加費用」と言われた。

対処法： 「工数上限」と「上限を超える場合の協議プロセス」を契約書に明記する。例えば「月間稼働時間が○○時間を超える場合は、事前に委託者と協議する」という条項を入れる。

事例4：「成果物の著作権トラブル」問題

状況： 開発したシステムを別のベンダーに移管しようとしたら、元のベンダーから「ソースコードの著作権は当社にある」と主張された。

対処法： 契約書で著作権の譲渡を明記する（条項6参照）。特に「著作権法第27条・第28条の権利を含む」という文言を忘れずに入れる。

準委任契約書の作成・チェックの実践ステップ

契約書レビューの実践ステップ——5つの確認手順

ベンダーから提示された準委任契約書を、自社でチェックする手順をまとめます。法務担当者がいない中小企業でもできる、実践的なステップです。

ステップ1：業務内容の具体性チェック 抽象的な表現（「〇〇の支援」「〇〇の開発」）で終わっていないか。含むもの／含まないものが明記されているか。

ステップ2：提出物リストの有無 月次報告書以外の提出物が定義されているか。設計書・ソースコード・マニュアルなど、具体的に列挙されているか。

ステップ3：完了条件の明確性 「業務の完了」をどう判定するかが書かれているか。検収プロセスは明示されているか。

ステップ4：著作権・知的財産権の帰属先 発注者に帰属するよう記載されているか。27条・28条の権利を含むと明記されているか。

ステップ5：解除・精算・再委託の条件 中途解約時の扱い、再委託時の承諾ルールが明確か。

この5つをチェックするだけで、将来のトラブルの大半は防げます。

「自社だけで判断するのが不安」なときの相談先

とはいえ、契約書のレビューは専門知識が必要な領域です。特に、中小工務店・設計事務所のように法務専任者がいない組織では、「これで本当に大丈夫なのか？」という不安がつきまといます。

そんなとき、建設業界の業務実態とIT開発の両方を理解している専門家に相談するのが最も確実です。アトリエ・バイナリ（atelier binary）では、中小工務店・設計事務所が抱える「紙とExcelに頼った業務」「属人化した見積もり作成」「現場と事務所の情報断絶」といったレガシーな課題に対して、契約書レビューから要件定義、ベンダー選定、プロジェクト伴走までを一貫してサポートするコンサルティングを提供しています。特に**「ベンダーが提示した契約書を、発注者の立場でチェックする」**サービスは、これからDXを本格化する中小企業の経営者から高い評価をいただいています。

準委任契約における「納品物定義」のゴールデンルール

最後に、実務で使える7つのゴールデンルールをまとめます。

1. 「納品物」ではなく「提出物」という言葉で定義する——法的な齟齬を避けられる
2. 最低でも設計書・ソースコード・テスト結果・運用マニュアルは必須——後の引き継ぎに備える
3. 月次報告書の記載項目を契約書で規定する——「何を受け取るか」を事前に合意
4. 業務範囲は「含む／含まない」の両面で書く——解釈の余地を減らす
5. 著作権は発注者帰属を原則にする——将来の改修・移管の自由度を確保
6. 工数上限と超過時の協議プロセスを入れる——予算超過リスクをコントロール
7. 定例会議の議事録を提出物に含める——プロジェクトの意思決定履歴を残す

これらを契約書に盛り込むだけで、「準委任契約のあいまいさ」から生じるトラブルの9割は防げると言っても過言ではありません。

こんな方に今すぐ読んでほしい

• ベンダーから提示された準委任契約書をどうレビューすべきか分からない方
• 過去のシステム開発で「何が納品されたのか不明」な経験をした方
• 現在進行中のプロジェクトで、契約範囲の解釈違いに不安を感じている方
• DX推進のために、安全な発注体制を整えたい中小工務店・設計事務所の経営者
• 「準委任＝納品物なし」という業界慣習に違和感を抱いている発注担当者

準委任契約は、要件が流動的なDX案件において非常に有効な契約形態です。しかし、その柔軟性は**「納品物の定義」という土台がしっかりしている場合にのみ活きる**ものです。土台が曖昧なまま進めれば、柔軟性は「無責任」に変わり、プロジェクトは漂流します。

「ベンダーに言われたからこのテンプレートで契約しよう」という受け身の姿勢を、「自社を守るために契約書に何を書くか能動的に決める」姿勢に変える。 それが、DX投資を成功させる発注者の第一歩です。

まとめ

まとめ

準委任契約だからといって、納品物の定義を曖昧にしてよい理由はどこにもありません。 むしろ、準委任契約こそ「提出物リスト」を明確にすることで、その柔軟性を最大限に活かせるのです。

本記事のポイントを整理します。

1. 準委任契約には「履行割合型」と「成果完成型」の2種類がある——この違いを理解しないまま契約するとトラブルの温床になる
2. 履行割合型でも「提出物」は必ず契約書に明記する——設計書・ソースコード・マニュアル・議事録など
3. 契約書には8つの必須条項を盛り込む——業務内容、提出物、完了条件、報酬条件、善管注意義務、著作権、秘密保持、解除・再委託
4. トラブル事例の多くは「契約範囲の解釈違い」——含むもの／含まないものの両面記載で防げる
5. 著作権は発注者帰属を原則にする——将来のシステム改修・移管の自由を守るため
6. 自社レビューの5ステップ——業務内容の具体性、提出物の有無、完了条件、著作権、解除条件を順にチェック

中小工務店・設計事務所の経営者にとって、システム開発の契約書は**「見慣れない外国語の書類」のように感じられるかもしれません。しかし、建設業の請書・特記仕様書の感覚に照らし合わせれば、本質的にやるべきことは同じです。「何を」「いつまでに」「どうやって受け取るか」を明確にする**——ただそれだけのことです。

「この契約書、準委任だから納品物欄は空でいいんですよね？」——もしベンダーにそう言われたら、それはトラブルの赤信号です。 建設業の常識と同じように、発注者として自社を守るための「図面と仕様書」をしっかり要求してください。契約書の書き方に迷ったときは、建設業界のDXに精通した専門家に相談するのが、最も確実で、最も安上がりな方法です。契約段階で数時間投資するだけで、プロジェクト後半の数百万円規模のトラブルを防げるのですから。