なぜデスマ案件が起きるのか、スケジュールは最初余裕があったはずなのに・・・それでもデスマが発生して最終的に実装する開発者にすべてしわ寄せがいきます。そこでwebディレクターとして開発者を守る方法をご紹介
デスマが発生する理由は企画への詰めが甘い
企画からリリースまでのスケジュールで最初にあるのが企画フェーズそして最後が開発リリースのフェーズ。この流れで一番スケジュールを食いつぶすのが企画の部分です。
規模が大きくなればなるほど、偉い人が参加して承認フローの階層が増えていく。開発するためには企画と仕様が固まらないと勧められません。しかし、人数が多いため好き勝手なことをいう企画者たち。技術的に出来ないことまでも出来るでしょと簡単に言ってくれる始末。
そのため、企画がスケジュールをどんどん食いつぶしていきます。思いつきでどんどん企画の内容が変わっていく、企画の内容が変われば仕様が変わるし、実装方法が変わる。そんな感じで、企画が決まらないと進まないんですよね。
企画は全体スケジュールの最初なので、そこまでスケジュールにシビアじゃない。企画とデザイン開発に挟まれる。webディレクターは本当にやべぇ～こいつはやべぇ～って思うのです。そこでまずwebディレクターがやること
企画に対して締め切りを切り守らないとリリース日は無理と伝える
これは絶対にやらないとだめ、企画を甘やかせるのだめ。企画をもらったらダメ出しをさっさとして、スケジュールをきっちり守らせること。それが明日だったら夜中だろうが明日の朝までに必ず調整してください。そうじゃないとリリースできません。と突っぱねる事が大事。
そのためには当然全体スケジュールを関係者全員に周知しておく必要があるし、守らせる必要がある。当然すべてメールという証拠を関係者全員に送っておくこと。責任箇所を明確にして自分と開発を守ることにつながる。
まあ企画もやっていたので企画側の気持ちもよくわかるので企画側の気持ちもそのうち書く。
企画が走り始めたら勝手に仕様書を作り始める
自分の場合はUIとフロント設計の仕様書を書いていました。これは企画書が１枚のパワポでも想像でかける。出戻り覚悟で作っておく。これをやるためには企画に対して、目的とゴールとKPIを何度も確認する。これが超大事。目的とゴールさえあれば、その道筋を作るだけなので、企画が求めるものを想像して作ることが出来る。企画に実装したい内容をつめるには別の方法もあるのでそれはまた別の機会に。
今までの経験上、目的とゴールとKPIがしっかり企画書に書いてあって、全員で認識していればほとんど出戻りは起きない。
勝手に仕様書を作る意味はもうひとつある。企画がふわっとしているイメージを、さっさとwebディレクターと開発側で握ってしまうことで企画を固めるのを早められる。開発には実装イメージを掴んでもらい事前にやばい場所を洗い出してもらえるのです。
webディレクターが仕様書で気をつける場所はエラー
通常のユーザー遷移は簡単に仕様書はかける。動線設計は基本的に複雑にしないことだし、いかに使いやすいかを求めていけばシンプルな設計になっていく。これはだれでも出来る。
開発者がデスマに巻き込まれるケースはエラーのルールが確定されてない時
開発者は実装するときにエラーページや予期しない動作までも処理に入れておかなければいけない。なにもしない時はどう処理すればいいのか。まで考えて実装するので、仕様書を書くときは全てあるパターンと全て無いパターンを作り、そしてありえない動作のエラーを想定して作るのである。
例えば実装後に起きそうな問題
- 検索に何もいれないで検索ボタンを押したら
- 会員登録中に地下鉄で通信が遮断されたら
- ボタンを連続で押したら
- アクセスが集中した時の対応
- リアルタイムで同期するかしないか
こういうことを仕様書にしっかり書いておくことでありえないエラーで開発との無駄なやりとりを減らして、開発には集中して作業できるようにしてもらう。
事前に起こりそうなエラーを潰しておけば致命的なエラーは起きない。今まで、でかい案件ばっかりをやってきたけど、自分のチームは大きなバグもなく、リリース日は特に怖いことはなかったし、切り戻したりしたことはなかった。いやマジで開発陣が超優秀で助けられた。
開発陣は締め切りを死守してくれる
何が何でも締め切りを守ろうとしてくれる。そのために、出来る事や出来ないこと、どこまでならできるかを端的に話してくれる。そのため冷たいイメージを持つ人もいるけれど本当はいい人ばかりなのです。寡黙な人も多いけれどね。そんなわけでいろんなしわ寄せが最後に来る開発陣に負担をかけないようにすることはwebディレクターの大事なお仕事でもあります。
こんな記事も書いてます