グラフィックデザインの勘所と書いてはみたものの、僕、あんまり専門でもないので大したこと言えないなーと思いつつ、何回かに分けてエントリーを書きます。

どこからデザインを作り込むか。

正直に言って、今このエントリーを書きながら、非常に悩んでいます。いやね、自分がデザインするときってどこから始めているんだろうか、と。

レイアウトは先ほどのエントリーのプロトタイピングあれこれで基本的なところは決まっているわけです。あと、配色とかもポートフォリオを集めるで決まっているわけです。すると、あとはどうやっているんだろう。。。

このNPtech.jpの場合はまず絶対にグリッドシステムのラインをそのままデザインにしたい！というのが明確にありました。故に、背景にほぼ均等間隔にラインを引いているわけです。それで、単にラインを引いただけでは面白くないよなと思い、上から段々に灰色から黒色に濃くしていったりしています。

で、あえてラベリングを英語にすることによって「わかりやすいかっこよさ」を演出していたりします。本当はナビ部分とかは日本語のほうが視認性が圧倒的に高いんですけど。Verdana使いたい！という理由もあります。

その上で全体的に2.0っぽくしたくなかったので、ドロップシャドウとかを使わずにやっていくと、どうしても平べったいイメージになってしまいます。そこで、各所ボーダーに対して色の違う1pxのボーダーを2色くっつけて表示してみたり。すると、ちょっとだけそこが盛り上がっているように見えますよね？

ありゃ、このままいくとｇｄｇｄコースだ…orz

デザインの勘所

ものすごく無理矢理にまとめてみます。

1. デザインはデザインする前が勝負！どんな情報を掲載し、掲載しないかの取捨選択をしておくこと（そういうのがユーザビリティやディレクションのワークフローの必要性だと思うのです）。
2. かちっとデザインしようとすると面白みがなくなる。コントラスト大事！
3. でも、一方で揃えるべきところは揃えること。統一感大事！

うーん、うまく言葉に表わせていない。

グラフィックデザインをするときは、情報を整理してその強弱をわかりやすくすること、一方で楽しさ、面白さ、そういう感性的なもの。

そう、うまく理論的な情報整理と感覚的な楽しさ、それをどのように融合させるのかがデザインの大事なところなんだと思います。

ダメですか、このエントリ－。次のエントリー頑張りますので、勘弁してやってください。

プロトタイピングの必要性

さて、前回のセス・ゴーディンの訳文から今回はNPtech.jpを題材としたパーソナルブログの作り方の話に戻ります。

今までのプロセスというのは大まかに言ってしまうと、

• クライアント、閲覧者の明確化
• それに合わせたコンテンツ、デザイン（要はuser experience）の整理

というのをやってきたわけです。それらの整理された情報をどのようにサイトとして反映させるのかということになります。整理しただけでは意味がないですよね。

その第一歩として取り上げるのがプロトタイピングです。日本語に訳さなくてもお分かりだとは思いますが、「試作品」ですね。

ここで、一度試作品とは何ぞやということをちょっと考えてみます。試作品はなぜ作るんでしょうか。その必要性を考えるためには、ご自身のこんな経験を思い出してもらうとよいかもしれません。

• クライアントがデザインを気に入ってくれない。
• ディレクションが甘くニーズを引き出せていなかったため、必要な機能が足りていない。
• デザイナー、ディレクター、クライアントがそれぞれ全く違うものをイメージしていた。

などなど。

こんなときにいきなりモックアップレベルのクオリティの高いものを作ってしまうと、その修正が難しくなってしまいます。そこで、まずは試作品を作り、というよりも試作を重ね、徐々に完成品に近づけていくというプロセスが重要になってきます。このあたりはHuman Centered Designなどを参考にするとよいと思います。

プロトタイピングの作成

プロトタイピングを作成する方法、ツールはいろいろとあります。いくつかピックアップしてみます。

• PowerPoint
• Visio
• イラレ、フォトショ
• Dreamweaver
• 手書き（ペーパープロトタイプ）
• Omni Graffle

などです。僕がおすすめというかよく使うのはPowerPointです。PowerPointを使ってどのようにプロトタイプを作成すればよいのかについてはパワーポイントでプロトタイピング（日本語訳） – TRANS [hatena]を参考にしてください。

実際のプロトタイピング

下記スクリーンショットが実際に僕がNPtech.jpを作っていた際に作ったプロトタイピングのデータです。なんとなく雰囲気はお分かりになってもらえるでしょうか。

正直、プロトタイピングだけを考えると作業工程が増えてしまうという点ではあまりプラスにはならないのですが、やはりこの段階をきっちりと踏まえておくことで完成度の高いパーソナルブログを作成することができます。

よいマーケッターが知っていること。

• 個人情報を利用した広告は今後迷惑メールよりも多くなることが予測されている。
• 約束を守り続けることがブランドを築くための重要な方法である。
• 最も重要な顧客は平均的な顧客の何倍もの価値がある。
• 財布の中身におけるシェアこそが大事。その割合を上げればもっと利益が上がるし、結局はマーケットシェアよりも重要な指標になる。
• マーケティングは商品が作られる前から既に始まっている。
• 広告は単なる症状であって、戦術だ。マーケティングはもっともっと面白い。
• 値段を安くするというのはコモディティ商品を売るための重要な方法だ。ただ、それはマーケティングの話ではなく、効率性についてだ。
• 顧客同士が何かを話すということは好んで好まなくても何かを生み出すものだ。よいマーケティングというのはその会話をプラスの方向へ持っていく。
• すごい商品というのはうわさになる。
• マーケティングとは、社員が電話で回答し、請求書を作り、返品したりすることだ。
• 普通に接してさえいれば、人は自身の体験談を話してくれるものだ。
• 毎年一定の予算で同じようなマーケティングをしているのであれば、それは費用として目に映るだろう。しかし、よいマーケッターというのはそれを費用ではなく、投資として捉えている。
• 人は自分が必要なものを買うのではない。ほしいものを買うのだ。
• 自分で責任を持たないと、見込み客もあなたと取引しようとは思ってくれない。
• 人がほしいオマケというのは、自分が好きなものを買ったときについてくる感動してしまうようなボーナスである。
• B to Bマーケティングとは、顧客自身がほしいものを会社に支払わせているに過ぎない。
• テレビ広告や迷惑メールなどの顧客に割って入るような伝統的な手法は費用対効果をどんどん下げている。一方、ブログやRSSなどの新しいアイディアの方法はその効果を証明し続けている。
• マーケティングは全人類、いろんなレベルの収入の人たちに基本的な人間のウォンツを約束し、届けよう。
• よいマーケッターは物語を話す。
• 人はわがままで、怠惰で、無知で、気も短い。そこから始めてみる。すると、自分の発見に嬉しく驚いてしまうだろう。
• マーケティングがうまくいくときは人々がchoose to noticeすることをマーケティングする。
• 効果的な物語というのは、自分がその物語を話したくなるような同じ世界観を持った人たちとあなたをマッチングするのだ。
• 顧客を選べ。ほかの顧客によい物語を届けるために邪魔するような人たちと付き合う必要はない。
• 「すべての人」をターゲットにした商品というのは、ほとんどの人たちに届かないものだ。
• 本当にドキドキするようなよい物語というのは、いろんな人の間で生き続けていくものだ。
• マーケッターはその商品の側面的な効果にも責任を持つべきだ。
• 顧客の物語を共有できれば、信頼を得ることもそう難しくはない。
• よいマーケッターは評価指標を持っている。
• マーケティングは緊急のものではない。それはその仕事が完了するまでの長い期間、よく計画され、よく考え続けられているものだ。
• 1人のがっかりしたお客さんは喜んでいる10人のお客さんと同じ価値を持つ。
• Googleの社会では、世界で最もよいものがほとんど勝つ、そしてどんどん勝ち続けていく。
• ほとんどのマーケッターはそれなりに十分なものを生み出し、それで終わりにする。最高のマーケッターたちはそれなりに十分なものでは納得しない。
• 今までよりもリッチな人々がいる。そして彼らはそれぞれ違うように扱ってほしいと思っている。
• 直接エンドユーザと取引しようとしている団体は将来性がある。
• 短期間だけならソーシャルメディアで遊んでみればいい。ただし長い期間ではなく。
• 誰かを雇った時、解雇した時、それは商売をしているということなのだ。同じようにアフターサポートに電話したとき、誰かにメモを送った時も、また商売なんだ。
• もっとよいマーケッターになりたければ、ブログを書くこと。それは自身のライティングに謙遜ということを教えるからだ。

訳者からの感想

最近気になっているのはこの「story」という概念です。ここでは物語と訳しましたが、ちょっとニュアンスが違うなーとも感じています。ちなみに、このstoryについては、NPOのWebサイトの最優先の改善ポイント | NPtech.jpでも取り上げましたので、ご参照ください。

ポートフォリオを集める

今まではどちらかというと、情報をリストアップし、整理するという作業でした。そろそろデザインらしいデザインの話をしてもよいのかなと思います。もちろん、今までも書いてきたのもデザインの話です。ここからはデザインの中でも、グラフィックデザインのフローを少しずつ書いていきます。

まず僕がすることはポートフォリオを集めること。ポートフォリオとは一般的には自分の作品集というような意味ですが、個人的には「制作するサイトのデザインの参考になる作品群」と定義付けしています。意味的にはムードボードに近い感じです。

本来は気に入ったサイトを1つずつSBMなどに管理していくのが理想的なのですが、ここに関しては他人任せです。僕の場合はデザインのまとめ系サイトをdel.icio.usで管理することによってその代替としています。

del.icio.usのWebデザインギャラリー

このページからあっちのサイトへ行ったり、こっちのサイトへ行ったりと繰り返し、今までのフローでイメージできるサイトに近いものをピックアップしていきます。

NPtech.jpの場合

では、NPtech.jpの場合はどんなサイトを参考にしたのか。ネタばれしてしまうのが痛いところですが、

• thruSITES / UK web design and development
• Intype – In type we trust
• Blog ☺ cause/affect
• afasici papuasia

と、全部英語のサイトです。

それにもちゃんとした理由があります。今回のNPtech.jpでは「単純なくらい分かりやすいかっこよさ」というのを目指したからです。このサイトの主な想定読者層は社会起業やNPO関係者でネットに関係した情報を収集する層というふうに捉えています。そのため、あまりWebデザインというものを知らないからこそ、かちっとしたデザインで信頼を勝ち取る、というようなことを考えているわけです。

ゆえに、英語圏のサイトのかっこいいもの（この場合はクールなもの）を選び、また、あまり日本語圏では使われない背景色を黒にしたりしています。

もし、皆さんもポートフォリオの集め方で「こんな方法いいよ！」とか「このサイト便利だよ！」というのがあったら教えてください。友人の服飾デザイナーさんはデザインするときに雑誌から切り抜いたモデルの写真を画用紙にペタペタ糊付けしていましたね。

そんなこんなでそろそろ次あたりから実際に手を動かすというお話をしていきたいと思います。

情報を設計するワークフロー

唐突ですが、サイトのコンテンツをどのようにリストアップしていますか？漏れがあったり、重複したりしていませんか？はたまたデザインを作りこんでコーディングをスタートしてから、やべえメニューが1つ足りていない！とかなっていませんか？

そういったことを未然に防ぐのが情報設計というやつ。インフォメーションアーキテクチャですね。

今回はコンテンツ – 情報をどのように設計するのかについて基本的なフローを説明しておきます。

僕のフローはこんな感じです。

1. 2つか3つの競合サイトのコンテンツをリストアップする。
2. 自サイトの独自コンテンツをリストアップする。
3. それぞれのコンテンツをグループ分けする。
4. そのグループに優先順位をつける。
5. サイトマップを作る。

次の章でNPtech.jpを事例に具体的に見てみます。

NPtech.jpでの事例

NPtech.jpそれ自体は単なるブログですので、競合サイトというよりもほかのブログを参考にしました。これらのブログはデザイン面でも本当に影響されました。

• Nitram+Nunca
• greenhug : 良いコト・モノだけエコニュース
• Mushline

それから今までのワークフローで紹介した手法からオリジナルなコンテンツも加味し、こんな感じでコンテンツをリストアップしました。

• 記事
• 記事サマリー
• カテゴリ
• タグクラウド
• アバウトのページ
• プロジェクトのページ
• アーカイブのページ
• 最新記事一覧
• 最新コメント一覧
• コンタクトのページ
• 検索ボックス
• 広告
• タグライン
• RSSリンク
• WordPressの著作権
• 自分の著作権

とこんな感じですね。実際のデザインではこの過程で必要を感じなくなり却下したものや逆に付け加えたものもあります（ちょっと思ったんですが、厳密にはコンテンツという言い方は正しくないですね。英語で言うと、chunkです。ユニットとかそんな感じかな）。

あとはこれらをグループ化して、それぞれのグループに優先順位を与えて、コンテンツの位置付けを決めたりします。ここで、ある程度どんなコンテンツが必要なのかについての一覧ができるので、それをサイトマップに落とし込めばいいわけです。

ちょっと急ぎ足になりましたが、こんなところで。

マッピングとは何か？

過去2回ほどのエントリーでやってきたことは、自分のポジションを知り、その上でほかの人たちのことも知ろうというものでした。そういった情報を得てから、自分のブログはどんなコンセプトで作るのかを考えていくわけです。

では、一体何から考えていけばいいのでしょうか？そろそろムードボードとかを作るためにサイトや素材を集めますか？いやいや、僕はまずはアイディア出しだと思います。

その手法がマッピングというものです。いや、もしかするとマッピングと呼ばないのかもしれない（おいｗ）でも、僕はワークショップやコーチング系のセミナーでそう習ったはず。というわけで、このエントリーではマッピング（仮）と呼びます。

では、そのマッピング（仮）とはどんなものでしょうか。手っ取り早くパーソナルブログの作り方で取り上げている事例、NPtech.jpのときのマッピング（仮）を掲載しておきます。

字が汚いとかそういう批判は受け付けられません。いいんです、個人的なものですから。

マッピングの作業フロー

コーポレートサイトを制作する場合はディレクターさんとかが仕切って、数人でブレストするのがよいのですが、パーソナルブログなので、基本的には一人でやってみましょう。

まずは、次のものを準備します。

• 紙1枚
• ペン1本
• 誰にも邪魔されない10分ほどの時間

紙に自分のサイト名、もしくは「パーソナルブログ」と書いて、四角で囲います。

次にそのサイトから「ぱっと」連想するキーワードを思いつきでよいので、周りにいくつか書き留めます。それを四角で囲み、「パーソナルブログ」と線で結びます。次はその思いついたキーワードから、また別のキーワードと…このように思いついたことをどんどん紙に書いていきます。

以下、注意点。

• あまりにも関係なさ過ぎるキーワードばかりになったらそこはそれ以上伸ばさずに、ほかのキーワードに戻り、そこからもう一度始めてみましょう。
• 1つのキーワードから思いつくことは1つである必要は全くありません。理想はくもの巣みたいな感じです。

すると、上で紹介した画像のような状態になると思います。あとは、この中からパーソナルブログに関係ありそうなキーワード群が固まっているはずなので、それらを線で囲みます。

NPtech.jpの場合はつながり、黒・白、シルバー、やさしい、リングなどを囲んでいます。これらがパーソナルブログのキーワードです。NPtech.jpのときはサイトカラーは黒白を基本としていますし、その中にやさしいという色を使いたくて、ロゴやリンクが緑、加えてところどころにリングを表す円形を書いています。

このときに選ぶのは色合いやデザインのキーコンセプトに直接関係するものでなくても構いませんし、ここで抽出されたキーワードを必ずサイトに反映させないといけないというわけでもありません。

あくまでアイディア出しです。ただ、アイディア出しはその発想こそが重要なので、まずはいろんな視点からいろんなことを思いつくために、このマッピング（仮）は面白いと思うのです。

アトム

「アトム（atom）」は、Erlang で使う定値のことです（数値は除く）。アトムの値は、英数字やアットマークあるいはアンダースコアが使えます。ちなみに大文字で始めると変数として解釈されてしまうため、シングルクォートで囲む癖をつけるとよいです（シングルクォートで囲むと、アットマークやアンダースコア以外の文字も使えます）。例えば、

1> Lang = ‘japanese’.
japanese

2> Resid = Osaka.
* 1: variable ‘Osaka’ is unbound
（Osaka を変数と解釈するので、まだ値で束縛されていないというエラーが出る）

3> Resid = ‘Osaka’.
‘Osaka’

となります。

アトムも Erlang の式として扱われ、値を持ちます。当然、アトムの値はアトム自身なので、’japanese’ というアトムは japanese という値を持つと考えてください。したがって、上記の 1> では、Lang という変数を ‘japanese’ というアトム（これは japanese という値で束縛されている）で束縛していることになります。

4> ‘kwsn@kwsn.com’.
‘kwsn@kwsn.com’ # アトムはアトム自身を値としてもっています

タプル

さて、数値や浮動小数点数あるいはアトムを一つのまとまったデータとして扱いたいときがあると思います。例えば、個人のプロフィールを、

氏名、性別、現在地、キャリア、機種

という項目でまとめて扱いたいとき、

kwsn, Male, Dojima, au, W51H

という幾つかのデータの集まりに名前をつけて扱えたら、

kwkw, Male, Dojima, au, W51H

という他の集まりと比較したときに、「氏名だけが違う」との結果から、例えば他人であると判断できたりするわけです。Erlang では、ひとまとまりの値（表記するときは変数やアトムなのですが）を取り扱う方法として、「タプル（tuple）」と「リスト（list）」という二つの方法が用意されています。

まず、上記のプロフィールからタプルを作ってみましょう。

5> Tuple = { ‘kwsn’, ‘Male’, ‘Dojima’, ‘au’, ‘W51H’ }.
{ kwsn, ‘Make’, ‘Dojima’, au, ‘W51H’ }
#（大文字で始まるアトムは変数と解釈されないように、シングルクォートで囲まれて表示されます）

これで、Tuple を5つの値から成るタプルで束縛したことになります。タプルは波括弧（ブレース）で囲んで表記するという点に注意してください。また、タプルは入れ子にもできるので、｛式, ｛式, ｛式, 式｝, 式, 式｝, 式, 式｝のようにも作れます。

リスト

リストも同じように幾つかの値で作れますが、タプルと違う特徴があります。試しにリストを作ってみましょう。

6> List = [ 'kwsn', 'Male', 'Dojima', 'au', 'W51H' ].
[ kwsn, 'Male', 'Dojima', au, 'W51H' ]

表記としては、値を鍵括弧（ブラケット）で囲むのがタプルとの違いです。ここまでは括弧の違いだけですが、タプルは要素の個数を変えられません。いちど作ったら、中身はずっと同じままです。これに対して、リストは後から要素を先頭に追加できます。

それからリストには、パイプ「｜」で、先頭の要素である「ヘッダ」と先頭以降の要素からなる「テイル」に、それぞれリストとして分割できるという特徴があります。

7> [ ListHead | ListTail ] = List.
[ kwsn, 'Male', 'Dojima', au, 'W51H' ] # 見た目は同じ
8> ListHead. # 先頭
kwsn
9> ListTail. # 残り
[ 'Male', 'Dojima', au, 'W51H' ]

のように、先頭と残りに分割できます。そこで、次のような事例を見てみましょう。

10> List = [ 1, 2 ].
[1,2]
11> [ Prior | Posterior ] = List. # List を前後に分割します
[1,2]
12> Posterior.
[2]
13> [ PrePosterior | PostPosterior ] = Posterior. # 残りを更に前後に分割します
[2]
14> PostPosterior.
[]

ここで分かることは、要素が一つの場合でも作れることと、要素がない場合でも作れるということです。もちろんタプルについても、要素が一つだけでもかまいませんし、要素がなくてもかまいません。

では次に、前後に分割できるという特徴を使って、次のようにどんどん分割するとどうなるでしょうか。

15> A = [ 1, { 2, 3 } ].
[ 1, { 2, 3 } ]
16> [ B | C ] = A.
[ 1, { 2, 3 } ]
17> [ D | E ] = C.
[ { 2, 3 } ]
18> [ F | G ] = E.
** exception error: no match of right hand side value []

最後にエラーが出てしまいました。この理由は、「リストの分割」とは、或るリストを前半のリストと後半のリストに分けることだからです。16> では、A というリストを分割して、1 と [ { 2, 3 } ] という二つのリストにしています。それから、17> では、[ { 2, 3 } ] というリストを分割して、[ { 2, 3 } ] と [] という二つのリストにしているのです（実際、E. を入力すれば、E が [] であると分かります）。したがって、18> では空のリストを更に分割しようとしているため、エラーとなっているわけです（リストとして分けなければならないので、タプルである { 2, 3 } は分割できません）。

タプルとリストはどちらも、お互いの要素として使えます。つまり、タプルの要素としてリストがあってもよいですし、その逆も可能です。

19> A = [ 1, 2, { 3, 4 } ].
[ 1, 2, { 3, 4 } ]
20> B = { 1, 2, [ 3, 4 ] }.
{ 1, 2, [ 3, 4 ] }

タプルとリストから値を取り出す

次に、タプルとリストから値を一つ取り出す手順についてご紹介しておきましょう。要素を取り出せたら、要素ごとに比較したり、他の目的に値を使えますね。それでは、まずリストからお話しすると、これはさきほどの「先頭とそれ以外にリストを分割する」という操作を繰り返して値を取り出します。いま、[ 1, 2, 3 ] というリストがあって、2番目の要素（「2」）を取り出したいとすれば、

21> TestList = [ 1, 2, 3 ].
[ 1, 2, 3 ]
22> [ L1 | L2 ] = TestList.
[ 1, 2, 3 ]
23> [ L3 | L4 ] = L2.
[ 2, 3 ]
24> L3.
2

として、目的の2を取り出せます。また、取り出したい要素の数が分かっているなら、

25> [ Li1, Li2, Li3 ] = TestList.
[ 1, 2, 3 ]
26> Li2.
2

のように、元の TestList というリストと同じ数の要素でパターンを作り、変数を取り出したい値の束縛対象として指定してもよいでしょう。あるいは、元のリストの要素が分かっていれば、他の要素を全く同じ値にして、

27> [ 1, List2, 3 ] = TestList.
[ 1, 2, 3 ]
28> List2.
2

のようにしても、取り出せます。

後半の二つの方法は、Erlang のプログラミングでは「＝」記号を使ったパターンマッチングと呼ばれていて、左辺と右辺のパターンを照合するという操作を行います。この照合が正しく行えたら、左辺の変数やリストなどは、右辺で該当している変数の値などによって束縛されるのです。ですから、もともとの要素が分かっていて、それを単独の変数に割り当てたいときは、

29> [ One, Two ] = [ 295, 'foo' ].
[ 295, foo ]
30> One.
295
31> Two.
foo

とすれば、One, Two それぞれにリストの値を割り当てられます。

次に、タプルの場合はどうでしょうか。タプルの場合は、ヘッダとテイルに分割できないので、このパターンマッチングを使います。

32> Tup = { ‘die’, ‘der’, ‘den’, ‘die’ }.
{ die, der, den, die }
33> { D1, D2, D3, D4 } = Tup.
{ die, der, den, die }
34> D3.
den

上記の例は、三つ目の “den” を取り出そうとした場合です。もちろん、

35> { die, der, DX, die } = Tup.
{ die, der, den, die }
36> DX.
den

として、取り出したい要素だけに変数を割り当ててもOKです。

無名変数

それでは、今回最後に、「無名変数」をご紹介しておきます。さきほどのようにパターンマッチングでリストやタプルから要素を取り出せますが、全ての要素に一時的であれ変数を割り当てるのはメモリの無駄遣いですし・・・それよりなにより面倒くさい（笑。そこで、取り出したい要素以外は「どうでもよい要素」ですから、どうでもよい要素はどうでもいいように扱えたら便利ですね。そこで、「どうでもよい変数」というのが用意されています。実際、無名変数を ”don’t care variable”（どうでもよい変数）と呼んでいる解説ドキュメントがあります。

無名変数は、アンダースコア（＿）で表されます。そこで、上記の 35>, 36> を無名変数を使って書き換えると、

37> { _, _, DX, _ } = Tup.
{ die, der, den, die }
38> DX.
den

となって、一つだけ要素を取り出すのが楽になります（ちなみに、このようにパターンマッチングを使って値を取り出す方法を「ユニフィケーション」と呼びます）。リストやタプルの要素が幾つあるのかわかっていて、ユニフィケーションで値を取り出すときは、無名変数を使うと楽ですね。

以上で今回のお話は終わりです。次回は、簡単なプログラムを書いてみたいと思います。

おまけ: Erlang の環境を作ってみる

会社で使っているテスト用のマシンは、MacMini（PowerPC 1.4GHz, MacOS X 10.4）です。Erlang をインストールするには、Linux 用のソースファイルから自力でコンパイルする方法と、MacPorts というインストールソフト（GUI でインストールするために、別途 Porticus というソフトも使えます）を使う方法があります。MacPorts でインストールするよりも好きな場所へ自力でインストールする方が、僕個人の精神衛生によいため（笑、自力でインストールしています。MacPorts か自力のどちらにしても、インストールした後は、bin の中にある erl という Erlang の実行ファイルにパスが通るように（フルパスを入力しなくても erl と入力するだけで起動するように）、環境変数に Erlang のフォルダを追加しておきましょう。なお、MacMini は社内の LAN にぶら下がっているのですが、モニターは繋いでいないので、別のマシン（僕が業務用に使っている個人マシン）からアクセスする際は TeraTerm や Putty などの ssh ターミナルを使っています。ファイルを送るときは共有アクセスできるフォルダに入れています。

Erlang を入れるだけだと、Windows 用の Erlang を個人マシンに入れてシェルを使っているのとさほど使い勝手は変わりません。そのため、Yaws という名前の、Erlang（一部 C ）で書かれたウェブサーバを入れています。これは Linux 用のソースをダウンロードしてから、make, make install で、

** etc files went into /usr/local/etc
** executables went into /usr/local/bin
** library files went into /usr/local/lib/yaws
** var files went into /usr/local/var
** default docroot went into /usr/local/var/yaws/www

という場所にそれぞれインストールされます。設定ファイルは /usr/local/etc/yaws.conf にありますので、<server>～</server> で指定する、ちょうど Apache の VirtualHost 設定のような項目を次のように書いています。

<server 192.168.1.***>
port = 8080
listen = 0.0.0.0
docroot = /Users/*******/htdocs
appmods = <cgi-bin, yaws_appmod_cgi>
</server>

設定をご覧頂くと、8080 ポートを使って他のマシンからアクセスすると、/htdocs がドキュメントルートになります。通常の 80 ポートは Apache 用に使っているため、LAN でのブロードキャストされた IP で 80 番ポートにアクセスすると、Apache で使っているドキュメントルートが表示されるので、使い分けができます。

こんにちは、TRANSの小嶋です。今回はちょっと番外編ということで、こんな記事を書いてみました。

去年、TRANSでWordPressで企業サイトを作る際によく使うプラグインというのを書いて、久々に見返すと使っているプラグインが結構変わっていたり、WordPress自体もどんどん機能が洗練されてきて、正直プラグインを選ぶ機会は減っているのですが、それでも使い続けているプラグインを自分の備忘録として書き出しておきます。

ちなみに、ここで取り上げるプラグインは「パーソナルブログの作り方」で事例として取り上げているNPtech.jpでも使っています。

特に企業サイトを制作する際に使っているプラグイン

では、早速ですが列挙しておきます（2009年7月1日に更新しました）。

Akismet

説明の必要はないですね。ブログ用のスパム対策のプラグイン。WP2.5系でもデフォルトでインストールされています。

• 参考記事：最強の呼び声高いブログ用対スパムプラグイン「Akismet」 – GIGAZINE

WP Multibyte Patch

WPのマルチバイト文字の不具合を直してくれるプラグイン。同様にデフォルトでインストール済み。

• 参考記事：WP Multibyte Patch | EastCoder;

Google (XML) Sitemaps Generator for WordPress

Googleのサイトマップを自動的に作ってくれるプラグイン。ほかにもYahooやMSN、Ask.comなども自動生成。

• 参考記事：Wordpressでサイトマップを作成する[to-R]
• 配布場所：Google (XML) Sitemaps Generator for WordPress
• 日本語化：Google XML Sitemaps 日本語ファイル – MMRT daily life

FeedBurner FeedSmith

WPのフィードをFeedBurnerにリダイレクトするプラグイン。これ、みなさん.jp（日本語）で動きますか？僕は.com（英語）のほうを使っています。Googleのアカウントに一本化されているのであまり関係なくなったのかも。

• 配布場所：FeedBurner Help Center – Creating your WordPress feed (self-hosted WordPress)

WP Super Cache

WPが生成するページをキャッシュしてくれて、ページの表示速度を速くしてくれるプラグイン。

• 配布場所：WP Super Cache

WP-PageNavi

ページネーションを割り振ってくれるプラグイン。これは必須というわけでもないのですが、結果的にほぼ間違いなく使っているので一緒に入れています。

• 配布場所：PHP ? Programming ? Portfolio | lesterchan.net
• 日本語化：WP-PageNavi 日本語版 – MMRT daily life

WP-DBManager

DBのバックアップをメールやファイルなどで手軽にできるプラグイン。

• 配布場所：PHP « Programming « Portfolio | lesterchan.net
• 日本語化：WP-DBManager 日本語版 – MMRT daily life

Revision Control

投稿やページの変更履歴を保存する機能をWordPressは持っているのですが、その機能をオフにしたり履歴を保存したりすることができます。

• 配布場所：WordPress › Revision Control « WordPress Plugins

雑談

企業で使えるオープンソースCMS一挙12種類解説（機能やインストール/管理の難易度評価付き） | Web担当者ForumでWordPressが紹介されなかったので、WPもCMSとして頑張ってくれるんだよ！という主張です。

それにしても1年前と比べると利用するプラグインが本当に減りました。テーマの作り方がうまくなったのか、いややっぱりWPがうまく成長しているんでしょうね。TRANSでは以下の記事も参考に。

• WordPressテーマ（テンプレート）カスタマイズのまとめ（日本語訳）
• WordPressでECサイトっぽいテンプレートを作る。
• WordPressで企業サイトを作る際に押さえておくべき10個のこと

2種類のクライアントとヒアリングシート

ちょっとパーソナルブログの話から離れますが、1つのサイト、もしくはブログを運営するにあたって気をつけなければならないことがあります。それはクライアントは2種類いるということを忘れないことです。これを忘れてしまうと、サイトの方向性がかなり捻じ曲がってしまいます。

2種類とは、サイトを見てくれる訪問者とサイトの制作を依頼するクライアント。この2種類。

訪問者さえ満足してくれればそれでいいやん！というのもあながち間違いではないのですが、受託開発型の場合はそうも言ってはいられないのが辛いところ。お金の出所というのはすごく重要です。

そんなために、僕がサイトを制作する時は大体2つのヒアリングシートを使い分けます。それがこのヒアリングシート。ダウンロードできるようにしておきますので、適当に改変するなり何なりして使ってやってください。僕もいろんなヒアリングシートを参考にしながら、項目を追加したり、抜いたりして作ってきたものです。

• ヒアリングシート

内容は「基本事項」というお金を出してくれるクライアントと「顧客」という訪問者向けにシートを分けています。本当は、「顧客」のほうはサイトを見てくれそうな人たち（見込み客）にグルインするのがよいのですが、小規模サイトの場合は時間的にも予算的にも難しい。そんなときはそのクライアントの営業さんなど、直接お客さんと折衝する人たちの意見を聞くと参考になることが多いです。

また、ここでヒアリングシートという媒体に落とし込むのは主に3つの理由があります。

1. クライアントとドキュメントを共有し、共通認識を図るため。
2. 意見や理解を言語化することにより、アイディアを形にするため。
3. あらかじめ聞いておくべきことを忘れないため。

ちなみに、NPtech.jpの制作においてもこのシートはざっくりとですが、どちらとも使用しています。それによって、頭でぼやーと考えていたものをより明確にする狙いがあるからです。そのため、こういったシートが手元にあれば、ぜひパーソナルブログを作る際も活用したほうがよいと思います。

それと、ほかにも個人的にいくつかシートは持っているのですが、そのアイディアをくれたブログの記事も紹介しておきます。

• WEBディレクションで使うＩＡツール : ユージック

そんなこんなでパーソナルブログでヒアリングシートを使ってみるのも悪くはないよっていう話でした。

まずはじめに断っておかないとダメなことがあります。それは、このテーマでは単に日記を書くためのパーソナルブログではなく、どちらかというと情報発信をしていきたい！という方向けの話になります。そこで、パーソナルブログといっても、実際には企業サイトの制作フローをベースに説明していきますので、もしかすると日記を書きたい！と思っている方には少し話が堅くなるかもしれませんが、ご了承ください。

類似テーマのブログを探す

まず、僕が始めにしたことは、自分が書くテーマと似たような内容を扱っているブログを探すことでした。感覚的にはわかっていただけると思うのですが、ブログにしてもネットにしても、オンリーワン（笑）というのが非常に際立つメディアです。そのため、すでに類似のテーマのブログが数多くあり先駆者がいるということは、そのブログとの競争的なところが発生しますので、どうしても情報の影響力を持っておくのは難しくなります。そこで、まずは類似のサイトを探すことから始めます。

ただ、類似のサイトがたくさん見つかったからといって悲観的になる必要はありません。その中で扱われていないニッチなテーマをうまく探し出せばよいのです。いわゆるポジショニングです。

例えば、TRANSという僕のブログでは現在主にアクセシビリティのテーマを扱っていますが、元は単なる日記から始まり、CSSやWordPress、そして翻訳記事と移り変わって、今のアクセシビリティをメインに書くブログになっています。かといって、既にアクセシビリティのサイトは数多くあり、その中で自分の独自色をどのように打ち出していくのかがポイントでした。

その中で僕がポジショニングとして意識したのは、ビービットのユーザビリティ実践メモのアクセシビリティ版を目指そうというものでした。こういった実践的な内容でアクセシビリティを扱ったブログがなかったからです。このように、はじめからそのポジショニングがうまくいかなくても仕方がないのかもしれません。徐々に軌道修正しながら面白い、独自性のある情報発信をできればいいと思うのです。

ユーザ、もしくは見込み客にインタビューする

その上でできれば自分のブログを将来的に読んでくれそうな人にも意見を聞いておきましょう。その人はどんなブログを普段読んでいるのか、どんなことに関心があるのか、など。簡単でもよいので意見聞いておき、かっこよくいえばペルソナ的なものを頭にイメージできるようにしておくと後々にブログのデザインや情報設計をする際に役立つことと思います。

個人的にはパーソナルブログだからこそ実験的なことも行うとよいと思いますし、はたまたこのディレクションのようなステップを踏んでおくことが重要だと思います。次回はヒアリングシートなどを使って、もう少しブログのベース部分を考えてみます。