フリーランスの検収とは？基準・結果・修正依頼を記録する進め方

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

業務委託の検収では、納品したファイルを開けたかだけでなく、合意した仕様に対して、どの版を、どの条件で確かめ、どの結果になったかを残すことが大切です。送付した側の「完成しました」と、受け取った側の「確認が終わりました」が同じ対象を指していれば、修正や追加の相談も整理しやすくなります。

この記事は、フリーランスが小規模なソフトウェアや簡単な業務ツールを納める案件を中心に、検査の準備から結果の記録、修正後の再検査、完了後の引継ぎまでを解説します。継続的な相談業務や常駐業務へ同じ仕組みを一律に当てはめるものではありません。まず、自分の契約が何を納入物とし、何を検収完了の条件にしているかを確かめてください。

例として使うのは、架空の「問い合わせ一覧ツール」です。担当者が件名を登録し、未対応の問い合わせを絞り込み、その結果を一覧データとして書き出す小さな仕組みを想定します。仕様、担当、版番号、検査手順、結果、日程、文例はすべて説明用に作成したものです。実際の開発やテストを実施した記録ではなく、架空の記入例として読んでください。画像も説明用の生成イメージです。

公式資料は二〇二六年十月六日（日本時間）に確認しました。IPAのモデル契約は確認観点の参考であり、すべての業務委託に当然に適用される法律ではありません。契約の効力や責任、法律の適用には個別の事情が関係します。判断が分かれる場合は、契約とやり取りをそろえて弁護士などの専門家へ確認してください。

納品・受領・検査・検収完了を別の状態として整理する

「届いた」と「確認を終えた」を別の欄へ置く

納品は、自分が合意した納入物を渡す工程です。受領は、相手がそれを受け取ったことを確かめる場面です。検査では、対象物が合意仕様に合うかを確かめます。検収完了の扱いは、結果の通知なども含めて契約の定めを確認します。これらの言葉を現場で同じ意味に使うこともあるため、本稿の呼び方だけで相手の契約を読み替えないようにしましょう。

たとえば、共有先へファイルを置いた直後に「ありがとうございます」と返信された場合、その言葉が何への返答なのかを見ます。到着のお礼か、開封の連絡か、検査結果の承認かが分からなければ、完了欄を埋める前に確認します。相手の返答を都合よく広く解釈せず、判断してもらいたい対象を具体的に示す方が行き違いを減らせます。

一方、受領確認の返信がまだないことだけで、法律上も未受領だと決めることはできません。実際の受け渡しの状況と、管理表で返信を確認した時点は別です。メールの送信日時、相手側で利用できる状態、到着確認の連絡をそれぞれ控え、支払期日の起算日を検討するときには、その事実関係を使います。

契約から確認条件だけを抜き出す

検査に入る前に、基本契約、個別の注文、合意した仕様書、変更の合意を並べます。必要なのは契約全文を管理表へ写すことではなく、対象物、判断基準、検査する人、期間、通知方法、再検査の扱いを見つけることです。文書どうしに差がある場合は、優先関係と合意の経緯を確認し、一方だけを選んで作業を進めないでください。

検収の条項が見当たらない場合は、他社のひな型をそのまま後付けしません。「今回どの項目をどの方法で確認し、結果を誰から受け取るか」を相談し、実務で必要な手順をそろえます。その相談自体が契約変更を含むなら、相手側でも判断できる人へ確認します。作業担当者の予定調整と、条件を変える合意を混ぜないことが大切です。

※表は横にスクロールできます。

この表は、必ず六種類の書類を作るという意味ではありません。一枚の表でも、案件管理ツールでも構いません。ただし、「完了」という一つの選択肢に全部を押し込むと、実装が終わったのか、検査が終わったのか、入金まで済んだのかが分からなくなります。出来事ごとに、確認した人と根拠の場所を残してください。

誰が結果を判断するのかを確かめる

発注窓口と、実際にツールを操作する担当者と、最終的な結果を通知する人が別のことがあります。問い合わせ一覧ツールなら、日々の受付担当が動作を確かめ、業務責任者が結果を取りまとめる、といった体制を想定できます。担当者の肩書から権限を推測せず、今回の案件で誰が何を判断するかを確認します。

受託側で動作確認を行っていても、それを発注側の検査と同じ結果として扱えるかは別の話です。自分の確認は自分の実施記録として残し、相手に必要な検査を省略してよいと勝手に判断しません。説明会で一緒に画面を見た場合も、対象項目と結果を記録し、単なる操作説明だった部分まで合格にしないようにします。

複数の担当から相反する連絡が来たら、すぐに両方を実装し直すより、同じ仕様と対象版を見ているかを確認します。受付担当は「未対応だけ表示したい」、別担当は「完了済みも全部見たい」と言っている場合、異なる画面の相談かもしれません。事実を整理して、結果をまとめる窓口へ戻すと、不要な改変を防ぎやすくなります。

予定と実績を並べて、遅れの理由を残す

検査開始の予定と実際の開始を別欄にします。予定日になっても試験用のデータが届かなければ、「開始済み」ではなく、何が不足しているかを残します。相手の担当不在、権限不足、手順書の不足、対象版の相違では、次に動く人が違います。単に「相手待ち」と書くより、確認する内容を一つに絞る方が対応を頼みやすくなります。

予定が変わるときも、元の日付を消すだけにせず、変更の理由と新しい予定を記録します。実務上の日程調整が、契約上の期限や法律上の支払期日まで変更したことにはなりません。どの予定を動かし、どの条件は別途確認中なのかを分けましょう。この節で完成させるのは、納品から完了までの状態一覧です。

合意した仕様を確認できる検査項目へ移す

仕様の版を固定してから検査票を作る

検査票を作る出発点は、すでに合意した仕様です。要望を新しく聞き集めたり、作る範囲を広げたりする工程とは分けます。問い合わせ一覧ツールなら、合意済みの仕様書第一版を基準とし、件名の必須入力、未対応の抽出、書き出す列の順序、操作説明の対応を確認対象にする設定です。

IPAの情報システム・モデル取引・契約書 第二版の第27条は、仕様書を基に検査項目・データ・方法・期間などを双方で確認するモデル例です。本稿ではこの考え方を参考に、独自の簡単な検査票を示します。モデルの文言や役割を、自分の契約に採用済みであるかのように扱わないでください。

仕様書に「使いやすい一覧」とだけ書かれていたら、検査時に自分の判断で合格条件を作り足すことは避けます。何を満たせばよいかを関係者へ確認し、補足の位置付けを合意します。既に決まっている条件の説明なのか、新しい要求なのかによって、取り扱いが変わるためです。曖昧な箇所は検査票へ隠さず、確認事項として表に出します。

一行ごとに、条件・操作・期待結果をそろえる

検査項目には、参照する仕様、開始時の状態、使用するデータ、操作、期待結果を記入します。実際の結果は実施後に記入する欄にし、最初から期待結果を複写しません。手順を読んだ担当者が、別の人へ口頭で質問し続けなくても同じ対象を確かめられるくらいに具体化すると使いやすくなります。

次の表は、未実施の架空の検査手順です。検査番号をT01からT06、仕様番号をS01からS04としています。番号は識別のためのもので、業界の標準書式ではありません。実際には相手が使う番号へ合わせ、仕様と検査の対応が追えるようにしてください。

※表は横にスクロールできます。

件名必須という一つの仕様でも、空欄を拒否する確認と、必要な値があるときに登録できる確認を分けています。拒否する場面だけが正しくても、通常の入力まで保存できなければ使えません。反対に、普通に入力できたことだけでは、空欄を止める条件は確かめられません。仕様の意味に沿って、必要な分岐を選ぶことがポイントです。

この架空例では、未対応二件と対応済み一件を合わせて、元のデータは三件です。抽出後の期待件数は二件で、三件すべてを出すのが正解ではありません。件数だけでなく、対象となる番号も照らします。二件表示されたとしても、未対応一件と対応済み一件なら、件数は合っていても結果は仕様に合いません。

検査データは説明できる小さな組を用意する

最初の確認には、何が正解かを目で追える架空データを用意すると便利です。各行の番号、件名、状態が分かり、なぜ抽出されるかを説明できるようにします。実際の顧客情報を使う必要がある場合は、利用目的、共有先、許可された環境を確かめ、単に手近にあるからと本番データを複製しないでください。

検査データを途中で直す場合は、データの版も変えます。最初の確認では未対応が二件だったのに、誰かが一件を対応済みにしていたら、同じ手順でも結果は変わります。開始前にデータを戻す手順、担当者ごとの検査用コピー、同時に操作してよい範囲などを決めると、実装の問題と検査条件の相違を区別できます。

本稿の小さなデータで確認できるのは、指定した条件の基本的な動きです。大量データでの性能、あらゆる端末での表示、セキュリティ全般が保証されたという意味にはなりません。契約で別に要求されている確認があれば、その担当と手法を整理します。専門的な試験を行っていないのに「全テスト完了」と表示しないことが必要です。

合格以外の状態も、最初に選べるようにする

検査結果を「合格」「不合格」だけにすると、実行できなかった項目までどちらかへ寄せたくなります。本稿の記入例では、未実施、実施中、適合、不適合、保留を区別します。保留には、確認できない理由と再開の条件を添えます。前提がそろわないことと、試して違いが見つかったことを同じ意味で記録しないようにします。

複数の確認を一つの行へまとめると、一部だけ終えた状態が隠れます。たとえば書き出しで、対象行、列順、値の内容を別々に確認するなら、その内訳を残します。全体として一つの項目にする場合も、どの観点を終えたかを説明できる欄を設けてください。チェックマークを増やすことより、判断の根拠を残すことを優先します。

検査票の案ができたら、仕様から検査へたどる読み方と、検査から仕様へ戻る読み方の両方で点検します。検査がない仕様、参照先のない検査、合意していない期待結果を探します。この節の成果物は、合意仕様と検査項目の対応表です。作成者と相手の確認結果を添え、検査する人へ渡せる版として残しましょう。

検査対象の版・環境・期限・連絡先をそろえて渡す

「最新版」という名前だけで渡さない

完成したつもりのファイルでも、相手が以前の共有先を開けば、古い動きを確かめることになります。納入物一覧には、成果物の名称、ファイル名、版、置き場所、対応する説明資料を記入します。「最終版」「本当の最終版」のような名前を増やすより、識別できる版を使い、今回どれを検査するかを明記する方が確実です。

問い合わせ一覧ツールでは、プログラム一式を第一版、操作説明を第一版、検査用データを第一版として渡す設定にします。それぞれが同じ版名でも、別の文書なので一覧の行を分けます。プログラムだけを更新して説明書を据え置く場合は、説明がそのまま使えるかを確認し、変更しなかった資料も識別できる形で残します。

ファイルの同一性が重要な案件なら、相手が扱える方法でチェックサムなどの照合情報を付けることも考えられます。ただし、それだけで動作品質や契約への適合が証明されるわけではありません。小規模な案件では、まず版、提出日時、変更履歴が一致しているかを確かめ、技術的な管理方法を目的以上に増やさないようにします。

検査に使う環境を特定する

環境欄には、使う端末や基本ソフト、ブラウザー、関連する設定など、結果に関係する条件を書きます。「一般的なパソコン」では範囲が広すぎます。契約で合意した環境を基準にし、現時点の実際の版を調べて記入します。この記事では実機を用いた確認をしていないため、特定の製品版で動作確認済みとは示しません。

検査場所が本番環境と違う場合は、その違いも残します。本番では別の外部サービスへつながる、扱うデータが多い、利用者の権限が違う、といった差があるなら、検査環境だけでどこまで判断できるかを共有します。未確認の範囲を黙って合格へ含めず、必要な追加確認の担当を決めることが大切です。

試験用の利用者を準備する場合は、その人に何の操作を許すかを確認します。確認しやすいからと、全員へ管理者権限を渡すことは避けてください。認証情報は納入物一覧や広く見える指摘票に書き込まず、合意した安全な受け渡し方法を使います。検査終了後に不要となる権限の扱いも、後の引継ぎへつなげます。

※表は横にスクロールできます。

期限は契約と明示内容から確認する

検収期間が法律で一律に七日や十四日と決まっている、と説明することはできません。今回の契約が何を起点とし、どの期間で検査し、いつ結果を通知すると定めているかを確認します。営業日と暦日、時刻、休日の扱いが重要な場合は、その意味までそろえます。曖昧なまま自分の計算で締切を確定しないようにしましょう。

フリーランス法の取引条件明示の対象で、給付内容を検査する場合には、検査を完了する期日の明示が必要です。根拠はフリーランス法の考え方（二〇二六年十月一日改正）の取引条件明示の項目です。受託者側の引継ぎ票は、その明示内容を確認するためにも使えますが、発注者側の明示義務を当然に代替するものとは扱いません。

日程に無理があると気付いたら、未実施の項目と理由を早めに共有します。「忙しいので延ばしてください」だけより、「検査用の利用者が未準備で、書き出しの確認を開始できていない」と書く方が、必要な対応が分かります。変更を相談したという記録と、実際に変更が合意された記録は区別してください。

質問窓口と結果通知の宛先をそろえる

操作上の質問は制作担当へ、正式な結果は契約の窓口へ、という運用もあります。問い合わせ一覧ツールの検査を始めるときは、質問先、指摘票の置き場所、結果の受領先を一つの案内にまとめます。担当者が休んだときに、別の人がどこから確認を続けるかも分かるようにすると、個人の受信箱だけで作業が止まりにくくなります。

自作の開始案内は、「問い合わせ一覧ツール第一版を提出しました。対象と環境は引継ぎ票第一版、確認項目は検査票第一版をご参照ください。ご指摘は検査番号と再現条件を添えて指定の一覧へお願いします。結果の通知は合意済みの方法と期日に沿ってお願いします」といった形です。実際の相手に必要な情報だけへ調整してください。

案内には、今まで合意していなかった自動承認や追加料金の条件を混ぜません。受領のお願いと、条件変更の提案を同じ一文にすると、何を了承したかが曖昧になります。新しく決める必要のある条件は、未決事項として分け、確認された内容を関係する契約や記録へ反映します。

送信する前には、今回の対象一式を開いて点検します。名前は合っているのに中身が古い、説明書から開く先だけが旧版、架空データに前案件の情報が残っている、といった取り違えを探します。この節の成果物は納入物一覧と検査開始の引継ぎ票です。相手が同じ対象へ到達できる状態まで整えて、検査へ渡しましょう。

不合格理由を再現条件と合意仕様に照合する

最初に「何が起きたか」を受け取る

「動きません」という指摘だけでは、どの場面で何が違ったのかが分かりません。いきなり相手の操作を疑ったり、すべてを自分の不具合と認めたりせず、対象版、環境、開始状態、行った操作、期待した結果、実際の結果を順に確認します。原因の判断より先に、同じ出来事を再現できる材料をそろえることが重要です。

架空例として、未対応の絞り込み後に書き出した一覧へ、対応済みの行も入っていたとします。検査番号はT05、参照仕様はS03です。指摘票には「書き出しが変」ではなく、「画面の抽出対象は二件だが、書き出しには三件あり、対象外の番号が含まれる」と残します。期待と実際を並べると、調べる場所が明確になります。

相手の環境でだけ起きる場合は、同じ版か、同じデータか、同じ操作順かを確かめます。再現しなかったことは大切な結果ですが、それだけで問題が存在しないと結論付けません。「受託側の確認環境では未再現、相手側の条件を照合中」と記録し、次に確認する違いを具体化します。

証拠は必要な部分を、対象番号と一緒に残す

画面の画像や記録を付ける場合は、指摘番号と検査番号へ対応させます。画像だけが大量に並ぶと、何を示していたのか分からなくなります。画面名、操作直後の状態、参照する行を短く説明し、個人情報や別案件の内容が写っていないか確認します。証拠を残すために、関係のない機密情報まで配布しないようにしてください。

記録を取り出すために、本番の設定を変えたり、利用者の操作履歴を広く集めたりする必要があるなら、先に権限と範囲を確認します。本稿は、そのような調査を無条件に許可するものではありません。小さな架空データで再現できるなら、まずその条件を使い、実データが必要な場合だけ適切な方法を相談します。

※表は横にスクロールできます。

期待件数二件と実際の三件との差は一件です。ただし、「余分な一件を消せば終わり」と手作業でファイルだけを直すと、ツールが同じ条件で再び誤出力する可能性があります。納入物として何を直す必要があるかを仕様へ戻って確かめ、出力ファイルの調整とプログラムの修正を取り違えないようにします。

合意仕様との不一致と、後からの追加希望を見分ける

指摘の中には、もともとの約束に合っていない点と、新しく便利にしたい希望が混ざります。未対応だけを書き出す仕様なのに対応済みも含むなら、仕様との不一致を調べます。一方、「書き出す列へ担当者の部署も追加したい」という話なら、既存の合意に含まれるかを確認し、含まれていなければ追加相談として整理する考え方です。

見分けるために必要なのは、相手の言い方の強さや「修正」という件名ではありません。元の仕様、変更合意、提出物、問題の条件を並べます。もとの仕様に明記がないから必ず追加、後から見つかったから必ず無償、といった単純な決め方は避けましょう。文書の不足や双方の認識差がある場合は、その経緯も含めて協議が必要です。

フリーランス法第5条の不当な変更・やり直しの禁止は、対象となる発注者による原則一か月以上の業務委託など、適用条件のある規定です。受託者に帰責事由がないのに利益を不当に害する変更などが問題になります。すべての修正依頼が違法になるという説明は適切ではありません。公正取引委員会のＱ＆Ａの適用条件とQ82を確認してください。

その場で決められない指摘を放置しない

区分が決められないときは、「協議中」として、足りない材料、判断する人、回答の予定を残します。たとえば部署列の追加について、以前の会議で含める話があったという指摘なら、その記録を確認します。相手の記憶だけを否定することも、資料を探さず追加を引き受けることも避け、合意の経緯を同じ場所で見られるようにします。

自作の受領返信は、「指摘番号I01を受け付けました。対象版と再現条件を照合し、合意仕様S03との差を確認します。部署列の追加希望は別の相談として記録しています。対応範囲と日程は確認後にご案内します」とできます。確認していない原因や費用、解決日を断言せず、受け付けた内容と次の行動を伝えます。

重大な影響がある指摘は、通常の一覧へ入れるだけで済ませず、合意した緊急連絡先へ状況を共有します。ただし、利用停止やデータの削除を勝手に行って解決しようとしないでください。どこまで影響しているか、今わかっている事実、利用上の判断を誰へ求めるかを整理します。専門的な対応が必要なら適切な担当へつなぎます。

一つの指摘で複数の現象が起きている場合は、対応を分けて管理することがあります。画面表示の誤りと書き出しの誤りが同じ原因とまだ分からないなら、別の確認対象として残します。反対に同じ指摘が複数の窓口から届いたら、元の番号へ結び付けます。未対応の件数が少なく見えるように、根拠なくまとめないことが大切です。

この節の成果物は、指摘事項と対応区分の記録票です。「受付」「確認中」「対応方針確認済み」「修正済み」「再検査待ち」を使い分けると、何を待っているかが伝わります。修正ファイルができた段階で指摘を閉じず、相手の確認結果までたどれるように、次の再検査へ引き継ぎます。

修正・再検査・みなし合格の条件を確認する

直した場所と、新しい対象版を対応させる

修正を行うときは、指摘番号、変更内容、対象版、確認する項目を同じ履歴へ残します。問い合わせ一覧ツールの第一版で書き出し対象が違っていたという架空例なら、I01に対応する修正版を第二版として区別します。「修正しました」という連絡だけでは、相手が何を開き直すか分からないため、置き場所と版を一緒に伝えます。

修正版の中に、まだ合意していない部署列の追加まで混ぜることは避けます。関連しそうだからと一緒に変更すると、再検査で確かめる条件が変わります。今回直した範囲と、別の相談として残っている範囲を明示してください。内容を変更していない資料も、今回の版に対応して使うことが分かるように一覧へ残します。

修正前の記録は、許可された保存方法に沿って残します。第一版の出力結果を第二版の結果で上書きすると、何が直ったのかを説明できません。比較に必要な記録を保ちつつ、相手が誤って旧版を使わないよう、検査対象への案内は明確にします。保存することと、通常の利用先として残すことを分けましょう。

再検査する範囲を、変更の影響から相談する

修正した検査項目をもう一度確かめるだけで足りるかは、影響する範囲によります。書き出しの処理だけを直した場合でも、抽出条件の受け渡しに変更があれば、抽出と書き出しのつながりを確認する必要があります。すべてを毎回やり直すか、該当行だけで終えるかを機械的に決めず、変更理由を示して範囲をそろえます。

IPAの第二版本文の第28条は、具体的な不合格理由、修正、必要な範囲の再検査を扱うモデル例です。再検査の担当や期間は、自分たちの契約と調整内容を確認します。モデルに記載があることだけで、個別案件の条件が自動的に決まったとは考えないでください。

※表は横にスクロールできます。

この表も未実施の架空手順です。T04に関連する書き出しの扱いが元の仕様に書かれていなければ、都合のよい結果を期待欄へ足して合格にしません。既存の合意内容を確かめ、解釈を補う必要があるのか、追加の条件を決める必要があるのかを整理します。検査の途中で基準が動くと、前の結果との比較が難しくなります。

再検査の結果は、新しい記録として残す

結果欄は、前回の不適合を削除して適合へ書き換えるだけにしないようにします。初回の対象版と結果、再検査の対象版と結果を別に残せば、指摘が解消された経緯を追えます。相手が結果を確認した日時と、自分がファイルを提出した日時も分けます。これにより、修正済みなのに確認待ちの項目を見つけやすくなります。

再検査で同じ問題が残った場合は、指摘を開いた状態で続け、今回確認した条件を追記します。別の問題が見つかった場合は、新しい指摘番号にして元の修正との関連を示します。「一度直したので完了」と処理せず、現在の対象版でどの結果が得られたかを基準にします。原因が違う可能性もあるため、前回の説明をそのまま流用しません。

影響がないと判断して以前の結果を参照する項目には、その判断を残します。再実施していないのに、第二版ですべて実施済みと表示しないことが重要です。「第一版の結果を参照、変更の影響なしと双方確認」のように、引き継いだ結果と新たな実施結果を区別します。何を確認したかが読み取れれば、後からの調査にも使いやすくなります。

返信がないときは、条項の条件から確かめる

みなし合格とは、定められた条件の下で合格と扱う条項のことです。IPAのモデルにも、契約で定める検査期間内に具体的な理由を記した書面の異議がない場合を扱う例があります。しかし、相手が既読にした、返事が数日ないという事実だけで、どの契約でも自動的に合格となるわけではありません。まず自分の契約にその条項があるかを確認します。

条項がある場合も、対象物の納入、期間の起点と満了、通知方法、異議の内容、変更合意などを照合します。検査に必要なものがそろっていたか、期間中に別の窓口へ指摘が届いていないかも事実として整理します。適用の判断に争いがある場合は、単独で完了を宣言して処理を閉じず、専門家へ契約全体を確認してもらいましょう。

条項がない、意味が不明、受領の事実も確かめられない場合は、状況確認の連絡を行います。自作例は「提出した第二版について、検査状況を確認させてください。対象は検査票のT03・T05など、合意した再検査範囲です。実施できていない項目やご指摘があれば、対象番号と状況をご連絡ください」とできます。未合意の自動承認をこの連絡で追加しないでください。

完了通知に対象と残件を添える

検査結果がそろったら、契約で定めた完了の手続きを確認します。通知には、案件名、納入物の版、結果の対象範囲、参照する検査記録、残件の有無を添えると、別の版への承認と取り違えにくくなります。社内の承認待ちがある場合は、その状態を正確に記録し、実際に受け取っていない合格書を受領済みにしないようにします。

一部の未解決事項を残して区切る相談をするなら、その内容、影響、後の対応、検収との関係を明確にします。「軽微なのでよいだろう」と受託者だけで決めたり、相手が利用を始めたという理由だけで全条件の承認としたりしません。この節の成果物は、修正履歴・再検査結果・完了通知の一覧です。後から一つの指摘を選んで、最後の判断までたどれる形にします。

完了後の対応と支払期日を別々に引き継ぐ

検収完了の後も、確認する約束を分けて残す

検収が完了しても、契約上の責任や秘密保持などがすべてなくなるとは限りません。残っている課題、見つかった不具合の連絡先、保守の有無、対応する期間と範囲を契約へ戻って確認します。完了という表示は、その時点で所定の確認を終えた記録として扱い、その後のあらゆる問題に対応しなくてよいという意味へ広げないでください。

IPAの第二版でも、第29条は検収後の契約不適合を別に扱い、期間は個別に定める形になっています。さらに民法第637条の「不適合を知ってから一年以内の通知」に関する規定は、検収後一年の無料保証と同じ意味ではありません。契約条項と法の条件、例外を分けて確認し、一律の保証期間に置き換えないようにします。

たとえば、納入時の仕様に合わない問題が後で見つかった場合と、運用開始後に新しい機能を希望された場合では、確認すべき経緯が違います。基本ソフトの更新後に動作が変わった場合も、契約で想定した環境や保守の範囲を調べる必要があります。発見した時期だけで有償・無償を決めず、事実と条件をそろえて判断します。

残件は、解消条件と担当が分かる形にする

残件には、今回の完成範囲へ含まれる未完了事項、後の運用で確認する事項、別途の追加希望を分けて記録します。部署列の追加希望が未承認のままなら、完了した機能として紹介しません。「別途相談中、採否未定」とし、今回の検査結果と同じ一覧でも区分が分かるようにします。対応する約束をしていないのに、予定日を入れることも避けます。

運用側へ渡す情報は、操作説明、正式な利用先、問い合わせ窓口、障害時の連絡方法など、合意した範囲でそろえます。開発担当だけが知っている保存場所や作業上の仮設定が残っていると、担当が変わったときに困ります。秘密情報を一覧へ貼り付けることは避け、必要な人が安全な方法で受け取れるようにします。

※表は横にスクロールできます。

検査用の利用者や共有先を片付ける場合は、誰がいつ何を行うかを確認します。検収が終わったからと、必要な確認記録まで一方的に消さないでください。契約や組織の保存方針、法令上の必要性を踏まえて、残すものと終了するものを決めます。相手に渡した共有先を閉じるなら、代わりの参照先が必要かも確認します。

検収の進み具合と支払期日を別に照合する

フリーランス法第4条の対象となる取引では、原則として給付を受領した日から六十日以内のできる限り短い期間内に、報酬の支払期日を定める必要があります。検査の有無とは別に受領日を確認するため、検収が終わるまで支払いを無期限に延期できるとは考えません。詳細はフリーランス法の考え方の「期日における報酬の支払」を参照してください。

情報成果物の制作途中の一時的な預かりや、受託者の責めに帰すべき不適合による支払前のやり直しなどには、条件に応じた取り扱いがあります。単に修正版を送った、検査をやり直したという事実だけで、毎回すべての支払期日が自動的にリセットされるとは説明できません。公正取引委員会Ｑ＆ＡのQ45・Q46と実際の経緯を照合します。

支払確認票へ残すのは、当初の受け渡しの日時、その対象、やり直しの理由と指示、再提出の日時、合意した支払期日です。検収一覧の「完了日」をそのまま起算日へコピーせず、適用される法令と取引の条件から確認します。相手の経理へ情報を渡す際も、事実の記録と法的な判断が必要な箇所を分けて整理してください。

本稿では未払いの督促や回収方法、請求書の税計算は扱いません。検収工程で必要なのは、後続の担当が同じ事実を確認できるようにすることです。受領がいつだったか、どの修正が何に対応したかが曖昧なら、その箇所を確認します。支払期日に疑問がある場合は、契約と記録をそろえた上で、公的な相談先や専門家へ確認しましょう。

一つの指摘から最終版まで、取り出してみる

保存の確認では、単にフォルダーがあるかを見るだけでなく、指摘番号を一つ選びます。そこから合意仕様、最初の対象版、検査条件、実際の結果、修正内容、再検査結果、完了通知へたどれるかを確かめます。共有リンクが切れていたり、画像だけが残って対応する検査番号がなかったりしたら、記録のつなぎ方を見直します。

記録を増やすほどよいというわけではありません。必要な材料を、許可された場所へ、相手と確認できる形で残すことが目的です。会話の全文を何か所にも複製するより、案件番号と参照先を整理した方が扱いやすい場合があります。別の顧客へ使う空の検査票には、前の案件の名前、条件、データを残さないようにしてください。

次の案件へ生かす振り返りは、起きた行き違いを具体的な改善へ変えます。対象版を間違えたなら版の案内、同じ指摘が分散したなら受付窓口、期待結果が曖昧だったなら仕様との対応を直します。何もかも厳しくするのではなく、今回どこで判断材料が不足したかを探すと、相手の負担も増やしすぎず改善できます。

次の納品では、まず一項目を最後までつなぐ

業務委託の検収を進めるときは、合意仕様を検査項目へ移し、対象版と条件をそろえ、指摘を再現できる形で受け取り、修正後の結果まで残します。その上で、契約上の完了条件、残件、対応窓口、支払期日を確認します。書類の数よりも、それぞれが同じ納入物を指していることが重要です。

最初から大きな管理表を作る必要はありません。今の案件から一つの仕様を選び、確認する手順と期待結果を書き、その対象版と結果の受領先を添えてみてください。実施していなければ未実施、合意できていなければ確認中と正直に残します。その一項目を完了の記録まで追える形にしてから増やすことで、小さな納品型案件でも、互いに確かめながら区切りを付けやすくなります。