常に先手を意識する、Webディレクターとしてのリスクマネジメント術
仕事に限らず、物事を実行するうえで計画性ってのは絶対的に重要なわけです。
とはいえ、すべてが計画通り完璧に終わるプロジェクトなんてのは現実には少ない。だから、プロジェクトをリードするディレクターに求められる能力のひとつに、先手を打って今後発生しそうなトラブルを事前に回避するための「リスクマネジメント力」があります。
当然、経験値の高い人ほどいろんなトラブルを経験してきているはず。僕だって、失敗は山ほど……。よくも悪くも失敗から学んで、人は成長していくものなのです。
なぜか最近、いろんな人からトラブルの相談を持ちかけられることが多いです。
「みんな大変だ。苦労してるなぁ」と思いつつ、でも、それって実はちょっとした「気づき」で回避できたことなんじゃないの？ と思うことも少なくない。
忙しいときはついつい単純なミスを起こしがち。やっぱり人間が関わる以上ヒューマンエラーはなくならない。かく言う僕も結構いい加減なところがあるのを自覚していて、いい意味で自分をまったく信用していません。
ミスを起こしてしまうこと、トラブルが起きることを前提にワークフローを組んでおくことはとても重要。将来、発生しうるリスクはなるべく先回りして潰しておきましょう。
すべての基本は前倒しから
スピードは大事だけれど、ある程度バッファを確保したスケジュールを組むのが基本
子どもの頃、夏休みの最終日に宿題をやりはじめていたような人はディレクターをやっちゃいけない人種だと思うのです。究極的に言えば、そういうこと。
作業にかかる工数がどれぐらいかということと関係なく、スタートが切れる状態ならばそれをいつやるべきかについては、基本は常に「今でしょ？」なハズ。暇を持て余すぐらいだったら「やっちゃえば？」と。
特に手の遅い人ほどそういう意識を持たないとダメ。
自分の仕事が速いのか遅いのかはなかなか客観視できないけど、周囲からとてつもなくスピードを評価されてるっていう実感を自分自身で持てない限り、自分の仕事は決して速くないと思ったほうがよいと思います。僕だってそう。
だから、ココロに余裕を持つために何事もできる限り前倒しの意識を持つ。実際、デザインしたり文章を書いたりっていう仕事は、作り終えて1日経って冷静な目で見てみたときに「なんか違うな、コレ」となることがとても多い。
スケジュールに余裕がない仕事のやり方をしてる人は、推敲ができないからアウトプットのクオリティが安定しないリスクを抱えてる。もちろん、推敲には必ず時間がかかるということでもないから、一定水準のクオリティで物事が仕上がっていたら、それはそれでOK。期日まで寝てればいいだけです。
あとは単純に、病気や怪我、PCの故障など、万一の予期せぬ事態に備える意味でも仕事を前倒しておくべき、というのは改めて言うまでもないですよね。スピード感は大事だけど、常にギリギリでスケジュールを組んでしまうと、何かトラブルが起きたときに一気にすべてが破綻します。
常に作業に追われてアタフタしてる人は、そもそもスケジュールの組み立てに問題がないか考え直してみるのも手だと思います。
前倒しが基本と言っておきながら矛盾するけど、前倒しにもリスクはあります。
見切り発車はよくない。後々、状況が変わる可能性のあるものはできる限り、固めるべきところを固めてスタートすべきです。
僕もいまだに見切り発車して失敗、ということはときどきあります。そのへんのバランス感覚はやはり経験を積まないと、なところですね。
インフラまわりは最初にしっかり固めておくこと
「テストサーバーでは動いてたのになぁ……」というのは結構ありがち。できる限り本番と差異のないテスト環境を用意することが重要
静的なHTMLをコツコツ作る仕事は少なくなってきています。
動的なWebを構築するためにはクライアントサイドの技術だけでは完結しません。サーバーサイドの技術を使う以上、サーバーまわりの仕様を制作前にしっかり固めておくことがとても重要です。
我々でサーバーを自由に選定できればたいした問題ではないけれど、技術的に制約のある既存のサーバーで何とかしなければならないケースだってありえます。インフラまわりを誰が用意し、どんなサーバーを使えるのかは事前に確認する必要があります。
あとはドメインを新規に取得したり、サーバーを移転したり、SSL証明書を取得してインストールしたりといったことも、数日間かかる（少なくとも数分では終わらない）作業であるということをあらかじめ考えておかないと、後々大変なことになるので要注意です。
インフラは一番最初に固めましょう。
デザインやコーディングのレギュレーションを確認
デザインを作り終わった後に、「レギュレーションに沿ってないから作り直し」なんてことにならないように
インフラまわりを固めて技術仕様が決まり、デザインを作る前に確認しておくべきはレギュレーションの有無です。
コーポレートロゴやブランドロゴの取り扱いはもちろん、Webサイトのデザイン・レイアウトに何かしらのレギュレーションを設けている企業も多いです。ユニバーサルデザイン（アクセシビリティ）にどこまで配慮する必要があるのかというのも要確認ですね。
クライアントや制作するサイトの内容によって、どこまで厳密にレギュレーションを適用するのかは相談の余地があると思いますが、少なくとも事前にそうしたレギュレーションの有無については確認しておくべきでしょう。
デザインやレイアウトだけでなく、コーディングについてもレギュレーションがないかどうかは事前に要確認です。
仮にレギュレーションがなくてこちらでお任せという場合にも、コーディング前にHTMLのバージョンを何にするかはクライアントとコンセンサスを取っておくとよいと思います。
コーディングでもっとも問題になるのは対象ブラウザ。これは制作する側からするとコーディング前に絶対必要な情報なので、対象ブラウザが何なのかはクライアントとの間で事前にしっかり取り決めをしておきましょう（というか、見積もり時に提示しておくべき）。
IE6対応は少なくなりつつありますが、クライアントの社内PCがIE6の場合には対応せざるをえません。IE6対応の必要がコーディング後に発覚した場合はマークアッパーに怒られること必至。事前にきちんと確認しましょう。
また、ディレクトリ構造やファイルの命名則などに関するレギュレーションの有無も、事前に確認しておいたほうがコーディングはスムーズに進むでしょう。
ワイヤーフレームの役割を考える
ワイヤーフレームはあくまでも中間成果物。プロセスは確かに重要だが、ユーザーにとっては最終的なアウトプットがすべて
案件によってはビジュアルデザインよりもUIデザインが重視されるケースが増えてきました。
最近そこかしこで言われているように、旧来のワイヤーフレーム → デザインカンプ → コーディングというワークフローではうまく回らないプロジェクトが今後増えてきそうです。
UIをしっかり考えて、実際に動きが確認できるモックアップを作りながら、ビジュアルデザインを詰めていく。
先日、自社のプロジェクトとして僕たちが制作したCGPWEBについても、まず最初に考えたのはUIでした。それは、UIデザインがこのサイトの根幹を成すPRポイントと位置づけたからです。
データ分析から導くWebデザイン／エンジニアリング – CGPWEB ［株式会社シータス＆ゼネラルプレス］
ただのページではなく、アプリケーションとしての見せ方・機能を求められるWeb構築も、まずはワイヤーのような設計資料を起こしてから制作スタートで問題ないとは思います。
しかし、ワイヤーやデザインカンプのような静止画ではなかなか動きを想像することができない。仮に想像できたとしても、技術的に想定通りの振る舞いが実現できる保証はないかもしれない。
そうなると、ワイヤーやデザインカンプにいくら時間をかけて見た目を詰めても仕方ありません。できるだけ早い段階のうちにブラウザで直接確認できるモックアップを作って、実際にUIをテストしてみたほうがよいでしょう。
そういうフローを組まないと、いざ実装段階になって「やっぱりできませんでした」となるリスクが付きまといます。
もちろん、従来通りのワークフローでじゅうぶんうまくいくプロジェクトのほうがまだまだ多いです。あくまでもUIを重視する場合ですが、リスクヘッジとして旧来のワークフローは見直したほうがよさそうです。
運用や更新作業をどうするか
Webサイトは作った後の運用こそ重要。作る前から運用体制のことはしっかり考えておきたい
Webの場合は、ローンチ後にサイトを誰がどういうかたちで運用していくのかというのが実はかなり重要になってきます。
更新をこちらで引き受ける場合にはどのぐらいのコスト・期間で何をやれるのか、クライアントに運用を引き渡す場合には引き継ぎのために何をしてあげるのかを事前にはっきり提示しておきましょう。
仮に運用をクライアントに引き渡したとしても、少なくともローンチから数日間はサイトをちょくちょく覗いてみて不具合がないか軽くチェックしたり、ウェブマスターツールまたはGoogle Analyticsのデータを見て検索エンジンのクロールエラーなどがないかを見ておくとよいと思います。
サイトがきちんと走り出したかどうかは見届けないと。
しかし、運用に関する費用を貰えていないのにクライアントのサポートセンターみたいになってしまうのが、制作者として一番やってはならないパターン。
杓子定規にクライアントからのヘルプを拒否するのは難しいですが、曖昧であったり、下手に丁寧すぎる対応はモンスタークライアントを生み出しかねない。このへんは対価をきちんと貰えるようにうまく立ち回らないと、というところです。
そして、大企業のWebサイトには複数の制作会社が絡んでいるケースがほとんど。
運用・更新に複数の制作会社が絡んでくると事態はとても複雑になるので、最新データの所在であったり、CMSにログインする時間帯であったりを関係各位に常に情報共有しなければなりません。
バージョン管理システムなんかを上手に活用できればいいけれど、複数の制作会社が絡んでくるとなかなかそうもいかないケースもある。
大切なのは、ちょっとした更新作業と思われるものも実は意外と気を遣うし面倒なのだ（すべての作業がそういうわけでもないけれど）、というのをクライアントにきちんと説明し理解してもらうこと。そして、それに対する対価をしっかり請求することだと思います。
そこはやはりお仕事ですので。
何事も決して安請け合いはしないこと。正当な対価をもらえないのであれば、基本はやらない、少なくとも自分は関わらない。わざわざリスクを自分で招き入れるような行為をする必要はないというのが、ディレクターとしての僕のスタンス。
自らがコントロールできないプラットフォームに依存するリスク
無料のプラットフォームは確かに便利だが、リスクでもあると認識はしておきたい。たとえばGoogleのAPIだって、いつ仕様を改変するかわからない
FacebookやTwitterによる情報発信が思わぬ炎上を引き起こしてしまうリスクはもちろんあります。
しかし、それを恐れてSNSを運用しないわけにもいかない現代なので、SNSで不適切な発言を行わないよう運用者の教育は徹底すべき。
万一、炎上してしまった場合にどのように対処するのかも事前にある程度シュミレーションしておくことです。
そして、FacebookやTwitterといった自分のコントロールできないプラットフォームを利用する際にリスクとなるのが、彼らはいつどのように仕様を変えてくるかわからないということ。
以前もエントリーを書いたけれど、ここ最近ではFacebookがタイムライン表示に変わったり、TwitterのAPIが変わったりといったことがありました。
TwitterのAPI問題を見ていて改めて思ったこと – やっぱりWebが好き – Writing Mode
SNSはもはやなくてはならないプラットフォーム。
しかし、そこに依存した企画には一定のリスクがあることを理解し、クライアントにもきちんと説明する必要があるでしょう。
それでもトラブルは起こる
新しいチャレンジにリスクは付き物。リスクのことばかり考えていたら、いつまでもスタートは切れない
クライアントとの契約の問題だったり、著作権や商標権の問題など法律にかかわるトラブル。または支払い条件や振込・支払遅延など、お金にまつわるトラブル……。
専門家に頼らざるをえないトラブルも数多くありますが、こうした潜在リスクに気づけるかどうかは結局のところ経験したもの勝ちでしかない。
我々にできるのは仕事の範囲をなるべく狭く限定せずに、ひたすら経験値を蓄えていくことだけです。
そして、どんなにリスクに備えてもやっぱりトラブルは起こります。
万一のトラブルに備える意味でも、コミュニケーションは口頭で伝えたり電話で済ませるだけでなく、メールだったり議事録だったり、きちんと文書として残し共有するようにしましょう。
結局、コミュニケーションの齟齬がトラブルを生む原因だったりします。お互いに「言った」「言わない」となってしまうのが一番収集がつかないパターン。なぜトラブルが起こったのか、過去の経緯を辿ったうえで状況を把握するためにもドキュメントに残すということは大事です。
トラブルの解決についても、まずは経験を蓄えていくしかないですね。
だいたいにおいてトラブルっていうのは、これまでに聞いたことがないものばかりです。ということは、これまでの経験からどう応用できるかだったり、困った時のカードとして蓄えておいた知識・教養または人脈をいかに上手に活用できるかだったりします。
経験値を蓄えた人だからこそできる、すばやい状況判断と適切な初動がトラブル解決の糸口です。ここはもう、とにかく勉強し、経験するしかない世界だったりするんじゃないかな。僕もまだまだわからないことはいっぱいです。
以上、僕が普段Webディレクターとして考えているリスクマネジメントまとめでした。
リスクマネジメントはとても重要です。
だけど、リスクのことばかり考えていたら物事は何も前に進みません。
むしろ多少のリスクを抱えてこそ、逆にチャンスがあったりするわけで。場合によっては、とりあえず走ってみて、走りきったあとに考えればいいケースだってあると思います。
時代の流れはとてつもなく速い。何かに躊躇してストップしていると、あっという間に周回遅れにされちゃいます。そのことに気づかない人たち、または気づいていても結局スピード感のない人たちはすぐに淘汰されてしまうに違いない。
常にチャレンジャーでありたいと思う今日この頃です。