 |
|
|
| 1 2 3 次のページ
|
|
| アンケート内容
|
今回は、リッチクライアントを先行して導入した企業のインタビュー結果を報告する。
今回報告する事例は、表1のように「ファットクライアントからリッチクライアントへ移行した事例」、「HTMLクライアントからリッチクライアントへ移行した事例」に分類した。
| |
対象システム
（会社名） |
効果
（メリット） |
課題
（デメリット） |
| ファットクライアントからリッチクライアントへ移行した事例 |
学校会計システム（会社A） |
利用者に対するユーザビリティ(生産性)の維持
プログラム配布の容易性による導入と運用の効率化 |
リッチクライアント動作環境自体のバージョンアップへの対応 |
| 販売統計システム（会社B） |
利用者に対するユーザビリティ(生産性)の維持
プログラム配布の効率化 |
リッチクライアント動作環境自体のバージョンアップへの対応
クライアント側の環境設定 |
| 社内総合調達システム（会社C） |
利用者に対するユーザビリティ(生産性)の維持 |
開発コスト
人材不足
ライセンスコスト |
| HTMLクライアントからリッチクライアントへ移行した事例 |
業務系アプリケーション（会社D） |
ユーザビリティの向上
プレゼンテーション層とビジネスロジック層の分離開発による保守(コンテンツ管理)費の削減 |
開発生産性の低下
設計方式の欠如
人材不足 |
|
表1：リッチクライアント適用事例一覧
|
効果（メリット）に関しては、高度なユーザビリティやプログラム配布の容易性などと、どちらの事例もリッチクライアント共通の効果を享受したものとなっている。課題（デメリット）については、開発生産性が上がったとするところもあれば、下がったとするところ、動作環境自体のバージョンアップ問題が顕在化したところ、そうでないところと、必ずしも共通した課題ではなく、リッチクライアント製品／技術よって異なる課題が顕在化している様子がうかがえる。
|
| ファットクライアントからリッチクライアントへ移行した事例
|
|
| 会社Aの学校会計システム
|
|
| |
移行前 |
移行後 |
| クライアント |
Visual Basicで開発したWindowsネイティブアプリケーション |
.NET Framework上で動作するWindows Form |
| サーバ |
Windows Server |
IIS（Windows 2003 Server） |
| 開発環境 |
Visual Studio |
Visual Studio .NET |
| C/S接続 |
|
独自プロトコル（XMLベース） |
|
会社Aは、私立学校法人用ソフトウェアの市場の7割を占めている会社で、主に学校会計、学校給与、学費管理、そして資産管理システムを販売している。
会社Aが提供する学校会計システムは、それまでVisual Basicで開発されたクライアント／サーバ・システムであり、主に表2のような問題を抱えていた。
|
- 導入作業の非効率
-
- クライアントとサーバの両方にソフトウェアをインストール／セットアップする必要があった
- 問題があった場合、社員が現地まで赴き対応する必要があった
- 運用サポートの非効率
-
- 利用者のPC環境が異なるため、問い合わせがあった場合、電話では何が問題なのかわからない
- そのため利用者は問題があった場合、PCやデータの郵送、画面ハードコピーのFAXなどを行うか、サポート要員が派遣されてくるのを待つ必要があり、問題解決までに数日かかることもあった
|
表2：会社Aのリッチクライアント導入前の問題点
|
そこで会社Aでは、表2の問題点を解決する技術としていち早くリッチクライアントを採用し、学校会計システムの新バージョンから本格的に取り組み始めた。その結果、表3のような成果をあげた。
|
- 導入作業の効率化
-
- ユーザ企業側はブラウザからURLをたたくだけでよい
- サーバやクライアントへのインストールやセットアップは必要なくなった
- サーバやクライアントへのインストールやセットアップは必要なくなった
- 運用サポートの効率化および質の向上
-
- リモートサポートが可能となり、数日かかっていた問題解決が数分で対応可能となった
- 会社Aからのお知らせなどをシステム上の掲示板に掲載することもできるため、きめ細かなサポートができるようになった
|
表3：会社Aのリッチクライアント導入後の成果
|
しかしながらWeb化したことにより、LAN環境ではさほど問題とならなかったセキュリティやネットワーク帯域によるパフォーマンスが新たな課題として顕在化した。セキュリティについては、HTTPS（SSL）上にXMLをベースにした独自プロトコルを開発した。ネットワーク帯域については、ユーザ企業ごとに異なり、必ずしもブロードバントではないため、データベースの最適化を行い無駄なデータがネットワークに流れないように工夫している。
さらにリッチクライアントにしても解決されない課題として、リッチクライアントアプリケーションが動作するインフラである。代表的な例として、.NET Frameworkのバージョンアップがあげられる。これは.NET Framework自体がバージョンアップされると、（厳密には）アプリケーションコードの書き直しが必要になるためであり、新しい機能を追加したインフラに対して、どのように対応していくかが課題としてあげられた。
.NET Frameworkで動作するWindows Formや、J2SE上で動作するJavaプログラム、Macromedia Central上で動作するFlashなど、独自のインフラ上で動作するスタンドアロン型リッチクライアントでは、インフラ自体のインストールやバージョンアップ、修正パッチ対応など共通の課題を抱えている。
|
1 2 3 次のページ
|
|
|
|
|
著者プロフィール
株式会社野村総合研究所 田中 達雄
1989年4月に富士通株式会社に入社。ソフトウェア工学を専門分野とし「UMLによるオブジェクト指向開発実践ガイド（技術評論社出版）」を共著。2001年2月に野村総合研究所に入社。現在、情報技術本部にてIT動向の調査と分析を行うITアナリスト集団に所属。Webサービス／BPMなどの統合技術、エンタープライズ・アーキテクチャなどが専門。
|
|
|
|
|
|
