納品前に揉めないために、着手前に決めたい3つの基準
金曜夕方、終わったはずの案件が戻ってきた
「ここまでやったのに、まだ終わりじゃないの…？😥」
納品前で、こんな気持ちになったことはありませんか？
たとえば、管理画面の小さな改修を受けたとします。依頼は「一覧に検索条件を1つ追加したい」。見積りもそこまで大きくない。既存の画面に条件を足して、検索できるようにして、軽く表示確認をして、金曜の夕方に「対応完了しました」と連絡する。
少し肩の力が抜けたところで、相手から返信が来ます。
ありがとうございます。確認しました。 あと、CSV出力にも同じ条件を反映できますか？ それと、過去データもこの条件で見たいです。 念のためスマホ表示も確認してもらえると助かります。
悪い依頼に見えないのが、また困ります。CSVも、過去データも、スマホ表示も、使う側から見れば自然な確認です。相手も責めているわけではない。むしろ、ちゃんと業務で使えるかを見ようとしているだけです。
でも、受ける側の頭の中では別の声が出てきます。
これ、修正なのかな。追加なのかな。今から範囲外って言ったら、感じ悪いかな。
この時にしんどいのは、作業が少し増えることだけではありません。終わりが見えないことです。どこまで直せば完了なのか、誰がOKを出すのか、追加要望なのか不具合なのか。そこが曖昧なまま話が進むと、最後だけ急に自分の責任が広がったように感じます。
以前、納品直前の相談でよく見たのも、技術的には大きな問題がないのに、完了条件だけが揃っていないケースでした。担当者も悪気があるわけではない。むしろ、社内でちゃんと使えるか確認しようとしている。でも、着手前に線を引いていないと、最後の確認がそのまま無限の調整に変わります。
この記事で整理したいのは、強い契約文言の作り方ではありません。納品前に揉めないために、着手前の会話で最低限どこを揃えるか です。完璧な契約書を作れなくても、完了条件、確認者、追加対応の3つだけ先に置くと、最後の消耗はかなり減らせます。
揉める原因は、作業量より「終わり方」の空白
納品前に揉める案件では、相手の要望が全部おかしいとは限りません。むしろ、1つずつ見ると「まあ、確認したくなるよね」と思えるものが多いです。だからこそ、受ける側は苦しくなります。
CSVにも同じ検索条件を反映したい。過去データでも使えるか見たい。スマホでも崩れていないか確認したい。どれも、業務で使うなら気になることです。だから必要なのは、強く突っぱねることではありません。自然な要望を、今回の完了条件と混ぜないこと です。
相手の「確認したい」も、こちらの「終わった」も自然
発注側からすると、「完成したものをちゃんと確認したい」だけかもしれません。社内で使う人に見せたら、別の観点が出てきた。上長に見せたら、運用の話が出てきた。担当者としては、それをそのまま伝えているだけです。
受ける側からすると、「依頼された機能は入れたのに、まだ終わらない」と感じます。最初の依頼は検索条件の追加だったはずなのに、最後にはCSV、過去データ、スマホ表示、別部署の要望まで入ってくる。ここで疲れるのは、相手の態度というより、話の置き場所がないことです。
「それは不具合ですね」「それは追加ですね」「それは次フェーズで考えましょう」と分ける場所がないと、指摘は全部同じ箱に入ります。名前のない箱に入った要望は、たいてい「修正お願いします」になります。
確認者が増えるほど、責任範囲も広がって見える
納品基準がないと、確認者が増えるたびに責任範囲も広がります。担当者、上長、業務部門、運用担当、場合によっては別会社の担当者。全員が違う観点で見れば、それだけ指摘も増えます。
もちろん、関係者の確認自体は大事です。ただ、誰の確認をもって完了なのかが決まっていないと、「まだ社内で見ています」がいつまでも続きます。こちらは納品済みのつもりなのに、相手の内部確認が終わるまで終われない。これがいちばん消耗します。
公正取引委員会・中小企業庁・厚生労働省が整理しているフリーランス法の資料でも、業務委託時には給付の内容、受領期日、検査完了期日、報酬額と支払期日などを明示する考え方が示されています。個別の適用は案件によりますが、実務上も「何を渡し、いつ誰が確認し、いつ支払うのか」を曖昧にしないことはかなり重要です。
納品基準を決めるのは、相手を疑うためではありません。最後に「言った・言わない」「そこまで含むと思っていた」で関係を悪くしないために、先に戻れる線を置く。基準は冷たい線引きではなく、お互いが安心して終われるための約束 と考えた方が置きやすいです。
あの案件を、着手前に戻して考える
では、最初の管理画面改修に戻ってみます。もし着手前に、ほんの少しだけ終わり方を決めていたら、金曜夕方の会話はどう変わったでしょうか。
決めることは、そこまで多くありません。最低限この3つです。
- 何が揃ったら完了とするか
- 誰がどの観点で確認するか
- 修正と追加対応をどこで分けるか
この3つがあるだけで、納品前の会話はかなり落ち着きます📝
1. 何が揃ったら完了とするか
まずは完了条件です。ここで決めたいのは、「完璧な状態」ではなく「今回の契約として受け入れられる状態」です。
管理画面の検索条件追加なら、たとえばこう置けます。
今回の完了条件は、対象の一覧画面で指定した検索条件が使え、検索結果が画面表示に反映されることとします。CSV出力、過去データの再集計、スマホ表示の追加確認は、必要に応じて別途整理します。
この一文があると、CSVの話が出た時に「やりません」と冷たく返す必要がありません。代わりに、「今回の完了条件は一覧画面への反映までなので、CSV反映は追加対応として整理しましょう」と戻れます。
ポイントは、完了条件をふわっとした言葉にしないことです。「いい感じに整える」「一通り対応する」「問題なく動く」だと、最後に解釈が割れます。代わりに、「どの画面」「どの操作」「どの範囲」「どの確認」でOKにするかを書きます。
ここまで細かくすると面倒に見えるかもしれません。でも、実際には逆です。最初に少しだけ書いておくと、最後に「これは含んでいましたっけ？」と悩む時間が減ります。完了条件は、納品直前の交渉を減らすためのメモ です。
2. 誰が、どの観点で確認するか
次に確認者です。これは意外と抜けます。誰がOKを出すのか。担当者なのか、責任者なのか、業務部門なのか、運用担当なのか。複数人が見るなら、誰の確認が必須で、誰の意見は追加要望として扱うのか。ここを置いておきます。
管理画面の例なら、担当者は画面表示を見る。業務部門は検索条件が実務に合うかを見る。責任者はリリースしてよいかを見る。こう分かれているなら、それぞれの観点を先に軽く聞いておくと安心です。後から全員の視点が一気に出てくるより、最初に「誰が何を見るか」を並べた方がずっと進めやすいです。
ここでよくあるのが、担当者はOKと言っているのに、上長確認で止まるケースです。担当者を責めても解決しません。最初から「最終確認者は誰か」「確認に何営業日かかるか」「指摘はどの形式でもらうか」を聞いておく方が、ずっと穏やかに進められます。
IPAが公開している「情報システム・モデル取引・契約書（第二版）」でも、システムの仕様やプロジェクト管理方法、検収方法などについて、ユーザ企業とITベンダが共通理解のもとで対話を深めることへの期待が示されています。検収は最後に突然出てくる儀式ではなく、プロジェクトの進め方そのものとつながっています。
3. 修正と追加対応をどこで分けるか
最後に、修正と追加対応の線引きです。
ここがないと、納品前の指摘が全部「修正お願いします」になります。でも実際には、指摘の中身はかなり違います。こちらの不備、合意済み仕様とのズレ、発注側の新しい要望、業務判断の変更。これらを同じ箱に入れると、受ける側だけが苦しくなります。
合意した動作を満たしていないなら修正です。指定ブラウザで崩れている、保存されるべきデータが保存されない、権限チェックが抜けている。これは直すべきです。一方で、納品前に初めて出た新しい条件は追加対応に近いです。
管理画面の例で言えば、検索条件が効かないなら修正です。検索結果が保存済みデータとずれているなら修正です。でも、CSV出力にも同じ条件を追加する、過去データの集計ロジックまで変える、スマホ画面の調整も含める。これは必要な対応かもしれませんが、最初の依頼とは別の話として扱えます。
公正取引委員会等のフリーランス法資料では、フリーランスに責任がないのに費用を負担せず給付内容を変更させたり、受領後にやり直させたりする行為が禁止行為として整理されています。もちろん、すべての案件に同じように当てはまるとは限りません。ただ、実務の感覚としても「何が不備で、何が追加か」を分けておくことは、自分を守る土台になります。
実務では、強い言い方より短いメモが効く
「とはいえ、契約書を毎回細かく直すのは難しい」と感じる人も多いと思います。小さな業務委託や、既存取引先との追加依頼では、分厚い条文を毎回交わすわけではないですよね。
それでも、何も残さないよりは、メールやチャットの一文でもかなり違います。大事なのは、立派な書式ではなく、あとで戻れる文があることです。
見積りや着手前に使いやすい書き方
たとえば、着手前には次のように置けます。
今回の完了条件は、対象画面で指定フローが動作し、事前に共有した確認項目を満たすこととします。確認者は〇〇さん、確認期間は納品後5営業日以内とし、合意済み範囲にない追加要望は別途見積りとして整理します。
このまま使えるかは案件によります。ですが、完了条件、確認者、確認期間、追加要望の扱い。この4つがあるだけで、納品前の会話はかなり守りやすくなります。
もう少し柔らかくしたいなら、こうでもよいです。
納品前に認識がずれないよう、今回どこまでを完了範囲とするかだけ先に揃えておきたいです。追加のご要望が出た場合は、必要に応じて別枠で整理できればと思います。
このくらいなら、相手を疑っている感じは出にくいです。むしろ「丁寧に進めたい」というニュアンスになります。
走っている案件なら、確認リストに戻す
すでに着手している案件で、今さら契約の話を出しにくい場合は、契約条件ではなく確認リストとして戻すのが現実的です。「納品前に認識を揃えるため、完了条件を一度整理します」と前置きして、対象範囲、確認者、確認期限、追加要望の扱いを書き出します。強い交渉ではなく、進行整理として出す方が受け取られやすいです。
金曜夕方に言いにくいことほど、先に置く
最初の管理画面の例で考えると、納品後に「CSVは別です」と言うのは少し気まずいです。相手からすると、完成したものを見た上で自然に出した確認だからです。こちらからすると、最初の範囲にはなかった話です。このズレが、金曜夕方にぶつかると重くなります。
でも、着手前に「CSV出力は必要なら別途整理します」と置いてあれば、同じことを言っても受け取られ方が変わります。急に断ったのではなく、最初の確認に戻っているだけになるからです。
打ち合わせで合意したことも、そのままにしない方がいいです。あとで自分も相手も忘れます。会議後に、短く戻しておきます。
本日の確認内容です。今回の納品範囲はAとB、確認者は〇〇さん、確認期限は7月15日まで。Cについては追加要望として、必要であれば別途見積りします。
このくらいで十分です。相手から「認識違いです」と返ってくれば、早い段階で直せます。返ってこなければ、少なくとも自分の中では戻れるメモになります。
記録は、強く出るための武器ではありません。次に揉めないための地図です。ここを勘違いしない方が、相手にも出しやすくなります。
最後は、「あとで誰が困るか」で見る
納品基準をどこまで決めるべきか迷ったら、「曖昧なまま進めた時、あとで誰が困るか」で見ます。確認者が曖昧なら、自分は終われず、担当者も社内確認に追われます。追加対応の線がないままなら、自分は無償対応を抱え、相手も予算の見通しを持てません。
つまり、納品基準は自分の防御だけではありません。相手にとっても、プロジェクトを終わらせるための材料です。最初から全部を固定する必要はありませんが、途中で迷った時に戻れる場所は作っておく。これだけで、最後の会話はかなり変わります。
最初に少しだけ勇気を使う
納品基準の話は、最初に少し勇気がいります。「細かい人だと思われないかな」「関係が固くならないかな」と気になりますよね。
でも、最後に揉める方がずっと重いです。納品直前に「それは含んでいません」と言うより、着手前に「ここまでを完了範囲にしましょう」と言う方が、関係は守りやすいです。
最初に少しだけ勇気を使う。これが、最後の気まずさを減らします。怖い話を早めに小さく出すことが、あとで大きく揉めないための準備 になります。
最後に
納品前で揉めやすい案件は、最後の対応力が足りないというより、最初の基準が薄いことが多いです。だから着手前に、完了条件、確認者、追加対応の線を置いておくとかなりラクになります。
まずは最近しんどかった案件を1つ思い出して、「何が揃えば完了だったのか」を書き出してみてください。次に、「誰がOKを出すはずだったか」「どこから追加対応だったか」を並べてみる。それだけでも、次の案件で先に聞くべきことが見えてきます。
納品は、最後に根性で乗り切るものではありません。先に終わり方を決めておくと、作る側も頼む側も、少し安心して前に進めます✨
納品基準、追加対応、検収まわりの線引きが曖昧な案件は、早めに言語化すると守りやすくなります。ひとりで抱え込まず、今の案件に合わせて整理してみましょう。
