Ridualというアプリケーションを開発する際に、諦めたものがある。Webサイト開発をメインにすること。矛盾するように聞こえるかもしれないが、開発ツールの開発を選んだ時点で、開発の現場に居続けることは無理だと分かっていた。なにしろ体は一つしかない。
それ程の数のサイトを手がけてきた訳ではないが、自分の手の届く範囲で最新の考え方を取り入れたサイト開発を心がけてきた。様々なツールに囲まれながら、それほど不自由していた訳でもない。それでも、何かしらこの先へ進むのに、ためらいを感じる様になっていた。このまま、サイトデザイナとして進んでいくことも許されたかもしれないが、XMLという魔法を信じることにした。
ためらう理由は一つ。サイト開発をして行く上で、新しく面白いことの比率が、しなければならない通常の作業の比率に比べて、余りに小さくなっていく予感があったからだ。
山ほどのリソース、海ほどのドキュメント。遭難しそうで、溺れそうな量。品質管理の大切さは知っているし、そのための作業だと知っていながら、手が動かない。アイデア発想を「直接的ワーク」と呼ぶのに対して、管理的な作業を「間接的ワーク」と呼ぶと、後者の割合が徐々に大きくなっていく。HTMLのコーディングよりもOfficeを使っている時間が長くなり、これで良いのかと焦りを感じてきた。
しかも、根っからの凝り性が気になる。officeによるドキュメントもやり始めれば、凝ってしまう。一生懸命綺麗なものに仕上げる。レイアウトも索引も揃った、綺麗なドキュメントが出来上がったとき、喜んでいる自分に気が付いた。あれ、これで良いのか？
内部ドキュメントは、エンドユーザに見られることはない。開発の記録のようなものだ。しかし、生々しい記録ではない。クライアントに見せられるように、最終段階のまとめが中心だ。メンテナンスをする上ではこの上ない資料も、開発してきた自分にとっての必要性はどんなものか。次の開発の支えになる資料とは、その綺麗さではなく、本当のところは何に迷って何を基準に選択してきたかという思考の履歴だと思う。そこにエンドユーザをどう捉えるかが潜んでいる。そこがごっそりと抜け落ちている。
しかも、作られた資料の正確さと、それが使われる現場の様相を知っている。資料は大量になればなるほど、制作に時間がかかる。それは、日々刻々と変化しているWebサイトを考えると、最良でもリリース時の話でしかない。ドキュメント作成時間というタイムラグは避けようがない。更に自分がメンテナンスする側になっても喜んで読みたくなるような書き方のされたものには中々お目にかかれない。ドキュメントとして整備すればするほど制作に時間がかかり、整備されて分厚くなればなる程読まれなくなる。ドキュメントはかくも辛い宿命を背負わされている。
勿論良いドキュメントも存在する。作るに早く、読むに簡単、読者に明確で迷いも与えない。ドキュメント制作も含めたワークフローが確立しているところは、そんな簡潔な「解」に行き着いている。但し、多分文化的な違いに泣かされている。予算と提出資料の分厚さが比例しなければならない文化圏で仕事をする場合だ。
プログラミングの世界でも、ドキュメントは大きな課題だった。様々な試行錯誤を経て、最近はやはりソースコードから自動生成という形に落ち着いている。ナマモノはやはり素材そのものに聞くしかない。わざわざ資料作成タスクを作ることはない。ソースコードからアプリケーションだけが生成される時代じゃない、ドキュメントも最新版を生成する。
それがWebサイト開発では上手く回らない。ソースコードのように「機能する」部分だけで構成されていないからだ。レイアウトのために様々な工夫がなされている。そこから大切で人に伝えるべき情報を引き出すのは、プログラムではできなくて、やはり人間の仕事になってしまう。レイアウトに凝れば凝るほど、ドキュメントで自分の首を絞める結果になる。一子相伝のような職人技であるならば、他人がメンテをすることもできない。結局その人にお願いすることになる。それならその人が記憶を辿れる資料があれば事足りるのかもしれない。やはり堂々巡りに陥る。
でも、一筋の光が見えた。CSSだ。レイアウト情報を分離して、レイアウトとして機能する部分だけをまとめることができる。ある程度の自動処理が可能だ。複雑なテーブルレイアウトを解析するよりも遥かに論理的な部分だけでできそうだ。次期Ridualの始まりだった。
そして、再び壁に当たる。次期Ridualの話をすると、「山ほどの実績がある俺たちには、それが必要そうに見えない」、こともなげに言われる。場数を踏んでいないことは信頼に足りない事だそうだ。でも、そのチームも少し見ているだけでも、楽に開発が進んでいるとは思えない。なんだかいつも泥沼に片足をとられている。直接的ワークよりも間接的ワークの方が多そうだ。それも場数が少ない目に映る幻想か。
実際のところ、Ridual Ver.1でも同じような壁はあった。ベータテストをお願いしたところからは、ことごとく「Aができないから駄目」という否定的な答えしか返って来なかった。自分達の経験(文化)ではAが必要で、それができないものは、他に何ができても不要。多少の恨めしさを加味して大袈裟に書くとこんな感じか。
それで、Ridualの場数補強はどうしたのか。様々な知恵や経験則を刷り込むにはどうしたか。Ridualがダウンローダを装備して、既存サイトをお邪魔させてもらった。ディスクをやたら消費するのでキチンと保存していないが、面白そうなサイトがあると、そこにチャレンジする。自分が面白いと思った情報をRidualが取ってこなかったら、Ridualが青臭い。どんな条件に反応すべきかを調べて、その解析能力を鍛える。これを繰り返した。
太古のコードが現役であるサイトに一番泣かされた。全然HTMLじゃない。なのにブラウザでは表示される。ブラウザって偉いもんだとため息が出た。でも、綺麗なHTMLしか相手にしないというタカビーでは、Ridualが相手にされない。あくまで現場主義で行く決心がついた。
そうして、リリースできたRidual Ver.1だが、もう一つ教訓を残してくれた。場数が大切な訳ではない。「優れた場数」が必要なのだ。同じ人が作ったサイトは、コードの使い回しが目に付く。それは必ずしもベストなものでなかったりする。恐らく、数をこなして身についている知識よりも、少なくても大変なサイトを経験して得られた知識の方が、スケール的に大きいのだろう。そして、Web屋の知識とは、このスケールの大きい方の話なのではないだろうか。
場数が足りないとの批判に対する心構えをもう一度思い出して、Ver.2に取り組む。間接的ワークの軽減は、先に進むための足場作りをして行くことと同義だ。そうして見回すと、様々なフリーウェアやシェアウェアが既にある。それが存在しているということは、既にそのツールがないと先に進めないと思える状態になっているのだろう。先達はいつも遥か先にいる。早く追いつきたい。
以上。/mitsui