次の英単語の意味は？：Illustrate
数年前にどこかの英語の試験で出た問題。職業のイラストレータしか頭にない者へのひっかけ問題で、答えの選択肢には「絵を描く」というのがない。「説明する」がその時選ぶべき答えだった。
「絵を描く」ことが、「説明する」ことにつながっている。絵にすることが物事の解説につながっている。そう思えて、嬉しく、忘れられない問題になった。何かの絵を描くとき、その一面しか見えていなかったなら、人に説明できるだけの情報量になっていない。実際デッサンをするときは、描く時間よりも見ている時間を多くするようにアドバイスされることが多いし、見えるはずもない(描かれるはずもないない)反対側にまで回り込んで観察した上で描いたりする。絵に描けるということは、全体像を掴んでいることを前提にしていると感じることが多々ある。そして、その想いは、Web の世界に入ってからも益々強くなっている。
Webサイトの構造を誰に説明するときも、必ず「絵」を使う。道具は、ほぼ間違いなく Adobe Illustrator だ。手に馴染んだペンのように直感的に絵を描ける(最近のは重いけれど)。込み入った絵を描きたい訳じゃない、サイトの構造を描き、それにコメントやアイデアを書き込む。描いているうちに、浮かんだアイデアの長所も短所も見えてくる。描きながら考えて、考えては描き続ける。
今ままでの経験で最終決定の権限が与えられたことはない。だから、基本的に描かれるのは推薦案であり、その絵の中には長所や短所が含まれていて、判断材料にしてもらう。わざわざ正直に描きすぎて結論が出なかったこともある。けれど、議論がそこからスタートする。一目瞭然の絵でサイトの構想が描かれているので、意見が出しやすい。厚い文字だらけの仕様書を持っていっても、こうは行かない。先方が読んでいるうちに、作くろうとする情熱がどことなく冷めていく。
始まった議論は、大抵はこちらの意図と少しずれたところに着地する。本当はどうだろうという疑問もなくはないが、描いた当人には達成感が残る。なにしろ、早く結論が出たんだから、それを最優先に歓迎したい。時間が無駄に流れていくことが一番辛いことだと思うから。そして、絵を見せた先方がたにも花を持たせる。自分達で結論を出したんだと思わせることで。一目瞭然の絵があればこそ引き出せた結論である場合が多いと思う。しかし誰にも感謝されない、偉いとも言われない。自分なりに綺麗に描いた構想図が、皆の赤ペンで書きなぐられた跡を見て、孤独な達成感に浸る。
何も語らない「絵」が雄弁だと思える。言葉にすると百人百様の表現があるかもしれないが、そのサイトを表す最適な「絵」が描けたとき、そのサイトの最大の理解者になれている気がする。
でも、「縁の下の力持ち」は絵だけじゃない。一覧表だってそうだし、ログだってそうだ。最終的に表に出て行くグラフィックに比べると、地味な作業だ。多種多様な情報を一目で分かるようにするために一覧表を作成する。アクセスの実体を見抜くようにログをつぶさに見ていく。大抵は夜に、それも随分と遅くなってからする作業のようにも思う。決して主役ではない作業。でもなくてはならない作業。言わば脇役のような存在。しかし、名脇役であれば、そのサイトを輝かせるのに一役も二役もかってくれる。映画と同じだ。そして見る人によっては、脇役が主役を喰ってしまうことだってある。
サイト構築の主役は、Dreamweaver や GoLive や Text エディタで充分だ。この主役達をより輝かせる助演男優賞/女優賞を取れるツールはないだろうか。
サイトマップを自動的に生成したい。作成した絵は他のツールで加工したいし、ブラウザで他の人にも見て欲しい。イメージのサイズやALTの情報を一覧表にしたい。ページやイメージの一覧表は作れないか、作られた一覧表は EXCEL で開きたい。作成された一覧表を、何かで編集した上でバッチ的データ処理に使いたい。
こんなことは夢想にすぎないだろうか？ いや、こんなことこそコンピュータがやるべきじゃないか？ だって、どの絵を選ぶかどの情報を見るかという判断フェーズを除くと、全て単なる定型データ処理じゃないか。
「Ridual」は、そんなコンセプトで開発が進められている。だから説明がしにくい。どの処理も頑張れば皆誰もが作れるアウトプットだ。今までデモをしてきた感触でも、指示系統に属する人にはピンと来てもらえない。「サイトマップ作って」、「リソースの一覧表作っておいて」の一言で済む作業だからだ。そして勿論、人間相手の方が融通がきく、最終アウトプットのレイアウトも好みに合わせてくれる。でも、やはり問いたい、「優秀なデザイナに、そんな作業をさせて良いの？」と。
iModeサイトのサイトマップを自動生成してみた。総200ページ程度。一部分だけが、突出した深さになった。開発に携わる者ならば誰もが知っている、仕様変更が幾重にも重なった機能の部分だ。そのマップを生成する時間は、ファイルの読み込みからサイトマップを実際に出すまでに約20分(Pen3/700MHzクラスで)。クライアントはその絵を一枚みただけで、そのリニューアルを決心する、「これほどのパケット通信料を払って誰が最後の画面(ゴール)まで来るのか」と。
この実話は、開発を進めてきたことへの不安を払拭させてくれた。ここでは何が効率化されたのだろうか。サイトマップの自動生成(デザイナの負荷軽減)？、クライアント説得材料の準備(プロデューサワーク)軽減？、コミュニケーション(情報交換の)効率化？ 多分、全部だ。そして、その全ての効果よりも大切なものを恐らく生んだと思っている。それは、「やる気」だ。一枚の絵がクライアントを動かし、次の「より良いサイト」目指してチームが動くようになる。しかも今度は同じツールで測れば(サイトマップを見れば)、そのアクセスのし易さが一目瞭然なのである。これで鼓舞されなければ嘘だろう。
これはベストに近い成功事例だ。毎回こんなドラマを生めるツールには育っていない。まだまだ裸のエンジンに近い。動的ページが主になっている時代に、PageMill ver.1 を開発しているようなものだ。でも、もう暫く開発を進める予定です。時間がない方々にお願いしていることは重々承知で、ご意見を期待します。
以上。/mitsui