こんにちは、制作部の長をやらせてもらってます、なかみーです。
前回の記事「Webディレクター必見！プロジェクトを円滑に進め、遅延を発生させないためのポイント3つ」では、プロジェクトの遅延を事前に防ぐためのポイントについて紹介させていただきましたが、それでもトラブルが発生してしまうことはよくあると思います。
トラブルが起きるとどこかに羽ばたいていきたくなりますが、誰も好きでやっているわけではないですよね。
そこで本日は、トラブル発生時にWebディレクターがとるべき3つの手順について紹介していきたいと思います。
1. 発生事象を理解する
当たり前だ！と思うかも知れませんが、火中にいると冷静でいるのはなかなか難しいことです。
トラブルの発生には、必ず何かしらの理由があります。その発生している事象をしっかりと理解することが、トラブルを鎮める第一歩になります。
つまり、まずは「何が起こっているのか」を正しく把握するようにしましょう。
僕の経験から、よくある事象3例をあげますと
- 事象1：仕様が決まる気配がない
- 事象2：デザインが決まらない
- 事象3：バグがとにかくスゴイ
となります。いずれにしても、解決の第一歩は「理解」です。まずはしっかりと向き合いましょう。
2. 発生事象の原因を考える
「何が起こっているのか」を理解したら、次は「なぜ起こってしまったのか」の原因を考えましょう。これも上述した「何が起こっているのか」に対応して原因を考えてみます。
1つの事象に対して、複数の原因が絡みあうこともありますので、冷静に振り返ってみましょう。
事象1：仕様が決まる気配がない
- 原因：作りたい機能がいっぱいある
- 原因：競合にはない機能をつけたい
- 原因：制作物の目的が忘れられている
- 原因：どんな機能をつけたらいいか分からない
事象2：デザインが決まらない
- 原因：トンマナの合意が取れてない
- 原因：求められているものではなく、作りたいものを作ってしまっている
- 原因：選ばせすぎて一周してしまった
- 原因：単純にスキル不足
事象3：バグがとにかくスゴイ
- 原因：設計書・要件定義書がない
- 原因：試験仕様書がない
- 原因：試験観点が少なすぎる
- 原因：時間がなさすぎて単体テストを無視した
- 原因：IE7に対応しなければいけない、と後でわかった
事象には必ず原因が存在しているので、まずは落ち着いて自身に問いかけたり、メンバーに聞いたりしてみましょう。
3. 原因への対策を考える
ここまでくると少し冷静さも取り戻しているかもしれません。起こってしまったことはもう仕方がないことですので。
どれだけリカバリーできるか、ここからがWebディレクターとしての腕の見せどころです。対応策をしっかりと打ち出しましょう。
事象1：仕様が決まる気配がない
原因：作りたい機能がいっぱいある
【対策】
機能の優先順位をつけましょう。実装されないと成立しないものであれば、優先度が最も高くなります。判断軸を設け、整理をしてみましょう。
原因：競合にはない機能をつけたい
【対策】
上記と同様に、優先順位をつけましょう。判断軸は「競合に対しての優位性」となるかと思います。
「その機能がなければ競合に勝てないのか」「その機能はリリース時に必須であるかどうか」「別の機能で担保できないか」などの流れで判断してみましょう。
原因：制作物の目的が忘れられている
【対策】
最初のコンセプトに立ち返りましょう。今こそ全員の意識を統一するときです。あらためて目的を理解したうえで、必要かどうかを判断するようにしましょう。
原因：どんな機能をつけたらいいか分からない
【対策】
あったらいいなと思う機能をまずは洗い出しましょう。そのうえで優先順位をつけ、不要な機能は削るようにしましょう。
事象2：デザインが決まらない
原因：トンマナの合意が取れてない
【対策】
再ヒアリングや参考サイトの提出をおこないましょう。再ヒアリングが時間的な問題で難しい場合は、参考サイトを複数提出して、イメージに近いものを選んでもらうようにしましょう。
原因：求められているものではなく、作りたいものを作ってしまっている
【対策】
求められている役割を、あらためて説明してあげましょう。役割を理解したうえでの表現であれば、受け入れてくれる人もいると思います。
エゴだけを優先していては、独りよがりになってしまうので、さじ加減も重要です。
原因：選ばせすぎて一周してしまった
【対策】
コンセプトや狙いを改めて説明してみましょう。迷ってしまったり、あれこれといじっているうちに最初に戻ってしまうというのは、よくあることです。自分たちのおススメや希望についても、伝えておくようにしましょう。
原因：単純にスキル不足
【対策】
これが一番さびしい結果ですが、そんなときもあります。すぐに代わりのデザイナーさんにお願いしましょう。何がダメだったのか、次はどうすればよいかのアフターフォローも忘れずに。
事象3：バグがとにかくスゴイ
原因：設計書・要件定義書がない
【対策】
書ける時間があれば書きましょう。でも書く暇もない！という状況もあると思います。そんなときは必要なポイントだけでも資料に残してみるようにしましょう。
原因：試験仕様書がない
【対策】
上記と同様ですが、試験手法を定めてみてはいかがでしょうか。
原因：試験観点が少なすぎる
【対策】
試験観点に優先順位をつけるのもおススメです。まずは正常系、次にセキュリティ、異常系、負荷、性能とリリースに必要な順でいきましょう。
しかし優先順位以前の問題であれば、制作物の特徴を見極め、必要そうなものを列挙していきましょう。
原因：時間がなさすぎて単体テストを無視した
【対策】
テストコードを書いてみるのもいいと思います。
原因：IE7に対応しなければいけない、と後でわかった
【対策】
プログレッシブ・エンハンスメントで交渉するのも1つの手段だと思います。「情報の欠損はないが、演出の差は生じる」など詳細を説明してみましょう。
まとめ
いかがでしたでしょうか。まとめると、とても簡単です。
- 状況を理解する
- 根本原因を究明する
- 解消するための手段を列挙する
トラブルは誰にとっても避けたい事態です。
しかし、既に起こってしまったことと向き合い、いかに素早く的確にリカバリーできるかで、逆転することだって可能になります。
トラブルのときこそ落ち着いて、1つずつ焦らずに解決していきましょう！
それでは、また。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
