1960 年生まれ，独身フリー・プログラマの生態とは？　日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から，現在に至るまでの生活を振り返って，週1回のペースで公開していく予定です。プログラミングに興味がある人もない人も，フリー・プログラマを目指している人もそうでない人も，“華麗”とはほど遠い，フリー・プログラマの生活をちょっと覗いてみませんか。
※　記事は執筆時の情報に基づいており，現在では異なる場合があります。

　正直なところ，私はコンピュータ技術のトレンドにあまり敏感なほうではない。新しい用語が登場するたびに調べるのは手間がかかるし，技術情報サイトに満載の「新しいぞ」「使えるぞ」「できるぞ」の押し売りにもうんざりしているからだ。今回取り上げる「Ajax」についても同様で，最初に見かけたときに軽く意味を調べておいた程度だった。どうやらJavaScriptの技法に新しい名前を付けて，例によって「新しいぞ」と騒いでいる，というのが第一印象であった。しかし，頻繁に見聞きするようになるとだんだん気になり始めてくる。いったい何が話題になっているのだろう。もう少し具体的に把握しておいたほうがいいのかもしれない。

　いくつかサイトをまわって，サンプルを二つ，三つ読んでいるうちに，これはどこかで見たことがあるぞ，と思った。あれは確か，Windows NT 3.51か4.0で，IISのバージョンがまだ3.0ぐらいのころだったと思う。IIS管理ツールのWebインタフェースを使っていて，ディレクトリのツリーを表示する部分の動きが珍しかったので，いったいどんな実装をしているのだろうと思ってコードを読んだことがある。実はブラウザのスクリプトを使って，裏でこっそりHTTP通信をして，ツリーを書き換えていたのだ。

　ああ，こんな技法もあるんだなと感心した記憶がある。ポップアップメニューを表示したり，テキストボックスへの入力に追従してインクリメンタル・サーチする機能も，よく考えてみると別に目新しくはなく，JavaScriptで書いたHTMLエディタさえも，Yahoo!メールのWebインタフェースでおなじみであった。JavaScriptとDHTMLの応用という側面だけをとらえれば，あの「アクティブ・デスクトップ」の再来なのではないかと感じられる面もある。

　さて，それではいったい何がトピックなのだろう。それはやはり，こういう技法集に「Ajax」という名前を付けて周知を促したことにほかならない。もちろん，以前からあるものに名前を付けただけではない。いくつかの点においては，整理され，方向性が示されている。

　例えば，表示を書き換えるロジックにDHTMLを使うという設計。ActiveXコントロールを使うと動作環境が限られてしまうが，DHTMLなら，少なくとも理屈のうえではブラウザの互換性だけを考えればよい。裏でこっそりHTTP通信するときのデータ形式。これは別に設計者が勝手に決めてもよいのだが，XML-RPCとかJSONのような仕様を持ってくれば手っ取り早い。このようにして，実装に必要な要素技術の土台がある程度示されることで，固有名詞を冠する「価値」が出てくる。

　もちろん，批判的な意見もあるに違いない。例えば動作環境をWindows＋IEに限定するなら，画面の書き換えから通信処理まで，すべてActiveXコントロールでやってしまえばよい。ActiveXが嫌いならJavaアプレットだってよいはずだ。マルチプラットフォームと言ったって，IE以外のシェアがどれほどのものだろう。こう考えると，「Ajaxというのは，要するにアンチ・ベンダー的な実装を追求したものにすぎない」とも言える。つまり，大手のソフトウエア・ベンダーの支配から逃れるためだけに，わざわざ苦労してJavaScriptでコーディングしたり，文字列の結合を使ってHTMLを組み立てたりしているのだ。

　しかもおまけに「リッチ・クライアント」という言葉まで浮上してきている。少し前にシン・クライアントを持ち上げていたのは誰だったっけ。シン・クライアントではサーバーに負担がかかるばかりか，大衆向けのハードウエアの売れ行きに影響するということにやっと気がついたのだろうか。しかし，こちら方面の考察はこのぐらいにしておこう。行き過ぎると宗教論争にしかならないのは目に見えている。それよりもっと大事なことがたくさんある。

　一つは，ルック＆フィールについて。例えば「ダイアログというのはこういうものです」といった一定の基準は，本来はOSが提供しているものである。AjaxアプリケーションはJavaScriptの機能を使って描画するわけだから，プラットフォームのデスクトップにマッチしたデザインになるとは限らない。操作性もしかりである。

　そんなのはJavaScriptでコーディングすればいいではないか，と言うかもしれないが，現実はそれほど甘くない。いや，それよりも怖いのは，「何でもあり」だと勘違いした設計者が，変てこなユーザー・インタフェース仕様を出してくることである。ざっと画面を眺めただけで見積もるととんでもないことになるかもしれない。ベータ版を見せてから「このポップアップメニューはスライド表示で」とか「この部分はマウスの動きに合わせてスムース・スクロールで」などと，設計書に書いてないような要望が繰り出されたら，たまったものではない。

　もう少し深刻な問題は，スキルの高いウェブ・デザイナーの確保である。私の知っている範囲にすぎないが，例えば有名なブログ・システムについて，自由にスキンを作成できるデザイナーがどれだけいるのだろうか。顧客からの様々な要望に対してAjaxアプリケーションをばりばり開発するには，デザインと制作の連携が不可欠になる。

　「そんなのはDreamweaverのプラグインにしておけばいい」という意見もあるに違いない。しかし，プラグインを使って誰でも楽々とAjaxアプリケーションを開発できる状況になれば，Ajaxであることを理由に開発費を上乗せすることは難しくなる。そうなる前に投資して「Ajax対応」をうたうことで単価を上げるか。それとも，誰でもできるようになるちょっと手前でこそっと稼ぐか。同業者の思惑は様々であるに違いない。もちろん「この案件はぜひAjaxで」と指定してくる顧客がいればの話であるが。