読者調査結果

@IT読者調査結果:デベロッパー編(1)
〜リッチクライアント開発の引き合い状況は?〜

小柴 豊
アットマーク・アイティ
マーケティングサービス担当
2004/10/23

 クライアントアプリケーションの「使いやすさ」とWebアプリケーションの「管理しやすさ」を兼ね備えたテクノロジとして、昨今話題の“リッチクライアント”。果たしてシステム開発の現場では、リッチクライアント開発がどの程度現実化しているのだろうか? @ITのデベロッパー系2フォーラム(Java Solution/Insider.NET)が共同で実施した読者調査から、その状況をレポートしよう。

現在はHTML+JavaScriptが主流

 はじめに、読者が現在かかわっているプロジェクトでは、主にどのようなクライアント開発技術/製品が利用されているのか、確認しておこう。結果は図1のとおり「ブラウザ(HTML+JavaScriptなど)」がダントツのトップとなっており、Webアプリケーション主流の時代を証明している。ブラウザ以外ではWindowsアプリケーションが上位に続いているが、「.NET Framework+Windowsフォーム」(以下、.NET+Windowsフォーム)が「Win32ネイティブ」を上回っていることから、.NETベースのクライアント開発案件が増加している様子が分かる。

図1 現在利用している主なクライアント開発技術/製品(N=746)

リッチクライアントの引き合いは増加中

 図1の結果を見る限り、現時点ではブラウザによる既存Webアプリケーションの優位は揺るいでいない。そこで次に、読者の周りにどの程度リッチクライアント開発の引き合いがきているのか、その状況を尋ねてみた(図2)。さすがに「すでに多くの引き合いがあり、採用が本格化している」との回答は6%にとどまったものの、「引き合い件数は増えており、一部で開発/導入が始まっている」を合わせると、全体の20%がリッチクライアント開発を手掛けていることが分かった。

 また「最近引き合いがくるようになり、提案/検討が進んでいる」「具体的な引き合いはまだないが、問い合わせや相談は増えている」といった“潜在需要層”も合計で42%に上っており、今後の案件拡大を予感させる。リッチクライアント技術のライフサイクルは、コンセプトを語る“黎明期”から、具体的な実装が始まる“導入初期”に移ったといえそうだ。

図2 リッチクライアントの採用/引き合い状況(N=746)

リッチクライアント技術の選択要件は?

 では今後リッチクライアントを実現する技術/製品を選択する際、読者のプロジェクトで重視される要件とは何なのだろうか? 複数回答可で尋ねた結果、「入力作業などユーザーの業務生産性が向上できること」「ユーザー操作時の応答性/パフォーマンス」といった“ユーザビリティ要件”の重視度が、コストなどほかの項目を大きく上回った(図3)。

図3 リッチクライアント技術選択時の重視点(複数回答 N=746)

 “ブラウザを超える使いやすさ”はリッチクライアントの主要価値であるだけに、これは当然の結果であるように見える。しかし2003年8月に実施した読者調査では、同様の設問に対して「アプリケーションの配布しやすさ」「開発環境が充実していること」の重視度が、「ユーザーの操作性」を上回っていた(第8回Insider.NET読者調査 図5参照)。この1年間にリッチクライアント開発が現実味を増したことで、デベロッパーはより“ユーザー視点に立った”技術選択を迫られているようだ。

〜 読者のコメントより 〜

  • 現在、クライアント環境はブラウザを使う場合が一番多い。オフコンや汎用機からのマイグレーションの商談だと、操作性が落ちるのが最も懸念される。
  • 操作性の面でもう少しよくなればいうことなし。お客さまは操作性重視である。
  • 実際にどの程度操作性が上がるのかが疑問。クライアント/サーバ並みの操作性(ENTERでのフォーカス移動やファンクションキーなど)をいかに簡単に作成できるのか?

次に採用したいリッチクライアント技術とは?

 続いて読者のプロジェクトで今後採用を予定(検討)しているリッチクライアント技術を尋ねたところ、「Windowsアプリケーション」に最も多くのポイントが集まった(図4)。Swingの性能改善/SWTの登場などで見直されつつある「Javaアプリケーション」が2番手につけているものの、全体的にはクライアント/サーバ時代からクライアント開発に強みを持つマイクロソフト技術が、リッチクライアント時代にも大きな存在感を示している。

図4 今後採用予定/検討しているリッチクライアント技術(複数回答 N=746)

 上図を見ると、これからのリッチクライアントの本命はマイクロソフト技術であるように思われる。しかしこうした集計データは、別の視点から見ると、また違った様相が浮かび上がるものだ。そこで冒頭で触れた「現在利用しているクライアント開発技術」別に、図4のデータを再集計した結果も紹介しておこう。

 図5の青棒グラフを見ると、現在のWindowsアプリケーション開発者の83%が今後ともWindowsアプリケーションの採用を予定/検討しており、このロイヤルティーの高さが、全体の数値に影響を及ぼしているように思われる。一方、現在の主流派であるブラウザ利用者の回答(図5 黄棒グラフ)は大きく異なり、Windowsアプリケーションと同様にJavaアプリケーションやFlashなど、より多様な技術の採用を予定/検討していることが分かる。このようにして見ると、“ブラウザ代替”としてのリッチクライアントには広い可能性があり、現在は本格導入期に向けた技術選択の岐路に差し掛かっている段階といえそうだ。

図5 現在の主利用技術別 リッチクライアント採用予定(複数回答 N=746)

 @IT では、こうしたリッチクライアント技術の選択や実装に関心のあるエンジニアに向けて、新フォーラム「Web Client & Report」を開設した。以下の関連記事と併せて、ぜひご参照いただきたい。

調査概要
調査方法 Java Solution/Insider.NETフォーラムからリンクしたWebアンケート
調査期間 2004年7月20日〜8月13日
有効回答数 746件

関連記事
Webクライアントの使いやすさを見直す (Web Client & Report)
スマート・クライアントの傾向と対策 (Insider.NET)
EclipseによるSWTアプリケーションの作成 (Java Solution)
XMLでリッチクライアントを実現「Macromedia Flex」 (Java Solution)
Webは生産性を下げる? ブラウザを超える手段とは (@IT情報マネジメント)


@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)