Ajaxのシステムを構築する際，やってはいけないことは，「ユーザー・インタフェースを下流工程で大幅に修正することだ」（Web開発を手がけるアークウェブ 最高技術責任者 志田裕樹氏）。クライアント側でJavaScriptのロジックが動作するAjaxでは，クライアント側での実行結果をサーバー側に保存する場合もあり，ユーザー・インタフェースの変更はサーバー側のロジックやデータベースのテーブル構造に影響を及ぼしやすい。上流工程でしっかりと操作性を設計し，下流工程で修正しないようにしたい。

　そうした開発プロセスのベースになるのは，「ユーザー中心設計（UCD）」である。徹底して利用者の目線に立ち，使い勝手の要件を洗い出したりテストしたりする。「最近はAjaxで過剰な演出をしているサイトが少なくない。本当に利用者のためになる操作性や演出かどうかを考えないと，サービス提供者や開発者の自己満足になってしまう」（ゼロベース 田中氏）。

　開発を進めるに当たってAjax特有の標準化項目がある（図1）。標準化すべき項目は，デザイナとクライアント開発者の間，クライアント開発者とサーバー開発者の間にそれぞれある。

図1●Ajaxの開発プロセスと標準化すべき項目
図1●Ajaxの開発プロセスと標準化すべき項目
[画像のクリックで拡大表示]

　デザイナとクライアント開発者の間では，操作性やデザインを統一するためのルールと，デザインとロジックを分離するためのルールなどを決める。HTMLのデザインを決めるCSS（Cascading Style Sheets）には，JavaScriptで操作するためのID属性を割り当てることができる。このID属性の名前や命名規則をあらかじめデザイナとクライアント開発者で取り決めておく。そうすることで，HTMLデータ内にJavaScriptコードを書く必要がなくなり，分業が容易になる。これらは，Ajaxを使った名刺作成サービスを開発したフォトクリエイトの小澤拓摩氏（開発本部）やゼロベースの米谷和馬氏（クリエイティブディレクター/デザイナー）らが徹底しているポイントだ。また，「Webブラウザの標準モードと後方互換モードのどちらか，もしくは両方を想定するかの取り決めも欠かせない」（サイボウズ 開発部 生江憲治氏）。

　一方，クライアント開発者とサーバー開発者の間で標準化すべき項目の代表例は，同期通信か非同期通信か，リクエストとレスポンスのデータ形式に何を使うか，の2点である。Ajaxでは非同期通信を使うことが多いが，「送受信の順序保証が必要な場合は同期通信を選択すべき」（オープンストリーム 川道氏）である。実際，この連載第2回の図1で示したプログレス・バーは，パフォーマンスが1割程度落ちることを覚悟して同期通信で実装した。非同期通信にして通信の順序が入れ替わってしまうと，処理の進捗が戻ってしまうことになりかねないからだ。

　リクエスト/レスポンスで多用するデータ形式を大別すると，XML，JSON（JavaScript Object Notation），テキスト/CSV（Comma Separated Values），HTML部品の4種類がある。これらは，サーバー側の非同期呼び出し機能をサービスとして再利用する可能性があればXML，クライアント側でレスポンス・データの後処理が必要ならばJSON，後処理が不要で表示するだけならHTML――といった使い分けが可能だ。パッケージ・ソフトの開発ならば「伝送するデータに応じて使い分ける」（NIコンサルティング創発部 部長 ソフトウェアアーキテクト 上田廣昌氏）という考え方もあるだろうし，業務システム開発では「保守性を高めるために統一する」（オープンストリーム 高安氏）という流儀もあるだろう。