「これで確定です」が守られない。仕様変更をどう防ぐか私なりに考えてみた

そもそもなんですけど、Webって仕様変更できちゃうんですよね。

これがWebの良いところであり、悪いところだなと思うんです。

たとえば印刷で輪転機を回した後に「やっぱり色を変えてくれ」と言われたら全部刷り直しですよね。

プラスチックのプロダクトを型にはめて作っている最中に「形を変えて」と言われても無理ですと。

リアルなものづくりには、それまでに絶対確定しなきゃいけないという緊張感があるんです。

でもWebは「直せるよね」という空気がどうしてもある。

だから作り手も「わかりました、やります」と言えてしまうし、言っちゃう。

クライアントも今までの経験から「なんとかなるんじゃないかな、とりあえず言ってみよう」と思っている方はいると思うんですよね。

じゃあこれをどう防ぐか。もう最後は数字で握るしかないと私は思っています。

わかりやすく言うと、納期と金額のところですね。ここで握るしかない。

ただ、実際にことが起こってから言うと、喧嘩になります。

少なくとも綺麗な話にはならない可能性が絶対にあるんです。

なので、一番最初の要件定義が始まるタイミングで確定を取らせてもらう。

そのうえで「ここから先、仕様変更になると手戻りがすごくあります」と伝えておくんです。

ご覧になっている側は「高さを10ピクセル増やすだけ」に見えても、実際はCSSを直さなきゃいけない。

プログラムなら共通化を考えて作っているので、一つのイレギュラーで全部を確認して調整する必要が出てくるかもしれません。

大事なのは伝え方だと思っています。

「なりますよ、だから絶対わかってますよね、こちら伝えましたからね」と言ってしまうと、その時点で喧嘩腰になっちゃう。

そうではなくて「こういうふうにご理解いただけたら大丈夫ですか？」と柔らかく聞くんです。

このタイミングだったら、まだ柔らかく聞けると思うんですよ。

相手が「まだちょっともしかしたら」と言うなら、「じゃあバッファを」とか「お見積もりに少し乗せていいですか」と交渉もできます。

これが、お客さんから言われてしまってから、それまで先手を何も打っていなかったら、もうむしろ負けです。

そこから軌道修正して良好な関係のままやるのは、相手がよほどいい方じゃないと難しいと思います。

もう一つ、ディレクターの立場として考えておきたいことがあります。

仕様変更を安請け合いしてしまうと、クリエイティブのメンバーが苦労するんですよね。下手したら自分も苦労する。

「納期は変わらないけどこれを足してくれ、だからみんなで徹夜」みたいなことになる。

じゃあ徹夜をしたときに、みんなの溜飲が下がるものって何でしょうか。

残業代が出るのは最低限当たり前として、自分たちが頑張った分が会社の売り上げにもちゃんと反映されている。

それが感じられるかどうかは、すごく大事だと思うんです。

だから私は、ディレクターがクリエイティブを守れる唯一の方法は、時間とお金を取ってくることだと思っています。

仕様変更をどれくらい受けるかは、会社やスヌーピー次郎さんの矜持次第でいいと思うんです。

100対0で受けないと言えるならそれでもいい。いいものを作りたい、寄り添いたいという思いで受けるのも、全然いいと思います。

ただ、そのときに「せめて何手前から交渉しておくか」を考えておいてほしいんですよね。

今回これを経験したなら、次に活かしてほしいんです。

ただし、次のプロジェクトで「前回すっごい大変だったので、今回は仕様変更できないですからね」なんて言っちゃダメですよ。

前のことを蒸し返したら、それはそれで喧嘩になっちゃうので。

そうではなく、しれっと前回のことは忘れて「じゃあ今回の要件定義、これで大丈夫ですか？」と。

そのうえで「もし変更があったら、次はさすがに費用のお話をせざるを得ないので、そこだけはお願いしますね」と伝える。

前を引きずらずに交渉するところから、防御策を打っていけるといいんじゃないかと思っています。

まとめ

結局のところ、仕様変更そのものをゼロにするのは難しいんですよね。だからこそ、起きてから慌てるのではなく、要件定義の一番最初に柔らかく先手を打っておく。いまの私は、そこがいちばん現実的だと考えています。

• Webは直せてしまうからこそ、仕様変更の緊張感が薄れやすい
• 防ぐなら納期と金額を、要件定義の最初に柔らかく握っておく
• 言われてから軌道修正しようとすると、もう負けになりやすい
• ディレクターがクリエイティブを守れるのは、時間とお金を取ってくること