野村総合研究所 情報技術本部
主任研究員 田中 達雄
2005/10/14
|
前回「スタンドアロン型リッチクライアントとは？」では、成熟期を迎えようとしているリッチクライアント市場の歴史をひもとくとともに、現在提供されている製品をその特徴から分類し整理した。 |
| 最近のスタンドアロン型リッチクライアントの動向 |
現在、スタンドアロン型リッチクライアントに関する動きには主に3つがある。1つ目はスタンドアロン型リッチクライアントによる「User Experience性重視への対応」、2つ目はブラウザ型リッチクライアントによる「スタンドアロン型への対応」、3つ目は「次世代デスクトップ環境への応用」である。
 |
| 図1 スタンドアロン型リッチクライアントの動向 出所）野村総合研究所 |
| User Experience性重視への対応 |
これまでのスタンドアロン型リッチクライアントは、主にイントラネットの世界で、利用者の生産性を重視する方向で成長してきた。しかし今後、インターネットの世界に限らず、イントラネットの世界でもUser Experience性が重視されるようになることが予想される。また、ベンダの拡大路線からこれまで主にUser Experience性を重視してきたブラウザベース型リッチクライアントの市場を取り込むために、対抗する技術や製品を投入するといった動きが始まっている。
大きな動きとして、2005年9月13日よりロサンゼルスで開催された『Professional Developers Conference （PDC）』で発表されたマイクロソフトの「Expression」シリーズの提供がある。これは「今後、User Experience性を重視したアプリケーション開発が進む」と判断したマイクロソフトが当分野で人気の高いマクロメディアの「Flash」に対抗して提供する開発者用製品である。
|
Expressionシリーズ
|
Expressionシリーズには上記3つの製品が含まれるが、その中の「Microsoft Expression “Sparkle Interactive Designer”」はまさにFlashに対抗する機能を持ち、さらに開発したコードからは、スタンドアロン型リッチクライアント（.exe）とブラウザ型リッチクライアント（Web Browser Application※1 wba）のどちらも生成することができる※2。
| ※1： Web Browser Applicationとは、マイクロソフトが新たに提供するWebブラウザ向けアプリケーションプログラムで、実行環境としてWindows
Presentation Foundation（WPF）を必要とする。 ※2： どちらもWindows Presentation Foundation（WPF）を実行環境とするため、（WPFがどの程度軽量化されて提供されるかにもよるが）その適用範囲は、利用する端末を特定できるアプリケーションにとどまる可能性は高い。端末を特定しないアプリケーションのクライアント開発には、「Microsoft Expression “Quartz Web Designer”」もしくはAjax開発環境として提供される「Atlas」を使うことになるだろう。 |
また、「Microsoft Expression “Sparkle Interactive Designer”」で開発したプロジェクトや開発コードは、Microsoft Visual Studioに取り込むことができるため、Webサービス利用やコンポーネント開発、デバッグ機能、チーム開発など既存の成熟したスタンドアロン型リッチクライアント開発環境と連携することも可能である。これはUser Experience性の高いコンテンツ開発を得意とするクリエイターと利用者生産性重視の開発を得意としてきたアプリケーションシステムプログラマーとの協業を手助けするかもしれない。
これまで実行環境であるWPFと開発言語であるXAMLが発表されていたが、これで専用の開発環境まで提供することが示された。リッチクライアント市場に対して着々と布石が打たれ、ほぼ準備が整った感に思える。また提供後は、User Experience性重視のリッチクライアント開発には開発生産性の低下を招くとの懸念があっただけにマイクロソフトの成熟した開発環境との連携は大きな強みとなることが予想される。
| ブラウザ型リッチクライアントによるスタンドアロン型への対応 |
ブラウザ型リッチクライアントの場合、イントラネットの世界で利用者の生産性を重視してきたものとインターネットの世界でUser Experience性を重視してきたものに大別されるが、どちらからもスタンドアロン型へ対応する動きが見られる。
ブラウザ型リッチクライアントの欠点は、Webブラウザの制約をどうしても受けてしまうことにある。User Experience性を重視するとともに既存のスタンドアロン型リッチクライアントに劣らぬ利用者生産性を確保するためには、スタンドアロン型実行環境への対応が必要となる。
過去、スタンドアロン型リッチクライアントからスタートし、当時のブラウザの利便性を重視したニーズを受け、ブラウザ型リッチクライアントへ移行したリッチクライアントもあり、当時とは逆の動きとなるが、現在のトレンドは、ネットワーク帯域の拡大や自動アップデートといった技術的進歩もさることながら、利用者生産性のニーズがブラウザの域を超えたものへと変化しており、再考する時期にあると思われる。
主な動きには、ブラウザ型リッチクライアントの雄である「Flash」のスタンドアロン型実行環境「Macromedia Central」や「Curl」の独立型アプレット「Detached Applet」の提供がそれに相当する※3。
| ※3： ブラウザ型リッチクライアントとして、ブラウザのプラグイン上で動作していた既存のリッチクライアントプログラムが、そのままスタンドアロン型の実行環境で動作するようになっていれば問題ないが、そうでないスタンドアロン型実行環境の場合（スタンドアロン型実行環境専用のSDKを開発時に必要とする場合など）は、単純に移行できないため普及の面で苦戦を強いられることになるだろう。 |
| 1/3 |  |
|
INDEX |
||
| スタンドアロン型の次世代デスクトップ環境を占う | ||
 |
Page1 最近のスタンドアロン型リッチクライアントの動向／User Experience性重視への対応／ブラウザ型リッチクライアントによるスタンドアロン型への対応 |
|
| Page2 次世代デスクトップ環境への応用／スタンドアロン型リッチクライアント普及時の課題／懸念される異種混在のスタンドアロン型実行環境 |
||
| Page3 リッチクライアント開発における共通課題／Rich Client Frameworkの必要性／スタンドアロン型リッチクライアントの将来 |
||
- GASで棒、円、折れ線など各種グラフを作成、変更、削除するための基本 （2017/7/12）
資料を作る際に、「グラフ」は必要不可欠な存在だ。今回は、「グラフの新規作成」「グラフの変更」「グラフの削除」について解説する - GET／POSTでフォームから送信された値をPHPで受け取る「定義済みの変数」【更新】 （2017/7/10）
HTMLのフォーム機能についておさらいし、get/postメソッドなどの内容を連想配列で格納するPHPの「定義済みの変数」の中身や、フォーム送信値の取り扱いにおける注意点について解説します【PHP 7.1含め2017年の情報に合うように更新】 - PHPのfor文＆ループ脱出のbreak/スキップのcontinue【更新】 （2017/6/26）
素数判定のロジックからbreak文やcontinue文の利点と使い方を解説。for文を使ったループ処理の基本とwhile文との違い、無限ループなども併せて紹介します【PHP 7.1含め2017年の情報に合うように更新】 - Spreadsheetデータの選択、削除、挿入、コピー、移動、ソート （2017/6/12）
Spreadsheetデータの選択、挿入、削除、コピー、移動、ソートに使うメソッドの使い方などを解説する
 |
|
|
|
|
