さて、今回は表題にもあるとおりクライアントとの更新やりとりを簡単にしよう！っていう意図から、僕がディレクションの現場で使ってきたテンプレートやら何やらを公開しながら後悔するっていうネタになります。

そもそもなんで更新依頼処理ってあんなに面倒なんだろう？

案件やサイトの構造、クライアントの理解度とかこだわり具合によってかなり変化するとは思いますが、大体以下の流れを辿ってサイトの更新依頼から公開となります。

更新時の依頼→制作フロー

・まずは何の話なのかを解読
・更新なのか新設なのかを解読
・何がやりたいのか？またそれはなぜなのか？を聞き取って
・どのくらいの期間であげればいいか確認
・要素を洗い出してざっくりワイヤー作って
・確認してもらって修正
・必要な画像やら原稿やらを依頼して
・もらった素材を配置して再度確認
・内容が固まったらデザイナーに制作依頼
・あがったものをもっかい確認してもらって
・テストアップ→修正
・んで本番アップ

うーわーーーー
書いてるだけでめんどくさくなってきました。

同じ現場のスタッフから「○○を■■にしといて」って言われる分には非常に簡単に話が通じる更新依頼。
でも、なぜかクライアントからの依頼となると上記のような異常に面倒な手順を踏まなければ上手く回りません。（この場合、少数派となる「好きにやってくれ！お前にすべて任せる！」というイキなお客さんは省きます。）

で、何でこんなことになってしまうのか？ですが、上記を見ていただいてもわかるとおり、とにかく「何をどうやりたいのか？」を確認する手間と、「これでいいのかどうか？」を確認する手間の2つが非常に面倒なんです。

「これでいいのかどうか？」の部分は今回のテンプレートではどうにもなりませんが、そこはとりあえずまた別の機会に効率化を目指すとして、今回は「何をどうやりたいのか？」の確認をスピードアップしてしまいましょう。

というわけで、事前にその辺を全部まとめて教えてもらいましょう

ほとんどのディレクターさんがそうだと思うんですが、複数のクライアントを抱えて一手に回してますよね？なので考えたのは、色々なケースに対応出来る汎用依頼テンプレートを作ってしまおう。という発想。

もちろん、このままですべてのクライアントやすべてのサイトに流用出来る訳ではないですが、ちょちょっと編集するだけで結構汎用出来るはずです。

ダウンロードはこっから→更新依頼原稿テンプレートセット

このテンプレートセットをクライアントのWEB担に送付しておくと、更新時の手間の大半を占める「で、何がやりたいの？」の確認や、「原稿とか写真とかくださいよ」っていうようなやりとりを大幅に減らせました。

この更新テンプレートというやり方自体は特に珍しいものでも何でもなく、どこの制作会社でも当たり前のようにやっていることだろうとは思います。

が、しかし。

中小の制作会社でディレクターになり、しかも社内に「ディレクターの先輩」に当たる人がほぼいなかった僕は、前述のややこしいやりとりにかなりやられちまっていました。

ので、こういうテンプレートがどっかにないか検索してみたもんです。

最近になってもう一回検索してみたら、まだ無いみたいだったのでブログネタにしてみました。当時の僕のようにへこたれているディレクターさんに便利に使ってもらえたらなーと思っています。

ダウンロードはこっから→更新依頼原稿テンプレートセット

リニューアルの目的設定と重視ポイント

ちなみに、今回のリニューアルにあたって重視した点は、ひたすらに「記事を読みやすくする」というというシンプルなもの。
最初期の立ち上げ時にアフィリエイトの一環として始めてしまったブログだったために、いまいち導線もあやふやな上に広告が多くて読みにくいという問題があったんです。なので、今回はこれを改善し、より読みやすいブログとしてリニューアルしたということになります。

なぜ「読みやすさ」を重視することに？

まあぶっちゃけて言うと、記事のジャンル的に（ほぼ）制作業界の方しか読まないんですこのブログ。なので、広告収入はほとんどゼロに近かった。
そもそもアドセンスくらいしか貼ってなかったんで、あんまり収入を得ようっていう意図も無かったんですが、それにしてもクリックされなかった。

ていうか広告邪魔でした。

それから、当初想定していたよりもホッテントリへの登場回数が多くなり、記事にダイレクトにアクセスする方が多くなった。というのが理由です。

つまり「記事を読みに来てくれている方」が多くなっているのに、「記事よりも広告を見てください！」なレイアウト設計だとよろしくないな。と思ったのです。

具体的に何をしたのか？

Webデザインのタネの@sivacchiにデザインしてもらうということで、当たり前のようにソースはガラっと変わっていますが、基本的な配色やイメージはそのまま踏襲していただきました。

デザインのコンセプトはリリース当初と変わらず、「偉そうである」ということ。なんとなく権威っぽいイメージで、記事に説得力を持たせたかったんです。

それから、リニューアルによって以前からの読者の方に「別のサイト」に見られてしまう事態は避けたくもあり、テイストは踏襲してもらうことにしました。

並べるとかなり分かりますが、フォントを調整していただいて、素人仕事くさかった以前のロゴを洗練していただきました。同時にユーティリティエリアもより洗練された印象に。

これが最も大きく変わったところ。無駄な広告のせいでせまーくなっていた記事領域を大きく拡張。デザインもすっきりとシャープなものに変更していただきました。

コンテンツ内容、デザイン、インタラクションまでを大きく変更。記事閲覧の邪魔にならないように、マウスをフォーカスするまで若干透過するように調整してもらいました。

以前MTから投稿した記事データにも対応可能なように、カテゴリーごと背景色が定義されています。今までと見た目は大きく変わらず、見やすくなっていると思います。

もちろん、上記には書ききれないほどに色々な変更が加えられています。デザイン修正ではなく、リニューアルでしたので。細かな改善点はまた機を見て自慢するかもしれません。

そして果たしてナカムラは何に気づいたのか？

今回のリニューアルを終えて僕が僕自身に感じたことはただ一つ。「自分のことになると途端に色々ダメになる」ということ。

正直なところ、上述した自分のブログの問題点に関しては指摘されるまで特に問題とも思っていませんでした。人のサイトを日々解析して、改善点を探し続けているディレクター職の人間のはずなのに・・・！

自分のことになると途端にチェックが甘くなると言いますか、言い訳してしまうと言いますか。

自分自身への言い訳ほど容易で心地良い物はない。

どうしても自分自身相手だと良いわけが出来てしまうんだろうと思います。
忙しくて出来ない。広告収入があるわけでも無いのにやる意味ない。所詮個人ブログなんだから。このブログのネタだとアクセスはそんなに伸びない。

ちょっと考えるだけでも山ほど良いわけが用意出来てしまいます。
しかもその全ての言い訳が、「改善できない」理由として通ってしまうんです。だって自分自身が交渉相手ですから。

でも実際やってみたら何が起こったのか

実際、リニューアル前と後だと、日当たりのVisit数は倍近いです。もちろんその間に割と長いことホッテントリに居続けた記事があったりなどしましたが、リニューアル前と後の一ヶ月間でデータを比較してもやはり30％近くのアクセス、および一人あたりの滞在時間が増えている計算になります。

誰が読みに来るのか？
その読みに来てくれたユーザーになにをして欲しいのか？

日々の仕事同様、言い訳などせずに常にこの疑問を自分に投げかけ続けるよう、意識したいと思います。

どういった時に口頭でのコミュニケーションが必要になるのか

Webディレクターとして仕事をする上で、「口で言って物事を伝える」という場は実はそんなに多くはありません。が、その少ない機会というのがすごく重要な場合ばかりなので、どんな場所で必要になるのか？をまずは書いておきます。

代表的なパターン（対外部）
・クライアントに対し提案、交渉を行う時
・要望やクレームに対する回答を返す場合
・成果など、何かを報告する時

代表的なパターン（対内部）
・社内的な提案を上層に提案する時
・デザイナー、プログラマーに仕様や要望を伝える時

話し方は、基本的には「結・結・結」で

ちょっと極端な例になりますが、何かを単純に伝達しようという場合には以下のような感じでしゃべります。

「これをやるので、こういうものを作って欲しい」
「これはこういう意図で作るものなんだ」
「で、その目的を達成するためにも1ヶ月以内で作って欲しいのさ！」

最初が「最終的に把握して欲しい内容」＝結
次に「理由、もしくは強調」＝結
最後に「内容の補足」＝結
という構成です。ちょっと上記の例文は極端すぎるかもしれませんが、要するに「要点だけ言うこと」と「Aを聞いておかないとBが分からないといった話し方を避ける」という2点に気をつけて喋る。ということになります。

説得や交渉の場合は「結・起・承・結」

人に何かを伝えるだけでは足らず、その伝える内容に対し、納得なり妥協なり何らかの変化をさせなければいけない場合、上述した「結・結・結」で意見を押し通そうとするとだとケンカになります。
こういう場合は「結・起・承・結」のパターンが役に立ちます。

例としてあげると、
結：「この金額じゃ無理です。機能縮小もオススメできません。」
起：「だってね、○○と××を実装して・・・」
承：「で、そのサービスでマーケットを開拓していくんですよね？」
結：「じゃあこの機能どうしてもいるよね？ちゃんとやろうよ。」

みたいな感じ。
最初の結と最後の結だと、同じことを言っているようで、話がちょっとすり替わってます。2つめの起のとこで、別の話がスタートしているんです。

まずは最終的な自分（自社）としての結論。そこから説得スタート！て進めるイメージですね。「そんな乱暴な・・・」と思われるかもしれませんが、ここをボカしたまま話を進めると、ほぼ間違いなく話がこじれます。なので、交渉ごとの時にはこういったスタンスで話をすすめたほうが、結果的にうまくいくことが多いと思っています。

話の最初を聞いておけばOKなように。また、どこかのセンテンスが抜けても内容がある程度把握できるように

文章なんかではよく、「起・承・転・結」なんていう展開方法が用いられますが（最近はそうでもないのかな？）、実は口頭で話して物事を伝える場合、この方法はあんまりオススメできません。なぜならどーしても長ったらしくなるから。

例えば
「○○株式会社さんが新しいサービスをやりたいらしくて」
「そのためにこんな機能とWebサービスが必要なんだよ」
「でも、××っていう事情があってそれが出来ないから」
「だからこういう策を1ヶ月以内に実現する方向でいこうと思うんだ。」

一見するとわかりやすいし、何の問題も無いように見えますが、これはあくまで文章として読んだ場合。（実際、プレゼン資料なんかではこの書き方のほうが納得を得られやすかったりもします。）

しかし、これを口頭で、実際に事例に当てはめてしゃべってみると結構長くなります。 そして、聞かされた相手は『内容を聞き取りながら先を予測し、自分が何を把握すればいいのか瞬時に判断した上で要点を把握する』というちょい難しめなことをしなくてはいけなくなります。これはしんどい。

なので、基本的には全部結論。あとは優先度順に伝える。というのが口頭で何かを人に伝える際の基本形になります。

この状態からプロジェクトの本格スタートまでにディレクターが用意するべきものは何があるんだろう？今日はそのへんをまとめてみます。

ゴールまでのざっくりストーリー

たとえばコーヒーのポータルサイトだったとして「コーヒーに関する情報なら何でもあります！」って言っても何も始まらない。そこにあるストーリーを多少適当でもいいのでドラマチックに盛り上げてしまいます。

1：店主はかつて2店舗のカフェを切りもりした実店舗の経営者
2：学生の頃からカフェが好きで、なんとか自分の理想のカフェを作りたかった
3：それは、カフェの持つ独特の雰囲気とコーヒーの香りが大好きだったから
4：だから、自慢のカフェの雰囲気を全国どこにいても感じてもらえるサイトを作りたかった。とかなんとか・・・

コンセプトキーワード

なるべくシンプルに、なるべく誰にでもわかる言葉が望ましいです。
キラキラしてる。とか、感動的とか、そういった曖昧な言い回しは便利なんですが、コンセプトキーワードとしてはもっと具体的なほうがGood。
数字を入れたりちょっと仰々しい言い回しを使ってみるのもいいかもしんない。

例：
○カフェの雰囲気を100％家に持ち帰ることが出来るサイト
×コーヒーの総合情報サイト

ターゲットの設定

ペルソナ定義・・・と言うよりターゲットユーザーの設定ですね。準備段階では簡潔に、「自分の知り合いでいうとあの人が一番コレ好きそうかなー？」という、ターゲットユーザーの仮定をします。
親しい友人や恋人、隣にいるスタッフ、あそこの会社のあの社長などなど、その辺にいる身近な人を想像しながら、「この人とこの人（3人くらいかな？）に喜んでもらいたい！」とかって決めておきます。

ユーザーの心理シナリオ

後で出てくるプロセスフロー（サイトの中、WEBの中でどう動くか？）とは異なり、シナリオとは「その人がサイトに来るまで」と「サイトに来てアクションを起こすまで」の2つをストーリー（お話）としてまとめる作業です。
僕はここでは夢物語を書いてしまうことが多いです。ざっくり定義したペルソナを対象に、こんな風に心理状態が推移してくれたら最高だよね！ていうシナリオを書き出していきます。

例えば、ペルソナに30代サラリーマン男性、妻子持ち・・・etc.とかって定義したとして（まあ僕のことです）

1：仕事の合間にコーヒーはよく飲む。
2：でもインスタントのコーヒーに飽きてきている。
3：サイトの存在を知る。
4：お小遣いで手が届くプレミアムコーヒーの存在を知る。
5：コーヒー豆のうんちくを知って飲みたくなる。
6：どーせならって凝りたくなる。
7：ちょっといいコーヒーミル（豆ひき）も一緒にほしくなる。
8：周辺器具と一緒に、スペシャリテコーヒーのレシピも知りたくなる。
9：色々見てるうちに買う前提になっていて、結局買う。
10：友人・知人・嫁に自慢。
11：さらに自分自身もリピート。

コンテンツ案まとめ

上記のようなシナリオが完成したら、それを実現するために必要なコンテンツ群をパワポでばーっと書き出していきます。この場合、

・コーヒーそのものに関するうんちくコンテンツ
・コーヒー豆の品種一つ一つに関する深い知識コンテンツと味比較コンテンツ
・コーヒーレシピのコンテンツ
・周辺機器の情報と使い方解説
・紹介しているものを直接購入出来るショップコンテンツ
・自慢というアクションを容易にするSNS連動コンテンツ・・・

と、まあこんな感じでしょうか？

ライバルサイトの分析メモ

ここまで概要が固まれば、ほぼサイトの属すことになるジャンルと、競合サイトの絞り込みが可能になります。
いわゆるベンチマーク調査が出来る下情報がそろったってことです。
関連ジャンルの様々なサイトをまとめて、どんなコンテンツを持っているのか？価格帯とデザインの方向性はどんな感じか？購入のための導線設計はどうなっているのか？1ページあたりに存在するコンテンツ量はどんなもんか？などをざかざかと手書きでもメモ帳でも記録していきます。

ライバルサイトチェックポイント
・どんなコンテンツを持っているか？
・コンテンツの「かたより」はどこにあるか？
・どんな導線を持っているか？
・デザインのテイストはどんな感じか？
・一番「儲かってそうなサイト」はどこか？
・キーワードは何を狙っているか？
・ユーザーに何をさせるためのサイトか？
などなど

ユーザー調査メモ

ユーザー調査、なんて言うと非常に大仰な感じですが、要するに
楽天とかアマゾン、Yahoo！ショップ＆オークションで、ユーザーのレビューと売れてそうなショップのランキングを見てメモっておこうってことです。
色々なユーザー調査の方法があるだろうとは思いますし、僕のこの方法はユーザー調査とはいえないかもしれません。でも、何となくつかめますし、何より早いです。
構築予定のサイトが属するであろうカテゴリにおいて、今何が注目されていて、みんなが何を見てサービスが期待するアクションをするに至っているのか。
みんなが本当にほしがっているのはどんなものなのか？など、以下のような項目に分けて見ていくと、結構分かって来ます。

ユーザー調査チェックポイント
・そのカテゴリで一番売れている商品は何？
・それを買った人は何て言って喜んでいる？
・それを買った人は何て言って怒っている？
・高いものと安いもの、買った人のレビューでテンションが高いのはどっち？
・自分で見ていて一番欲しくなったのはどれ？
・それはなぜ？デザイン？価格？みんなの意見？
・自分の身近な人に勧めるならどの商品？

コンセプトマップ

一番大きなコンセプトを真ん中に置いて、それぞれ派生したコンテンツごとのコンセプトを定義した資料です。
例えば、コーヒーの周辺器具を扱うカテゴリと、コーヒーのレシピを扱うカテゴリでは、基軸となるサイトコンセプトは共有していないといけないですが、それぞれは別個のコンセプトを持っていないとつじつまがあわなくなりますよね？

ディレクトリマップ

コンセプトマップよりももっとシステマチックに、いわゆるディレクトリ構造に即して作成されるマップ。この時点で、ページ構成なんかを当て込みで決めてしまいます。

ルートフロー

サイト内にやってきたユーザーを3つくらいのグループに分けて定義。それぞれ、どこからやってきてどう抜けていくのか？を図にしたものです。

例：
メインユーザー
PPC→TOP→個別（3～10PV）→購入

サブユーザー
検索→TOP→個別→共有

コンセプトモデルワイヤーフレーム

このブログでもさんざん書き方やら効率化やらのネタで登場していますが、ここでようやくワイヤーフレームの作成となります。
ただ、ここまで事前の定義が出来ていれば、実はワイヤーの作成自体はもうそんなに難しく無いはず。頭の中にあるイメージを一気に書き上げてしまいましょう。

構築のスピードとクオリティをあげる、本気のワイヤーフレームの書き方

ここで注意事項ですが、この段階でのワイヤー作成に、もし時間がとれるなら、予算とか時間とか仕様とか、全部忘れて、「このサービスをこのターゲットに向けて提案するなら、こうあるべきでしょう！」という要素を全部組み込んで、コンセプトモデルを考え出してしまうと色々うまくいくことが多いです。

「そりゃーもっといっぱい予算があればねぇ・・・」とか言う前に、「クライアントがお金をもっと出したくなるプラン」を先出ししてしまいます。
言われたことを実現するために予算よこせ！て言ってもなかなかうまくいかないもの。
むしろ、ディレクターの持つ「根拠を持ったアイデア」に投資させる。位の考え方で作ってしまっていいと思います。
あくまでコンセプトモデルなので、夢を見れるモデルを構築します。

プレゼン資料

具体的なプレゼンの資料作成方法は別のエントリーで解説しているのでこっちを参照

提案資料とデザインの切っても切れない関係について

上述の内容を「ざっくりとまとめた資料」を作成します。
あんまり緻密にはまとめません。もちろん人によってかなり作り方に開きはあると思いますが、僕はプレゼンは極端なくらい簡単に「結転結」でまとめるのが好きだしうまくいくと思っているので、内容はかなりかいつまんでざっくりとまとめます。

計画表

ほとんどの場合、当たり前のように「想定外」が起こるので、「想定外のことが起こるだろう」という想定を行った上で計画を立てます。
つまり、ざっくり多めに取る。ということ。基本的にはあんまりキッチリ組まない方が良いです。納期を守ったほうが良いのは当たりまえですが、ゆとりをもった方がクオリティが上がること。キッチリ区切ると混乱を生みやすいことを説明すると、意外とすんなり通ったりもします。
「○月○日、デザイン3時間」とかではなく、「○月中旬～○月下旬：デザインと確認」みたいな感じに組んでおくと楽ってことです。

プロジェクトスタート！

さて、いよいよサイト構築がスタートだ。
もう、何も怖くない・・・でしょ？

「とりあえず作ってみて。みてみないとわからないから」つぶやきまとめ」

んで、この記事に対して僕がディレクターとして思ったことがあったり無かったりしましたので、ちょいと書いてみようかと思います。

ナカムラが思ったこと。

これってディレクターが前段階でもの申してやればなんとでもなることじゃね？

まず、クライアントの意見は全部入れるとだいたい見当違いのものができあがることが多いです。もうね、これは仕方ないと思う。だって企業の担当者はWEBの専門家では無い場合がほとんどなんだもの。

だから、どんなものができるのかイメージできない。 結果として「とりあえず作って見せてよ。お金出してるでしょ？」というスタンスになってしまう。これをそのまま受けてしまうと何が起こるか？それは以下のような最悪のスパイラルでしょう。

想定される最悪の事態

とりあえず作ってみて
→デザイナー頑張ってとりあえず作る。

気に入らないから別パターンお願い。
→さらに頭をひねってやってみる

やっぱり○○が■■だから～・・・
→やってみる・・・

無限ループに限りなく近いなにかが起こる。

いったいなにが足りないとこういうことになってしまうんでしょう

まず、とりあえず。という段階では、決まっていないことが多すぎる場合がほとんど。 ・どんなターゲットに
・どんな価格設定で
・どんなイメージ戦略で
・どういうスパンで
・どう売っていくのか・・・
こういった事（つまりはそのサービスをWEBでやる目的）が不確定だったり、もしくはフワフワしている段階で起こりやすくなります。

そもそもこの段階でデザインを見たいって言うこと自体がイミフwwwというレベルなんですが、それでもどうしてもデザインが無いと先に進めないんだよ！という方も少数ですが確かにいます。

では、そんなとき僕らディレクターはどう返したらいいのか？

ディレクターはこう言ってあげればいいと思うよ。

「できますよ。でもお金かかりますよ？」
「そしてそれは安くはないですよ？」
「逆に、デザインに関して任せてくれれば、そこから上がる数字に責任持ちます。」
「デザインを好みで決定しないなら、そこは責任を持てないけどOK？」

とりあえずこれを伝える必要があると思います。
で、僕の経験上、だいたいのクライアント担当者は、ここで折れてくれます。

そもそも、やり方にも問題があるのかもしれない。

こういう要求がまかり通ってしまう背景として、ディレクターを含めた社内スタッフ全体に「クライアントの意見を100％に近い形で反映しなくては！」
もしくは、「クライアントをデザインで満足させなくては！」
という間違った思い込みが前提にあるように感じます。

確かにクライアントの担当者をデザインで魅了する。これは非常に大事です。
大事ですが、もっと大事なのは、そのサイトを訪れたユーザーを満足させるデザインであること。のハズ。

で、これはやってみないとわからない。の部類に入ることだと思うのです。
WEBのプロとして責任を持てる制作物をしっかりと作り込んで、アクセス解析に基づいた分析から、さらなる作り込みやリニューアル、リデザインの提案を進める。

最初っから100％のものを作ろうとするより、ずっと理にかなっているやり方だと思うのです。

僕らの仕事は、極端な言い方をすれば「人の仕事（やりたいこと）の手助け」。 デキるディレクターってのは、多分よりいいサービスを生み出すために、自分以外の人のために時間を多く使える人のことだろう。なんて考えてみた。

ディレクターがいなくても案件は回る。でも・・・

僕らディレクターは、案件の規模やチームの完成度により、
「自分では何もしなくてもWEBサービスが完成してしまう」
ということが起こりえる特殊な職種です。

たとえ客先との連携がうまくいっていなくても、頑張り屋のデザイナーが先行してイメージを作ってくれれば、それがきっかけになって話が進む。なんてよくあるし、

たとえばワイヤーが不十分だったとしても、残業を繰り返してでも足りない要素を補ってくれるデザイナーやコーダーがいてくれればそれでサービスは完成してしまう。

たとえば仕様設計書がいい加減でも、プログラマーが寝ずにがんばってくれたらあるいは完成してしまうかもしれない。

確かに納期があるし、複数案件回してるし、顧客対応に追われてるし、
言い訳しようと思えばいくらでも出来るんですが、
「コンセプトを作ったディレクターが監修してないコンテンツ」を作ってもらって、その責任は誰が負うのでしょう？

先出ししたデザインに対するクレームや無茶振り注文はデザイナーの責任？
ワイヤーが足りなくて、それを補うために作られたコンテンツでエラーが出たらコーダーやプログラマーが悪い？

絶対違いますよね？
それはディレクターの責任です。

どんなユーザーに、どんな導線で、
どんな気持ちで、
どう使ってもらって、
どんなコンバージョンを生み出すのか？
これを決めたディレクターがちゃんと監修して設計図（ワイヤーとか仕様書）をあげることで、初めて「こうしたほうがいいんじゃない？」というチームメンバーからの改善要望を反映することが出来るはず。

その先にしかいいコンテンツ、いいサービスなんて生まれないはずです。

もう一度自分の仕事を振り返る。

だからこそ、僕らディレクターはより速く、より簡易にチームのイメージを共有化出来る資料を作らなきゃいけない。

より正確に仕様を固めないといけない。

より完全な原稿をあげなきゃいけない。

もちろん、チームメンバーに頼るな。ということではないですが、 全部他人任せでさも自分がやったみたいな顔するディレクターは死んでいい。 と個人的には思っているので、自分自身がそうはなるまいぞ。と思って書いてみました。

これを読んで「俺は大丈夫だ。だっていっぱい仕事してるもん。」と思った人ほど、もしかしたら危ないのかもしれない。（やっぱり自分が以前そう思っていたので）

まずは、サイトの特長や企画特性に合わせて、各サイトの要素を洗い出します。コンテンツマップとは別に考える、いわゆる「パーツ」の部分も含まれるので、かなり量は膨大になりますが、しっかりやります。

んで、かならず「誰が読んでも何の事を言っているのかわかる一般用語で名称をつけます。」

コンテンツマップを作成し、各コンテンツにも優先度をつける。

上記の要素リストとは別に、コンテンツマップも作成したほうがいいです。

要素リストとは異なり、おおざっぱに言うとサイトの中にページとして存在させたい内容を洗い出します。

洗い出し終わったら、その内容を優先順位順に並び替え、一緒にできそうなところは一緒にして、分けた方がよさそうなところは分けて・・・といった調整をザックリ行ってしまいます。

コンテンツに優先度をつけたコンテンツマップのサンプル
パワポファイルをダウンロードして見る。

とりあえずワイヤー案を手で書いてみる。

上記まで完了すると、だいぶ頭の中身が整理されて、「何が重要で何が重要でないのか？その根拠はなにか？」くらいは余裕でしゃべれるようになっているはず。

ここまで来たら後一歩です。とにかくその頭の中身を共有できる形に変えて、デザイナーなりクライアントなりと共有していきます。

んで、まずはきったなくてもOKなので、手書きでワイヤー案をまとめてしまいます。

右の画像がナカムラの書いた手書きワイヤー案。
なにこれひどい・・・ｗ

パワポで清書してみる。

別にソフトは何でもいいのですが、僕的にはクライアントとも共有しやすいパワーポイントが大のお気に入りです。

ページ設定は、35×65くらいで、ベースとなるサイトイメージを貼り付けた状態で作ることが多いです。

フォントサイズなんかも実際のサイトとそろえるように注意します。

可能な限り原稿も入れ込んで、テンプレートパターン、および想定する全てのレイアウトパターンをワイヤー化

TOPページ、一覧ページ（カテゴリーパターンがある場合その全て）、動的生成ページ、静的に作る独自レイアウトページ、検索結果、特殊な機能を持っているページなどなど、全てのレイアウトパターンを、可能な限り書き出して、その全てのページのワイヤー化を行います。

正直、ここからいきなり手をつけてしまうディレクターさんが多く、そのせいで要素やコンテンツごとの洗い出しが悪くなり、「え？何このページ？クラス新しくつくらなきゃじゃん！」と悲しい叫びを上げるデザイナーさんが多いような気がします。

ここでコンテンツの洗い出しをミスったら、それはディレクターの責任。 ちゃんと抜けなく洗い出せるように、上述の要素リスト、およびコンテンツマップ、そして手書き段階での共有をしっかりしておきましょう。

実際のECサイトのワイヤーフレームサンプル
パワポファイルをダウンロードして見る。

ちなみに、ここに書いてある改造は完全に自宅マシン用です。 会社のマシンでここまでやると・・・ちょっと動作とかアドオンの不都合とか色々検証してないことも多いので、出来るだけご自身の責任でお願いいたします。

とりあえず手始めに入れるアドオン

SQLiteOptimizerアドオンを入れる
Firefoxの重たくなる一番の原因となる、SQLiteの計量最適化を図ってくれるアドオン。

Faster Fox Liteアドオンを入れる
設定は「ターボチャージャー」に。
かつ、アドバンス設定で「Disable IPv6 DNS lookup」にチェック。

MemoryFoxアドオンを入れる
使っているうちに肥大化していくFirefoxのメモリ食い過ぎ病を回避してくれます。
とりあえず全部チェックいれとけばOKです。

BarTab Liteアドオンを入れる
タブの内容を、「そのタブをフォーカスする瞬間まで」読み込まないで置いておいてくれるというナイスなアドオン。使ってみるとそのすばらしさは一発でわかります。何より、起動時に威力を発揮！かなり便利です。

FireBugアドオンを入れる
言うまでもなく人気のWEB開発者用アドオン。便利だからってのもありますが、入れるとちょっとだけ処理が早くなる・・・気がします。（気のせいだったらしいです。実際にはちょっと遅くなるみたい。）

アバウトコンフィグから設定すること

about:config
└network.http.pipelining→「true」
└network.http.proxy.pipelining→「true」
└network.http.pipelining.maxrequests→「8」
└browser.cache.memory.enable→「true」
　→右クリック→「新規作成」→「整数値」
　→browser.cache.memory.capacity→数値入力
※搭載メモリが1GBの場合：16384
※搭載メモリが2GBの場合：32768
※搭載メモリが3GBの場合：49152
※搭載メモリが4GBの場合：65536

FireFoxのアドレスバーに、「about:config」と打ち込んで、警告文とか全部無視して、上記の通り打ち込んで、それぞれ真偽値、もしくは整数値を上記の通り変更します。 内容は、「無理していい？いんじゃね？」みたいな感じ。

user.jsの設定

以下の.jsファイルをダウンロードして、『C:\Program Files\Mozilla Firefox\defaults\profile』に設置します。中身は色々と「早くするぞー！おー！」て内容の設定資料みたいな感じっす。 ※Vista、7の場合の格納場所はよくわかんね。

user.jsのダウンロード

最後にFirefox高速化支援系フリーソフトを導入

SpeedyFoxの導入
Firefoxのデータベース軽量化系ソフトの一つ。実は同じようなソフトはかなりたくさんあるんですが、実体験として最も早くなる！とおすすめ出来るものです。
動作はスタンドアローンで、基本的にFirefox本体を落とした状態で起動。数秒で作業は終わり、完了すると異常なほどFirefoxの起動が速くなります。

Firebootの導入
Firefoxのアドオンの問題点でもある「多言語対応」を「日本語だけあればOKじゃね？」ということで、膨大な量におよぶ多言語のUI表示用データを削除してくれる優れものツール。なんですが・・・どーもこいつを使うと、いくつかのアドオンがクラッシュしてしまいます。まあ、それでも高速化そのものは結構速くなるので、
「消えた（使えなくなった）アドオンは再インスコすればおｋ！」という豪気な方のみ使用されることをおすすめいたします。

以上です。
たぶん、これであのくっそ重たかったFirefoxの起動は（PCにもよりますが）おおよそ5秒以内になるはず。普通のブラウジングは本当にびっくりするくらい速くなりますよ。
ええ。もう本当に「今まで何やってたんだよFirefox！」ていうくらいに。