泥臭いWEBの底から～WEBディレクター覚書～

このブログを読んでくれている人の数はそんなに多くないのだけれど、おそらくほとんどが同業界の人だと思う。内容的に。で、そんな人たちにいまさらこんなことを書く意味があるのかどうか知らないけれど、

WEBディレクターは他のWEB系職種と違い、アイデンティティが非常に不安定だ。そのため、定期的に「自分は何者か」を確認せずにはいられない。

というテーゼに従って、そろそろまたwebディレクターそのものについての記事を書くことにする。ってか、個人的に書きたくなってきた。
で、今回は「webディレクターの2類型」について。

云々（うんぬん）
「Webディレクターの仕事とは」

リーダー的な仕事（プロジェクトリーダー）とマネジャー的な仕事（プロジェクトマネジャー）が含まれている

にもあるように、webディレクターの仕事には大きく分けて2つのタイプがある。それぞれの違いは上記ブログを参照してもらうとして、そもそもwebディレクター自身がこの2類型に分かれると思う。そして、この2類型では同じ行為でも捉え方や背景にある認識がずいぶん違う。

リーダー型webディレクター

自己イメージ：
自分がスタッフのリーダー

対スタッフ：
自分がスタッフを引っ張っていく
スタッフとは自分がまとめるもの
自分が上、スタッフは仮想部下

対クライアント：
フロントに立つ
クライアントの要望は「叶えるべく動く」

発揮する能力：
リーダーシップ

責任に対する考え：
「自分が責任者なので、責任を負う」

メリット：
迅速な判断と統率の取れた行動

リスク：
内紛の発生
他スタッフの意見が活かされない
webディレクターの暴君化

成果：
webディレクターの力量に左右されがちなので、優れたディレクターの下では場合は非常によいものが出てくるが、劣ったディレクターの下では成果も上がらない。

チームとしての方向性：
組織としての総合力を伸ばす



マネージャー型webディレクター
自己イメージ：
あたかも芸能人のマネージャーのごとく、自分が制作スタッフに仕える

対スタッフ：
自分が個々のスタッフを支援する
スタッフとは自分が世話するもの
自分が従、スタッフは仮想主人

対クライアント：
矢面に立つ
クライアントの要望は「叶うよう手伝う」

発揮する能力：
支援と援護

責任に対する考え：
「スタッフが困らないよう、自分が責任を負う」

メリット：
フラットな関係性で、スタッフが主体的に動ける

リスク：
意思決定の曖昧化
内向きの姿勢
webディレクターのイエスマン化

成果：
webディレクターの力量だけで全てが決しないので、ディレクターの力量を超えたものが出てきたり、逆にディレクターの力量のわりにいまひとつの成果しか上がらなかったりする

チームとしての方向性：
個々人の能力を活かす


実際にはもっと複雑だろうし、上記2類型の間には無数のグラデーションがある。ただ本人の気質やそれまでの経験から、たいていのwebディレクターは上記2類型のどちらかがベースになっていると思う。

よくあることだけれど、これも一概にどちらがいいとか悪いとかいうモノではない。ただ、クライアントとディレクター、あるいはプロデューサーとディレクターが同じタイプだと上手くいかない気はする。また、個々のスタッフにおいても、どちらのタイプのwebディレクターの方がやりやすいかは異なるだろう。

ただ、自分がどちらのタイプなのか、あるいは自分の接するwebディレクターがどちらのタイプなのかを意識できれば、自ずと見えてくることもあるだろう。

webディレクターをしていると、新しい案件のたびにどういう行動を取るかだいたい決まってくる。人それぞれだけれど、大筋は似たようなもんじゃないだろうか？そこでマゴついていると後々三途の川が見える複線になったりもする。そこで、自分の場合をモデルに書いてみようと思う。ある程度、webディレクターの経験がある人には役に立たないと思うけれど。制作会社の場合です。

01：営業とやけに目が合う
営業さんが遠くからこちらを見ている。というか、どうも自分を探しているらしい。目が合う。無理矢理モニターに視線を戻す。営業さんがこちらへ近づいてきて「ちょっといいかな？」…これが案件のスタート。営業さんが自分の席へ来るのではなく、なぜかミーティングコーナーなどへ呼び出された場合は死亡フラグ（というのは言いすぎか）。

02：ヒアリング
とにかく営業さんが持っている情報を引き出す。期日は?規模は?何をするのか?客先への1stコンタクトは打ち合わせ?メール?何か提出しろって言われてる?そのクライアントの案件をウチが手がけたことあるの?ひょっとして、誰かが投げ出した案件なんじゃないの?

とまあ、上記のようなことを問いただす。答えを引き出しながら現状の作業負荷と照らし合わせて、引き受けられそうか判断する。

この時点で相当香ばしい案件（孫請けだけど明後日コンペだから数時間後に元請けと打ち合わせとか、前の担当者が社内にいて、客先と喧嘩して降ろされたor理不尽すぎて降りた、とかヘタ打って引責で外れたとか）であることが判明することもあるけれど、営業さんもそれは承知なので、引き受ける受けないで死を賭けたバトルになることも。

03：会社名やサイト名で検索
その会社がどんなサイトを運営しているのか、まず確認する。新規立ち上げならサイトの感じを把握するくらいでいい。
リニューアルなら、現状がどうなっているのかを把握する必要がある。ページ数が少ないなら、その場でページリストを作りつつ、各ページで気づいたことをメモっていくといい。ただし、以下のような場合は恐怖に震えること。

・ページ数がどう見ても100を超えてるっぽい
・おまけにサイト構造が複雑怪奇（内容的に階層構造やカテゴリ構造に矛盾があるっぽい）
・さらにサイトマップがない
・サイトマップがあっても、掲載されてないページのほうが多い
・おまけにナショナルクライアント級の大企業だ

こうなると、概してサイトの全容はクライアント側の担当者も含めて誰も知らなかったりする。なので実際はどれだけのページ数で、どれくらいがテンプレート的に作れるのかを把握するだけでけっこうな時間が掛かる（前に書いた「フリーソフトでサイトマップを作る方法」である程度は短縮できるかも）。ともかく、きちんとサイトの全容を把握しないと見積りがちゃんと取れない。
なのに見積り提出期限が明日ってまだクライアントと一度もコミュニケーション取ってないんですけど？的なケースも。

こういう場合は「全体で100ページだった場合」などで概算を出して、注釈として「全体のページ数によって金額は変動する場合があります。あらかじめご了承ください」とか書いておく。ページ単価を出すなら、必ず「テンプレート化できるもの」と「できないもの」との2種類の単価を出しておくこと。

リニューアルでもページ数が少ないだとか、既存コンテンツに何かを追加するだとか、そういうときは心を落ち着けてデザインの感じを見るなり、提案内容のアイデアをイメージするなりするといい。

04：人員の確保
内制なら「手の空いてる人はいねがー？」と言いつつデザイナーさんやらマークアッパーさんやら諸々の席を徘徊して人員を押さえる。早い者勝ちなので1分1秒でも早く。自分の狙っていた人が他のwebディレクターと話をしている場合は飛び掛かってそのwebディレクターを追い払うこと。野性の世界。

外注の場合なら、心当たりの相手や今回の要件らしきものに合致しそうな相手へ片っ端から電話。とりあえず押さえておく。その際、「こういう案件をやってもらいたい」ではなく、「こういう案件の引き合いがあって、もし本当にやることになったらお願いできますか？」という程度にしておく。もし最終的に受注できなかったときのことを考えて。先方が「受注確定で要件も決まっている」と誤解してしまうと申し訳ないし。

…とまあ、新しい案件を割り振られたらこの程度は一気にやっておくと後々で助かる、かもしれない。

Flashゲーム型広告について、とりとめもなく考えている。考えたことのメモ。

増加の背景：
高速回線の普及率や有用だと思うクライアントの増加などがある。また、制作経験のある制作会社が増え、ガワだけを入れ替える形でよければ、以前より安価に制作できるケースが増えていることも影響しているはず。

種類：
・ブログパーツに貼れるものと貼れないもの
・ミニゲームとADV（主に「脱出」系）
→昨今はコンシューマゲームのADVで、たまにFlashで再現した体験版がある
　ex;流行り神2　http://hayarigami.com/2/
・既存ゲームのビジュアルを変えたもの（神経衰弱とか）とオリジナリティのあるもの
・クリア後に賞品（壁紙とか）のあるものとないもの

考察：
ブログパーツにすること自体は難しくない。ただブログパーツにするには、ブログパーツとしての要点を抑えておく必要がある（関連記事：「ブログパーツの基本的な要点」）。

ミニゲームは既存からガワだけ変えるタイプに多い。開発期間が短く、費用もまずまず。ブログパーツにもしやすい。ただ、広告としてはゲーム画面の上か下にバナーを表示させる程度。クリアを設けるなら、クリア後に賞品（壁紙でも何でもいいのだが）でアクセスのインセンティブが必要。
→「ステージ01でブログパーツは終了。ステージ02以降はサイトで遊べる」という誘導は有効かもしれない。

また、ミニゲームは広告の対象と自然な形で関連付けるのが難しいかも。やれたとしても「クリーナーだから汚れを退治」など表面的な？ものになりがち。

ADVはほとんど脱出ゲーム（ex：The Shochu Bar http://gs.gotmail.jp/）。開発にお金が掛かるので、数はまだ多くない。今まで目にしたものでは、商品訴求よりも「啓蒙」に力点を置いたケースが多い、の、か、な？
ミニゲームよりもテキストでいろいろと情報を盛り込めるが、上手くシナリオと絡めないと、情報部分はユーザにスキップされてしまう。というか、そこだけゲームと切り離してスキップ可にすると、けっこう読み飛ばされそう。とはいえ、それをそのままスキップ不可で読ませるのはユーザ体験を損なう。広告効果を最大化するためには、かなりストーリーと上手く絡める必要がある。

脱出系が多いのは、たぶんキャラ絵を描かなくていいから。OPとかEDで出す場合にも、それならシルエットで許されそう。キャラ絵の有無は開発期間と費用に直結するし、絵柄の好き嫌いも出やすい。脱出系なら風景だけで済む。

現状、脱出系は「クリック総当り」でとりあえず画面内をクリックしまくる程度。ゲームとしての楽しさはない。この方式だと、「もうクリックできそうな場所ないのに進めない」という「詰み」の状態が発生することも（実際、上記のThe Shochu Barは途中で詰んだ）。この場合、考えて解決できるわけでもないので、逆にゲームという形態が広告を見せる枷となってしまう。贅沢かもしれないが、単純にADVゲームとして面白ければよいのだがなあ。

どんな形態であれ、ゲームであればユーザの接触時間、意識を向けてもらえる時間は長いので、「記憶してもらう」「印象付ける」という目的には効果的かも。「商品知識を深めてもらう」にもバナーよりは効果的か。ただ、失敗すると「テレビCM」のようにコンテンツに挟まったノイズみたいな印象を抱かれかねないので注意が必要。

AXEBUSTERS（http://www.axeeffect.jp/axebusters/index.html）はFPSっぽくてゲームとして面白いが、金かかってんだろうなぁ。購買意欲とか商品知識とかではなく、ブランドイメージ形成を狙っているのだろう。ただまあ、もし自分がFlashゲーム型広告を提案するなら、やっぱりそこを主軸にするだろうなあ。そこが一番、狙いやすそうだから。提案にも自信が持ちやすい＆目算を立てやすい。

そもそも、ユーザにとってFlashゲーム型広告の場合は「ゲーム」というコンテンツとしてのウエイトが意識の中で大きいから、「購買を促す」という効果は期待薄なんじゃなかろうか。ゲーム中はゲームに意識の焦点をほぼ占有されているわけだし。そういう意味では、バナーとかタイアップ記事とかを目にしているとき以上に、広告対象そのものには意識が向かないかもしれない。

なんか本当にとりとめがないな。

参考：
アドバゲーム
http://www.nikkeibp.co.jp/netmarketing/word/explan/061226_advergame/
→そもそもは「ゲーム内広告」なんだよな。Flashゲーム型広告は「ゲームそのものが広告」といったイメージがある。

株式会社SGラボ
http://www.sg-lab.net/
→The Shochu Barの制作会社。スクエニと合資会社なのか。というか、「JPRS24」もここなのな。

勘違いかもしれないが、とあるブログのフィードを購読していて、ある現象に気づいた。そのサイトからのフィードをOperaのフィードリーダーで取得しているのだが、フィードを読み込むたびに「画像」と書かれたAltが表示され、完全に読み込みが終わると何も表示されなくなる。

たぶんこれは「画像が何回表示されたか？」でフィード開封数の近似値を計測しているのだろう。
もしこの推測が確かなら、懐かしい。ちょう懐かしい。HTMLメルマガでは開封数の近似値を計測するのに、そうした手法がよく使われていたからだ。いや、たぶん今でも使われていると思う。誰だか知らないが、この手法をフィードの開封数計測に転用することを思いついた人はアイデア賞だ。

というわけで、ニーズがあるかどうか知らないけれどHTMLメルマガについて。とはいえ、自分がHTMLメルマガの制作や運用に携わっていたのは2年ほど前なので、その点を含み置きください。

1:HTMLメルマガのメリット
→なんといっても画像が使えるところ。それに尽きるといっていい。画像が使えれば上記のように、開封数もある程度は計測できる。自分で試したことはないが、当時は動画も埋め込めた。Flashはどうだったんだろう。今は無理かも。特にOE系は。Flashもダメかも。ただ、テキストメルマガに比べて制作費が高くなるのがネック。今だと対費用効果としては見合わない気がしないでもない。

2：HTMLメルマガの制作について
2-1：静的なHTMLファイルにすること
CSSは使用可。外部ファイルにするときは忘れずに絶対パスで記述するように（画像もリンクも、URLはすべて絶対パスで記述する必要がある）。phpなどは不可。JavaScriptも不可。HTML+CSSで実装可能なこと以外は考えるのもおぞましいと思ってください。

2-2：コーディング
SEO対策も何もあったもんじゃないので、Validでなかろうとマークアップ的にお粗末なテーブルコーディングでも、何でもいいです。ブラウザ以上に表示領域のサイズが各人まちまちなので、なまじHTML+CSSにしないほうがよいのかも。そこはマークアップエンジニアの技量しだいだけれど、きちんとマークアップする理由はさほどない。音声読み上げに配慮する場合くらいだろうか。

2-3：対応メーラー
OEでほぼ充分だし、それに対応していればWEBメールなどでブラウザ上で呼んでいる読者にも問題なく表示される。ただし、他にもBecky!やらなんやらあるうえにブラウザ以上に表示が気まぐれなので注意。
まあ、jpgやgifとテキストを簡潔なレイアウトでシンプルに表示しているだけならあまり気にしなくてもいい。少しでも込み入ったことをしようとすると（といってもたいしたことはできないが）、たいていどれかのメーラーで表示がおかしくなる。実際、以前とあるHTMLメルマガでフレームにコンテンツを読み込んで配信後も更新できるようにしようとしたのだけれど、いくつかのメーラーで表示がおかしくなり、断念したことがある。

2-4：サイズ
大体のメーラーはブラウザよりも横幅が狭いウィンドウサイズになっている。なので、だいたい600px幅くらいにしておくのがよい。800px幅では大きすぎで、大きくてもせいぜい700px幅くらいにしておくとユーザに親切。

2-5：デザイン
縦の表示領域は、幅に比べてはるかにブラウザより狭い。デザインする際はそれを意識しておいた方がよい。デザインカンプをモニタで見る際も、縦幅を狭くしてチェックする方がより実際に近い印象を掴める。そうでないと、配信後になんとなく印象が違う、ということに。また、表示領域の狭さもあるので、個人的には2カラム3カラムはありえないと思っている。

とまあ、注意点としては以上。

3：余談
海外からのスパムで、たまにテキストだけなのにHTMLメールで送ってくるものがある。ああいうものも画像埋め込みで開封数を計っているんじゃないかとにらんでいるのだけれど、真偽を確かめたことはない。

たとえば、何か案件が受注できそうだとする。
そうなると見積りを作ることになる。見積りを作るには少なくとも作業量をある程度明確にする必要がある。作成するページのリストやらワイアフレームやら。あるいは提案書作成。そのためにはヒアリングをする必要がある。全体のボリュームが見えてくるまでにけっこう時間が掛かることもある。なのであまり細かく準備せず、大まかな準備と経験値から概算見積りを出すこともある。

ところが、制作を外部にお願いする場合はそこからの見積りを出してもらうのに、ちゃんと作業量などを割り出しておく必要がある。でないと後でモメることになりかねない。それを避けるための作業。ヒアリング、企画書作成、作成ページのリストアップ、ワイアフレーム。これだけやれば立派な前工程だ。そして、前工程はディレクターが主に引き受ける。

だけれども、その段階ではお金がもらえるあてはない。というか、受注確定していない。骨折り損という可能性も。見積りが算出できるころには、前工程が終わっていることもありうる。まあ、そこまで行く前に概算見積りを出しているはずだけれど、その額と最終的な額との差額が大きく乖離しすぎているとマズい。

webディレクターは受注前からすでに前工程をスタートさせることになる。なので、どのタイミングで案件がスタートしているのか、厳密には捉え切れない。どれぐらいの準備で見積もり金額を出したり出してもらったりするのが最適かも、ハッキリとはしない。

結局のところ、見積りを算出するのに「真に」適切な準備とタイミングというものはないのかもしれない。場合によって変わるからではなく、そもそもそんなものは存在しないのではないか。

とはいえ、どこかで見積りを算出しないといけないので、以下にいくつかのケースを書いて見る。

1：小規模な場合
「特集で2ページくらい」など、やろうとしていることが小規模な場合はすぐに見積りが出せる。バナー作成とか。

余談：クライアント側の人へ。ちょっとした作業に意外な値段を請求されて不安になったり疑心暗鬼になったりすることがあると思う。ただおそらく、それはボられているわけではない。あまりにもボリュームが少ない作業はかえって単価が高くなるのだ。たとえば、5分で済む作業だからといって500円請求すると赤字になってしまうので、5000円請求するなど（額は適当です）。仮に、もっと大きな作業を頼んでも5000円だったとしても。
大きな案件に含まれていればサービスでやってくれそうなものを切り出して、単体で頼むとそういうことになりがちだ。

2：具体性がない場合
「こんなことしたいんだけど…」という方向性はあるものの、それ以上は何もない場合。受注確度で変わってくる。確度が低ければ（そもそもやるかどうかも判らないとか）漠然とした説明から漠然とした数字を出す。十万単位くらいで。ただし、先方にも詳細が決まってないので酷くざっくりした数字だと念を押しておくこと。やろうとしていることが漠然としていても、小規模ならハッキリした数字の見積りを出せばいい。

確度が高ければ、まず提案書を作る。その段階で。十万単位くらいの見積りを出す。この場合も大雑把な数字だと説明する。その後で詳細を詰めて、見積りを順次出していく。見積もりも「これをやるならこの額」「これをやらないならこの額」みたいにAコースBコースと必要に応じて数種類が用意できるといい。

3：とにかく規模が大きい場合
具体性があろうがなかろうが、規模が大きい案件は全貌を把握して見積りを算出するのが難しい。まず、全貌を把握するのに時間が掛かる。かといって「○百万ですね」などと適当に言っておくと、それはそれで面倒なことになる。詳しくは書かないけれど。「けっこう額が膨れてしまうんじゃないでしょうかねぇ」などと、打ち合わせの場ではお茶を濁しておく方がよい。

大きな案件は作業量の触れ幅も大きかったりするので、全貌が掴みきれなくても「これこれの規模であれば幾ら。増えれば増額、減れば減額」という「これこれの規模」を決め打ちで明確にした見積りを最初に作るとよい。余談だが、こうした案件で一度、「巻物」級の長い長い壮大な見積りを出したwebディレクターを見たことがある。

4：提示額が予想より多いとき
まずない。けれど、もしあった場合は「多くてもそれくらいですね」と言って、とにかくさっさと受注すること。もちろん、見積りは提示額より低くなっても誠実に。

5：予算と要望の乖離が大きいとき
上司や自社の営業担当者と相談してください。

以上。上記に当てはまらない場合は…見積りの提出期限までになるべく作業量を確定して、その時点での情報を元にがんばってください。