Butterfly only knows.

札幌のデザインマネジメント会社社長のブログです。

川端康成『古都』より

最後にひっくり返されないためのデザイン進行

 制作案件におけるデザインの役割は、MVCのアナロジーでいえばVIEWにあたり、ユーザーインターフェイスに関して責任を持つべきだ、というのが弊社の持論。インターフェイス(さらにいえばユーザーエクスペリエンス)に関して責任を持ち、リスクを取り、その対価をデザインフィーとして頂くこと。そういうスタンスで臨むため、クライアント側のプロジェクトに対する決裁者には、あなたの仕事はデザイン決定ではなくデザイン戦略決定であり、デザインによって獲得するべき具体的な目標を設定することですから、と言っている。

 案件を進める上でいつも気をつけていることは、最終的な判断を下す人(決裁者)を常に意識し、要所要所で進捗具合、方向性をリークしておくことだ。ベストなのはプロジェクト自体に決裁者を巻き込んでしまうことだが、難しいことが多いであろう。なので、アンオフィシャルな形でもかまわないので、今こうなっているということを直接伝えるようにしている。これをクライアントの担当者に任せてはいけない。こちらとしては可能な限り、1担当者へのルート と 2決裁者へのルート の両方を確保しておき、情報の取得にせよ方向性の調整にせよ、2つのルートからコントロールが効くようにしておくことが肝要だ。いらぬ手間・労力が必要だが、それにより完成間近でそれまで何のコミットもしてこなかった決裁者に全てをひっくり返されるリスクはかなり減らすことが出来るであろう。

 基本的なことだが、関係者間での情報共有は徹底するべきで、なおかつ情報共有のための時間(連絡会的なもの)をわざわざ設けないで済むようななんらかの情報共有ツールを用いるべきだ。最も手軽なのはプロジェクト用のメーリングリストを使って、たとえ1 to 1のメッセージでも1 to n にすることで情報を共有するやり方。これは手軽な反面、時間軸での変遷・経緯がわかりにくいことと、ドキュメントの共有には向かないという欠点がある。

 連絡にはメールやMLを用いるとして、wikiを使った情報共有を今のところスタンダードとしている。もちろんクライアントにもアカウントを発行し、議事録から成果物のチェックにまで用いている。
 ある案件では、デザイン案に関する簡易なwikiをクライアント社内に広くアナウンスしてもらったことで、直接の担当部署だけではない多くの社員の意見を吸い上げることができ、大変有効であった。さらにその制作物(ウェブサイトだった)が完成した後、「自分も意見をいったサイトができあがった」という意識を多くの社員が持ってくれたことで、その企業全体のネットに関するリテラシーが上がったという副次的なメリットもあった。

 今現在は制作進行に関するそういったツール類(連絡用、情報共有用、コンセンサス用、それから見積〜請求までの事務仕事用まで)は既存の各種サービスを組み合わせて使っているが、これを自社開発したシステムに置き換えている段階だ。


♪ Road To Nowhere / Talking Heads