 |
|
第8回 読者アンケート結果
|
情報システムの構成は、汎用機中心からクライアント／サーバ（以下C／S）システム、Webシステムへと変遷してきた。そうした中、最近ではWebシステムにおけるシン・クライアント（Webブラウザ）の弱点を克服する手段として、さまざまな「リッチ・クライアント」技術が登場している。はたして現在のクライアント開発にはどのような課題があり、そこにどのような解決が求められているのだろうか？ Insider.NETフォーラムが実施した第8回読者調査から、その状況をレポートする。
現在かかわるシステム開発の種類は？
まず始めに、読者がかかわっているシステム開発の種類から確認しておこう。図1のとおり、「イントラネット」「インターネット／社外用のWebシステム」および「C／Sシステム」の3種類が大きな比率を占めており、全体的にWebベースのシステム開発が現在の主流であることが分かる。
 |
| 図1 現在主にかかわっているシステム開発の種類（n＝533） |
以下のトピックでは、システム開発にかかわる読者（458人）の回答に絞って集計を続けよう。
現在主流のクライアント・アプリケーションは？
次に、読者が開発しているシステムで、現在おもに利用しているクライアント側アプリケーションを聞いた結果が図2だ。Webシステムの隆盛を反映して、クライアントにブラウザを利用する構成が、最も一般的であることが分かる。
 |
| 図2 現在利用している主なクライアント・アプリケーション（n＝458） |
ブラウザ以外のクライアント技術では、「ネイティブなWindowsアプリケーション（アンマネージ・コード）」「.NET Framework／CLR上で動作するWindowsアプリケーション」「Javaアプリケーション」のポイントが比較的高いものの、今のところ突出してシェアの高いものは見当たらない。
Webブラウザの課題とは？
では現在最も利用されているクライアント・アプリケーションとしてのWebブラウザには、どのような課題があるのだろうか？ 複数回答でたずねたところ、全体の7割が「ブラウザの種類やバージョンによって、動作や表示が異なる場合がある」点を指摘している（図3）。JavaScriptなどを使う場合は、同じブラウザでもバージョンやOSによる挙動の違いがあり得るだけに、開発者としては煩雑な動作確認に頭が痛いところだろう。
 |
| 図3 クライアント・アプリケーションとしてのWebブラウザの課題（複数回答 n＝458） |
またそれ以外にも、「表現力が乏しく、ユーザー・インタフェイスが貧弱」「サーバと通信する時間がかかり、応答性／パフォーマンスが悪くなる」など、ブラウザに関するさまざまな問題点が挙げられた。しかしこれらの大半は、もともとWebページ表示用に作られたブラウザを、業務クライアントに応用したために発生した構造的な課題であるため、その解決に「ブラウザ以外」の選択が求められるのもうなずける。
リッチ・クライアントの採用状況は？
続いて、ブラウザに替わるリッチ・クライアントの採用状況を聞いた結果が図4だ。「すでにリッチ・クライアントの開発に着手している」読者はまだ全体の1割にすぎないものの、「今後採用を予定／検討している」または「採用予定はないが、興味はある」という前向きな開発者が66％を占めており、「ブラウザ利用のWebアプリケーションで特に問題はない」（8％）との意見を大きく上回った。このデータを見る限り、クライアント・アプリケーションとしてのブラウザが急速に代替されるとは思えないが、システム開発者のリッチ・クライアントにかける期待の大きさは、充分にうかがえる。
 |
| 図4 リッチ・クライアントの採用状況（n＝458） |
リッチ・クライアント技術の選択ポイントは？
次に、今後リッチ・クライアント技術を選択する際、読者がどのような点を重視するのかたずねたところ、「アプリケーションや実行環境の配布／更新が簡単であること」「開発環境が充実していること」および「入力時などにユーザーが操作しやすいこと」が、そのトップ3要因に挙げられた（図5）。
 |
| 図5 リッチ・クライアント技術選択時の重視点（複数回答 n＝458） |
「リッチ・クライアントの復活」とはいえ、配布や更新の方法までC／S時代に戻ってしまっては、管理工数が増加して元も子もなくなってしまう。新時代のクライアント技術には、C／Sシステムの使い勝手と、Webシステムの管理性を兼ね備えた特性が、強く求められている。
今後注目のリッチ・クライアント技術とは？
最後に、読者が今後採用を考えている具体的なリッチ・クライアント技術とは何なのか、その検討状況を紹介しておこう。図6に見られるように、現在最も本命視されているのは、「.NET Framework／CLR上で動作するWindowsアプリケーション」であった。.NET時代のWindowsアプリケーションでは、上述したアプリケーション配布問題への回答として、「ノータッチ・デプロイメント」機能が用意されている。ノータッチ・デプロイメントを使えば、プログラム（exeファイル）はWebサーバ上に配置し、クライアント側からそのリンクをクリックするだけで、自動的にダウンロード／実行することができる（ノータッチ・デプロイメントの詳細は「特集：ノータッチ・デプロイメント」を参照）。C／SシステムとWebシステムの長所を融合したこの機能は、今後とも開発者から大きな注目を集めていきそうだ。
 |
| 図6 採用を予定／検討しているリッチ・クライアント技術（複数回答 n＝458） |
ただしノータッチ・デプロイメントを利用する際にも、現状ではクライアント側に.NET Frameworkをインストールする必要があり、その工数を危惧する読者のコメントも見られた。クライアント用の.NET Framework導入については、現在Windows Updateが利用できるほか、再頒布パッケージ（dotnetfx.exe）を使ってアプリケーションと共に配布することも可能となっている。Insider.NET会議室にも関連スレッドが立っているので、興味のある方は下記関連記事／スレッド内容を参照されたい。
| 調査概要 | |
|
調査方法
|
Insider.NETフォーラムからリンクした Webアンケート |
|
調査期間
|
2003年7月22日〜8月18日 |
|
有効回答数
|
533件 |
| 関連記事 | |
| 特集：ノータッチ・デプロイメント | |
| 特集：InfoPathの衝撃 | |
| 検証：新世代リッチ・クライアントの可能性を探る | |
| 「.NET Framework の再配布」スレッド | |
 |
「Insider.NET 読者調査結果」 |
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
