業務委託の成果物、保守は誰が？納品後トラブルを防ぐ契約5項目

「システムは無事に納品された。検収も終わった。これでひと安心」——そう思った矢先に、運用を始めたシステムでバグが出たり、「思っていた動きと違う」という仕様の食い違いが見つかったりすることは珍しくありません。慌ててエンジニアに修正を依頼したところ、「それは追加料金です」と言われた。あるいは何度連絡しても返信が来ず、そのまま連絡が取れなくなってしまった。こうした「納品後のトラブル」に心当たりはないでしょうか。

業務委託でエンジニアに開発を発注するとき、多くの発注者は「どんな成果物を、いつまでに、いくらで作ってもらうか」には注意を払います。しかし、その成果物を受け取った「後」のこと——バグが出たら誰が直すのか、仕様を変えたくなったらどう頼むのか、どれくらいの速さで対応してもらえるのか——を契約で決めているケースは意外なほど少ないのが実情です。

なぜこうしたトラブルが起きるのかというと、「保守サポート」が契約のグレーゾーンになりやすいからです。発注者は「納品したものに不具合があれば直してくれて当然」と考え、受託者は「契約に書いていないことは別料金」と考える。この認識のズレが、追加報酬を巡る揉め事や対応の遅延を生みます。

この記事では、業務委託エンジニアに発注した成果物を受領した後の「保守サポート」を、契約でどう取り決めればトラブルを防げるのかを、発注者の視点で解説します。具体的には、（1）法律上「無償で直してもらえる範囲」はどこまでか、（2）それを超えて任意で決めるべき保守の5項目（範囲・期間・単価・レスポンス・対象外）は何か、（3）契約書にそのまま転記できる文言例と受領時の確認事項、（4）2024年11月施行のフリーランス新法で発注者に求められること、（5）保守フェーズの依頼先をどう選ぶか——という順で整理します。

専門用語はできるだけ平易に補足しながら進めますので、契約に詳しくない方でも、読み終えるころには「次の発注で何を・どう決めればよいか」の判断軸が手に入るはずです。

「成果物を受け取った後」のトラブルはなぜ起きるのか

まずは、納品後によく起きるトラブルを具体的に見ていきましょう。「自分のことだ」と感じる場面があれば、それはこの記事で予防できる課題です。

納品後に起きる3つの典型トラブル

業務委託エンジニアからの成果物を受領した後、発注者が直面しやすいトラブルは大きく3つに分けられます。

1つ目は、バグ対応の「追加料金」問題です。 運用開始後に不具合が見つかり、修正を依頼したところ「それは保守の範囲なので別料金になります」と言われるケースです。発注者は「納品物の欠陥なのだから無償で直すべきでは」と感じ、受託者は「契約に保守は含まれていない」と主張する。どちらの言い分にも一理あるからこそ、こじれます。

2つ目は、対応範囲の認識ズレです。 たとえば「ログイン画面の表示がおかしい」という不具合報告に対し、発注者は「バグ修正」と考えていても、エンジニアは「それは新しいブラウザへの対応であって、当初の仕様にはなかった機能追加だ」と捉えることがあります。バグ修正なのか仕様変更なのか、その線引きが曖昧なまま発注すると、対応のたびに交渉が発生します。

3つ目は、連絡途絶です。 これはフリーランス・個人エンジニアに発注した場合に特に起こりやすいリスクです。本業が忙しくなった、別の案件にかかりきりになった、といった事情で返信が遅くなり、最悪の場合そのまま音信不通になってしまう。組織のように代わりの担当者がいないため、システムを書いた本人と連絡が取れなくなると、運用が立ち行かなくなります。

トラブルの共通原因は「受領後フェーズの取り決め不在」

これら3つのトラブルには、共通する根本原因があります。それは、成果物を受け取った後のことを契約で決めていないという一点です。

多くの発注者は、無意識のうちに「検収＝ゴール」と考えてしまいます。発注した成果物が納品され、動作を確認して検収が完了すれば、プロジェクトは終わり。そう捉えるのは自然なことです。

しかし、システムは納品して終わりではありません。運用を始めればバグは出ますし、事業の状況が変われば仕様も変えたくなります。本当のスタートは検収の「後」にあるのです。にもかかわらず、契約書には検収完了までのことしか書かれていない。だからこそ、検収後に発生する保守・修正・変更の依頼が、すべてグレーゾーンの交渉になってしまうわけです。

なお、こうした受領後のトラブルの多くは、そもそも検収の基準が曖昧だったことに端を発します。受領の瞬間に「何をもって合格とするか」を仕組み化しておく方法は業務委託エンジニアの成果物検収・品質管理を仕組み化する方法で詳しく解説しているので、検収フェーズから整えたい方はあわせてご覧ください。

この記事のスコープは、まさにこの「検収完了後」のフェーズです。発注前の契約形態の選び方や検収のやり方そのものではなく、受領した成果物をその後どう保守していくかの取り決めに焦点を当てます。

この記事で得られること

ここから先で解説する内容を、あらかじめ地図として示しておきます。

• 無償／有償の区別: 法律上、無償で直してもらえる範囲（契約不適合責任）がどこまでかを理解する
• 5項目の取り決め: それを超えて契約で決めるべき保守サポートの5項目（範囲・期間・単価・レスポンス・対象外）を押さえる
• 文言例と受領時の確認: 契約書や受領確認書にそのまま使える文言例を手に入れ、受領の瞬間に何を合意すべきかを知る
• フリーランス新法対応: 2024年11月施行の新法で、発注者として守るべき義務を確認する
• 依頼先の判断: 保守を同じエンジニアに継続依頼するか、別調達・内製にするかの判断軸を得る

順番に見ていきましょう。

「無償で直してもらえる範囲」はどこまでか — 契約不適合責任の基礎

「このバグは無償で直してもらえるはず」「いや、これは追加料金だ」——納品後のトラブルで最ももつれるのが、この無償・有償の境界線です。この境界を引くために、まず知っておくべきなのが「契約不適合責任」という法律上のルールです。少し法律の話になりますが、発注者目線で必要な部分に絞って平易に解説します。

契約不適合責任とは（2020年民法改正の変更点）

契約不適合責任とは、ひとことで言えば「納品された成果物が契約の内容に適合していなかった場合に、受託者（エンジニア）が負う責任」のことです。発注した内容と違うものが納品された、約束した機能が動かない、といったときに、発注者が無償での修正などを請求できる法的な根拠になります。

この制度は、2020年4月1日施行の民法改正で導入されました。それ以前は「瑕疵（かし）担保責任」という名前で呼ばれていたもので、「瑕疵担保」という言葉を聞いたことがある方も多いでしょう。改正によって名称が「瑕疵担保責任」から「契約不適合責任」に変わり、内容も整理されました（参考: マネーフォワード クラウド契約）。

発注者にとっての実務的な意味はシンプルです。「契約で約束した内容と違う成果物」については、原則として無償で対応を求められる——これが契約不適合責任の基本的な考え方です。逆に言えば、契約で約束していなかったことは、この責任の対象外になります。だからこそ、後で触れる「契約に何を書いておくか」が決定的に重要になるのです。

発注者が請求できる4つの権利と通知期間

成果物が契約内容に適合していなかった場合、発注者は以下の4つの権利を行使できます。

納品後のバグ修正で発注者が主に使うのは「追完請求」です。「契約どおりに動かないので直してください」と求める権利だと考えればよいでしょう。

ただし、ここに重要な期間ルールがあります。改正民法では、契約不適合を知った時から1年以内にその旨を受託者へ通知しなければ、原則としてこれらの権利を失うとされています（参考: マネーフォワード クラウド契約）。注意したいのは、「1年以内に修正を完了させる」ではなく「1年以内に不適合の事実を通知する」という点です。不具合を見つけたら、まずは速やかに記録を残して相手に伝えることが、権利を守るうえで欠かせません。なお、権利そのものは別途、消滅時効（権利を行使できることを知った時から5年など）の制限も受けます。

これらの期間は、契約書で別段の定めを置くこともできます。たとえば「契約不適合責任の通知期間は引渡しから6か月とする」といった取り決めです。発注者としては、この期間が極端に短く設定されていないか（自社に不利になっていないか）を契約締結時に確認しておくとよいでしょう。

請負契約と準委任契約で責任がどう変わるか

ここで一つ、見落とされがちな重要なポイントがあります。それは、契約の類型によって責任の性質が変わるということです。

業務委託契約は、大きく「請負契約」と「準委任契約」に分けられます。

• 請負契約: 「成果物の完成」を約束する契約。成果物が契約に適合していなければ契約不適合責任を負う。バグ修正の無償対応を求めやすいのはこちら
• 準委任契約: 「業務の遂行」を約束する契約（成果物の完成までは約束しない）。完成義務を負わない代わりに、「善管注意義務」（善良な管理者として注意を払って業務を行う義務）を負う

ここが落とし穴になりがちです。準委任契約の場合、原則として成果物の完成自体を約束していないため、請負契約と同じ意味での契約不適合責任は適用されません。「準委任で契約していたのに、納品物のバグは当然無償で直してもらえると思っていた」というのは、よくある誤解です。

そのため、準委任契約で発注する場合は、なおさら「不具合対応をどうするか」を契約で個別に決めておく必要があります。請負か準委任かによって「黙っていても無償対応してもらえる範囲」が変わることを、まず押さえておきましょう。請負契約と準委任契約の違いや、発注前にどちらを選ぶべきかについては業務委託エンジニアの契約形態の選び方で詳しく整理しています。

なお、準委任契約で「自社の指示どおりに作業してほしい」と発注者が細かく指揮命令を行うと、偽装請負と見なされるリスクがある点にも注意が必要です。保守フェーズで対応を依頼する際の指揮命令の境界線については偽装請負チェックリストを参照してください。

契約不適合責任「だけ」では納品後の保守が回らない理由

ここまでで、「契約で約束した内容と違うもの」については契約不適合責任で無償対応を求められる、ということが分かりました。では、これだけで納品後の保守は十分でしょうか。答えは「いいえ」です。

契約不適合責任がカバーしないものは、たくさんあります。

• 通知期間を過ぎてから出た不具合: 「知った時から1年」「契約で定めた期間」を過ぎると、原則として無償対応を求められなくなる
• 運用しながらの改善・チューニング: 「もっと使いやすくしたい」「処理を速くしたい」といった改善は、契約不適合（＝当初の契約との違い）ではないため対象外
• 機能追加・仕様変更: 「新しい決済方法を追加したい」「画面に項目を増やしたい」といった変更は、そもそも契約の範囲外なので別途の発注になる
• 外部環境の変化への対応: OSやライブラリのアップデート、ブラウザの仕様変更などに起因する不具合への対応

つまり、契約不適合責任は「納品時点で契約と違っていたもの」を一定期間カバーするセーフティネットにすぎず、システムを継続的に運用・改善していくための「保守」そのものを担保するものではないのです。

だからこそ、契約不適合責任とは別に、任意の「保守サポート」を契約で取り決める必要があります。次の章では、その保守サポートで決めるべき5項目を具体的に見ていきます。

受領後の保守サポートを契約で決める5つの項目

ここからがこの記事の中核です。契約不適合責任ではカバーされない「任意の保守サポート」を契約で担保するために、発注者が決めておくべき5つの項目を解説します。それぞれ「なぜ必要か」「どう決めるか」「決めないとどうなるか」をセットで押さえてください。

①対応範囲 — どこまでが「保守」なのかを定義する

最初に決めるべきは、何を保守サポートの対象とするかです。ここが曖昧だと、対応のたびに「これは範囲内か外か」の交渉が発生します。

ポイントは、「バグ修正」と「機能追加・仕様変更」を明確に分けることです。

• 保守に含めるもの（例）: 既存機能が仕様どおり動かない不具合の修正、軽微な不具合への対応
• 保守に含めないもの（例）: 新しい機能の追加、画面項目の追加、外部サービスとの新規連携など、当初の仕様にない変更

あわせて、対象となるシステム・環境の範囲も明記します。「どのシステムの」「どの環境（本番／検証）の」「どの範囲のコードまで」を対象とするかを決めておくと、後で「それは対象外のサーバーだ」といった行き違いを防げます。

決めないとどうなるか: 報告した不具合がバグ修正なのか機能追加なのかで毎回揉め、対応が遅れます。

②対応期間 — 無償保証期間と有償保守期間を切り分ける

次に、保守サポートの期間を決めます。ここで意識したいのは、前の章で説明した「契約不適合責任の通知期間（無償保証期間）」と、「任意の有償保守期間」を切り分けることです。

整理すると、納品後の時間軸は次のように二段構えで考えられます。

1. 無償保証期間: 契約不適合責任に基づき、契約と違う成果物を無償で直してもらえる期間（例: 引渡しから○か月）
2. 有償保守期間: その後、運用を支えるために有償で保守を依頼する期間（例: 月額契約で1年間など）

この2つを混同すると、「無償だと思っていたのに有償と言われた」というトラブルになります。契約段階で「ここまでは無償保証」「その先は別途の保守契約」と線を引いておきましょう。保守期間の開始日・終了日、更新の有無もあわせて明記します。

決めないとどうなるか: いつまで無償でいつから有償か分からず、不具合対応のたびに費用負担で揉めます。

③料金・単価 — 課金方式と最低発注単位を決める

保守を有償で依頼する場合、その料金体系を決めます。代表的な方式は3つです。

どの方式を選ぶにせよ、無償対応との線引きを明確にしておくことが重要です。「契約不適合責任の範囲は無償」「それ以外の保守は有償（この単価）」とはっきりさせておきます。

また、時間単価やチケット制の場合は「最低発注単位」も決めておくとよいでしょう。「5分の修正でも最低1時間分を請求する」のか「実時間分のみ」なのかで、小さな依頼のしやすさが変わります。

決めないとどうなるか: 依頼するたびに見積もり交渉が必要になり、機動的な対応ができません。

④レスポンス・SLA — どれくらいの速さで対応してもらうか

不具合が出たとき、どれくらいの速さで対応してもらえるかは運用上きわめて重要です。これを定めるのが、いわゆるSLA（Service Level Agreement／サービス品質保証）です。

決めておきたい主な項目は次のとおりです。

• 一次回答までの時間: 不具合を報告してから最初の返答が来るまでの目安（例: 営業日内に○時間以内）
• 対応時間帯: いつ対応してもらえるか（平日日中のみか、夜間・休日も含むか）
• 緊急度の定義: 「システム停止などの緊急」と「軽微な不具合」を分け、緊急度に応じた対応時間を設定する

ここで一つ注意点があります。個人のフリーランスエンジニアに対して、組織向けのような厳しいSLAを課すのは現実的ではないことが多いです。「24時間365日、1時間以内に対応」といった条件は、一人で働くエンジニアには物理的に困難で、引き受け手が見つからなかったり、形だけの約束になったりします。相手の稼働状況に合った、実効性のある水準で合意することが大切です。

決めないとどうなるか: 「いつ対応してくれるか分からない」状態になり、緊急時に運用が止まります。連絡途絶リスクへの最初の歯止めにもなる項目です。

⑤対象外条件 — 保守に含めない範囲を明記する

最後に、保守の対象外とする条件（免責）を明記します。①の対応範囲が「何を含めるか」だとすれば、こちらは「何を含めないか」を念のため明文化するものです。両面から定義することで、グレーゾーンを最小化できます。

対象外として明記されることが多いのは、次のようなケースです。

• OS・ライブラリ・ミドルウェアの更新に起因する不具合: 外部要因による問題は別対応とする
• 発注者や第三者が加えた改変に起因する不具合: 納品後に別の人がコードを変更した結果の不具合は対象外とする
• 仕様変更を伴う対応: 機能追加・変更は保守ではなく別料金の開発案件とする

これらを書いておくことで、「それは私の保守の範囲ではありません」という主張の根拠が双方に明確になり、かえってスムーズに話が進みます。

決めないとどうなるか: 本来は別案件であるべき対応まで「保守だから無償で」と求めてしまい、関係がこじれます。

5項目チェックリスト

ここまでの5項目を、発注前に確認できるチェックリストとしてまとめます。次の発注時に、契約書や見積もりにこれらが盛り込まれているかを確認してみてください。

受領時に確認すること＋契約書にそのまま使える文言例

前章で決めるべき5項目が分かったところで、それを実際の契約書や受領時の合意にどう落とし込むかを見ていきます。ゼロから文章を考える負担を減らせるよう、文言例も示します。

成果物受領時に合意・記録すべき事項

保守の取り決めは、できるだけ「成果物を受領するその瞬間」に確定させておくのが理想です。受領後に時間が経つほど、エンジニアの関心は次の案件に移り、条件交渉が難しくなるからです。

そこで役立つのが、「成果物受領確認書」という形で受領時の合意を文書化しておく方法です。盛り込んでおきたい事項は次のとおりです。

• 受領日: いつ成果物を受け取ったか
• 検収完了の定義: どの状態をもって検収完了とするか（テスト項目の合格、動作確認の完了など）
• 契約不適合責任の起算点: いつから通知期間がスタートするか
• 保守へ移行する条件: 検収完了後、どの条件で有償保守契約に移るか

受領という一度きりのタイミングで「ここまでが当初の契約、ここからが保守」という境界を明文化しておくことが、後のトラブルを大きく減らします。なお、検収完了の定義そのものをどう設計するか（テスト項目の合格基準や動作確認の手順）に迷う場合は、業務委託エンジニアの成果物検収・品質管理を仕組み化する方法が参考になります。

保守サポート条項の文言例

業務委託契約書、または保守に関する覚書に盛り込む条項の例を示します。あくまで叩き台ですので、自社の状況に合わせて調整してください。

第○条（保守サポート）
1. 乙は、本件成果物の検収完了後、別途定める保守期間中、
   以下の範囲の保守サポートを提供する。
   (1) 本件成果物の既存機能が仕様に適合しない不具合の修正
   (2) 軽微な不具合への対応
2. 前項の保守サポートには、新規機能の追加、画面項目の追加、
   外部サービスとの新規連携その他仕様の変更を伴う対応を含まない。
   これらは別途の業務委託として取り扱う。
3. 保守期間は、検収完了日の翌日から起算して○か月間とする。
4. 保守サポートの対価は、月額○○円（税別）とする。
5. 乙は、甲からの不具合報告に対し、原則として営業日内
   ○時間以内に一次回答を行う。対応時間帯は平日○時から○時とする。
6. 次の各号に起因する不具合は、本条の保守サポートの対象外とする。
   (1) OS、ライブラリその他第三者提供ソフトウェアの更新
   (2) 甲または第三者による本件成果物の改変
   (3) 仕様の変更を伴う対応

この例は、前章の5項目（対応範囲・対応期間・料金・レスポンス・対象外）をそのまま条文に対応させています。自社のシステムに合わせて、対象範囲や期間、料金体系を書き換えて使ってください。

フリーランス新法で発注者に求められること

個人のフリーランスエンジニアに業務を委託する場合、2024年11月1日に施行された「フリーランス・事業者間取引適正化等法（フリーランス新法）」によって、発注者側にいくつかの義務が課されています。これは「知らなかった」では済まされない法令上の義務なので、受領・保守の実務に関わる範囲を押さえておきましょう。

取引条件の明示（3条通知）: フリーランスに業務委託をした場合、発注者は業務の内容、報酬の額、支払期日などを書面または電磁的方法で明示しなければなりません（参考: 政府広報オンライン）。保守を依頼する際も、この明示義務は同様に適用されます。

報酬の60日以内支払い: 成果物などを受け取った日から数えて60日以内のできる限り短い期間内に、報酬の支払期日を設定し、その期日までに支払う必要があります。ここで注意したいのは、起算点が「受け取った日」であって「検収完了日」ではないという点です。「納品後30日かけて検品する」と契約していても、支払期日は検品完了日ではなく、あくまで物の提供を受けた日から60日以内に設定しなければなりません（参考: 政府広報オンライン）。検収に時間をかける運用を取っている場合は、支払いタイミングが法令に違反していないか確認が必要です。

継続的業務委託の中途解除は30日前予告: 6か月以上の期間にわたって行う業務委託（更新により継続して6か月以上になるものを含む）を中途解除しようとする場合、発注者は原則として少なくとも30日前までにその予告をしなければなりません（参考: 公正取引委員会 フリーランス法特設サイト）。月額固定で長期の保守契約を結ぶ場合は、この継続的業務委託に該当する可能性があるため、解約したくなったときに突然打ち切れるわけではない点に注意が必要です。

これらは発注者が守るべき義務であり、保守フェーズを含めた長期の取引ほど関わってきます。フリーランスへの発注を継続的に行う事業者は、自社の発注フローがこれらの義務を満たしているか、一度点検しておくことをおすすめします。

文言例を使うときの注意

ここで示した文言例やチェックリストは、あくまで「ゼロから書く負担を減らすための叩き台」です。実際に契約書として運用する際は、次の点に留意してください。

• 自社の状況に合わせて調整する: システムの重要度、想定する保守の量、予算によって、適切な範囲・期間・料金は変わります
• 最終的には専門家の確認を受ける: 契約書は法的効力を持つ文書です。重要な取引や金額の大きい契約では、弁護士など専門家のレビューを受けることを強くおすすめします
• 相手と合意できる現実的な水準にする: 発注者に一方的に有利な条件は、引き受け手が見つからなかったり、後の関係悪化を招いたりします

文言を整えることはトラブル予防の第一歩ですが、それを相手と誠実に合意できてこそ意味があります。

保守フェーズの依頼先をどう決めるか — 継続依頼・別調達・内製の判断軸

契約条項を整えたら、最後に考えたいのが「そもそも保守を誰に任せるか」です。同じエンジニアに続けて頼むのか、別の人や会社に切り替えるのか、社内で対応するのか。この意思決定の判断軸を整理します。

同じエンジニアに継続依頼する場合

最も自然な選択肢は、開発を担当したエンジニアにそのまま保守も依頼することです。

メリットは明確です。コードを書いた本人なので、システムの構造や設計意図を熟知しており、不具合の原因特定や修正がスムーズです。引き継ぎや学習のコストがかからず、立ち上がりが早いのが最大の利点です。

一方でリスクもあります。一つは「属人化」です。そのエンジニアしかシステムを理解していない状態が続くと、もし対応してもらえなくなったときに代わりがいません。もう一つは前述の「連絡途絶」リスク。個人に依存するため、相手の都合一つで保守が止まる可能性があります。さらに、唯一の理解者であるがゆえに、単価交渉で発注者が不利になりやすい面もあります。

これらのリスクを下げるには、後述するドキュメントの整備や、契約段階での引き継ぎ可能性の確保が有効です。

別のフリーランス／開発会社に切り替える場合

開発担当者とは別の人や会社に保守を任せる選択肢もあります。属人化を避けられる、複数の選択肢から条件を比較できる、といったメリットがあります。

ただし、この場合は引き継ぎコストが大きな論点になります。新しい担当者がシステムを理解するまでに時間がかかり、その間は対応が遅くなりがちです。

ここで効いてくるのがドキュメントの有無です。設計書、仕様書、環境構築手順、ソースコード内のコメントなどが整っていれば、別の担当者への切り替えはぐっと楽になります。逆に何も残っていなければ、コードを読み解くところから始めることになり、引き継ぎコストが跳ね上がります。

そのため、開発を発注する段階で「ドキュメントを成果物に含める」「ソースコードと一緒に設計資料を納品する」ことを契約に盛り込んでおくと、将来どの依頼先を選ぶにしても選択肢が広がります。属人化リスクへの根本的な備えになります。

内製化する場合

社内にエンジニアを採用・配置して、保守を内製する選択肢もあります。

内製が向くのは、システムが事業の中核を担っていて継続的な改善が必要なケース、更新頻度が高くその都度外注していてはコストもスピードも見合わないケースなどです。社内に知見が蓄積され、機動的に動けるのが利点です。

一方で、エンジニアの採用・育成・定着というハードルがあり、相応の体制と予算が必要です。一定規模以上の継続的な開発需要が見込めて初めて、内製のコストが正当化されます。

判断軸の整理

3つの選択肢を、どう選び分ければよいのでしょうか。次の4つの軸で考えると整理しやすくなります。

重要度が高く更新頻度も高いシステムは内製や複数体制での保守が安心です。逆に、軽微な保守が時々発生する程度なら、開発担当者への継続依頼がもっとも手間がかかりません。自社のシステムがどのポジションにあるかを見極めて、依頼先を選んでください。

まとめ — 納品後のトラブルは「受領前」の取り決めで防ぐ

ここまで、業務委託エンジニアの成果物を受領した後の保守サポートを、契約でどう取り決めるかを解説してきました。要点を整理します。

• 無償と有償の境界を理解する: 「契約で約束した内容と違う成果物」は契約不適合責任で無償対応を求められますが、これは納品時点の不適合をカバーするセーフティネットにすぎません。運用改善や機能追加、期間経過後の不具合は対象外です
• 保守サポートを5項目で決める: 対応範囲・対応期間・料金/単価・レスポンス（SLA）・対象外条件の5つを契約で明文化することで、グレーゾーンを最小化できます
• 受領時に合意し、文言で残す: 「成果物受領確認書」で受領日・検収完了の定義・保守移行条件を記録し、契約書には保守条項を明記します。フリーランスへの発注では、フリーランス新法の60日以内支払い・中途解除30日前予告などの義務も忘れずに
• 依頼先を判断する: 継続依頼・別調達・内製の3択を、システムの重要度・更新頻度・社内体制・予算の軸で選びます。ドキュメント整備は属人化への根本的な備えになります

最後に、この記事を通じて最もお伝えしたいことを一つ挙げるなら、それは「保守の取り決めは、納品後ではなく発注・受領の段階で決めておくのが最善」だということです。

トラブルが起きてから「契約に書いていなかった」と気づくのでは遅いのです。次に業務委託エンジニアへ開発を発注するとき、あるいは現在進行中の契約を見直すときに、本記事の5項目チェックリストと文言例をぜひ手元に置いてみてください。受領確認書の準備や契約条項の追加といった小さな一手間が、納品後の大きなトラブルを未然に防ぎます。

業務委託エンジニアの活用を、受領後のフェーズまで含めて体系的に押さえておきたい方は、より実践的なマネジメントの考え方を整理した資料もあわせて参考にしてみてください。発注から受領、そして保守までを見通した発注の仕組みづくりが、トラブルを繰り返さない外部人材活用への近道になります。