「あれ、これって仕様変更じゃないですか？」
エンジニアからそう指摘された瞬間、胃がキュッと縮む感覚を、私は何度も味わってきました。15年以上この仕事をしていますが、軽微なものも含めれば、仕様変更が一度も起きなかった案件のほうが珍しいというのが正直な実感です。
だからこそ最初に伝えておきたいことがあります。仕様変更は、あなたの実力不足で起きているわけではありません。 「起きないようにする」ことも大事ですが、それ以上に「起きたときにどう動くか」を身につけておけば、必要以上に恐れる必要はありません。この記事では、仕様変更が発生した瞬間にディレクターが取るべき初動と、被害を最小限にとどめる考え方を、現場での経験をもとに整理します。
仕様変更が起きるのは、あなたのせいとは限らない
「仕様変更」と「仕様漏れ」は違うものと考える
エンジニアから「それは仕様変更ですね」と言われたとき、まず自分の中で切り分けてほしいことがあります。それが本当の意味での「仕様変更」なのか、それとも「仕様漏れ」(決めるべきだったことを決め忘れていた)なのかという点です。
- 仕様変更：一度合意した内容を、後から変える
- 仕様漏れ：そもそも合意すべきだったのに、決めていなかった
この2つは原因も対応も違います。仕様漏れであれば「次から気をつける」で済む話ですが、仕様変更であれば、それは合意の更新が必要な出来事です。ここを混同したまま「すみません、こちらのミスです」と全部自分の責任にしてしまうディレクターを、私は何人も見てきました。原因を正しく切り分けることが、対応の第一歩です。
クライアント発・現場発、2種類の仕様変更
仕様変更には、大きく2つの発生源があります。
| 発生源 | 例 | 特徴 |
|---|---|---|
| クライアント発 | 「やっぱりこの機能も欲しい」「ここのデザイン変えたい」 | 事業判断や気づきによって、途中で要望が変わる |
| 現場発 | 「この仕様だと技術的に難しい」「工数が想定より膨らむ」 | 実装を進める中で、当初の想定が崩れる |
どちらから来た変更であっても、対応のプロセスは共通しています。次の章で、その初動を具体的に見ていきます。
仕様変更が起きた瞬間にすべき3つの初動
仕様変更に気づいたら、私は必ずこの順番で動きます。
まず「止める」：影響範囲を確認するまで着手させない
一番やってはいけないのは、変更依頼を受けたその場で「じゃあお願いします」とデザイナーやエンジニアに丸投げしてしまうことです。私も駆け出しの頃、クライアントの熱量に押されてその場で着手を許可し、後から「そこまで変えると他のページも直さないといけない」と判明して大炎上させたことがあります。
変更依頼を受けたら、まずは「一旦持ち帰ります」と伝えて着手を止める。これが最初の一手です。
「聞く」：変更の背景・優先度をクライアントに確認する
次にやるのは、変更の「背景」を聞くことです。「なぜ今この変更が必要なのか」「本当に今回のリリースに含める必要があるのか」を確認します。
現場では、クライアントの「ついでに」という一言が一番危険です。ここで背景を聞かずに引き受けてしまうと、後から「そこまでこだわっていたわけではなかった」と判明し、無駄な工数だけが残るケースもあります。
「伝える」：スケジュール・費用への影響を先に共有する
背景を確認したら、影響範囲(スケジュール・費用・関係者)を制作チームに確認したうえで、クライアントに先に共有します。ここで大事なのは、対応可否を答える前に、影響を先に伝えることです。「できます」と先に言ってしまうと、後から「やっぱり厳しいです」とは言い出しにくくなります。
現場でよくある仕様変更対応の失敗パターン
その場のノリで「できます」と即答してしまう
クライアントの前で頼られている実感があると、つい安請け合いしたくなる気持ちはよく分かります。ですが、その場で即答してしまうと、社内に持ち帰った瞬間に「厳しいです」と言われ、板挟みになるのは自分自身です。「持ち帰って確認します」は、逃げの一言ではなく、プロとしての誠実な対応だと私は考えています。
変更内容を口頭だけで済ませてしまう
打ち合わせの勢いで「じゃあそれで進めましょう」と口頭合意だけで終わらせると、後から「言った・言わない」のトラブルにつながります。私は必ず、打ち合わせ後に変更内容を簡単な議事録やチャットのメッセージとして残し、双方が同じ認識であることを確認するようにしています。この一手間を惜しんで痛い目に遭った案件は、一度や二度ではありません。
仕様変更を最小限に抑えるために、事前にできること
ここまでは「起きた後」の対応を中心に紹介してきましたが、仕様変更そのものの発生頻度を下げる工夫も、もちろん有効です。
そもそも仕様変更が起きる根本原因の多くは、要件定義の段階で「何を・どこまで作るか」の合意が曖昧なまま進めてしまうことにあります。要件定義の具体的な進め方や、決めておくべき項目については、以前の記事「Webディレクターの要件定義とは？」で詳しく解説していますので、あわせて参考にしてください。
また、修正・変更が発生した場合の対応フロー(誰が確認し、誰が承認するか)をあらかじめ決めておくことも、変更対応をスムーズにする助けになります。
まとめ：仕様変更は敵ではなく、想定内の出来事として扱う
仕様変更は、なくすことを目指すものではなく、起きること前提で備えておくものです。「止める」「聞く」「伝える」の3つの初動を押さえておくだけで、板挟みになる場面はぐっと減らせます。
事前の備えとしての要件定義と、発生後の初動対応。この両輪を持っておくことが、仕様変更に振り回されないディレクターへの近道だと、私は現場での経験から感じています。
ディレ和尚のひとこと
変わらぬものを求めるより、変わるを受け止める構えを持て。
