佐藤氏は経営戦略統合フレームワーク「戦略BASiCS」を掲げています。具体的には以下の５つから戦略を決めるというものです。

• BattleField（戦場を決める）
• Asset（マーケティング資産を決める）
• Strength（強みを決める、差別化ポイントを決める）
• Customer（顧客ターゲットを決める）
• SellingMessager（魅力的な文句を決める）

私は仕事上、日々２〜４件の顧客にアドバイスをしていますが、３C分析やSWOT分析とかそういう話は大上段過ぎて使いづらいです。しかしBASiCSはとても説明に使いやすいです。分かりやすいからです。

中小零細企業が後発でサイトを立ち上げる際に最適

この本は、特に中小零細企業のようなあまり資源の無い企業、そして特に後発でWEBサイトを立ち上げる際に役に立つと思います（今新規ないしリニューアルでWEBサイトを作ろうという企業は、数だけで言えばほとんどが中小零細企業です）

『経営戦略立案シナリオ』の28Pに、以下の一文があります。

「この5つを徹底的に一貫させていけば、売れる確立は飛躍的に高まる。なぜかといえば、売りやすい戦場で、独自資源を生かして、差別化された製品を、ターゲット顧客に、分かりやすいように伝えることができるからだ」

これが、サイト作成のポイントを、とても分かりやすく説明していると思うんですね。

大雑把には

細かくはまたの機会にまとめてみたいなと思うのですが、仮にSEOでの集客がメインとして、おおまかには

• 自社の持っている資産を「強み」として活用できる顧客ターゲットを選定して
• そのターゲットが検索しそうなキーワードかつ、後発かつ新規ドメインでも、上位表示とアクセスが狙える戦場（＝キーワード群）を、キーワードツールや競合分析（SERPAnalyticsなど）で見つけて
• 競合と比べて強みとなるような差別化ポイントを、魅力的で分かりやすい文句でサイト上でアピールする

全ての要素がウロボロスのように循環しているように見えますが、全ての要素は全て影響しあっているので、そういうものとして捕らえたほうが言いかと思います。ただ、最初の取っ掛かりとしてはカスタマーから始めるのが良いかと思います。

実際は戦場の選定がキモなのですが、さらにその前提となるカスタマーのペルソナをどれだけリアルに描けるかがさらにキモだからです。

カスタマーの求めているものが分かれば、後は競合の強さとマーケットの広さを天秤にかけながら、戦場を絞り込んでいくだけです（その『だけです』が難しいのですが…）。

戦場を絞り込めば、新規参入でもそれなりに成果を上げることが可能です。当然、最初から大きな成果は得られませんが、そこで成功していけば、別の小さなマーケットで同じ流れで勝負したり、追加投資をしてより大きな市場に参入するという流れに持っていけます。

じゃあどうやって戦場を絞り込むのか（要は地域キーワードなどの複合キーワードの話になるのですが）、ですとか、差別化ポイントをどうやってサイト上でアピールするのかなどの細かい戦術・戦法の話はあるのですが、それはそれとして、WEBマーケティングで悩んだ方は、この本はお勧めです。

参考リンク

• 経営戦略立案シナリオ （amazon）
• 図解 実戦マーケティング戦略
• [マーケティングのコンサルティング・研修はストラテジー＆タクティクスへ]（佐藤氏サイト）

広告グループなら

• ネットワーク（Googleか検索パートナーか、コンテンツネットワーク化）
• 期間（日別、週別、月別…、後は曜日別など）
• デバイス別（PCか携帯か、など）
• クリックタイプ（URLか、通話か。通話は、リンク先を電話番号にした場合かと思います）

広告は、分割はないです。これは残念なところですので、広告文ごとに分析するなら、広告グループとセットで運用するしかないですね。

キーワードは、広告グループのものに加えて「検索クエリのマッチタイプ」が加わります。InsideAdwordsにも書いてありますが、これはとても有用です。完全一致、フレーズ一致、部分一致のそれぞれに分けてパフォーマンスを見ることができるからです。

詳細は、実際にみなさんのアカウントでいじってもらうと面白さを感じ取ってもらえると思いますが、ひとまず私としておすすめのものを２つピックアップします

１．曜日別のアクセス

広告グループについて、日別や週別などのシーケンシャルなスパンの他に、曜日別にパフォーマンスを見ることができます。

日付系の解析は季節要因やイベント要因もあるので、なるべく母集団を大きくしないと危険です。また、長い期間を取ること自体もその間の広告グループ内の広告文やLPの内容を考えないと危険です。

ただ、シーケンシャルな分割だとほんとにそれが大事ですが、曜日の場合、月曜日だけ特別に広告を変えたりですとか、水曜日だけLPが違ったりなどはあまり無いかと思います。なので、そこまで影響は無いかなと（そういうことをやっているならもちろん別ですが）

それを踏まえた上で1年分くらいの期間で見ると、大体特定の広告グループが曜日ごとにどう変化しているかがわかります。トレンドとして。

例えば、うちの場合、

「日曜日はクリック数は少ないが、コンバージョン率は高い（検索母数が少ない分クリック数が少ないが、コンバージョンしてくれる人は、家でもサービスについて考えていて、日曜にゆっくり考えて申し込んでくれているのかもしれない。とすると、以外に個人事業主や非サラリーマン的商売の方が多いのかもしれない」

ですとか

「月曜日はクリック率も高くクリック数も多いが、コンバージョン率が悪い（月曜日は、みな週初のいろいろな処理で忙しく、最終決定に至るまでの時間がとれないかも？」

などの仮説が浮かびました。

それが正しいかは、今後のキャンペーンの結果を見ないといけませんが、ためしに

「月曜日のLPは、急いでいて、決定まで至らない人のために敷居の低い商材を前に出す」、ですとか「日曜日は、最後の一押しをするために、特典のようなオファーをつけるようにする」などを行うことができるかと思います。

２．検索クエリのマッチタイプ

これはInside Adwordsでもふれているのですが、ちょっと違った観点からです。

キーワードを素直に出稿していれば、きちんとアクションキーワードを出稿していれば、恐らくほとんどの場合、完全一致が最もコンバージョンが高くなるはずです。まじりっけなしのド直球のユーザだからです。なので、不景気の今、完全一致で全てのキーワードを出稿して、CPA重視の策をとっている場合も多いかと思います、

ただ、ときたま部分一致の方がパフォーマンスがいい場合があります。特に検索数が少ないキーワードの場合によくあります。

その場合、キーワードアドバイスツールでは「データ不足」になっている、何かのキーワード達でコンバージョンが取れている可能性があります。なので、その時は検索クエリを分析してコンバージョン率が高いキーワードをあぶり出し、そこに完全一致で出稿すると、さらによくなることがあります。

そういった、超ニッチキーワードを探すという意味で、この分割はまた一つ有効性を持っているかと思います。

おわりに

分割も面白いですが、フィルタも面白いです。ネットワークタブで特に有効だと思います。いかんせんあそこは数が多いので、クリック数がゼロだったりするものをインプレッションから除いていくなどしていく必要があるかと思います。

そんな楽しい「分割」機能をまだ使っていない私のような肩は、ぜひ使ってみてください。

いくつか検索してみると、以下の記事に当たりました。

　　▼Gaining Search Market Saturation - Organic and Paid | On-Coming Traffic

この記事によると、「Googleが検索結果として返すページにある10このオーガニック検索結果と11の有料リンクの合計22個をできるだけ独占すること」ということのようです。

とは言え、たくさんのページを作って上位表示させて、さらに複数アカウントでAdwordsに出稿…などを行い、全てのリンク先がほぼ同じページになってしまったら、それはGoogleとしても気分は良くないだろうと思います。

なので、色々と違う切り口でサイトを作り、最終的には同じサービスにたどり着かせるということなのかな、サテライトサイトの１パターンと捉えるのがいいのかなと考えていたら、まさに「サーチ・サテュレーション」のサービスを行っている会社がありました。

　　▼Search Saturation - When 1 placement isn't enough!

WebpageFXという、WEB制作からマーケティング、コンサルなど全般を手がけている会社が一つのサービスとして、やっているようです。しかも、この会社の独自のサービスだとか。

サイトにサンプルのキャプチャが載っています。

これを見ると、

• Adwordsは通常の方法で出稿、販売代理店なども使って埋める
• ローカル検索の部分は、会社及びその代理店などで埋める
• オーガニック部分は、メインサイト以外に、関連ブログ・Twitterのアカウント・Youtubeの動画トップ・プレスリリースサイトなどで埋め尽くす

といった力技の模様です。

それを実現するために、初期費用は$25,000、月額費用が$5,000、もう少し安いのもありますがなかなかの費用です。KW広告の費用はまた別だと思うので、月額は倍くらいいくかもしれませんね。

なんとも力技なサービスですが、提供する側としても維持管理が大変そうです。システムのサポートがないと人件費だけで月額もらってる費用が飛びそうです。

また、きちんと見込みがあり、それなりにビッグなキーワードでないと、費用隊効果は悪いのではという印象です。こういうのは目標として定めてインハウスでこつこつやったほうがいいんじゃないかな、と思います。

サイトAとサイトBを見比べると、一見サイトAの方が良いサイトに見えます。

　『サイトA』
　　PV　：3,000/日
　　Visit：1,000/日
　　直帰率（トップページ）：50%


　『サイトB』
　　PV　：2,500/日
　　Visit：1,000/日
　　直帰率（トップページ）：75%

ややこしくなるので、前提として、ほとんどのユーザはサイトのトップページからランディングしてくるとします。
ないし、トップページからランディングしてきたユーザを対象にアドバンストセグメントなどでフィルタリングしたデータだとします。

この場合、サイトAの平均PVは「3.00」それに対してサイトBは「2.50」。
しかも直帰率もサイトAの方が断然良いので、サイトAの方がパフォーマンスが良いということになります。広告などでスプリットテストをしているなら、Aを取ることになると思います。

直帰しなかったアクセス者だけに目を向けてみる

ただ、ここで目線を変えて、直帰せずに残ったユーザにだけ目を向けてみます。

そのユーザがどのような動きかというと、直帰したユーザはPVとしては「１」なので

　『サイトA』
　　PV　：3,000/日
　　Visit：1,000/日
　　直帰率（トップページ）：50%　＝　500visit

　　残アクセス者のPV　：2,500/日
　　残アクセス者のVisit：　500/日

　　 → 残アクセス者の平均PV　＝　「5.00」


　『サイトB』
　　PV　：2,500/日
　　Visit：1,000/日
　　直帰率（トップページ）：75%　＝　750visit

　　残アクセス者のPV　：1,750/日
　　残アクセス者のVisit：　250/日

　　 → 残アクセス者の平均PV　＝　「7.00」

となり、残ったアクセス者の動きとしては「サイトB」の方がいい、ということになります。

問題がどこにあるのか？を知るために

上の数字は、言い換えれば、

　「サイトA」は、トップで直帰しなかったアクセス者は追加で4ページ見てくれた。
　「サイトB」は、トップで直帰しなかったアクセス者は追加で6ページ見てくれた。

ということです。個人的にこれを「追加PV」と呼んで、指標にしています。

この数字は、全体の平均PVと合わせると、サイトの問題がどこにあるかの箇所の絞り込みに有用です。

サイトのパフォーマンスとして、一番最初の集客の部分に焦点をあてると、ざっくりと

「集客がうまくいっているか」→「集めたユーザはターゲットとして狙っているユーザか」→「サイトのコンテンツはターゲットの心に響いているか」

といった流れがあります。

これを先ほどの二つのサイトに当てはめると、例えば、今度の改善点として、

　・サイトAは「ターゲットユーザはそれなりに集められているが、サイト内のコンテンツに魅力がまだ少ない、従ってコンテンツの充実が次の課題では」

　・サイトBは「ターゲットユーザを集められていないが、サイト内のコンテンツはターゲットユーザにとって魅力的になっている、従って集客のやり方を変えて適切なアクセスを集めることが次の課題では」

といった仮説がざっくりと立てられます。

そうしたら、後は他の指標（アクセスKWごとの動きとか）などを見ながら、ドリルダウンしていけば良いと思います。

もちろんこの例は、かなり大雑把で、実際にはもっともっと色々な要素が出てくるのでそれらを考慮しながら行わなければいけないです。

アクセス解析が出す情報を加工すると、もっと面白い数字が出る

ただ単純にアクセス解析ツールがダッシュボードに出しくれる情報だけを見るのではなくて、それを元に数字を加工して行くと、また有用な情報が見えてきます。

その一つの例として、今回「追加PV」の話を出してみました。

みなさんも、面白い指標があったら教えてくださいっ。

その他にも便利な機能がSEM Toolsには

他にもいろいろな機能がSEM Toolsにはついています（ツールバー形式です）

例えば「Link Checker」はTwitterなどでよく見かけるbit.lyなどの短縮URLを回答して見せてくれます。怪しいURLをチェックするのに役立つかもしれません。

後は「Keyword Typos」も面白いです。入力したキーワードのTypo（タイプミス）を教えてくれます。日本語には対応していないのが残念ですが…。例えば「HomePage」ですと「Himepage , Hlmepage , Hpmepage , Honepage , Hokepage , Hojepage , Homeoage , Homelage, Homepsge, Homepzge, Homepqge, Homepare, Homepane, Homepate, Homepahe」が出てきます。単純にキーボード上で打ち間違えやすいキーから考えて生成しているようですね。

こちらのMicrosoftの「Keyword Mutation Detection: Keyword Research: adCenter Labs」は、実際の検索結果のデータを下にして、ミススペルと思われるキーワードを出してくれます。やはり日本語は通じませんがこちらの方がマーケティング的には有用ですね。

やってみると、いろいろ足りない部分が見えてくるので、なんとなくGoogle Analyticsを使っていてもう少しうまく使えないかなぁというような方は、良い機会になるんじゃないかなと思います。

私自身も、事前学習の段階からこの辺もっと深掘りできるなとか、こんなことできたんだ、こんなこと決まってたんだ（商標とか商標とか商標とか）といった気づきがたくさんありました。

Google Analytics Individual Qualification Certificateの方は、希望者は名前を公開することができます。資格の性格上隠すものでもないとおもうので、非公開の人がいないと仮定すると、私で12人目です。（検索はこちらから）

12人って…あんまりみなさん興味ないのかな…そもそもの知名度の問題ですかね。結構妙なお墨付き感があっていいと思うのですが(^-^;

個人的には
　・載せたい情報を整理するのは、マインドマップ系
　・ブラウザ上での情報の整理は、サイトマップと、各ページのモックアップ作成

がいいと思っています。

mockingbirdでモックアップ作成

サイトマップはPowerPoint辺りで書くとして、なんか良いものないかな、と思っていたのはモックアップ作成ツールでした。

いろいろ、まったりと日々さがしていたのですが、最近良いなと思うものを見つけたのでご紹介です。

▼Mockingbird
　http://gomockingbird.com/

操作性がよく、かつ適度にシンプルです。

この、「適度にシンプル」なのが重要だと思っています。

モックアップは、装飾を排除しないと評価が難しくなる

今まではIllustratorを使っていたのですが、悩みがありました。なんというか、いろいろ色をつけたり形を整えたりしてしまうんです。楽しいので。

ただ、それをやっていると時間がかかるのはもちろん、なんとなく見た目でだまされてしまいます。
情報のグルーピングや見せる手法・インターフェイスなどを考えるのが本題なので、むしろ余分な装飾みたいな物は最初は無い方が、考えやすいんですよね。メインの画像の選定なんかも後々に回したほうがいい。

それに、このモックアップの段階できれいに見えない・分かりづらいなら、その後どんなに装飾を施してもいいものはなかなかできないんじゃないかと、経験上思っています。

逆に言えば、モックアップを作って、その段階ですでにシンプルなデザインとして成立してしまうようなところまでもっていけていると、いいものができます。特に瞬発力勝負なLPなどは、情報の構造がはっきりしていないとみんな直帰してしまうので重要かと思います。

MochinBirdはちょうどいいバランス

そういった、ある種、味付けからは隔離された世界を作るのに、このMochinBirdはプアすぎずリッチすぎずでとてもいいバランスだと思います。

しかも、アカウントを取れば作ったモックアップを他の人にも見てもらえるようになりますので、そこも便利です。
URLだけ送っておけば良いので、最新版の管理も楽ですね。いっぱいラフを作ると、どれが最新バージョンか分からず、話がかみ合わないこともあるので…

フォームのCRを上げようと思ったら、フォームだけ見ていても効果は薄い

その他のサイトでも結構ノウハウが見つかりましたが、それも含め大枠として気になるのことがあります。

それは、EFOをする時のノウハウのほとんどが、フォームそのものの設計の話だけで終わっていることです。

経験的にEFO、というかフォームを設置したページからのCRを上げるには、フォーム以外の要素がとても重要です。

もっと幅を広げれば、サイトのストーリーやゴールといった話になるので、あくまでフォームがあるページというくくりにします。
したとして、恐らく一番重要なのは

　　「お客さんが、フォームに入力したくなるようにすること」

で、その上で、次が

　　「お客さんが、フォームを入力するときに障害となるものを
　　　一つ一つ取り除いていくこと」

です。

EFOとして多くで語られている、例えば先ほどのページで言えば
　「１．入力項目がやたらと多い。」
　「２．必須・不必須が分かりにくい。」
　「１４．どこがエラーか分かりにくい。」
などの内容は、後者のテクニックの中の一つに過ぎないんじゃないかと思います。

極端な話、「これはすごいほしい！」と思っていれば、多少妙なフォームでも入力完了してくれますし、逆に、別に入れる必要性を感じてくれなければ、そもそもどんなに使いやすいフォームでも誰も入力してくれません。

まず、そもそも魅力的なものが、フォーム入力の向こうにあると思わせないといけないわけです。

フォームに入力したくなるようにするには

と、いう話をすると、「それってフォーム云々の話なんじゃなくて、営業戦術的な問題じゃないの」ということになりそうですが、そうでもないです。

多くのフォームは、なんらかのお返しを入力者に返しているはずです。
メールマガジン登録フォームなら、メールマガジンという情報を定期的に送るというオファーを返しています。
なにかのPDFダウンロード申し込みフォームなら、PDFですし、問い合わせフォームなら、質問に答えてあげるというメリットを返してあげています。

何かをちゃんとあげているはずです。オファーとフォームは大概の場合セットです。

ですので、EFOとしては、「フォーム入力のお返しのオファーを魅力的にする（≒フォームに入力したくなる）」という状態にすることが最も大事だと思っています。

例えば、家電メーカーのメールマガジンの登録フォームがあったとして、

これの説明が「弊社の新製品情報・お得な新着情報を定期的にお送りしています、ぜひご登録下さい」

という説明だけではなく

「このメールマガジンでは週に１回、家電製品をもっとカシコク使うポイントや、弊社の製品の意外と知られていない便利機能をお送りしています。配信解除はいつでも可能！今すぐご登録ください」

くらい書いてあげるだけで、随分コンバージョンは変わります。メルマガの内容ももちろん変えないといけないですが…。

ここで大事なのは「あくまで自社としてアピールしたい内容ではなく、お客さんが知りたい情報を前面に出した内容、打ち出しにすること」です。そして送るメールマガジンもそうすることです。

お客さんが入力する際の障害を取り除くこと

お客さんがぶつかる障害は、例えば問い合わせフォームなら大きく４つほどあります。メールマガジンなどの明確な返答が必要ない場合は、また違ってきますが一例として…

• 漠然とした悩みでしかないので、なんと問い合わせたらいいか分からない。（なんと言えばいいのか…）
• 自分が聞きたい内容が、本当にここで聞いていいような内容なのか分からない（もしかしたらお門違いかも…）
• きちんと対応してくれるかどうか分からないので、なんとなく腰が引けてしまう（どんな人が対応してくれるんだろ…）
• 入力の仕方が良く分からない、面倒くさい（どうやっていれるんだろ…）

これらをクリアすることが大事です。特に最初のほうです。

大概、お客さんの悩みは漠然としています。言葉にもできない人が多いです。「聞きたいんだけれど、どういったらいいか分からない」という状態です。

これに対して有効なのは、過去の質問の履歴を洗った上で、質問例を載せてあげることです。

質問の例を10個ほど載せてあげて、「例えばこんなことでお悩みなら、お気軽にご連絡ください」です。この時の質問例は多少リテラシー的に低めにしたほうが良いです。

続いて、問い合わせたい人が気にするのが「どういう人が対応してくれるか」です。

フォームという文字だけでのやり取りでも、ここは重要です。

これについては「対応してくれる担当者の笑顔の写真を入れる」「問い合わせしてくれた人で、後に顧客になってくれた人に、見込み客対応時のアンケートを書いてもらって、それを掲載するのも効果が高いと思います。

そんな感じで、ターゲットとして考えているお客さんが実際にフォームのページを開いている場面を想像して、不安に思いそうなところを一つづつ解消するとよいかと思います。

お客さんが納得してくれれば、入力項目は多少多くても大丈夫

先ほどの２点がクリアできていれば、入力項目などは大きな問題ではないです。ただ、きちんと対処すべきものであることも事実です。

先ほどのAxisさんの例を借りれば

---------

１．入力項目がやたらと多い。
→数自体は、第一義的には問題ではありません。お客さんに不信感を抱かせない範囲であれば。

２．必須・不必須が分かりにくい。
→記述は必要です。※印などは分かりづらいみたいで、日本語が一番反応が良かったです。後はサーバサイドではなくてクライアントサイドでの随時チェックがほしいですね。

３．個人情報の取り扱いが明記されていない。
４．SSLなどの暗号化がされていない。
→中小企業レベルまでですと、気にしている人はほとんどいないです。

５．情報が十分ではなく、怪しい感じがする。
６．デザインが悪く、怪しい感じがする。
→フォームというより、サイトそもそもの問題という気も…

７．入力した情報が次の画面から戻った時に消えていて、再入力の必要がある。
→これは致命的なので、JavaScriptでクライアントサイドでのチェックがいいかと思います。

８．文章が分かりにくい。(専門用語が多い)
→フォームに限らず、コンテンツはリテラシの低い人を意識的に想定したほうが良いかと。

９．カートが別ドメインに飛び、情報の取り扱いに不安を感じる。
→記入中は、記入に没頭しているので、あまりＵＲＬ欄などはみないかと思います。

１０.入力ステップが分かりにくく、いつになったら完了するのか分からない。
→フローチャートは必要ですね。

１１．アンケートなど余計なものが多い。
→「余計なもの」だと見せてしまっていることが問題で、項目数の問題ではないです。

１２．資料請求＝メルマガ登録、と強制的なものがある。
→よくないですね。少なくとも１つのフォームで１つ以上のアクションを求めるとＣＲがかなり落ちます。

１３．全角・半角の入力指示が細かい。
→これはＪＳでのチェックもさながら、サーバ側で内部的に吸収するのがベストですね。

１４．どこがエラーか分かりにくい。
→よくないです。

１５．フォーム前には明記されていなかった料金が発生する。
→ひどいです…ぼったくりです…

---------

細かいチューニングも、とても大事です。
フォーム入力後の対応フローも含めて、できるだけお客さんの負担を減らすようにするとＣＲは上がっていくと思いますよ。

そんな感じで、フォームとその周辺要素まで含めたものを対象にしないと、なかなかフォームのＣＲは上がらないと思います。

ですので、ＥＦＯは、フォーム以外の部分も含まれる概念なんじゃないかなぁと。

そんな取り留めの無い話でした。

ですので、詳細は特に触れません。海外SEOの鈴木謙一さんの記事が最高かと思いますので、こちらをぜひご覧ください。

▼これからはページ分割したセグメント単位のSEOで勝負！ | 海外SEO情報ブログ・メルマガ

検索エンジンは文書間の関係性を活用できる方向にも進んでほしい

個人的に気になっているのが、このセグメンテーションがどこまでいくかということです。

あんまり細かくなると、作るほうとしても利用者としても不便だなぁと。検索結果に、「あるページのこの部分」という単位で結果が出てきたら不便なイメージです（さすがにそれは無いと思いますが）

結論から言えば、ページをセグメント分けしてノイズを除いていく、一つのHTMLを分割して解析していく、という方向もさながら、その一方で、文書と文書の関係性というものにも考慮してもらいたいなと。

現在のSERPは基本的にページ単位で結果が表示されます。この検索クエリに対してはこのページがいいですよ、という形です。それは言い換えれば、クエリに対する情報の単位が今は「ページ」だということだと思います。

ただ、コンテンツはブログ的な記事みたいな一枚もの以外にもページモノの場合も多くあるわけです。
Illustrator的なものもあれば、QuarkExpress的なものも。

これは作り手としての立場ですが、その場合、その「ページもの」コンテンツ全体を、検索クエリに対して一つの単位としてみてもらいたいこともあります。特にあるコンテンツの内容が他のコンテンツの内容に重要な影響を与えている場合です。

素直にSEOをやってコンテンツの設計を行っていれば、一般的なKWならコンテンツの目次が一番上に自然とくるのですが、ロングテール系だったりすると、なかなか難しく。
苦肉の策として、文章の枕に「先にこっちを読んでね」ですとか、最低限のサマリをつけたりですとか、そういうことをしています。

ただ、やっぱりそういうのはほんとは無い方がいいなと。

入れるとしたら、コンテンツに書くのではなくて、文書情報として記載したい。

なので、現在metaタグでIndexやprevなどがありますが、これをまず検索結果上で有効活用してもらいたいということがあります。

将来的には、検索クエリに対して、ただのページだけではなく、ページが所属するコンテンツのトップやサイト全体のトップなど、そういった文書間情報がSERPに出るようになると良いなと思います。

サイトに情報を探しに来る人って、「このサイトに自分の求める情報がある！」と思った後は、「このサイトで自分が欲しい情報は、どこにどれだけあるんだろう、これで全部かな」というところに関心が行っていると経験上感じています。

そういうところのフォローにもなると思うんですよね(^-^

▼SEOmoz | How to Export Google Analytics Data to Excel via the API
　http://www.seomoz.org/blog/how-to-export-google-analytics-data-to-excel-via-the-api

インストールすると、Google Analyticsのタブが、Excelの上のリボンのところに出てきます。データはAPI経由です。

実は自宅が2003なのでまだ試していないので日本語が通じるかは分かりません。
ただ、個人的には日本語ってほとんど使わない（多分、ページタイトルの分析のところだけだと思いますし）ので、通らなくても別にいいかなと思います。

何が便利か

一般的にどうなのかは分からないのですが、私はGoogleAnalyticsのデータをカスタムレポートなどで見るだけでは調査したいことが調査しきれないことが多いです。

なので、いったんExcelでCSVに落として、そこから加工していろいろ比較したりしています。このやり方でいいと言えばいいのですが、何が大変かというと、CSVファイルが溜まっていくことと、その作業工数です。

「集計範囲を変える」「アドバンストセグメントを変える」などなど、少し変えただけで再度CSV吐き出し→データをきれいに→ソートしてうんちゃら、の繰り返しなので、途中で「あっ、ここも深堀すべきだった！」というときに正直萎えることが多いです。

でも、こうやってExcelから直結していればかなり改善します。もちろん、一番いい形はもっと先にあるのだと思いますが、かなり楽になります。

調査のボトルネックの一つにその準備がある

マーケ調査をしていると、特にWEB系では細かい数字をひたすらおっかけることになります。

そして、私のようにアナログにほぼ手動（それでもClickTracks時代よりは楽になったのですが…）でやっている場合は、その数字を作るまでがかなり大変です。お金をかけて開発すればいいのですが、要件等があいまいかつ、必要なアウトプットもころころ変わるので、なかなか難しいのが現状です。したがって手でやってます。

その状況ですと、もちろん時間もかかりますし、途中で「あっ、ここ深堀しておけばよかった！」というときに、また最初から…と思うと正直腰が引けることがあります。

質が下がってしまっていることは否めません。

マネジメントだけではなく、WEB系の調査でも、PDCAの話はよく語られます。ただ、意外と「Check」の工数が軽視されがちな印象があります。でも多分、「Check」ってバックエンドとして一番しっかりしてないといけないんじゃないかと思います。下手したらPlanやActに誤った評価をしてしまいます。

ですが、ここで「ざっと見たけど良くなってるからいいだろう、次行こう次」「予想よりうまくいかなかったけど、数字は嘘をつかないから仕方ないな…精査はともかくいったん元に戻そう」という風になって時間を取らなかったりすると、実は調査項目の計算式の誤りや、以前のデータの消しこみ忘れなどのせいで、おかしかっただけで実は…ということも起こりうります。っていうか起こしたことが何度あったことか。

特に失敗した経験は頭の中に長く残るので、悪かった場合は特に、ほんとに悪かったの？いいところはなかったの？というところまで含めてきちんと深堀した方がいいいと思います。

なので、このExcelはとてもうれしいです。結構前からでていたんですな…

Office2007に抵抗のない方でGoogle Analyticsをデータソースとして使っている方はぜひ使ってみてはどうでしょうか。

関連リンク

1. インストール方法など
2. 動作の解説ビデオ

機能的には正直IETesterの方が使い勝手はいいと思います。

ただ、オーバーレイ機能で重ねて見ることができるので、ピクセル単位での要求をしてくるクライアントさんに対しては便利かなと思います。エビデンスの作成という意味もこめて…

ちなみに、昔サブページを作った、某航空会社がそうでした。
仕様書もぎっちりPowerPointで作りこんであって、当時はNetscape vs InternetExplorer なブラウザ戦争だったので、スクリーンショットを取りながらTableをゴリゴリ組んでいた記憶があります。

ほとんど制作時間がそこで取られていたなぁという思い出です。

ブラウザの違いによる表示の違いがもしなかったら

もし、ブラウザの違いによる表示の違いがなかったら、言い換えれば複数のブラウザでチェックする必要がなくなったら、制作工数は劇的に減るはずです。

少なくとも、MacとWindowsで1つのブラウザでチェックすればOK、という次元になるだけでも相当変わるはずです。JavaScriptの解釈やCSSの解釈・実装状況まで含めて。

今のWeb界隈で、どうしても「物事を前にするめる何か」ではなく「今の何かに対するTips」というある種後ろ向きの情報の方が需要が高い、ないし興味を引いてしまうのは、個人的にとても切ないものを感じます。

ブラウザでの表示確認は、WEBサイトを受け取るお客さんとしては何の付加価値にもならない作業です。それだったら、そこをなんとかオミットして、JavaScriptのブラッシュアップだったり、サイトのコンセプトやアドバイスの時間を取ってあげたり。

…

しかし、それはそれとして、「Web Accessibility Toolbar」が早くIE8に対応してくれないか、心待ちにしている今日この頃です。HTMLやCSS関係は、IE8標準の開発者ツール（IE8標準機能のDeveloperTool（開発者ツール）が何気に便利：：[7korobi8oki.com]）でなんとかなるのですが、色弱の人への見え方や、ブラウザのリサイズなどで便利だったので。IE8に早く対応してくれないかな。

ターゲットとが、リテラシーが高く、新しいものに対しての親和性が強い顧客層であれば、メールの他にソーシャルメディアやRSS、マイクロブログ系も有用なチャネルとして、もしかしたらメールを超える場合もあるかもしれません。

しかし、多くのビジネスが相手にする顧客層は、基本的にコミュニケーションの手段はメールです。

さらに掘り下げれば、ローカルアプリのメールソフトです。設定されているメールアカウントは、プロバイダのメールアドレスです。ないし、オンライン系でもHotmailかYahoo!メール。Gmailはまだまだ少ない。なぜかというと、Outlookなどの一般的なメールソフトと使用概念が全然違うので、使い方が直感的に分かりづらいからです。

というわけで、私も、メールマーケティングはしばらく王道の座に座り続けることは確実だと思っています。

Rand氏のおすすめメールマーケティングフロー

ビデオの中で、Rand氏がホワイトボードを使って、おすすめのメールマーケティングの手法を説明してくれています。

仮に、あるサービスを販売することが最終目的だとします。
そのために見込み客を育てるツールとしてメールを使うとします。

今すぐ客も、もちろんいるはずですが、そういった人にメール購読を勧めても、むしろ「そんなことはいいから、仕様と料金で問題が無ければ後は買うから」ということで、大体見てくれません野で、そういう人には別の導線を用意したほうがいいですね。

抜粋すると以下のような内容でした。すでにノウハウを持っている方は知っている内容も多いかもしれませんが、これから始めようとしている方には、基本としてとてもいいと思います。

「１．将来的にサービスを使う可能性があるユーザが情報収集で使いそうなキーワード（Inforomation Query）でSEOやPPCを仕掛け、アクセスを集める。大前提として、リストを安易に買ったりしてはいけない。」

これはその通りだと思います。興味の無いユーザにメールを送っても、効果が無いばかりか、長期的に見ればブランド的にマイナスになる可能性もあります。

また、「見込み度のそれほど高くないユーザの見込み度を上げていく」という目的であるので、そういった情報収集レベルのユーザが入れそうな検索KWでアクセスを集める必要があります。

「２．魅力的なコンテンツを用意して、見せてあげる」

続いて、アクセスしてきた人達に、魅力的なコンテンツを見せることが必要です。

メールマーケティングではよくメールの内容などが主に説明されますが、個人的にはここが肝要だと感じています。

メールを登録しようと思うアクセス者は「登録すればもっといい情報が得られそう」「このくらいのコンテンツを用意して公開しているWebサイトなら、きっと登録しても損は無いだろう」と直感的に思えれば、メールを登録しようとしてくれます。

さらに、ここでの第1印象が、そのメールに対する扱いを変えます。盛り上がった気持ちで登録してくれれば、もしかしたらメールの振り分け登録までしてくれるかもしれません。人によっては、届かないときに電話までしてくれたりします（実際あります）

同様の理由で、メールがステップメール形式なら最初の１通がとても重要です。でないと配信停止の嵐、ないし読まれないで受信箱で新しいメールに押しながらされていくことになります。

「３．びっくりするようなオファーを無料であげる」

オファーはターゲット次第ですが、彼らが驚くようなものをメール登録のオファーとして掲げると反応が大きく上がります。不動産会社のサイトでしたら「失敗しない物件選びチェックシート」などがいいかもしれませんね。とは言えこれは最後の一押しです。

「４．売り込みでははないメールを送る」

メールマーケティングは、自然と顧客が問い合わせなりのアクションを起こさせるために徹することが肝要とのことです。こちらから売り込みに行くのは良くないということですね。

言い換えれば、あくまでマーケティングは、自社が喋りたい情報ではなくて、相手が聞きたい情報だけを載せることが大事、と言えるでしょうか。

「５．くりかえす」

とにかく反応が薄くても手を変え品を変え繰り返すことです。反応がある程度取れるところまできたらステップメールの仕組みを入れるなり、運用ルールなどを決めるなどして仕組みにしてぐるぐる回すのが大事です。

SEOmoz的コンバージョンレート

1000アクセス → 400人がコンテンツを見る → そのうち10%の40人がメール申し込んでくれる　→ そのうち半分がちゃんと読んでくれる。

メール購読のCRが大体4%くらいということです。
ただ、私の経験では、結構いいオファーを入れて、さらにSEOできちんとターゲットを集客できないと、多分１〜２％位に収まるんじゃないかと思います。４％はかなりいいです。

その他のおすすめ

コメント欄にもたくさんノウハウがあるので、ぜひ見てみてください。例えば「配信時間」「配信頻度」「表題」「コピーとメッセージ」の試行錯誤が必要、などです。

他にポイントがあるとすれば、フォームの項目の設計やオファーの見せ方、大義名分あたりがキーだと思います。

First, there are strange additions to permalinks, such as example.com/category/post-title/%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/. The keywords are “eval” and “base64_decode.”

http://www.techcrunch.com/2009/09/05/security-threat-wordpress-under-attack/

適当な外部書き込みが出来るディレクトリに、base64_decode＋悪意のあるコードを埋め込んだエンコード文字列でリクエストをかけて、内部でphpファイルを作って乗っ取りをかけ、その後、隠れたAdminユーザを作って、wp-config.phpをいじって、例えばテンプレートを改ざんしたりするようです。

ざっと関連情報を見たところ、目的はさまざまなようですが、単純にテンプレートに自分のサイトへのリンクを張ってバックリンク稼ぎをするだけのものから、.htaccessを使って別のサイトに強制的に飛ばして、アクセス者の環境変数とか取ってうんちゃらしていくものまでさまざまな模様です。

IEのセキュリティホールと組み合わされたりしなければ、アクセスしてくる人にとってはそこまで脅威ではないですが管理者にとっては大変です。

攻撃例

実際に攻撃を受けた方のログがこれです、こういった流れも多いと。

1. Others に対して書き込み権限を与えてあるディレクトリに、include_once() の http ハンドラを使用してロシアのサイトに接続するよう記述された php ファイルを作成する。（ファイル名はいくつかのパターンがありますが、system.php config.php など、他の PHP ファイルに紛れ込むようなファイル名が付けられています）

2. Others に対して書き込み権限を与えてあるディレクトリに、.htaccess を作成し、1 で設置されたファイルに誘導しようとする。

3. Others に対して書き込み権限を与えてある、既存の拡張子が .php のファイルに対して、1 と同様の内容を追記する。

4. Others に対して書き込み権限を与えてある、既存の拡張子が .html .htm のファイルに対して、外部参照 JavaScript でロシアのサイトに接続するよう追記する。

Rhein-strasse » Blog Archive » Web サイトが攻撃を受けました

Wordpressのプラグインにも

しかし、ちょっと本題からはずれるのですがWordPressってPluginを追加して自分好みにカスタマイズしていこうというイメージが、MovableTypeに比べて強いと思います。そのためか、Pluginに同様の仕組みが入っていた！というようなものもあるみたいですね。

下の記事で紹介されている「Twitter Poster」というプラグインは、広告部分をbase64_decodeで出力していたために問題になっています。

▼WordPressとeval(base64_decode(…)) - ExP10S10nZ's BLΩG
　http://blog.sabaitiba.com/2009/03/12/905.html?wscr=1600x1200

強い対応策を打つことは現実的には、なかなか難しそうですね。期待できるとすれば、Googleが何かWordpress.orgと個別に話をしていないかな、とか。WPのクラッキングにしても、プラグインにしてもリンクを獲得することが目的のものが大半のようなので

Wordpressの裾野が広がっているので…

Worpress側がどんなに「バージョンアップしてください」「こういうことはしないでください」と言っても、大半のユーザやっぱり、めんどくさかったり、とりあえず入れて使っているだけでそもそもそういう情報を気にしていない、というものだと思います。MTの2.6とか使っている人もまだまだいます。少なくとも自分の周りにすでに数名。

WordPressは自分で入れるから自己責任と言うのは正論ですが、それはそれとして現状打開としてなんらかの仕組みを入れないと、いたちごっこは続きそうです。

自動アップデートの仕組みを入れるとか、あるいは少なくともWordpressのDLをする際に、自分でセキュリティなどに対応できない人はSaaS型(ASP型)を選ぶように誘導するなどはやった方が良いのではと。

余談

逆に言うと、「セキュリティ関連は放って置いても安心」なサーバインストール型のCMSが出たら、WPに対して一部のセグメントに対してはシェアを取れるのではと思います。

MTもその辺を保障しているわけではないですし、SaaS型(ASP型)にすると制限がきついからサーバインストール型にしたいけど運用コストはかけたくない、っていう層は確実にあると思うんです。

これからWordPressなどをつきくずしてくとしたら、そのセグメントを橋頭堡にするのも一つの道としてありだなと思います。

前者だとしたら、Amazonの「買いたいものリスト」のような機能を携帯用のショッピングートに入れて、一画面で簡単に比較できるようにすることが効果的では、と思いますし、

後者なら、リピート客として囲い込むために、例えば

「購入後に他の人気商品を提示して興味を持ってもらう」→「それをリアルの世界で情報収集してもらう」 →「その商品を買ってもらう」→「さらに人気商品を」…っていうサイクルに持っていったり、単純にメルマガに誘導する方に力をいれた方がよいか。

で、個人的には、「商品を買い物かごに入れた後すぐに購入する」や「商品を買い物かごに入れた後数量・サイズを変更する」人の割合が携帯ユーザはかなり低いことを見ると、後者かなという印象です。

携帯ってやっぱり情報の一覧性に乏しいですから、実際に自分が欲しいものの情報は雑誌だったり路面で集めていると思うんです。

イメージ的には、子供を学校に送り出して一通り家事を終えた主婦の方が、夕方にファッション雑誌片手に携帯で検索して、よさげなところで買っているのでは？と。

最後のレジの部分だけ携帯ECサイトに移動しているイメージです。

逆にPCだと、ECサイトそのものでかなりショッピングできますので、その分いろいろ商品を手にとってとりあえず買い物かごに入れて最後に調整、みたいなことをしているのだと思います。

というわけで、携帯向けの携帯ECサイトはまずは顧客化に重点を置くのがいいかなと。

とは言え認知してもらうために集客も必要です。

ですが、顧客化の仕組みを整えた後にPPC広告なり、リアルへの出稿なりをしないと、投資対効果は期待通りにはならないと思います。

…

ちなみに、全然自分は携帯では物を買いません。横に並べて比較できないと気がすまないようで…

そして、やっぱり着て見て触ってすることが楽しいですので、実店舗へ行きます(^-^

売り手は「ショッピングカート」、買い手は「買い物かご」と呼ぶ

呼び名として浸透しているのは「買い物かご」「ショッピングカート」である、というのはGoogleのキーワードアドバイスツールの結果と違っていて面白いです。

お客さん側と制作サイド・売り手サイドの用語、ひいては意識のズレがあるのでは。

IMJの調査ですと、もっともしっくりくる名前は

• 買い物かご　：　61.5％
• ショッピングカート　：　26.2%

ですが、キーワードアドバイスツールでは

• ショッピングカート　：　74000件/月
• 買い物かご　：　6600件/月
• 買い物カゴ　：　2900件/月

です。

Googleで「買い物かご」などで検索する人は、ECサイトだったりを作りたい人ですよね（消費者は「秋物　激安　買い物かご」なんて検索はしないので）
つまり作り手側は、この機能なら「ショッピングカート」だと考えているわけです。

でもお客さんはIMJの調査によると、「買い物かご」だと考えているようです。

こういった、売る側と買う側の認識のずれが、いろんな所にちくちくと響いてくるんですよね。
お客さんの反応といった面もそうですし、提供してるサービスの使い勝手と言う面でも。

オンラインサービス提供者は定期的にインターフェイスの無作為テストを行わないといけないなと思いました。

GoogleAdwordsのウェブサイトオプティマイザーみたいなことを。

初心者が多いブログサービスなんか特に。
計測のあたりをクリアできれば、サービスの持続的な品質向上に役立つかと思います。

というか、FromAはまだしも、anに載っているのはかなりの割合でそうだったように記憶しています

FromAはと言えば、光通信とかクレイフィッシュ系が多かったような、違ったような。

FindJobは、そういうのは無いですが、実は人材派遣会社ですというところが多かったような違ったような。今でもそうですが。

…

それはともかくとして、ある日面接に行った事務所もアダルト系。

ただそこの人と妙に話が弾んでしまって、面接そっちのけでアダルトサイトの運営の話を聞かせてもらえました。面白かったです。

超激戦区かつ差別化が難しいかつネタ元が限られてる戦場なので、どの運営会社もすごくマーケティングに頭をぐるぐるさせていました。その事務所もしかり。

その事務所での話の中で、当時の自分にとって衝撃だったネタが一つあるのでご紹介します。

とは言っても今考えると、そりゃそうだよなぁな感じなのですが、当時はほんとに衝撃でした。

面接のときの課題、というかテストとして、サイトを見せられました。

一般人の女の子が趣味で自分のうっふんな（死語）写真を載せたりしているという設定のサイトでした。最終的には会員サイトか何かに誘導して有料会員になってもらうというゴールです。

同じ趣旨のサイトを二つ見せられました。

一つはとても整ったサイト、もう一つは今で言うとホームページビルダー的な、デザイン的に微妙なサイトでした。

どちらが人気があると思う？と聞かれて、自分は迷い無く整ったサイトと答えました。

デザインクオリティが高い方が好まれるだろうと思っていました。

正解は、そうですね、逆でした。素人くさいデザインの方でした。

だって、素人が作ってるサイト（っていう設定）だもん、と言われた時、長いため息がでました。

素人くさ過ぎず、プロっぽ過ぎず、という微妙なバランスを維持することが成功の秘訣だと、言ってました。何となく職人魂を感じました。そして、面接は落ちました。

とは言え今はこれ、簡単にできちゃうんですよね。良くも悪くも。

適当に無料ブログ借りて、文章はほんとに女の子に書かせてしまえば、放っておいても適度に素人くさいサイトができてしまいます。

なぜなら、たくさんの一般人が無料ブログを使うようになったことで、無料ブログを使っていれば一般人だって言う前提がなんとなく作られているからです。

昔はこんな前提なんて無かったから、素人くささを研究して、素人っぽさを試行錯誤して表現するということが必要でした。さっきの事務所みたいに。

そう思うと、素人を騙ってるアダルトサイトにとって、無料ブログの発展は結構な衝撃だったんだろうなぁと思います。職人の仕事じゃなくなってしまった。

と、そんなことを昔の名刺を整理していたら思いました。

しかし、今のところDreamWeaverから直でXML以外で出力する方法・ツールが分かりません…orz

というわけで、もうDWから直で出すのギブアップしました。
（ご存知でしたらどなたかぜひ…！）

それならということで、XMLを別形式に変換する方向で探したらありました。

　　ExmlEditer (Excel XML編集ツール)
　　http://www.vector.co.jp/soft/win95/net/se291321.html

XMLを読み込んで、こんな風に整形してくれます。後は、要素の属性（mm_reportlocationあたり）でフィルタすれば、ファイル名だけ抜き出せるます。

これで自分はかなり楽になりました。

ちなみにDreamWeaverが吐き出すXML（ResultsReport.xml）は

mm_reportの中にmm_reportitemがザーッと並んでいて

• mm_file　：　サイト内でのファイルpath
• mm_displaystr　：　DWの検索結果一覧に出力された文字列
• mm_data　：　ファイルの情報（何文字目から何文字目まで検索or置換したか、ファイルのWINDOWS上でのPathなど

といったものが並んでいます。

本当はXSLあたりを使うのが正当かと思いますが、とりあえず業務上はこれでOKかなと思っています。

他の「バリデート」あたりの項目にも応用できるかも。

DreamWeaverがらみ

DreamWeaverだとテンプレート機能が有名ですが、自分はあまり使いません。
多分それほどきっちり仕様が固めてサイトを制作しないからだと思います。
それより柔軟性とかスピード重視です。

そうなると便利なのが、「検索および置換」です（ふつーですいませんorz）。

その中でも「正規表現を使用」と、検索の「特定のタグ」が便利です。

「正規表現」

DreamWeaverでは検索と置換に正規表現を使えます。

もちろん"()"で囲んだ部分を$1などで参照できます。

DreamWeaverは標準で複数行の検索と置換に対応してるので、正規表現と組み合わせるとかなり楽にバッチ処理できます。

例えば、現在地表示のクラス名がついているdivタグの中のテキストをtitleタグの頭につけるとか。

いったんサイト全体バックアップを取ってからやれば安心ですし。
なにげに重宝しています。

→公式ヘルプはこちら

「特定のタグ」

「検索および置換」ダイアログの「検索（E)」には

• ソースコード
• テキスト
• テキスト（高度）
• 特定のタグ

の4種類があります。

特にこの中の「特定のタグ」が便利です。

あるclass属性を持つタグを一気に消したり、特定のタグを内容そのままで一気に別のタグに置換したりできます。古いHTMLファイルを一気にクリーンナップするのにも便利です。

「特定のタグ」機能については、あんまりいいドキュメントが見つからなかったのですが、いじってみればきっとすぐなじむのでは、と。何かいいのがあったら掲載します。

ひとまず見つかったのは

• Adobe - デベロッパーセンター : Dreamweaver使いのための「生活に役立つ小ネタ集」
• 【Dreamweaver】特定のタグの検索｜｜memorandum

です。

一括検索結果を記録：JGREP

つづいてJGREPです。名前が示すとおり、文字列の一括検索ソフトです。

一括で検索するだけだったらDreamWeaverの方がいいじゃん、複数行でも検索できるし、と思うかもしれませんが、DreamWeaverのそれには大きな欠点があります。

それは、検索結果を保存できないこと orz
（本当に方法ないんですかね…もしどなたかご存知だったら教えてください）

仕事なんかだと、サイトの変更箇所を洗い出して資料として提出するなんていうことが往々にしてありますよね。

そういう時はエクセルなんかで修正箇所を一覧にしたいのですが、いかんせんDWでは検索結果を保存できません。

なのでJGREPを使います。

使い方はJGREPのサイトやらを見ていただくとして、これを使うとWindowsファイルシステムのパスと、検索文字列の前後の文字列がCSVで保存できます。

後はエクセルで￥を／に変換したりしてURLに仕立て上げれば、参照可能な資料の完成です。

ファイルを一括作成

サイトが巨大だと、作成するHTMLドキュメントの量も莫大になります。
特にPHPとかASPでパーツを細分化して組み合わせて作る場合、準備としての空ファイルの作成だけでも大変です。

そういうときには、以下の二つのソフトの組み合わせが便利です。

１．bpTran　：　CSVからファイルを自動生成

CSV形式のデータファイルとテンプレートファイルの組み合わせで、ファイルを一括で生成できるソフトです。世間ではバルク的アフィリエイトサイト作成なんかに使われていることが多いようです。

それはともかく、これを使えば一気にファイルを作成できます。また、テンプレートファイルを編集すれば、内容もCSVを元に一括生成できます。

このソフトを使う前提で、サイトの構成をあらかじめCSVで作成しておき、変更が入るたびに毎回再書き出しというやり方もいいのではと。MTで言うRebuildみたいな感じで。

Flexible Renamer ：　ファイル名を一括変更

こちらはファイル名を一括で変えられるソフトです。
一括変更後のプレビューができるのがとても便利です。

えいやっと一括で変えてみたら、全然変わっていなかったり、おかしくなっていたり、しかも不可逆的におかしくなっていたり…という悲劇が避けられます。

さきほどのbpTraneで同じようなことはできますが、あれは要はもう一回出力して上書きしているだけなので

• そもそもbpTranを通して作ったものではない
• 作ったんだけどbpTranを通さない形で手がかなり入っていて、もはやbpTranで再構築すると大変なことになる

場合には無力です。

FlexibleRenamerは単にファイル名を変えるだけなので、難しいことを考えずにファイル名の一括変更ができます。

PHPやASPのパーツファイルのディレクトリ構成やネーミングルールが土壇場で変更になったりしても、「DreamWeaverでファイル内のパスやらを一括変更」「FlexibleRenamerでファイル名やらを一括変更」すれば、かなり楽になるのではと思います。

というわけで

ばらばらっと、自分が利用してる機能やらソフトを紹介してみました。
これで単純作業の工数が少しでも減れば幸いです。
そして空いた時間でクオリティアップ or 睡眠…したいですなぁ…。

IE7同封のVirtualPC用イメージファイルの準備

まず、Virtual PC 2007＋InternetExplorer7、InternetExplorer6のイメージファイルを落とします。これを使ってVirtualPCでXPをブートします。一番下の方の「IE6_VPC.EXE」か「IE7_VPC.EXE」が、そうです。IE7の方を選べば、すでにIE7が入った状態で後々起動してくれます。
Download details: IE App Compat VHD

実行すると中身が出てきます。途中で期限が今年の12月7日までだよ！といわれます。

そのまま進めて、vhdという拡張子のファイルができたらOKです。

VirtualPC2007のインストール

続いてVirtualPC本体がないとダメです。これは以下のサイトからダウンロード。無償です。
http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=04d26402-3199-48a3-afa2-2dc0b40a73b6

事実上昔はMac専用だったVirtualPCが今は無償とは…。
Connectix社が作ってましたねぇ。マイクロソフトに吸収されてしまいました。
ちなみに当時はSoftWindowsなんていう対抗馬が居ましたが、結局OSXに対応できずに消え去ってしまいました。懐かしい。

さてさてちなみに、VirtualPC内で動かすOSによって推奨スペックが違います。こんな感じ。

• Windows 98 Second Edition Mem:64 MB / HD:500 MB


• Windows 2000 Professional Mem:96 MB / HD:2 GB


• Windows XP Professional Mem:128 MB / HD:2 GB


• Windows Vista Enterprise Mem:512 MB / HD:15 GB

なんかVistaだけ格が違う…

要求スペックの詳細はこちら
→http://www.microsoft.com/windows/downloads/virtualpc/sysreq.mspx

インストールは特に問題なく進むと思います。
メモリーは迷いましたがとりあえず512MBにしたところ、現在ブラウジング用途だけですが全く快適です。

そしてインストールの最後で、さっき解凍しておいたvhdファイルを指定します。これでXPが起動します。
ただし、英語版です。

CPUは起動マシンのCPU、メモリは設定した容量が出ます。
そしてIE7入りならデスクトップにIE7があり、すんなり起動します。こんなん。

InternetExplorer7の日本語化

IEは最初は英語しか表示できませんが、右クリックからエンコーディングで「Japanese」を選ぶと、「LanguagePackのインストールをするので、XPのCDを入れてください」と求められます。

ひとまずこのマシンのCDを入れてみたところ（これはもしかしたらライセンス的にまずい？）、いくつか足りないファイルをスキップしたものの無事完了。

再起動したら、とりあえず日本語表示ができました。
これで表示確認には必要十分かと思います。

ちなみにPentium4 3.2GBですがタスクマネージャ上ではそれほどCPU使ってないのですが、どうも動かしているとファンが回りっぱなしです。なんだろ。

VirtualPC、色々応用が利きそうで面白いのでもっといじってみたいですね。
検索するとLinux系入れたりしている人が多い模様です。

Vistaの人がきちんとライセンス買って、XPや2kを入れるのもいいかも？
パフォーマンスがどれくらい落ちるかがネックでしょうか。

Macの時は相当落ちたなぁ…。G4-733で、PenIIIの500MBもなかったような…。

■関連サイト
マイクロソフト Virtual PC 2007（公式）

Virtual PC & SoftWindows（Mac時代のベンチが載ってます）

Flashの容量をどれくらいにすると、だいたい何割くらいの人に、広告主としては一番見て欲しい「スーパーバナーMega（Flash）」を見てもらえるかは

　http://yac.yahoo.co.jp/download/megarate.pdf

に簡単なグラフがあります。

一応広告自体は、「スーパーバナーMega（Flash）」は、1フレーム目30KBでswfファイル自体は1.8MBまで、アニメーションは30秒以内、フレームレートは30fps以内という制限になっています。

しかし、だからと言って1.8MBギリギリで制作すると、基準は1フレーム目のファイルサイズなので一概には言えませんが、さっきのグラフによると25％以下の人にしか見てもらえず、ほとんどの人にはその下の「スーパーバナーMega（ミドルFlash）」が表示されることになります。これはかなり痛いです。

なぜ痛いかと言うと、二つ目の「スーパーバナーMega（ミドルFlash）」は、恐ろしく制限がきついので、なかなか望むものが作れないからです。

「スーパーバナーMega（ミドルFlash）」の制限は、"ファイルサイズ12KB以上15KB以内"です。MBじゃないです。

15KB以内でFlashを作るのは、かなり割り切ってもともとのFlashに鉈をふらないと、結構きついです（きつかった）

三つ目の代替画像も容量が15KB以内なので、728×90pxの画像としてはかなりきつい。JPEGではまず無理ではないかと。

自分は背景をイラスト調に加工した後に、GIFで24色位でまとめてなんとかしのぎましたが、ものによっては全然別のデザインを起こさないとダメかもですね。

また、その他にもFlashには以下のような制約があります。

　　・互換性はFlashPlayer6以上
　　・フォントは全て分解してグラフィック化
　　・単純ループは不可。
　　・ムービーの圧縮は使用不可
　　・ClickTagを埋め込む必要がある。
　　・外部参照のデータを呼び込むActionScriptは禁止

詳しくは、Yahoo!のAd Creativeという広告主が見るサイトをご覧下さいませ。
　　→Yahoo! Japan Ad Creative

ちなみにClickTagちゅうのはこういうヤツです。

on(release) {
　　　if ((clickTAG.substr(0, 5) == "http:") or (clickTAG.substr(0, 6) == "https:")) {
　　　　　　getURL(clickTAG, targetTAG);
　　　}
}

<param name="movie" value="sample.swf?clickTAG=http://yahoo.co.jp/">
<embed srv="sanple.swf?clickTAG=http://yahoo.co.jp/">

と書いておけば、そこにジャンプするようになります。Flashの中身をいじらずにリンク先を変更できるので便利ですね。

この辺の資料が後から来たので、二度手間になってしまいました…。
バナー広告だからと言って十把一絡に甘く見るといかんですな…。

The report finds, among other things, that the majority of people browse maximized or very close to it. That Mac user have bigger screens, but their browser are the same size as on any other platform. And, in order to support 95% of your visitors, you need to design for a maximum size of 776x424px.

ほとんどの人が最大化か、それに近いサイズまでブラウザを広げているようです。また、Macユーザは大きいディスプレイを持っていることがおおいが、ブラウザ自体のサイズは他のプラットホームとあまり変わらないと。

そして、95%のユーザをカバーするには、776x424pxのサイズにしておけばいいそうです。縦幅に関しては、一目で目に入る高さですね。デザインと言うよりはマーケ的に気になるとこですな。

ちなみに測定法はこの辺のプロパティからです。
　Baekdal|TEST - Browser screen sizes

さらに詳しい説明はこのムービーから。
　Actual Browser Sizes - the Movie - Baekdal.com

前回の結果とほぼ同じですね。参考にさせていただきまぅ。
特に縦幅の情報は貴重だ…。

他にも、OSごとの最大化割合とか、面白いデータが揃ってます。デザイナーな方もディレクターの人も是非。
　

この記事では一ヶ月集計とのこと。

結果としては

The size of the browser's content area. The most common browser width is 1008px, and the most common height is 600px.

で、幅は1008px、高さは600pxにピークがきているようです。
記事の方にグラフが載っているのでそちらをどうぞ。
　＃ちなみにこれは、全ての解像度のユーザを対象にした結果です。
　＃640×480から、1920×1400等の大きいモニタ使用者まで一括で集計しています。
　
　

また、どのくらいの人が最大化しているかのグラフも載っています。
例えば、幅800pxの人は約90%が最大化。1280pxでは70%超が最大化、1600pxの人は、50%弱の人が最大化しているようです。

モニターが大きくなっても、あまりブラウザ自体の大きさは変えない傾向にあるようです。

大体のWebサイトがその辺りに最適化されているせいですかね。それとも、小さめのモニターを使っていた時代の慣れが関係しているのでしょうか。

そして、この辺りのデータの対応関係から導き出された、Webサイトの最適値は

e.g. if you want to support 90% of you visitors with a fluid layout, you need to make it work between 784x432px and 1268x896px. Similarly, supporting 90% of your visitors with fixed layout means fitting the design within 800x512px.

リキッドレイアウトを採用しているなら"784x432px〜1268x896px"に対応できるデザインであれば95％のユーザはカバーできる。フィックスなデザインをしているなら、800x512px以内にすれば95％のユーザをカバーできる、とのことです。

なるほど。

ちなみに値をどうやって取っているかはこのあたりをどうぞ。
http://www.baekdal.com/test/screen.asp

また、類似の調査をしている人もいました。
うう、フランス語かぁ…。

http://www.gwix.net/web_gwix/article.asp?filID=303
http://www.gwix.net/web_gwix/article.asp?filID=300
http://www.gwix.net/web_gwix/article.asp?filID=286

<h1><span>タイトル</span></h1>

としてマークアップして、cssでh1の背景に従来の画像を出し、さらにh1の中のspanの内容を見えないところに配置するだけです。

h1
　　{
　　　　background: url(header_img.gif) no-repeat;
　　　　width : 768px ;
　　　　height : 200px ;
　　}

h1 span
　　{
　　　　position: absolute;
　　　　left:-2000px;
　　}

という感じで。
spanが気になる人はspanを取って、h1に直接text-indent : -3000px とかでも良さそうです。

ところで、うちのサイトもそうですが、ページ全体を常にウィンドウの真ん中に表示するレイアウトは沢山使われています。

そしてそこに、別にcssで絶対配置したオブジェクトがあった場合、ウィンドウサイズによって絶対配置された要素とその他の要素の位置関係が変わってしまって参ったことはありませんか。

あれ、自分だけ…？('A`)
上から落ちてくるホバーウィンドウの時に悩んだんですが…。

とりあえずこれは、同じ記事の項目9番にも便利な例が載っています。

親要素の配置をrelativeにしておけば、その要素の中でabsolute指定された要素は、その親要素の原点を基準に配置することが出来ます。つまり、ウィンドウサイズが変わっても、相対的な位置関係が維持できます。

-------------

しかし、このevolt.orgでも、WinIEのサイズ計算のバグ対策が乗っていますが、これはDoctype宣言で標準モードにすれば良い気もするのですが、なぜ未だに語られるのでしょう。…何か罠が？

　＃追記05/07/25
　　　　WindowsIEの6より前ではDoctypeスイッチが効かないとのこと。うぅむ…。

それはともかく、CSS周りはまだまだ苦労するところが多いですね。
ちなみに、個人的には、WinIEの「floatさせた要素のmarginが2倍くらいになってしまう」というバグが一番今のところ悩みの種です。
他は個人的にはあんまり不満は無かったり。

どちらかというと、CSSをどう書けば、他の製作者に意味が伝わりやすいか、他の人が読みやすいか等の方が最近は気になります。

CSSもHTMLもフリーな記述形式なので、非常に製作者ごとに書き方に差が出やいですね。また、少し大きなサイトになれば、量も結構な量になります。

自分が書いたものでさえ、後で見ると意味不明だったり。
きちんとポリシーを作ってやろうと思っても、途中で辛くなってきて適当になってしまったり('A`)

…CSSの各セレクタごとにタグをつけて管理できるツールが切に欲しいです。適用箇所、作った意図、注意点、作成日などを参照できるようなものが。

-------------

ちなみに自分がやっていることは、
「全体に適用されるCSSと個別のページごとのCSSの分割」
「CSSへのコメント付け」
「全体を"header"、"menu"、"contents"、"footer"のような感じでIDを振り、セクションに分割。そしてその中の要素は特に必要が無くとも、それらを親とした、子孫セレクタとして記述」
「クラス名を考えてつけることをサボらない」

くらいでしょうか。

具体的な作り方

具体的な作り方としては。
デモページは以下のところにあるので、こちらのソースを見てもらうのが早いと思います。
http://www.456bereastreet.com/lab/flexible_custom_corners_borders/

単純化すると、
ひとまず以下のようにブロック要素を並べていきます。

一番外側（上のコードで言うfor_leftborder）と2番目のボックス（上のコードで言うfor_rightborder）は、入れ子になっていますが、役割的には同列です。
このサイトの場合、外側のボックスで

として、右寄せで縦線画像を配置し、内側のボックス（上のコードで言うfor_rightborder）にて、

として、左寄せで縦線の背景を置いています。paddingは、置く画像次第で変わる部分です。

そして、そのボックス（上のコードで言うfor_rightborder）の中に、並列に二つのブロック要素と、内容になるブロック要素を放り込みます。上で言う

の部分です。

最初の"box_top"は、フレキシブルな枠の上部を作っている部分です。

先ほどのサンプルページの"box.gif"と言う画像を、最初のbox_topにて右寄せで配置し、さらにその中のdivで、逆に左寄せで置くことで、横幅が可変になっています。（厳密に言えば、元の画像の幅までが限界ですが…1600pxあるので問題ないかと。）

同様のことを"box_bottom"にて行い、これで可変ボックスが完成です。

概観的にはこんな感じですが、外側のパディングの分を内側のマイナス指定のマージンで取り返したりと調整が行われていますので、ソースを見てもらった方が良いかと思います。CSSもヘッダーに書いてありますし。

1)仕事とそれ以外の時間をきっちり分けること。また、出来れば仕事空間も生活空間から切り離すこと。だらだらと一日中仕事をしないこと。

2)人脈を重視すること。顧客から顧客を紹介してもらうことも大切。また、一日家にいるのではなく、積極的に外部と関わりを持つようにすること。

3)支払いなどの方針をきっちりと決めておくこと。簡単にそれを曲げないこと。

4)プロジェクト管理と同じくらい、健康管理に気をつけること。

5)ネコを飼うこと。

という感じでした。
寝巻きで仕事をするな、とか、一日中机にかじりつくな、とか身に染みることがたくさんありました。

生活空間からすぐに仕事空間に移れるので、ケジメをつけるのが本当に難しいと思います。また、生活が苦しい時等は、何もしないこと休むことが辛くて、無理やり仕事や技術習得などの勉強をしたりしてしまって、精神的に厳しくなったり。

お金のやり取りなどは、非常に向き不向きがある分野だと思いますが、フリーならきっちりやらなければいけません。お金の話をいきなりするのは何か気まずいなー、と思ってしまう自分は非常に辛いです（なのでフリーはもはや諦めている訳ですが('A`)。

フリーできちんとやれる人は、中々いないと思います。そんなフリーの人達がフリーの人達に送るTipsが、Andy Budd::Blogography: Top Tips For Freelancersには詰まっていました。

その中から、気になった部分を抜き出してみました。
本当は全てコメントをつけた人の名前まで引っ張った方がいいのですが、ひとまず原文引用だけで今回は…。

-----------------------------------------------------------

At the end of each project ask the client for three colleagues who might benefit from your services, and be sure to follow up!

それぞれのプロジェクトの終わりに、あなたのサービスで手助けしてあげられそうな知り合いを三人紹介してくれるように頼んでみよう。そして、その３人に目を向けよう。

-----------------------------------------------------------

Get out there. There’s a tendency as a freelancer to stay in the office and just work, work, work. You need to get out in the community and be known.

外に出るべし。フリーの人は机にかじりつきがちですので。外に出て人と交わって知り合いを増やそう。

-----------------------------------------------------------

everything takes 3 times longer than your worst-case estimate

何においても、最悪の想定の3倍は時間がかかる。

-----------------------------------------------------------

it will always seem that your larger clients are deliberately trying to put you out of business by not paying you in a timely fashion despite really relying on you and your work

どんなにあなたとあなたの仕事を信頼してくれている大口顧客でも、きちんと支払いをしてくれずにあなたを倒産に追い込むことはあり得る。

-----------------------------------------------------------

Try to work always at the same time. From 9 to 5 or from 2 to 10 for example. Never work in a pyjama.

いつも同じ時間に規則正しく仕事をすること。9時〜5時とか、2時〜10時など。寝巻きで仕事をするのは絶対に止めた方が良い。

-----------------------------------------------------------

Phone, don’t email, especially if you’re contacting web agencies. They get hundreds of emails every week and even if you’re exactly what they’re looking for, unless you’re lucky they just won’t read your message.


特に相手が制作会社だったら、メールではなくて電話を使ったほうがいい。もし製作会社が探している人物にあなたが合致していたとしても、彼らは何百ものメールを毎週受け取っていて、幸運でもない限り目に入らないものだ。

-----------------------------------------------------------

Get your invoices, quotes, standard forms etc. in working order. Determine your payment (and any other) policies, inform clients of them up front, and stick to them

きちんと請求書の書式や雛形を作っておこう。また、支払いについてポリシーをきちんと決めておき、顧客に提示しておくこと。何か頼まれても、簡単にそれを変えてはいけない。

-----------------------------------------------------------

Set aside a work area, preferably in a seperate room which you can close the door on… In the corner of a lounge/dining room/bedroom etc is no good, because it’ll remind you of those stresses you have at work while you’re trying to relax

仕事をする部屋は、できればきちんと区別されたところが良い。居間や寝室の一部を使うのはあまり好ましくない。リラックスしたい時にも仕事中の緊張を引きずってしまうから。

-----------------------------------------------------------

The best advice I can give (which people have already mentioned here) is to remember why you’re doing what you do.

（みなさん気づいていることだとは思いますが）私は、何かをする時に、何故それをするのかを忘れないようにした方がいいと思います。

-----------------------------------------------------------

It’s an old chestnut, but it’s so true: you’re not going to look back on your life at 65 and think, “I should have worked more.” Make it a priority early on to make sure your social and personal life is as vibrant as your career, and stick to it.

これは、陳腐な話ですが、本質を突いていると思います。"65歳になって自分の人生を振り返って「もっと働かないといけない」等と思ってはいけません。もっと、自分の人生は自分のキャリアと同じくらい鮮やかで美しいものだと感じられるようにすることに重きを置いた方が良いです。

-----------------------------------------------------------

Start a monthly newsletter to your existing and potential clients to tell them about all the great work you’ve been doing.

At least once a month they will think of you, and there is a good chance you will have developed a solution for one client, and another client will realize they could use something just like that.

顧客や見込み客に対して、月に一度のニュースレターを出すのもいいと思う。

少なくとも月に一度は彼らにあなたのことやあなたの仕事を考えてもらえるし…（略）

-----------------------------------------------------------

こんな感じでした。
他にもたくさんのコメントが寄せられているので、是非原文をご覧下さい。

基本的にフリーというのは、厳しいですね。
フリーでないと出来ないことがあって、それがやりたくてフリーという流れでないと、色々と厳しい野ではないかと思います。

Webデザインの雑誌などを見ると、フリー志望の人がたくさんいるみたいですが、うぅむ、と思ってしまいます。

仕事が好きでやっているなら、面倒くさいことはまかせておける会社勤めのほうがいいと思うのですが…。いかがでしょうか。

1. あらかじめ決まっている締め切りの為、プロジェクトの遂行に極めて短い時間しか与えられていない。この状況では、プロジェクトを提案してきている人達は、前からその締め切りを知っていたが、計画を立てるのに予想より時間を使ってしまったため、制作の方に何とかしてほしいと思っていたりする。

2. プロジェクトを提案してきた客が、予算のことを考えていなさそうな時は、彼らはあまり下準備もせず、あまりそのプロジェクトを真剣に考えていないかもしれない。

3. 潜在的顧客が予算があることはほのめかすが、あまり具体的に語らない場合、しばしば客はあまりあなたを信用しておらず、予算を知らせると、それより高い額を請求されるんじゃないかと思っている。

4. 顧客が出来るだけ安価にサイトを作ってほしいとか、極めて少ない予算しか提示してこない場合がある。この場合、客はWebサイトを作る意義をあまり感じていないことがよくある。この状況では、自腹を切って予算を出しているような顧客は、極めて厳しい要求をし、大したことの無いものに、多くの期待をすることがありうる。

5. 顧客が許された予算より多くのものを期待する場合。この状況では顧客をなんとか満足させることすら難しいかもしれない。

6. コンペ形式でデザインを提示してほしいと言う場合。
   初期段階で、あなたがそのプロジェクトについてあまりよく知らない場合、トラブルの原因となりうる。こういった場合、コンペは制作者のスキルや履歴を見るというよりは、見た目の美しさを競うコンテストになるかもしれない。
   また、コンペに勝てなかった場合でも、あなたのデザインの一部が勝手に使われる可能性もある。

7. 潜在的顧客が、彼らの持ってきたプロジェクトにいくつの代理店が興味を示しているかを言わない場合。
   この場合、非常に多くの代理店にメールでコンタクトを取っている可能性があり、選ばれるのは一番安い代理店だったりする。

8. 非常に多くの代理店とコンペをすることがあるかもしれない。こういう場合は顧客はあまり下準備をしていないことがありうる。もしこのコンペが重い金銭的負担を代理店に期待している場合、勝利の可能性は制限されるだろう

9. 焦点の見えない打ち合わせ。大企業のプロジェクトには多くの投資家が絡んでいる。もし顧客の側でそのあたりをまとめられる人間がいなかった場合、こちらがわがそれをやらないといけない。このことは、プロジェクトをとても複雑なものにし、さらに間接的な費用の増大につながる。
   一つの納入業者なので、あなたにはその組織での発言権など無いため、それはとても難しいものになる。また、組織内の政争に巻きこまれる危険性もあるのだ。

10. 潜在的顧客が、プロジェクトに関してあなたに大した要求も伝えず、またこちらが出したデザインについての質問を満足させてくれるような時間すら与えてくれないことがある。
    もし顧客が、プロジェクトにこちらが提示した時間をかけることに、あまり乗り気でなかく、そのプロジェクトにあまり真剣ではなかったら、顧客はたくさんの代理店に声をかけていて、あなたと話す時間があまり無いか、あるいはただウィンドウショッピング感覚なのかもしれない。

原文は10 Bad Project Warning Signsから。
---------------------

確かに、顧客があまり制作に乗り気でない、また、顧客がWebサイトにあまり価値を感じていない場合は、いかに顧客に「こんなものに何でお金を払わないといけないんだ」と思われないようにするかに、凄く気を使います。

どういう風に受注してきたかに関わらず、なんとか顧客のモチベーションを上げていかないと、効果のでるWebサイトって出来ないですし。

しかし元記事にはコメントたくさんついてますね。まだ読んでませんが、面白いこと書いてありそうな予感。

また、Top Tips For Freelancers という記事では、ついこの間からフリーに鞍替えした筆者が、読者からTipsを募っています。現在52個のコメントがついてます。こっちも面白そうですねぇ。
というか52個もつくというのが凄い。

※エントリー作りました。フリーランスでやる時に知っておきたいTips集：：[7korobi8oki.com]

• Your website should be built with HTML code that is clean, well-organized, uncluttered, standards-compliant, and generally free of errors.

• Your site should use some form of template system, so that a change to a header, footer, menu, or other element shared across pages does not require the editing of each individual page.

• Your site should be displayed almost identically in any browser used by more than 1% of your target audience.

• Your site should degrade gracefully to text in non-graphical browsers (such as cell phones or some PDAs).

• Your site should be accessible to vision-impaired readers who may be using screen-reader software.

• Your site should be aesthetically pleasing, and its appearance should be appropriate to the message you want to convey.

• Your site should have a natural and logical information structure, so that the average user can quickly find what he or she is looking for.

• Your site should not contain any code or content that serves to exploit search engine algorithms in an attempt to receive higher search result rankings.
  

• 綺麗で整理された正しい標準のHTMLにて記述されていること。
• ヘッダーやフッター、メニューなどが変更しやすいようなテンプレート機能が用意されていること
• シェア1％のブラウザでも完璧に予想通りに見える。
• テキストブラウザでも見やすい。
• スクリーンリーダーでも扱いやすい。
• 美的に優れていて、サイトの伝えたいメッセージに沿ったデザインが施されている。
• 自然で論理的な情報アーキテクチャである。普通の人が簡単に目指すものを見つけることが出来る。
• SEOの痕跡をきちんと隠している。

というものです。
かなり言い尽くされたもはや「権利章典」という名前が合っているものです。

あまり現実的ではないし、色々と反論がなされています。かなりピュアな内容ですな。

実際制作をしていると、客側の事情、制作側の事情こもごもで、これを最優先に考えることは無理なのが現実です。（というかもっぱらコスト？）
一応現場で作っている時には、そっちを出来るだけ実現させようとは思っていますが、納期やスキルの面でまずひっかかり、後は申し訳ないですがモチベーションが持たないとか('A`)

ただ、こういうのが望ましいと言う努力目標として、こういったものを頭の隅においておくことは価値が十分にあることだと思います。なので、もうちょっと抽象的でもいいんじゃないですかね、権利章典は。あんまり無理やり現実に落とし込んでも、論議を呼ぶだけなのではないかと。

Webサイトはどうあるべきか、ということで意見の一致をみていないし、それがあるかどうかも分からないときに、結論が出るものでもないかなぁ、と。Webを広告に置き換えたとしても、人間に置き換えたとしても、サラダボウルに置き換えたとしても、結論が出るものでもないでしょう('A`)

そういえば、ニールセン氏のサイトの記事って、日本語訳されてたんですね。知りませんした。
　　＃useit.com: Jakob Nielsen on Usability and Web Design
　　＃ニールセン氏の和訳はJakob Nielsen博士のAlertboxから。

■アクセシビリティの高いサイトを増やすには

制作側だけで見ると、結局現状で、もっとアクセシビリティ対応を進めるには、サポートするソフトが出回ることが不可欠な気がします。各人の努力に期待するのは現状の制作業界には厳しいです…。

また、制作側が対応できればいいかというとそうでもなくて、それに加えて、それを価値として認めてくれるお客さんがいないと、片手落ちですし。

「アクセシビリティが高いサイトを作ることで、わが社にこういった利益が出る」というビジョンを持った会社でないと、結局「何か良く分からないものに金を払った、どう商売に生かしていいか分からない」となってしまって、無意味です。

アクセシビリティについて、制作側を突っつくのも必要ですが、同時にクライアント側も突っついておかないと、いかんと思う梅雨前の夜。

そう言えば、Web Accessibility Initiative (WAI) Home PageではWCAG2.0のドラフトを議論中ですね。

CSSについては、例えば有名らしい（知らなかった'A`）"a glimpse of the Guillotine"バグがすでに対応済みとのこと。このバグの詳細は、IE/Win Guillotine Bugに載っています。ある特定のfloatとlink周りの環境がそろうと、リンク先のように一部の内容が消えるといった、困ったことが起きる模様。

具体的には

1. コンテナとなる要素があり


2. その中にfloat指定された要素がある（そして、それはclearされていない）


3. コンテナ内に、floatされていないlink要素が、先ほどのfloatされている要素の後にある


4. linkのhover擬似クラスに、Background、Padding、Text Style、Border等を変更するスタイルが書いてある


5. ブラウザはIE

という要素がそろうと、起こるとのこと。リンク先を見てもらうと一目瞭然かと思われます。
　＃その他の各ブラウザのCSS周りのバグについてはCSSバグリスト＠CSSバグ辞典スレッドが最強です。

というようなバグが潰されているそうです。ありがたや。ベータ版は今年の夏を予定しているそうです。

[05/05/02追記]

PNGサポートを実現するに至るまでの経緯が、開発者によって記事になっています。
　　＃IEBlog : Tuesday, April 26, 2005 - Posts

Slashdot JAPANでも記事になっています。
　　＃Slashdot.jp：IE7の透過PNG実装内訳話

ちなみに、透過度フィルターを透過PNGに適用するとダメ、とか、MSTimesではダメという制限があるそうです。MSTimesってなんだろう。Google 検索: HTML+TIME2のことだろうか…。どっちにしても、初耳です。

しかし、100以上のサイトが並んでいるのは壮観です。いくつかのサイトのソースを見ると、やっぱり綺麗です。テキストブラウザで見ても自然に読めます。
　　＃テキストブラウザでの見栄えチェックは私はinfoaxiaで行ってます。
　　　例えば29digitalはこんな感じです。29digital.comオリジナルはこれ。

Blog | Davy Van Den Bremt | Music & Webdesignとか、underlow uncorporatedとか、Spilt Cocoa - Welcomeとか。デザインもソースも学ぶところが色々ありそうです。

また、それぞれのサイトのコンテンツも、CSS好きが書いてるだけあって、面白いものが多いです。UK Banking Accessibility Review · 29digital Design Studioとか。

HTMLだと、例えばIEのみ対応していないもので、"abbr"要素なんてあったんですな。略語としてマークアップさせるもののようです。
　＃参照：強調,引用,グループ化,画像などの要素 -- ごく簡単なHTMLの説明

<abbr title="Golden Week">GW</abbr>

こんな感じらしいです。IEだとabb要素を認識してくれないらしく、色々と対策が講じられてるみたいです。
　＃参照：WinIEでabbr要素を何とかする - 徒書

bdo要素

また、CSSの"direction: rtl"のようなもので、bdo要素なんてものもあったのか…。これはばけらさんによると、

異なる書字方向の言語を併用するようなケースでなければ活躍の機会は全くありません。

とのこと。

kbd要素、samp要素

キーボードで入力された部分だと示すために、kbdという要素が用意されているとのこと。また、samp要素は、プログラムやスクリプトのサンプルコードを表しています。

シチュエーションとしては、プログラミングの教科書などでしょうか。この辺りになると、必要ならXMLで書いた方が良い気がしますね。HTML4.01にはこんなものまであったとは。

Aural Cascading Style Sheets

CSSも,ちらほら知らんかったものがあるのですが、その対応状況はともかく、音声関係のスタイルがこんなにもあるとは知りませんでした。

音声系のスタイルはAural Cascading Style Sheetsと呼ばれて、略してACSS（アックス）と呼ぶそうです。（→IT用語辞典 e-Words ： ACSSとは 【Aural Cascading Style Sheets】　─　意味・解説）

W3Cの仕様書はAural style sheetsにあります。

日本語訳が、小町祐史氏のサイト（y-adagio）にある、CSS2の仕様書の翻訳「JIS/TR X 0032:2000, Cascading Style Sheets, level 2 CSS2 Specification」の中の[19 聴覚スタイルシート]のページにあります。
　　＃具体的にはAural style sheetsです。

これは、文書に音声に関する情報を盛り込んでおくことで、聴覚"表示"の品質を上昇させようというものです。例えば、文字サイズと同様に”音量”というプロパティがあって、これはVolumeという名前がついています。

例えば

div.giant { volume:x-loud }
div.ushmitsudoki { volume: silent }

というように使います。
これは相対的なものです、絶対単位でデシベルとかがあるわけではないです。カーオーディオのx-loudと、イヤホンのx-loudは絶対的な音量が同じだと、えらいことに。開いたらオーディオが壊れるページとかが。オーディオならいいですが、近所関係が大破する恐れも。

また、'play-during' というプロパティでは、BGMを指定することも出来ます。また、BGMではなく、効果音も'cue-before', 'cue-after'及び 'cue'プロパティで指定できます。
指定の方法は:before や :after疑似要素に似ていて、内容生成として、使用方法も同様のようです。
　＃擬似要素については：K@tsukun Page[:before および :after疑似要素]をどうぞ。

他にも、往年のText-Speechを思い出させるような、'voice-family' プロパティ。アクセントを指定するstressプロパティ、音声の豊かさ（？）をあらわす'richness' プロパティなど、多種多様な音声表現が用意されています。

これが実際に実用的になるには、長い年月が必要と思われますが、音声と言うものをどういった要素に分解するか、という点がとても面白いと思います。'richness' プロパティにはびっくり。
声色やテンション、話すスピード、間の取り方…プロパティがあるということは、重要だとみなされた、ということでしょう。

ところで、文字と音声だと、圧倒的に音声の方が情報量が多いですよね。文化人類学なんかでは、情報量が多くなる順に、文字→口承→踊り、である、なんていう話も聞きます。文字をはるかにしのぐ、言外の要素が音声や動作には含まれているというわけです。その辺りが、例えばネットでの純粋な情報収集手段としては、微妙なところです。

例えば、声色なんかは、余計な印象や先入観を与えてしまうこともあると思うので、本来の「純粋な情報」としては不必要なものだと思います。利用者の方で、好みの声を選べればそれでよいと思います。
フォントサイズなど以上に、音声の種類や、いわく豊かさなどは作り手は指定すべきではないです。

でないと、TV番組のように画面の印象だけで押し切ってしまえたりするのでは。ましてや情報を発する本人の声でも無いですし。

そんな感じで、Aural Cascading Style Sheets　音声スタイルシートネタでした。
DOMの方は、知らないこと多数なので割愛…('A`)

ちなみに、CSS関係の不具合はやはり『CSSバグ辞典スレッド』の要約
でしょうか。

CSS自体については、海外ではCascading Style Cheatsheet
が有名の様ですが、自分としてはCascading Style Sheets Reference
が最高に上質だと思います。

何度このページにお世話になったことか…。

ColorPic

紹介されているのは、まずカラーピッカーのColorPic。今まで他のカラーピッカーを使っていてそれなりに満足していたのですが、こっちもなかなか。

まず、基本的なカラーをピックする機能はもちろん一通り網羅。拡大率も変えられる、画面下の拡大鏡で対象に合わせて、Ctrl+Gでピックします。一度に複数の色をピックできます。デフォルトで16個と十分。また、ここでこのソフトのよさげなポイントの一つがあらわになるのですが、ショートカット完備で、慣れればかなりサクサクと色が取れます。

起動して取りたい色のところに持っていって「Ctrl+G」
さらに、上のパレットは、ファンクションキーにそれぞれ対応していますので、F2を押せば、ワンタッチで2つ目のスペースに移動できます。そこでまた「Ctrl+G」でピック…そしてF3…Ctrl+G…F4…Ctrl+G…

こうして好きなだけ色をとった後、ファンクションキーでカラーを選んで、Ctrl+Cを押せば、カラーコードをクリップボードにコピーできます。これはかなり楽そう。特にキーボード派には良いのでは。

MWSnap

続いてのMWSnapは、いわゆるスクリーンキャプチャ。BMP, JPG, TIFF, PNG GIFで保存できたりするのがよさげ。しかし、標準のスクリーンキャプチャの、ボタン一発の楽さもすてがたし。結局すぐにPhotoshopにペーストしてトリミングしてしまうので('A`)

TopStyle"Lite"

つづいて、http://www.bradsoft.com/topstyle/の、フリーの方のTopStyle"Lite"。こいつは以前から使っていましたが、リアルタイムにスタイルを表示してくれるので便利です。ただ、日本語に対応していないこと、そしてCSSを書き換えるたびに、下のプレビューウィンドウが一番上に戻ってしまうことがかなり個人的に面倒です。いちいちさっき見ていたスタイルまでスクロールしないといけないという罠。これが改善されれば悪くなさげ。特にピクセル単位での調整やら微妙なカラー調整に良いと思います。

Web Developer Extension

そして、FireFoxとMozillaの拡張ツールバーWeb Developer Extension

こいつは文句なしに便利です。ツールバーから画像の非表示をしたり、スタイルの非表示をしたり、画像サイズを表示したり、JavaScript切ったり、おまけに一発でValidateに持っていってくれたりで、Webサイトを作っていて追加のツールバーに抵抗がない人には是非お勧めです。ちなみに後発類似品でWeb Accessibility Toolbarもあります。こっちはIE用。

最後のひとつは、accessify.comの、Accessibility Toolbox 。これは、アクセシビリティに優れたFormを自動的に作ってくれるもののようです。お腹がえらく痛いので未使用('A`)

寝る前に牛乳をパック半分のみ干したのが良くなかったのだろうか…。週明けの忙しいときにやる気が右肩下がりです。

おや？と思ってカラーピッカーで取ってみると、やっぱり違う。何だ何だと思っていると、不意に右下のプルダウンメニューに目が。

「Protanopy (1 % of men)」

いつの間にかデフォルトの「Normal Vision」から変えてしまっていたようです。
しかしこれはどういう意味だろうか…というわけで調べてみると、以下のような意味でした。

Protanopyとはいわゆる「赤色が見えない」状態
Deuteranopyとはいわゆる「赤色が見えない」状態
Tritanopyとはいわゆる「赤色が見えない」状態
Protanomalyは、「赤色の見え方がおかしい」状態
Deuteranomalyは、「緑色の見え方がおかしい」状態
Tritanomalyは、「青色の見え方がおかしい」状態
Full colorblindnessはいわゆる「全色盲」で、
Atypical monochromatismは世界が「モノトーンに見える」ということらしいです。
　＃参照：http://www.drallanpanzer.com/color_vision_diagnosis.htm

つまりこのカラージェネレータは、なんと、色盲の人達の見え方をシミュレートしてくれるものなのです。

いじっていて、こんな風に見えるのかと言う驚きと共に、ウェブコンテンツ・アクセシビリティ・ガイドライン 1.0を不意に読み返したりと、いいきっかけになりました。自分にとっては、視覚で示されると下手な文章より説得力が大きいようです。

また、Vischeck: VischeckImageでは、手持ちの画像をアップロードして、色盲の人の見え方をシミュレートすることが出来ます。こちらもどうぞ。また、色盲の人にもわかるバリアフリープレゼンテーション法にある、神奈川県の 『色使いのガイドライン（PDF版）』も良い感じだと思います。

【追記】
大変ありがたいコメントを頂きました。誤訳を指摘していただきました。多謝多謝です。
誠に勝手ながら、有用な情報ですので、転載させていただきます。ご了承下さいませ。

---------------------------------------------------
凄く惜しい翻訳です。
全ては「色覚異常者の見え方」です。
日本には、赤緑色覚異常の第１色覚異常と第２色覚異常と青黄色覚異常と言います。
色覚異常を分けた「中波長領域＝色弱（弱め）〜色盲」が下記のようになります。

Protanopyとは「赤色色盲」
Deuteranopyとは「緑色色盲」
Tritanopyとは「青色色盲」
Protanomalyとは「赤色色弱（弱め）」
Deuteranomalyは、「緑色色弱（弱め）」
Tritanomalyは、「青色色弱（弱め）」
Full colorblindnessとは「全色盲（モノクロ）」
Atypical monochromatismとは「単色色盲（単色明度・モノトーン）」
です。
参考：色覚異常（色盲・色弱）http://www.wakaba-hp.or.jp/eye/eyesick_f/eyesick_13.html
参考：Wikipedia（色覚異常）　http://ja.wikipedia.org/wiki/%E8%89%B2%E8%A6%9A%E7%95%B0%E5%B8%B8

---------------------------------------------------