Web制作を進めていると、最初には見えていなかった要望が必ず出てきます。原稿を入れて初めて必要だと分かるページ、デザインを見て気づく導線、公開後の運用を考えて追加したくなる機能。要望が増えること自体は、失敗ではありません。
難しいのは、「できます」と答えた瞬間に、その変更がデザイン、実装、CMS、確認、公開日へどうつながるかが見えなくなることです。小さく見える修正でも、共通部品や複数ページへ広がれば、工程全体へ影響します。反対に、大きく見える要望でも、目的を聞き直すと既存機能や原稿の調整で実現できる場合があります。
私たちの反省会でも、修正回数の認識、想定外だったページや画像制作、途中から必要になったブランディング工程、担当交代後の残作業などが繰り返し話題になりました。そこで、要望を断るためではなく、実現方法を一緒に選べるように、目的と影響を先に整理します。
追加要望は、一つの作業では終わらない
例えば「フォームを一つ追加したい」という要望には、画面を作る以外にも確認することがあります。
- 誰が、何のために利用するフォームか
- 入力項目と必須条件
- 管理者通知と自動返信の内容
- 送信データを保存するか
- 個人情報の扱いと同意文
- 既存ページからの導線
- テスト環境と本番環境での送信確認
- 公開後に誰が受付を担当するか
画面上の一要素でも、業務や公開後の運用までつなぐと作業は複数の工程に分かれます。逆に、このつながりが分かれば、今回必要な範囲と後から整える範囲を選べます。
最初に聞くのは「何を足すか」ではなく「なぜ今必要か」
追加要望を受けたとき、すぐに工数を答えられないことがあります。制作側が渋っているのではなく、目的によって適切な方法が変わるためです。
「別ページを作りたい」という要望でも、検索流入を増やしたいのか、営業時に説明しやすくしたいのか、既存ページが読みにくいのかで答えは違います。新しいページが必要な場合もあれば、既存ページの見出しや導線を直す方が目的へ近い場合もあります。
私たちは、まず次を確認します。
- その要望で、誰のどんな困りごとを解消したいか
- なぜ着手前ではなく、今必要だと分かったか
- 公開日に必要か、公開後でも役割を果たせるか
- 現在決まっている内容の何が変わるか
- 代わりに減らせる作業や、既存機能で代替できる方法があるか
修正・追加・保留を、言葉だけで決めない
「修正だから元の範囲」「追加だから別費用」と、呼び方だけで線を引くと話が噛み合いません。同じ文言変更でも、見出し一つの差し替えと、全ページの情報設計を変える変更では影響が違います。
判断するときは、現在の合意と工程への影響を見ます。
現在の目的と合意範囲の中で調整できるもの
表現の精度を上げる変更や、確認時に見つかった不具合などです。ただし、共通部へ広がる場合や再確認が必要な場合は、その影響も共有します。
新しい成果物や前提が増えるもの
ページ、機能、撮影、イラスト、外部連携、更新業務など、当初なかった成果物や工程が増える変更です。実施可否だけでなく、必要な素材、担当者、確認回数、費用、日程を組み直します。
目的は妥当でも、今は条件が揃っていないもの
原稿、権限、承認者、仕様、公開環境などが未確定で、安全に着手できない変更です。却下ではなく、何が揃えば再検討できるかを残して保留にします。
制作チーム内で、影響を一度つなげる
変更を受けた担当者だけで判断すると、後工程で初めて問題が分かることがあります。デザイン上は小さな変更でも、実装方法やCMS入力、表示速度、公開手順へ影響するかもしれません。
必要に応じて、ディレクション、デザイン、実装、システム、運用の視点をつなぎます。
- 関連するページと共通部品
- 原稿、画像、翻訳などの追加素材
- CMSやデータ構造の変更
- スマートフォン表示と操作
- フォーム、通知、外部サービスへの影響
- 既に確認済みの範囲を再確認する必要
- テストと公開作業の追加
- 公開後の更新担当と保守
この確認をした上で、「そのまま実施する」「方法を変える」「公開後へ送る」「今回は行わない」を提案します。
空いている時間へ追加作業を隠さない
制作記録を振り返ると、追加対応をチームの隙間時間で吸収できた案件もありました。ただ、うまく収まった結果だけを標準にすると、次の案件では担当者の余力へ依存します。
追加作業が入るときは、元の作業が消えるわけではありません。何を後ろへ動かすか、誰の確認が増えるか、公開日を守るために何を分けるかを明らかにします。費用の話も、作業を断るためではなく、必要な人と時間を確保して品質を守るために行います。
公開日が動かせないなら、段階を分ける
すべてを公開日までに入れようとすると、確認不足のまま実装したり、既に確定した箇所へ急な変更を重ねたりしやすくなります。目的を損なわない範囲で、公開時に必要なものと公開後に追加するものを分ける方法があります。
段階を分ける場合は、単に「後回し」とせず、次を決めます。
- 今回公開する範囲
- 公開後へ送る要望
- 暫定表示や代替手段の有無
- 次に判断する時期と担当者
- 将来の追加を妨げない実装条件
公開を区切ることと、要望を忘れることは別です。次の判断条件まで残して初めて、段階公開として機能します。
要望への返答で共有すること
追加要望への返答は、「できます」「難しいです」だけにしません。少なくとも、次の内容を共有します。
- 私たちが理解した目的
- 実現方法と代替案
- 影響するページ・機能・工程
- 追加で必要な素材と確認者
- 費用とスケジュールへの影響
- 公開前に行うか、公開後に行うか
- いつまでに誰が判断するか
この形なら、依頼側も制作側も「何に対して決めるのか」が分かります。判断が保留になっても、再開するときに同じ説明からやり直さずに済みます。
制作中の変更チェックリスト
- 要望の背景と目的を確認したか
- 現在の合意範囲の何が変わるか分かるか
- 関連ページ、共通部、CMS、外部連携への影響を確認したか
- 追加素材と確認者が明確か
- デザインから公開までの追加工程を数えたか
- 費用と日程への影響を共有したか
- 公開前に必要か、公開後でもよいか判断したか
- 代替案や減らせる作業を検討したか
- 保留する場合、再検討の条件を残したか
- 決定内容と理由を制作チームへ共有したか
すぐに見積り直しが必要とは限らない
誤字の修正や、確認過程で見つかった明らかな不具合まで、すべてを大きな変更管理へ載せる必要はありません。影響が限定され、現在の目的と合意範囲の中で対応できるものは、通常の確認工程で進められます。
一方で、ページ数、機能、素材制作、承認経路、公開条件のどれかが変わるときは、一度立ち止まる価値があります。要望を小さく見せて押し込むより、影響を見える形にした方が、結果として実現までの道筋は短くなります。
