検証外注だよ！ディレクターくん

Webディレクター生活も、2年目に突入しました。
1年目は(当社比)挑戦の日々でいろんな学びがあり、さらに2年目は加速してどんどん戦闘力を挙げて行きたいところです。

久々のnoteになりましたが、今回はその中で得た学びを言語化したく、リリース前の検証業務について書いていきます。

起こったこと

実は、先日進めていた案件の検証段階で、ちょっと失敗をしました。

とあるWebサイトの制作を結構タイトなスケジューリングで進めており、検証業務を専門のベンダーさんにお願いすることになりました。
見積→仕様伝達→検証シート確認→検証当日と、いろいろバタバタしている中で事件は起こりました。

検証の日を終えて、予定していた6割程度しか着手出来ずに納品となってしまいました。

とっても胃が痛くなりました……。とりあえず起こったことはしょうがないため、自分の工数をフルに使って一度検証業務をガツっと巻き取り、なんとか本番リリースまでこぎつけました。努力と根性って時には大事ですね(白目

そして納品後、上司や検証会社を含めていろいろ話し合い、いろんなことが分かってきました。

公式

原因は一言でいうと、見積想定と実態の乖離でした。
検証の見積は、おおまかに以下の公式で表されます。

検証項目(ページ)数×端末数×想定不具合率

検証項目と端末数については当然として、想定不具合率が今回の乖離ポイントでした。これが検証の見積(想定工数)に大きく作用しています。

検証業務をする中では、当然ですが不具合が無いとスピーディーに完了します。逆に、不具合(もしくは不具合/仕様が曖昧ところ)があると作業が毎回止まり、起票/仕様確認/相談で工数が膨れ上がっていきます。

検証の見積には、書類に書いてなくとも裏でこの想定不具合率が設定されており、それに応じて工数と体制が調整されます。
※もちろん会社によって例外あると思います

そのため、想定不具合率が実情よりも低く見積もられていると、本来必要だった体制や期間がそもそも準備されない(つまり最初から詰んでる)事態になります。

乖離が起きたのは、検証会社の側で「過去にぼくらが出した不具合実績」をベースに率を試算していたことで「これくらいの不具合率で簡易に終わるだろう」と信用してくれたことが裏目にでたことも要因としてありました。

今後気をつけるべきこと

分解すると色々ありますが、ポイントは「どうやって無駄なく検証業務を終えてもらうか」で、そのために以下5点の備えをしていくことが重要だと考えています。

・そもそも、内部検証を事前にしっかり完了させよう
・見積時に、想定不具合率をすり合わせよう
・細かい仕様も事前に伝達しよう
・検証当日は、即座に連絡が取れるようにしよう
・予想外を考慮して、中間共有をしよう

そもそも、内部検証を事前にしっかり完了させよう
正直、ここが完璧であれば何も問題は無かった……が、「余裕をもってスケジューリングしよう」って解像度の低い施策は何も対策していないのと同じなので、スケジュールがパツパツでもいかに事故を防ぐかの観点で考えていくことが大事だと思います。

見積時に、想定不具合率をすり合わせよう
今回のように、本来必要な見積/体制で無かったケースもあるし、十分すぎるリッチな体制で見積が組まれているケースも想定出来ます。お互いにどれくらい大変そうな検証かを認識合わせることは、どの場合でも徹底すべきですね。

細かい仕様も事前に伝達しよう
検証側は仕様の経緯までは把握しきれません。「あれ、これって仕様っぽいけど検証シート上は不具合だなあ」ということも発生します。そこで作業者が上司にエスカレーション→上司からディレクターへ連絡となると、それだけで結構な工数になります。グレーなものの対処も考えると、打合せで詳しく仕様伝達しておかない理由はないですね。
雰囲気大丈夫そうでも、ドキュメントだけで仕様伝達はダメゼッタイ(超絶自戒

検証当日は、即座に連絡が取れるようにしよう
綿密に仕様伝達しても、それでもグレーな不具合はあるものです。検証シートに無いが実は重要だった例外ケースなど、やってみて初めて分かる気づきにも対処していくべきです。そんな時、ディレクターが1日打合せ漬けになっていたりすると、現場が停滞しっぱなしになります。
オンラインMTGをいつでも取れるように他の予定を調整するか、打合せのスキマ時間でも返信しやすいよう検証チームとチャットツールを繋ぐなど工夫は出来そうです。

予想外を考慮して、中間共有をしよう
もしもの予想外が発生したときのために、中間共有は必ず設けるべきです。また、メールでなく電話やオンラインMTGが望ましいでしょう。メールやチャットではレスポンスに時間がかかることもあるため、不測の事態に混乱している現場を放置してしまうリスクがあります。コスト面から検証を1日でやりきることも多いため、そのためには相談へのレスポンスの速さはとても重要です。

おわりに：今となっての反省

そんなことがありつつ、先日他人が制作/ディレクションした別の案件(それもいろんな経緯があり突貫で作ったもの)の検証をお手伝いをすることがありました。

他者への乱暴な検証依頼、ダメゼッタイ

何にでも言えることですが、自分が手を動かした経験は何にも代えがたいですね。そもそも不具合が多いこと、仕様か不具合か曖昧な現象への対処、リファレンスの不備などがどれだけ検証担当の工数と精神を圧迫するかを身をもって学びました……。

ぼくも気をつけます。皆さんも気をつけましょう。