FIRST THINGS FIRST
この記事のポイント
作業開始前の範囲を文章に残し、変更時には内容・追加費用・日程への影響を確認します。承認前に作業を進めない運用を決めておくと、請求時の行き違いを減らせます。
01追加になりやすい変更を知っておく
ページ数の増加、新しい機能、撮影や文章作成の追加などは、分かりやすい変更です。見落としやすいのは、構成確定後の大きな順序変更や、デザイン確定後の方向転換です。前の工程へ戻って作り直す必要があるかを確認します。
| 変更例 | 確認する影響 |
|---|---|
| 原稿量が大幅に増えた | レイアウト調整、ページ分割、確認範囲 |
| 予約機能を追加した | サービス選定、設定、テスト、利用料 |
| 写真を撮り直したい | 撮影手配、交通費、差し替え工程 |
| 承認済みのデザインを変更 | 再設計、実装済み箇所の修正、納期 |
| 別言語ページを追加 | 翻訳、校正、ページ制作、更新方法 |
02不具合修正と仕様変更を分ける
合意した仕様どおりに動かない状態の修正と、新しい要望を実現する変更では扱いが異なります。たとえば送信できるはずのフォームが動かない場合と、フォームに新しい分岐機能を追加する場合は別の相談です。
境界があいまいな場合は、最初の仕様書や確認用のデザインへ戻ります。合意した基準がないと、どちらにとっても判断が難しくなります。対象ブラウザ、必須機能、納品時の確認項目を先に記載しておくと話し合いやすくなります。
03変更依頼をまとめ、費用確認後に進める
思いついた修正を担当者ごとに別々のチャットで送ると、重複や矛盾が生じます。社内窓口へ集約し、必須の修正と追加の希望を分けて一覧にします。ページ、場所、変更理由、希望内容をそろえると、見積もりの確認も短くなります。
追加作業については、費用と日程への影響を確認し、社内で承認してから進めます。「とりあえず直しておいて」と伝えた後で金額の認識が食い違わないよう、承認方法も決めましょう。小さな変更でも、判断の記録を残すことが役立ちます。
記入例・想定例
変更:サービス紹介に事例を二件追加。理由:商談時に実例を見せたい。希望:今回の公開に含めたい。作業前に追加金額と公開日への影響を確認したい。
04確定する順番を守って手戻りを減らす
目的、ページ構成、原稿、デザイン、実装の順に確認すると、大きな変更を早い段階で発見しやすくなります。社内決裁者が完成直前に初めて見る運用は、方向転換が大きくなる原因の一つです。重要な承認段階に参加してもらいましょう。
ただし事業の事情で変更が必要になることもあります。すべてを当初の見積もりへ押し込むより、公開範囲を分ける、追加公開に回す、機能を代替するといった選択肢を相談すると、費用と日程を調整しやすくなります。
依頼・見直し前のチェックリスト
- 追加費用が生じる条件を確認した
- 不具合と仕様変更の判断基準を残した
- 社内の修正依頼を一つにまとめる窓口を決めた
- 追加作業は費用と日程の承認後に進める
よくある質問
誤字の修正にも追加費用がかかりますか?
原因、修正時期、契約範囲によります。制作側の転記ミスと、支給原稿の公開後変更では扱いが異なる場合があるため、修正対応の期間と範囲を確認しましょう。
追加費用が出たら公開を延期するしかありませんか?
今回の公開に必須かどうかを分け、追加部分を次段階へ回せる場合があります。費用だけでなく日程や公開範囲の選択肢も相談してください。