企業システムのクライアントをどう作るのか---古くて新しい問題が今，ホットだ。「リッチクライアント」を使えば操作性の高いGUIが実現可能。また，「シンクライアント」の導入により管理性が向上できる。リッチかシンどちらか一つにフォーカスした情報は少なくない。しかし，クライアントの歴史は操作性と管理性の綱引きだったと見る筆者は，二つを一緒に議論すべきだと考える。筆者が所属する「日経SYSTEMS」では，こうしたクライアントの最新動向を，今年から来年にかけて発信する予定だ。

C/Sシステムからの脱却で操作性が犠牲に

　まず，筆者が考える“操作性と管理性の綱引き”とはどういうものか簡単に説明しよう。ECサイトや販売管理，なんでもかまわないので，データを入力して登録するような画面を思い浮かべてほしい。「入力項目は必須のものだけが表示され一目瞭然，入力値の候補がプルダウンで示される，入力値の妥当性は自動的にチェックされる」---システムの使い手であるユーザーは，こうした操作性の高いクライアントを望む。

　一方，クライアントの管理性を向上したいと願うのは，システムの提供側，とりわけ運用担当者である。クライアントOSやその上で稼働する各種ソフトウエアのバージョン管理やパッチの適用作業に，相当の苦労を伴うからだ。社内の隅々に行き渡ったクライアントの管理に手を焼く声は，取材でもよく耳にする。

　こうして見ると，クライアントの要件は利用者の望み(操作性)と提供者の望み(管理性)が互いに引っ張り合い，静止したところに落ち着く。これが筆者の考える「クライアントの綱引き」である。

　さてこの綱引き，操作性と管理性のバランスは時代によって移り変わる。形勢が大きく動いたのは，クライアント/サーバー(C/S)からWebへとシステム構築の手法が広がった1999年ころだろう。インターネット技術をベースにサーバー・サイドJavaが主流になり，Webシステムの構築事例が増え始めた。このとき，クライアントに求められる要件は，操作性から管理性へと大きく振れたのではないか。

　C/Sシステムのクライアントは，クライアント側のシステム・リソースを有効活用し，とても操作性の高いGUIを実現できる（このタイプのクライアントをファットクライアントと呼ぶ)。その全盛時代は，Visual Basic（VB）に代表されるGUI開発ツールを使い，先に挙げたような操作性の高い画面が次々と生み出された。その半面，クライアント管理の煩雑さが運用担当者を悩ませることになる。VBのモジュールやランタイム，DBに接続するためのモジュールなどをクライアント一台一台に導入し，そのバージョンを管理する必要があるからだ。

　対策の一つとして，これらソフトウエアをサーバーで一括管理し，必要に応じてクライアントへと送り込む「ソフトウエア配布」の仕組みが確立された。確立されたといっても，すべてのクライアントに確実に配布するにはノウハウが必要で，筆者もそうしたクライアント運用の記事を書いた覚えがある。

　WebシステムではWebブラウザさえあればアプリケーションが実行できるので，ソフトウエア配布は不要だ。アプリケーション・ロジックはすべてサーバーに集約されている。C/SシステムからWebシステムに移行することで，クライアントの管理性は高まった。ただし，その引き換えに操作性が犠牲になったのである。

プラス・アルファでWebアプリの操作性を上げる

　HTMLは文書を閲覧したり検索，リンクしたりするための言語である。だから，これをベースとしたWebアプリケーションの操作性や表現力が低いのは当たり前。Webブラウザを企業のクライアントらしくするには，HTMLを駆使した上で，HTTPのセッション管理や，「戻る」ボタン対応など多くの工夫が必要だった。ただし，いくら工夫で補ったところで，その操作性はC/Sシステムには及ばない。そこで，HTMLにプラス・アルファすることで，より凝ったGUIを実現しようという動きが起きる。これが，リッチクライアントの源流だろう。

　HTMLにプラスされたものは，JavaScriptやWebブラウザのプラグイン・ソフトである。JavaScriptの利用は，今では「Ajax」というまとまりでとらえたほうがピンと来る。プラグイン・ソフトはAdobe Systemsの「Flash」，米Nexaweb Technologyの「Nexaweb Platform」，アクシスソフトの「Biz/Browser」，米Curlの「Curl」など様々ある。
　
　Ajaxは，「Dojo」や「Zimbra」などAjaxフレームワークが充実したおかげで，開発やテストが従来より容易になった。また，Adobe Systemsの「AIR」のように，Webブラウザに依存しないアプリケーションを構築できる製品も登場してきた。製品・技術が充実し，使いこなし方が分かってきたことで，リッチクライアントが普及期を迎えつつある。

　一方，シンクライアントは1996年に発表された「NC (Network Computer)」が脚光を浴びる。ハードディスクを持たない端末をクライアントとし，アプリケーションやファイルはサーバー側で一括管理しようというコンセプトだ。現在，シンクライアントには「サーバー・ベース」「ネットワーク・ブート」「ブレードPC型」といった方式があるが，このコンセプトは共通である。ハードディスクを持たないことで，最近ではデータ持ち出しへの対策になるといった，セキュリティ面の評価が高い。また，ソフトウエアや処理をサーバー側に集中配置しているので，クライアントの管理は容易だ。

　では，リッチクライアントとシンクライアントはどのような関係にあるのか。

そして「綱引き」から「共存」へ

　C/Sシステムで互いに引き合っていた操作性と管理性は，二つのレイヤーに分かれ，リッチクライアントとシンクライアントへ進んできた。前者はアプリケーションのインタフェースを受け持ち，C/SのGUI→HTML→リッチクライアントと変遷。後者はクライアントのシステム・リソースと処理の配置に注目し，C/Sのクライアント(ファットクライアント)→シンクライアントと進んだ。ただし，後者がカバーする処理にはアプリケーションも含まれているので，そこに重なりがある。

　この重なりは両者を併用するときの考慮点へとつながる。一例を示す。まず，サーバー・ベースのシンクライアントを導入したとしよう。これにより，クライアントで利用したいアプリケーションは管理サーバー上で実行される。クライアントとなる端末はサーバーに対してキーボードなどの入力情報を送り，処理結果の画面を受け取るだけだ。この仕組みは，Windows Server 2003の「Terminal Service」や米Citrix Systemsの「Citrix Presentation Server」(旧MetaFrame)などで実現できる。

　さて，このシンクライアントの上でAjaxで実装したリッチクライアントを動かしてみよう。単純に考えれば，WebブラウザとAjaxアプリケーションは，管理サーバー上に配置することになる。すると処理の流れはこうなる。クライアントの端末から入力情報を受け取った管理サーバーは，Ajaxアプリケーションに入力値を渡す。Ajaxアプリケーションは，アプリケーション・サーバー上のアプリケーションと非同期でやり取りしながら，処理を進める。そして端末へは処理結果の画面が転送される。クライアント端末<--->管理サーバー<--->アプリケーション・サーバーとつながる構成を頭に浮かべてほしい。どこか冗長だと感じないだろうか。処理が多段になっているので，パフォーマンスも心配だ。

　改善策としては，WebブラウザとAjaxアプリケーションをクライアント端末に導入することが考えられる。ただし，せっかくシンクライアント化してクライアント環境をサーバー側で一元管理したのに，WebブラウザとAjaxアプリケーションについては管理が別になってしまう。もし，シンクライアントを使いながら高い操作性を実現することが目的であれば，リッチクライアントを使わないという選択もある。管理サーバー上でC/S型のGUIを提供する方法だ。おそらく，シンクライアントとリッチクライアントの掛け合わせ方は，導入の目的や既存システムの有無といったパラメータにより変わってくる。

　クライアントの要件は，操作性と管理性の「綱引き」から「共存」へと変わってきたと筆者は考えている。両立できるなどと簡単には言えないが，その可能性は高まってきたのではないか。ITアーキテクトが腕を振るい，うまいアーキテクチャを考えていくことが求められる。冒頭で紹介したように，「日経SYSTEMS」では最適なクライアント作りを支援する情報を今後，発信していく。第一弾として，12月号でリッチクライアント技術をひも解く。クライアントについて意見を寄せていただけるとうれしい。