口頭での仕様変更が後でトラブルになる理由
外注の途中でクライアントから仕様変更が入った。急いで外注先に連絡して、電話やチャットで変更内容を伝えた。外注先は「了解しました」と言った。しかし納品物が届いてみると、変更が反映されていない箇所がある。「あのとき変更をお願いしたはずです」「聞いていない、記録がない」というやりとりになる。
このトラブルは、悪意から生まれるのではなく、口頭や一言のチャットで済ませた仕様変更の管理から生まれる。変更の内容・変更の理由・変更が影響する範囲・費用と期限への影響。これらを記録に残さずに進めると、後から何を合意したかが不明になる。仕様変更の管理を適切に設計することが、このトラブルを防ぐ唯一の方法だ。
仕様変更が起きやすい状況
外注の途中で仕様変更が入りやすい状況はいくつかある。クライアントから追加要件が来たとき、市場環境が変わってコンセプトを見直したとき、内部でレビューをした結果方向を修正したとき。これらは外注先の責任ではない変更だが、外注先の作業に直接影響する。
変更が入ったとき、発注者は早く外注先に伝えたいと思う。その焦りが「まず口頭で連絡して後で正式に送る」という流れを生む。しかし「後で正式に送る」が実行されないまま進んでしまうケースは多い。口頭連絡が唯一の変更記録になり、認識のずれの種になる。
コツ1：変更ログを必ず残す
仕様変更が発生したとき、変更の記録を文書化する習慣を作る。記録すべき内容は4点だ。変更日時・変更した内容・変更の理由・誰が承認したか。この4点が記録されていると、後から「いつ・何を・なぜ変えたか」が確認できる。
記録の場所はスプレッドシートでも、プロジェクト管理ツールでも、共有ドキュメントでも構わない。重要なのは外注先も参照できる場所に記録すること、そして変更のたびに必ず記録してから作業を進めるルールを守ることだ。「変更を伝えてから記録する」ではなく「記録してから変更を伝える」という手順にすることで、記録漏れを防げる。
コツ2：影響範囲を外注先と一緒に確認する
仕様変更を伝えるとき、変更が作業全体に与える影響を外注先と一緒に確認する。「A画面の仕様を変更したいのですが、B画面やC機能にも影響しますか」という確認を外注先に向けることで、変更の影響範囲を発注者側だけで把握しようとするより精度が上がる。外注先は実際の作業をしているため、影響範囲の把握が正確なことが多い。
影響範囲の確認を省くと、変更後に「実はここにも影響があって、作り直しが必要です」という報告が後から来る。発注者が「最初から教えてほしかった」と思っても、影響範囲の確認を依頼しなかった発注者側にも責任がある。変更を伝える時点で影響範囲の確認を外注先に依頼することが、後からの追加作業を防ぐ。
コツ3：追加費用・納期への影響を明示して合意してから進める
仕様変更は、費用と納期に影響することがある。変更の内容によっては、追加の作業時間が必要になり、費用の追加請求が発生する。納期が後ろ倒しになることもある。これらの影響を明確にしないまま「とにかく変更をお願いします」と進めると、後から「追加費用が発生します」という話になったときにトラブルが起きる。
変更を依頼するとき、外注先に「この変更で追加費用や納期への影響はありますか」と必ず確認する。影響がある場合は、費用と納期の両方について合意を取ってから作業を進める。合意の内容は変更ログに記録しておく。「口頭で追加費用なしと言っていた」という認識のずれを防ぐために、費用・納期への影響の合意は必ず文書で残す。
変更管理の設計を最初に伝える
外注先への最初の依頼時に、仕様変更が発生したときの手順をあらかじめ伝えておくことが効果的だ。「変更が発生した場合は、変更内容・理由・影響範囲を文書で確認してから作業を進めてください」というルールを最初に共有する。このルールがあると、外注先側も変更依頼を口頭だけで受け取ることに不安を感じるようになり、記録を求めるようになる。
外注先が「変更を口頭で受け取って進めていいか確認します」という姿勢を持てると、発注者側のリスク管理にもなる。変更管理のルールは、外注先を管理するためのものではなく、双方が安心して仕事を進めるための約束として機能する。
変更を断る判断も必要なことがある
仕様変更のすべてを受け入れなければならないわけではない。変更の影響が大きく、作業の大幅な作り直しが必要な場合や、変更によって当初の品質目標が達成できなくなる場合は、発注者側から変更の保留や代替案の提案をすることも外注管理の一部だ。
「変更を断る」というより「変更の影響を明確に伝えて判断を依頼する」という形で外注先に伝える。「この変更を行うと、現在進行中の○○の作業を3日分作り直す必要があります。それでも変更しますか」という確認を取ることで、変更を依頼した側も影響を認識した上で判断できる。こうした確認を省かずに行うことが、双方にとって合理的な意思決定につながる。
仕様変更の記録が後のトラブルを防ぐ証拠になる
変更ログが蓄積されると、プロジェクトの経緯が追えるようになる。「なぜ最初の仕様から変わったのか」「誰がいつ承認したのか」が記録として残る。これはトラブルが発生したときの証拠になるだけでなく、将来同じようなプロジェクトで同じ問題を防ぐための学習資料にもなる。
変更管理のコストは小さい。記録を残す習慣があれば、追加で必要な時間は数分だ。そのわずかな習慣が、後の大きなトラブルと大量の修正作業を防ぐ。
クライアント起因の変更と社内起因の変更を分けて管理する
仕様変更には2種類ある。クライアントからの要求による変更と、自社の判断による変更だ。この2種類を変更ログで区別して記録することが、後のトラブル防止に役立つ。
クライアント起因の変更は、クライアントからの承認が取れた日時も記録する。「クライアントの指示でこの変更を行った」という証拠が記録に残ることで、変更によって費用や納期が変わる場合のクライアントへの説明が明確になる。自社起因の変更は、内部での承認者を記録する。誰がいつこの変更を決断したかが後から確認できると、同様の変更が繰り返されたときの判断材料になる。
外注先への変更連絡は、変更の種類によって伝え方を変えることも有効だ。緊急の変更は口頭やチャットで速報してから、後で文書記録を残す。計画的な変更は最初から文書で伝える。緊急速報と文書記録のタイミングを分ける場合は、「速報を送ったら24時間以内に文書記録を送る」というルールを自分の中に設けることで、記録漏れを防げる。