しかし週が空けてみるフォーラムには問題を報告する書き込みが多数あり、結論としては自動アップグレードにバグがあったようです。個人ブログで失敗するのは別にいいと思うのですが、ビジネスとしてWordPress（以下WP）で構築したサイトをクライアントさんに提供している場合、こういうのは特に慎重になる必要があると思います。

特に最近のバージョンでは自動アップグレード機能が搭載され、さらに管理画面に「アップグレードしてください」と（あたかもエラー表示のように）表示されます。

いつもの管理画面にこんなアラートが出れば、よく分からないけどなんとなくアップグレード手続きを進めてしまうという事は当然考えられます。

そういったトラブルを避ける為に、アカウントごとの権限をしっかりと管理しておく必要があります。一般的にはクライアントさんに渡す管理アカウントの権限設定などどう扱われているのでしょうか？

権限設定はユーザーインターフェイスの最適化でもある

私はいろいろなCMSで沢山のサイトを構築していますが、最高権限（管理者）のアカウントをクライアントの更新担当者さんに渡す事は基本的にはありません。

それは「大事な部分はこっちで握っておいてあわよくば改修費用をとる」という意味ではもちろんなくて、権限を適切に設定することで「日常的に不要な機能を省く」ことができるからです。
画面に大量の選択肢が表示されるだけで「難しい」と感じてしまうのは極めて普通の感覚であり、権限設定によって『メニュー項目が減る、画面上の情報量が減る、自分に必要な選択肢だけ残る』、つまりこれだけで小さな『ユーザーインターフェイスの最適化』が出来ます。

例えばWPでいうと権限によって下図のように管理画面サイドメニューが変化します。

社内の更新体勢、担当者の習熟度によって適切に権限設定する

日常的に更新するため、もしくは十分な知識のない担当者さんに渡すアカウントは「編集者」にしておくべきだと思います。
「作者」は投稿はできるのに編集ができない、という中途半端な位置づけのため実際の所は用途がなく、もし複数人で更新する場合には、責任者を「編集者」としその他の人を「寄稿者」とします。「寄稿者」は記事を公開する権限がないため、下書きとして保存し更新責任者が内容をチェックして初めて公開、という形になり、コンテンツの質を維持する必要のあるビジネスサイトではうまく働くでしょう。

更新担当する方の役割、日常的な作業までしっかりと想像して考えれば、必然的に適切な権限は決まってくると思います。（もし最高権限を渡す必要がある場合でも、管理者アカウントは書類で渡して更新用アカウントを別に作ってあげればいい）

もし今回のように威勢良くリリースされた新バージョンに問題があったとしても、権限をちゃんと管理していれば大きなトラブルを防ぐことができます。

余談

フォーラムや関連するブログエントリーを見ていると、問題に対して厳しく批判しているものも。
実際クライアントさんのサイトが今回の問題で被害にあったとして、復旧作業のコストは誰が持つのか。WPの開発者？（ Absolutely NO ）、知識のないクライアント？制作会社？

ハイリスクハイリターンとは違うかもしれませんが、高機能なシステムを無償で使わせてもらう時点でユーザーは既にハイリターンを得ているのであって、全ての問題は自分の責任、ましてはビジネスでやっている以上は起こりうる問題のリスクマネジメントをしっかりしておかないと大変な事になると思います。

バージョン管理については、セキュリティ関連であればもれなく更新する必要があるし、単純な機能アップであればフォーラムの様子を見ながら慎重に行う、または不要であれば見送る、など判断が必要です。

「やぁ、これオープンだって！じゃあこれバンバン使って楽にWEB製作ビジネスしようぜ！！ユーザーコミュニティ？公式フォーラム？なにそれこわい。」ていう発想は、怖いなと思います。

Matt さんのプレゼンはとても面白かったです。
テクニカルな部分での具体的な話というよりは、WordPress の誕生から現在までの経緯や、世界中での WordCamp のエピソード、その他オープンソースとして続けて行く為に大切にしていることなどを超早口で紹介してくれました。

オープンソースであるWordPressを開発しているAUTOMATIC社がどのようにして収益を上げているのかという話は興味深かったです。「技術はいくらでもコピーできるけど、コミュニティはコピーできない」という言葉も印象的でした。

その他、いくつかのプラグインの作者さんの紹介プレゼンがありました。

個人的に為になったのは、田中さんの『20分で見るプラグインの作り方』でした。ただでさえ難しいコードの話は、言葉で説明されても「で、何からやればいいの？」という事は多いので、最初に実際の流れを画面で見せてくれるのはとても勉強になります。

あと雰囲気として感じただけですが、参加者の多くは開発者系の方々のようでした。
WordPress をカスタマイズして高機能な CMS として使うことは既に特別なことではないというか、全く難しくないしデザイナーの範囲でできてしまうくらいの事なので、デザインができる人はもっと参加するといいのかなと思いました。

CMS を自由自在に使うことは覚えれば誰でもできる事ですが、カッコいいデザインを作れる人は少ないですからね…。

やはり開発系の人だけが集まっていると敷居が高くなりがちなので、デザイナーによるフロントエンドカスタマイズの話題などが沢山あればより多くの人が集まり、結果的にコミュニティーも広がって行くのではと思います。

『このデザインを10分でWordPressで動くようにする』とか。10分じゃ厳しいか。

余談

会場は葛西という初めて行った街。
ランチ時に歩いてみましたが、チェーン系のお店が多く、なかなかよい店がみつからず。
30分くらい歩いて見つけたのが『ティールーム 街角』。
少々古びた外観で、外から中が見えない薄暗さ。ランチがあるのかどうかも分からなかったのですが、ただならぬオーラを感じて入ってみました。

思ったより広い店内に、革張りの古い家具、オレンジ色のライト、外を見つめながら煙草を吸うおばあさん。無愛想だけど嫌な感じがまったくしない、無駄の無い接客。完璧すぎます。

フードはトースト系とビーフカレーのみ。
カレーはごく普通の美味しいさで、コーヒーも深みのある味わい。1杯1杯丁寧に入れられている感じで、後から入ってきた女性が注文したオレンジジュースはミキサーの音がして5分くらいかけて作っていたり。

あまりに落ち着く空間で、あっという間に時間が過ぎてしまいました。
こんなお店が近所にあったなら！！！

ぜひ次回のWordCampも葛西でやって頂きたいと思います。

インストール後に行うべき設定などを、順を追って挙げています。

ユーザーをゼロから管理する

1. デフォルトの admin アカウントを削除
2. 複数の投稿者アカウントが必要になる場合は作成
3. ビジュアルエディタをオフにする

セキュリティに関して出来る限りのことをする、ということですね。ビジュアルエディタはどっちでもいいと思います。コードビューと行ったり来たりするような使い方をする場合は、オフにしてしまいましょう。

ブログ設定をする

1. パーマリンク設定
2. RSS 設定、FeedBurner への登録
3. コメント設定、コメントスパム対策

基本的な設定です。これらを後まわしにするとよい事はないです。

基本的なプラグインをインストールしておく

1. Clean Notifications
2. IImage Browser
3. FeedBurner FeedSmith
4. Google Sitemap Generator
5. No WWW
6. その他

どれもメジャーなプラグインです。www の有無でアクセスした場合の処理を考慮していないサイトというのは以外と多いように感じます。

テーマを選定・デザインする

ゼロからテーマを作る場合、Starkers というブランクテーマがいいらしいです。これは知りませんでした。

解析コードを入れる

アクセス解析用のコードを挿入します。

以上です。
どれも当たり前の事ばかりですが、ポイントは後回しにせずにインストール作業とセットにして最初にやってしまうべき項目、という所です。

筆者クリスさんの個人的な意見もありますが、お気に入りのプラグインなど自分なりにこういうガイドラインを持っておくと制作効率はどんどん上がると思います。

コメント欄も盛り上がっているので、一応読んでおきましょう。

CSS TRICS：The Very First Steps After a Fresh WordPress Install

なぜ日本語サイトは間抜けな印象になるのか

「意味が分からないことで文字自体をデザインとして見ることができる」という感覚的なものもあるけれど、特にWEBにおいて言えることは、「ピクセル表現上での日本語は可読性を保つ為の最小文字サイズが大きい」という点があると思います。

ローマ字はその造形自体がシンプルであること、また単語ごとに必ずスペースが発生するという法則から、10pxの文字でも十分に読めてしまう。
それが日本語となると、漢字が混じることで10ピクセルではとてもじゃないけど読みづらい、また読みづらい以前に文字が潰れてしまう。

文字が小さくできるローマ字は、カラム自体が１つのブロックオブジェクトとして扱いやすくなり、全体のデザインがまとまりやすくなる。
文字を大きくせざるを得ない漢字は、カラムがブロックではなく「文字のちらばり」のような印象になってしまうため結果的にデザインとしては扱い辛く、スカスカのブロックのような印象になる。

この文字自体の特性をうまくまとめる所に、全体のサイト印象に大きく影響するセンスが現われると思います。

『フォントサイズが大きい＝読みやすい』ではない

読みやすさを重視すれば「フォントサイズを大きくすればいい」と単純に考えがちですが、「フォントサイズが大きければ見やすい」とは限らないのがWEBデザインの特徴だと思います。

理由として、スクリーンという固定サイズの画面上では、フォントの大きさと一覧できる文字量が反比例するからだと思います。文字サイズが大きければそれだけ一覧性が犠牲になり、一覧可能な範囲が狭いということはまた別のストレスを生みます。

なのでフォントサイズも大切ではありますが、もっと気を遣うべきなのは実は CSS でのフォントの種類、行間、1行の文字数、背景色と文字色の関係だと思います。

Glam 日本版がそこまで野暮ったくならなかったというのも、その辺りがポイントではと思います。

その他、アンチエイリアスが綺麗な MacOS や Windows Safari などでの閲覧を前提として、日本語の良さが出る明朝体をうまく使っているサイトはとても読みやすく、綺麗です。

話は大きくそれて

この Glam.jp を見ていてひどく残念な部分もありました。
メインコンテンツはいわゆるスイーツな女性たちのブログなのですが、人によって写真サイズがばらばらだったり、改行スタイルも統一されていなかったりと、書式については無法地帯だということ。

またワードか何か、他のエディタからそのままコピーペーストされ、様々なスタイル情報がインラインで入ってしまいサイトの文字スタイルが無視されてしまっている記事まであります。

これはある意味で仕方なかったり、今をときめく改行ばかりの文章もそれが個性と言ってしまうこともできますが、ブランディングを含めたサイトの継続的なクオリティ維持の為にはこの辺りまでしっかりと統一した方がいい気がします。

ブログは WordPress で作られているようなので WISYWIG で自由に書いているのだと思いますが、例え更新者にHTML の知識がないとしても、最低限読みやすい段落の付け方くらいは意識してもらい、改行を1回押す事、2回押す事、Shift押しながら改行すること、それらがどんな意味を持つのかという教育は必要だと思います。

CMSにしたからといって、権限を渡すだけでは不十分というよい例ではないかと思います。あえてスイーツっぽさを醸し出す戦略だとしたら、それはそれでハイレベルです。

IE を使ってほしくないという気持ちは痛い程分かりますが、長谷川さんも書かれているようにクライアントワークではこれからも無視できないのが現実。

多分、新聞の日曜版でかわいいイラストと共に「ブラウザを選ぼう！」という記事が載るくらいにならないと、IE は使い続けられるでしょう。

日本で次世代ブラウザが普及しない理由（の想像）

最近 WEB制作系の雑誌で早速 IE8 対策として解説されてるのを見て思うのが、「結局は制作側が自分達で複雑化してしまっているんじゃないかな」ということ。

ハックだとか分岐だとか、いつまでやるのだろうかと。
複数のブラウザ仕様の隙間を探ることがWEB制作者のやるべき事なのかと。

普通に作ればほとんどの最新ブラウザで表示できるのだから、それでいいのではと思う。制作側が毅然としてこう考えていれば、
「うまく表示されないのはサイトが悪いのではなくてあなたが使用中のブラウザが問題なんですよ、よりよいブラウザは無料でダウンロードできますよ」という知識は自然と普及していくのではないかと思う。

かなり前に「欧州ブラウザシェア – ROSTRATA.net」という記事にも書いたけれど、特に日本ではその辺りの認識が低い。

その原因が制作者側自身にあるという仮説を立ててみる。

1. どんな環境でもお利口さんな優等生サイトを作りたい。ようこそあらゆる閲覧者様、ささ、どうぞ。という超 OMOTENASHI 精神。
2. なかなかうまく表示されないのがむしろ快楽というM的要素。
3. 細々としたハックを駆使して作り上げるという箱庭的な魅力。

これら日本特有の文化・国民性が、日本でのブラウザ世代交代の鈍化、もとい IE シェアの高さを助長している気がしてならない。

更に深く読むと、もしIEが消えてしまった場合、HTMLコーディングはものすごく簡単になり、HTMLだけしか出来ない人は一気に暇になってしまうので、それはそれでWEB業界としては問題かもしれない。
でも本来その時間はもっと進んだ技術習得とか、マーケティングとかに使うべきなので、やっぱり単なる構造文書でしかないHTMLごときに時間を使わなければならないという現状はやっぱり無駄が多い。IEのせいで。