20130113 01 dir-mtgスライド

第2回ウェブディレクションワークショップ

キュープラス株式会社 中村健太

WEB DIRECTION WORKSHOP ＠GARAGE AKIHABARA

まずはご挨拶

知ってる人も知らない人もこんにちは Webディレクターズマニュアルというブログの中の人をやっておりますキュープラス株式会社の中村です。

プロフィール Webディレクター歴5年目くらい もともとアフィリエイター その前はコーヒー屋の店長 子どもは2人（小2と年中さん） 年齢：31 趣味：モータースポーツ観戦 筋トレ（ハード） ランニング（ベリーハード）

このワークショップについて 主催：日本ウェブディレクション協会（仮） デスマーチを無くそう！そのために・・・ ・ディレクターの職域を明確にしよう ・ディレクターの認知を広げよう ・ディレクターをもっと育てよう そんなことやってる団体。

今日やること

今日はクライアントサイドも巻き込んだディレクションということで・・・

やることリストはこんな感じ

・初回のディレクターワークショップの内容ふりかえりと復習 ・広義の「コンセプト」について中村式定義 ・ディレクターは本当は2人必要 ・RFPの解説とその重要性について ・ワークショップ（とりあえず作ってみようぜRFP）

前回までの内容ふりかえりと復習

ディレクターは何やる人？

Webにおけるサービスなりビジネルをユーザーに届ける そのためのあらゆる部分の根幹にいる人。

具体的にはどんなことするの？ 根幹がブレないよう、サイトコンセプトの定義を行い「ユーザーに届くモノ」を管理していく。 クライアントもユーザーも制作スタッフも含めて先導するサイトコンセプトってすごく大事なんだよ。と。

サイトコンセプトってとっても大事だからちゃんと作ろうぜ サイトコンセプトとは、制作におけるあらゆる成果物（作るもの）の指針となるもの。 だから、誰がいつどんな気分でやってきて、どう感じてもらうべきサイトなのか？を徹底的に考えて「覚えやすくキャッチーな言葉で形にしよう」 それこそがWebディレクターの最も重要な仕事だと思う。

・・・たしかこんな感じだったと思う。

前回までの内容ふりかえりと復習 なぜWebディレクターがコンセプトを作るのか

理想

クライアント

しっかりとした コンセプト提示

発注

ディレクター

コンセプトを元に サイトを設計

クライアント

コンセプトが曖昧 もしくは無い

発注

ディレクター

え？と？何がしたいん？

クライアント

ビジネスの目的 （理念や目標）を提示

発注

ディレクター

サイトコンセプトを提示 した上でその了承を取っ

て 設計をスタートさせる。

よくあるケース だからこうやる

前回までの内容ふりかえりと復習

ようするに、 「理想の状態でやってくる案件」なんて そうそうないから、ディレクターが考えてやっちゃったほうが色々早いよ。 という論調でおおくりしました。

課題定期

お言葉ですが中村さん 理想の条件で渡されないからディレクターが独断でコンセプトを決めるというのは、 あまりに暴論ではないでしょうか？

課題定期

そうなんです。 そもそも、クライアント側にもコンセプトって色々あるんです。

ブランドコンセプト

商品コンセプト

パッケージコンセプト

プロモーションコンセプト

これらのコンセプト既にがあるなら、そこから派生した形で

クライアント側にサイトコンセプトを作ってもらう

ほうが良くないかい？・・・正論です。

課題定期

じゃあ・・・やっぱり ディレクターが強引にサイトコンセプトを決める のって良くないんじゃ・・・

この結論、 あってるけどあってない。 と僕は考えています。

サイトコンセプト

広義の「コンセプト」について中村式定義

「ディレクターが強引にサイトコンセプトを決めるのって良くない」という話題に触れる前に、まずは サイトコンセプトとはどこにあるのかというお話をしておきたいと思います。 あくまで中村の感覚ですが、おおざっぱに言って以下のような感じにサイトのコンセプトってのは存在すると思っています。

ブランドコンセプト

商品コンセプト プロモーションコンセプト

パッケージコンセプト

もちろん案件や商品、時と場合によって若干変わるとは思いますが、基本的な考え方として ブランド：世界（または国とか雰囲気とか） 商品：人（この場合踊ってる女の子） パッケージ：服とか性格 サイト： その人をみんなの前に連れていく別人格（マネージャー？） プロモーション：ステージイベントそのもの こんな感じのイメージ

本来あるべき形 だから本来は、ここにディレクターとクライアントの二人でたどり

着ければベストだと思います。 理想

クライアント

しっかりとした コンセプト提示

発注

ディレクター

コンセプトを元に サイトを設計

クライアント

コンセプトが曖昧 もしくは無い

発注

ディレクター

え？と？何がしたいん？

クライアント

ビジネスの目的 （理念や目標）を提示

発注

ディレクター

サイトコンセプトを提示 した上でその了承を取って 設計をスタートさせる。

よくあるケース だからこうやる

ディレクターは本当は2人必要

制作側のディレクターと、発注者側では専門性が異なる

商品知識 Webに関する知識 ディレクター △ ○

発注者 ◎ △

随分適当ですが、わかりやすくしてしまうとこういう形になるはず。 だからこそ、 商品に関する専門的で熱い気持ちをもった発注者 ×Webに関する熱い思いと責任感を持ったディレクター この二人でコンセプトを作るのが理想的。 これはもう間違いない。

ディレクターは本当は2人必要

なんだけど・・・実際には結構これが難しい。

クライアントサイド ・立案段階で制作会社がまだ決まってない。または複数いてコンペ中 ・とにかく発表予定までパッツンパッツンでそれどころじゃない ・そもそも担当自身が商品に詳しくない ・Webに関しても△どころじゃなく×に近い

Webディレクターサイド ・実は孫請けで担当者と直接話すことが不可能に近い ・納期納期でもうそれどころじゃない ・商品に関してあんま知らなくてもなんとかなるっしょ！とか思ってる ・提案資料がテンプレート型で実は自分で考えた経験が少ない

結局の所、ディレクターが商品知識を一生懸命勉強するか、または発注者側の担当が一生懸命Web上でのマーケティング方法やデザインについて勉強する（または好みで押し通す）しか無くなってしまっているのが現状です。

RFPの解説とその重要性について

で、ここまでが前置き（長かったですね）

本日の本題

・サイトコンセプトはブランドとか商品とかと密接につながっている ・だから本来であれば発注者とWebディレクターが一緒に考えるべき ・でも色々あって実現はハッキリ言って難しい。

・・・じゃあいっか。と諦める前に RFP作ろうぜ！

RFPの解説とその重要性について

RFPて何？ 情報システムの導入や業務委託を行うにあたり、発注先候補の業者に具体的な提案を依頼する文書。必要なシステムの概要や構成要件、調達条件が記述されているRFPには、必要とするハードウェアやソフトウェア、サービスなどのシステムの概要や、依頼事項、保証用件、契約事項などが記述されており、業者はこれをもとに提案書を作成する。発注元は業者の提案書を評価し、契約する業者を選定、ハードウェアやソフトウェア、サービスなどを調達する。 ・・・何言ってんのかわかんないやｗｗ

要するに 「こういうプロジェクトなんだ！Webでサイコーにする提案ちょうだい！」

ていうドキュメント（＝提案依頼書）のこと

ちなみに目的 口頭伝聞だと起こりやすい「聞いてないっすよ！」とか「え？そーいう意味だったの？！」を防いで、プロジェクトをスムーズに動かすために作ります。 「サイトコンセプトを一緒に作る」という無理難題は実現が難しくても、その前段階にある「提案依頼書」であれば互いに専門家である相手の意見を聞きながら作ることができるよね。というわけです。

RFPの解説とその重要性について

RFPがあると何が素敵なのか？ こういうことが少なくなる デザインできた！⇒なんか違う。やり直して⇒やり直す⇒うーん⇒以降ループ 組み上がったぜ！⇒え？！こうならないんですか？⇒え？なに？⇒こうやってください！⇒うーん、今更難しいですよ⇒えー

上記のようなグダグダな感じでで出来上がった（できあがってしまった）制作物が、ユーザーの心理を想定通りに誘導できるとどーーーーしても思えないし、実際そういうことになっちゃった案件って成果出にくいです。実際。

RFPの解説とその重要性について

そっか。じゃそれ作ればいーじゃん♪

RFPの解説とその重要性について

で・も・ね。

RFPの解説とその重要性について

ごめんなさい。大抵のRFPって意味不明で使いものにならないんです。

例01：某大手ホテルグループサイトリニューアル依頼 トップページ ○○の写真は大きめにするようにしてください。字は大きめがいいですetc... ■■の機能はもっとわかりやすくしたいと思っています。しかしながら・・・云々かんぬん

例02：某大手通販会社キャンペーンサイト新規構築依頼 公開環境：○○○○.com/ サーバー：弊社の専用サーバーを使用 商品概要：添付の資料（パンフレット）を参照ください 希望納期：○月○日 予算規模：○○万円 ・・・・・・・・・・・・・以上

さすがにネタだと思うでしょう？・・・ガチです。残念ながらマジでこんな感じです。 マジでこんな感じの内容をダラッダラと数十ページにもわたって書き連ねただけの資料が送られてきます。

RFPの解説とその重要性について

こんなRFP（もどき）では 「誰に」「いつ」「どんな気分で」「何をして」「結果どう感じて欲しいのか」 何にも分からない。 これで「提案してください。質問は質問状をメールに添付する形で・・・」とか言われても何をすればいいのかすら分からなくなってしまいます。

結果として起こりうる最悪のケース ディレクター頑張って提案してみる⇒なぜか通る⇒作り始める⇒デザイン上がる⇒見せる⇒「んーなんか違うんだよね」⇒以降ループ

なんでこうなるのか ・情報が不足しすぎて、そもそもブランドや商品のコンセプトをディレクターが理解出来てない ・結果としてクライアント側が意図していた本来あるべき軸の位置から大きく外れた提案になる ・そしてその提案が軸からずれているかどうか？をWebの専門家でない担当者は判断できず ・結果としてずれたままプロジェクトが動き出した。

RFPの解説とその重要性について

ここからは中村の持論ですが

RFPを「中の人だけ」で書いても意味が無い

・・・と僕は思っています。

自社内にWebの専門部隊がいて、今回は外注したいから。というならわかります。 ですが、形だけRFP（＝提案依頼書）を真似てもダメなんです。結局の所 「何が重要で何が重要でないのか？」をそのRFP作成担当者が理解していなければ、全員が不幸になるだけです。

RFPの解説とその重要性について

では正しいRFP記載項目ってなんだろう？ 大雑把ですが、大半のプロジェクトに使える汎用性を考えるとだいたいこんな感じ。これをベースに案件ごとに必要項目を追加していくイメージです。

概要系情報

目的と課題項目

見た目に関する事前情報

作業範囲と前提条件 スケジュールと予算感 目的とゴール、プロジェクトの抱える課題点、 「決める人」はどこの誰なのか、想定ターゲットユーザー

プロジェクト名 プロジェクト概要情報

デザインの必要要件 デザインによって解決したい要素

成果物の範囲、中間成果はどうする？、素材の準備について

公開日（または公開希望日）、確認に必要な時間、予算感

RFP具体項目 概要系情報

プロジェクト名 そのままズバリプロジェクトの名前。名前があるとなんとなくモチベーション上がるし、イメージがつきやすくなります。 概要情報 そのプロジェクトは一体何を誰にどうするために発足したのか？を端的に書きます。 例「○○な■■を△△の☆☆に？？するためにこのプロジェクトは存在します」みたいな。

RFP具体項目 プロジェクトの目的と課題項目

目的とゴール 具体的にいつまでに何を成し遂げることがこのプロジェクトの目的であり、その先に何ができればゴールなのか？ここも可能な限り具体的に書いていきます。概要とかぶるような感じもしますが、概要より細かい事を書くイメージです。 例「3年後の2016年末までに■■の販売数を現行商品の2倍にする」とかそんなん。 プロジェクトの抱える課題点 マーケットにライバルが多いとか、認知が薄いだとか、都合上ドメインを新規で取らなきゃいけなくて短期的なSEOは無理とか、偉そげな誰々が実はあんまり乗り気じゃないだとか、・・・要するに「これ今すぐやるとしたらこのへんで困るよね！」なポイントを赤裸々に格好付けずに書きます。 「決める人」はどこの誰なのか いわゆるステークホルダーってやつです。デザインは誰が最終的に決めるの？会議式なの？決定者がいるの？商品の発売時期は誰が決めるの？システムについては？マーケティングは？予算は？誰が決める人で、その決める時間はどれくらいかかるのか？を書いていきます。 想定ターゲットユーザー この商品は誰が、いつ見て、誰が買って、誰が、いつ使うのか？このへんをしっかり書きます。 またWebの観点から見て、このサイトは誰が、いつ、どのタイミングで、どこから来訪するのか？なども書き加えていきます。

RFP具体項目 見た目に関する事前情報

デザインの必要要件 今現在、どのようにデザインは管理されていて、この案件におけるデザイン（ビジュアル）はどう決定されていくのか？を明記していきます。ロゴのレギュレーション等はもとより、サイト上での表現ルールだとかがあるのか無いのか、あるならそれはどこの誰が管理していて、例外はどの程度あり得るのか等など。 デザインによって解決したい要素 これはWebの専門家と一緒にやらないと痛い目を見る項目。デザイン（見た目の装飾やビジュアルコントロール）によって、「何を解決できたらいいなー」と考えているのか？という定義です。 「かわいい！と思わせる」のか「すげぇ！使いやすい！」と思わせるのか、あるいは「ビジュアルによって話題性を作りたい」のか、「見た目で一瞬で商品を理解させたい」のか。 デザインによって解決できない問題なんかも多々あるので、話し合いながら「このサイト設計プロジェクトにおけるデザインの解決すべき課題点」を洗い出していきます。

RFP具体項目 作業範囲と前提条件

成果物の範囲 スライスされた画像だけでいいのか？レイヤー構造化された画像がいいのか？マークアップされた状態のファイル郡がいいのか？それともシステムまでフルスクラッチ？既存システムへの組み込みも含めて成果物？ これをちゃんと明記しておきます。 中間成果はどうする？ どのタイミングで成果物の確認を行うか。および、成果物のパターニングを必須とするかどうか？を決めておき、記載しておきます。 素材の準備について 提供できる。あるいは用意できる素材はどのようなモノがあるのか？これを”お互いに”確認しておきます。 ※制作会社側に素材がある又は新規で撮影可能とかってケースも多々あるため

RFP具体項目 スケジュールと予算感

公開日（または公開希望日） 決まっていれば必ず明記。その腕、「この日程からずれることが可能かどうか」ずれる場合にどのような手順（誰に相談しろとか）を踏むべきか？を明確にしておきます。 確認に必要な時間 ビジュアルデザインは推定で○○日、インタラクション（動くとこ）は推定で○○日、などなど。確認するパターンの数とか機能の多さによって大きく異なるはずなので、このへんは良く確認しあう。 予算感 明確に決まっていればその数字を。下手に隠して「安ければ安いだけ」とか言うと「じゃあ安いなりの提案を・・・」になりやすいので注意。「この価格内でサイコーのものお願い！」のほうがプロジェクトは上手く動く可能性が高いと思います。（持論） また、まるっきり決まっていなくても、なんとかして目安となる価格帯は考えておきます。上記の逆で、「せいぜい数百万単位かなー」とか考えてたら「見積り2,000万で出しときました！」になったときプロジェクトそのものがコケ兼ねない。

RFPについて

見ていただくと分かるかと思いますが、 担当一人だけでも 制作会社のWebディレクターだけでも RFP（＝提案依頼書）なんて作れないんです。

そこでワークショップ

では実際に実感していただきましょう。 ・ヒアリング（基本的な部分はまずヒアリングで） ・一人でRFP作ってみる（15分） ・その後、ライオン坂本さん（クライアント役）を囲むように座って 一緒にRFPを作ってみましょう。

複数の専門性の異なる頭脳が集まると どれだけ素敵なアイディアが産まれるのか。。。 楽しみじゃありませんか。ねぇ神戸くん？

ありがとうございました。