TOP設計・移行・活用> はじめに




Biz/Browser
Biz/Browserで経営の効率化を実現する

第1回:リッチクライアントとBiz/Browser
著者:アクシスソフト  永井 一美   2005/9/14
1   2  3  4  次のページ
はじめに

   近年「リッチクライアント」という用語が業界で浸透してきました。リッチクライアントとは何かということについては「リッチクライアントの現状と今後の動向」にも詳しく書かれていますし、インターネット上で多くの情報が載っていますので、詳細を説明するのは割愛しますが、端的にいえば、「C/S(クライアント・サーバ)とWebシステムの双方のメリットを提供するソフトウェア」といえます。
   一般的にリッチクライアントとしての特徴は、エンドユーザに操作性の良いGUI(グラフィック・ユーザ・インタフェース)画面をフロントエンドとして提供することと、アプリケーションはWebでのサーバ集中型として配布コストを抑えることです。

   本連載では、「リッチクライアント」カテゴリーに位置づく「Biz/Browser」について、生まれやコンセプト、簡単な画面作成、事例などを通して説明していきます。

   Biz/Browserの生まれは、1998年に遡ります。当時は、業務システムのWeb化がはじまった頃で、「リッチクライアント」という用語も存在はしていましたが、今のようなカテゴリーで捉えられてはいませんでした。

   Biz/Browserについて説明しても、役割を理解していただくのに苦労しました。HTML以外のものを利用することにも拒否反応がありました。Web化そのものに対しても「する必要がない」と門前払いされてしまうことも多かった時代です。
Biz/Browserの生まれ
図1:Biz/Browserの生まれ
(画像をクリックすると別ウィンドウに拡大図を表示します)

   開発動機は単純明快です。C/Sで構築されていたシステムをWeb化しようとしたとき、Visual Basicなどで実現できていた「操作性」をHTMLベースでは作れず、レスポンスも業務に耐えられるスピードを持てなかったからです。「何とかならないか?」そして「エンドユーザの利便性を継承するために何とかしたかった」それが出発点です。

   C/Sはホスト、オフコンでの端末UIと違い、GUIが進化し操作性を高めてきました。しかし、以下のような大きな問題を抱えていました。

  • 全クライアント端末にソフトウェアを配布しなければいけない
  • クライアント環境に対する依存度が高く端末によって動かない

表1:C/Sの問題点

   Webは、もともと遠くの文書を閲覧したいという目的からはじまりましたが、インターネットが安定し、安価に利用することができて、セキュリティも守れるようになりましたから、Webのしくみの中でC/Sと同等のフロントエンドを利用できることは、誰もが持っていたニーズだったのです。

   Biz/Browserを開発できたのは、以前のシステムより劣るものを技術の壁が原因で作らざるを得ない、技術者のプライドとして許せなかった面が強いと思います。


管理コストとエンドユーザコスト

   システムをWeb化することによって、管理コストは大きく削減できます。

   しかし、フロントの操作性を犠牲にすることでエンドユーザの生産性を落とせば、システムの管理部門が得るコストメリットより、エンドユーザ数に比例する生産性悪化コストの方がはるかに大きく、企業全体のコストは増えてしまうことに気づく必要があります。また、サーバ側やインフラのしくみは大変重要ですが、エンドユーザにとって「ユーザインターフェース」はまさにシステムそのものです。


Biz/Browserの理念

   現在のバージョンはXEと呼称し、管理番号としてはV4.1、もう足掛け7年になります。実質、販売が伸びはじめたのは2001年のV3からです。

   ファーストユーザとして、大手損保会社の代理店システムに採用されました。代理店でのPC動作ですから、構築側から見ると非管理(管理できない)端末です。現状では数万クライアントが稼動し問題なく動作しています。

   システムを提供する企業側にとって、管理されない端末であっても管理できる端末であっても障害がなく長期的に安定して動作することが、業務システムとしては当たり前であり根底のニーズです。

   また、規模が大きければ大きいほど古い、そしてスペックの低いクライアントが必ず存在します。管理端末であればなおのこと、リプレースには企業として多大なコストが発生しますので簡単ではありません。こういった低スペック環境でも問題なく動作することも非常に重要です。

   今、"ホストマイグレーション"として、ホストからWebへという波がありますが、ホストは"レガシー"という言葉で表現されるような悪いものではまったくありません。安定しています。

   Web化の波の中でホストを利用しながら一部をWeb化する、フロントエンドをWeb化するという選択を採るケースが多いようです。

   ホストを継続利用するのは「安定」を求めるからです。Webはオープン環境であり、不安定要素も多く存在します。業務システムの絶対ニーズは安定稼動です。Windows Update(最近はMicrosoft Update)を施行しないケースが多いのもこういったことが理由です。

   Biz/Browserは、フロントエンドとしてオープン環境差や環境の変化/変遷を吸収し、安定稼動を恒久的に提供することが大きな使命だと考えています。一方では開発ツールとして開発者の生産性を高めることも重要です。

   ここからは少し技術的な話に話題を移していきます。

1   2  3  4  次のページ


アクシスソフト 永井 一美
著者プロフィール
アクシスソフト株式会社  永井 一美
アクシスソフト株式会社 執行役員プロダクト事業部長
SI会社にてオフコンでのアプリケーション開発やメインフレームでのOS開発、PCでの開発、品質保証業務などを経験、SI事業部門の管理者を経てアクシスソフトに入社。入社時より一貫して製品事業に携わる。特にBiz/Browserにおいては、「確かなUIによりエンドユーザの生産性を高め業務に対するモチベーションを持っていただくことが、企業全体の生産性を押し上げる」との信念で推進している。


この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。

INDEX
第1回:リッチクライアントとBiz/Browser
はじめに
  Biz/Browserの位置づけ
  CRS(チェイン・リフレクション・スクリプト)とは
  画面デザイン
Biz/Browserで経営の効率化を実現する
第1回 リッチクライアントとBiz/Browser
第2回 Biz/Browserの運用事例
第3回 「Biz/Browser」の機能紹介
第4回 「Biz/Browser」の機能による生産性の向上
第5回 「Biz/Browser」の「昨日」「今日」「明日」
関連記事 : Eclipseで実現するリッチクライアントの世界
第1回 他とは異なるEclipse RCPの特徴
第2回 アプリケーションを実際に作ってみる(前編)
第3回 アプリケーションを実際に作ってみる(後編)
第4回 アプリケーションの配布
関連記事 : IdbAで構築する生産性が高いリッチクライアント
第1回 Rimless Computingとは?
第2回 リッチクライアントとIdbA
第3回 コンポーネントの開発事例
第4回 これからのリッチクライアント
第5回 開発生産性を向上するIdbA R2.0と、その方向性
関連記事 : リッチクライアントCurlの特徴と導入実態
第1回 リッチクライアントの発展とCurl
第2回 ドキュメントを活用したCurlアプリケーションの開発
第3回 Curlアプリケーションの公開
第4回 Curlの適用事例(前編)
第5回 Curlの適用事例(後編)
関連記事 : リッチクライアントの現状と今後の動向
第1回 リッチクライアントとは
第2回 リッチクライアントの市場調査結果
第3回 リッチクライアントの適用事例
第4回 リッチクライアント製品/技術動向
第5回 リッチクライアントの将来