Ajaxの登場(再認識)や各種ツール類や開発環境のコモディティ化
のおかげで、リッチクライアントもいよいよ本格的な普及時期を
迎えるのではないかという気がしています。
「リッチクライアント」という言葉の定義自体がかなり曖昧ですが、
(シンクライアントに対する言葉として、HDを持つH/Wを指すような
ケースもありますね) ここでは昨今の傾向に合わせて、
『従来のHTML+DHTMLと比較して閲覧性や操作性を向上させることの
できる技術およびその技術を用いて作られたWebアプリケーション
でのクライアント側の実行モジュール』
を指すことにします。
実は個人的には「リッチクライアント」の真の価値はローカルリソース
の活用にあると思っているのですが、それについては以前のエントリに
書いていますのでここでは割愛します。
http://d.hatena.ne.jp/dufresne/20040918
上記の定義に基いて最近注目されている市場が
「既存Webアプリケーションのリッチ化」
です。
リッチ化によって閲覧性や操作性が改善すれば、それだけ業務効率が
上がるため、顧客にとって投資価値が十分にあるはずだという発想です。
この流れは確かにその通りですが、だからといってリッチクライアント
技術やその動向に無縁だったプレーヤーがむやみにリッチクライアント
市場に参入するのは少々危険が伴います。
以下ではそのあたりを考えてみたいと思います。
まずは、リッチクライアントを取り巻く状況を自分なりに整理してみます。
・開発環境やノウハウのコモディティ化
リッチクライアントに限ったことではないですが、開発環境の無償化
や低価格下によって高度な開発環境を手軽に入手できたり、サンプル
コードやTIPSがBlogなどで参照できたり といった状況はさらに進む
と思われます。自分達が簡単にできることは競合他社や場合によって
は顧客自身が自らやってしまうことも可能であるということを念頭に
置く必要があります。自分達はとても画期的なことをやっている気に
なっていても、それと全く同じことがBlogにソース付きで紹介されて
いたといったことはよく起こりがちなことです。新規参入で情報網が
十分でない場合には特に気をつける必要があるのですが、経営層が新
技術導入による効果に過剰な期待を抱き、リリース日をタイトに設定
してしまいがちです。メイクを間に合わせることに精一杯になって、
他を見る余裕がなくなってしまうため、余計にそうした状況に陥りが
ちでもあります。
・伝えるコストと作るコストの逆転現象
上記のような傾向が進むと顧客にとってのコスト構造が変化してきます。
情報システムを構築しようとする場合、従来は「作るコスト」の比率が
大半を占めていました。ですが、既存のWebアプリケーションをリッチ化
するといった場合、例えばSun Java Studio Creator2のようなツールを
使えば既存のデータベースを維持したまま、リッチなUIを持つ環境をコー
ディングを最小限に抑えて構築することができてしまいます。Flexを活用
すれば既存のStrutsベースの資産を残しつつFlash化することもできます。
Ajaxについても最近はツールだけでなく、ノウハウ本なども出始めており
以前に比べて敷居はどんどん低くなってきています。
こうなってくると顧客にとっては発注先のSIerやベンダーに自社の業務を
的確に説明するという「伝えるコスト」の方が大きくなってきます。時間
を掛けてSIerやベンダーに説明したのに、セカンドフェーズで先方の担当
が変わってしまい、また同じことを説明しないといけないという経験を持
つ情シスの方は少なくないのではないでしょうか。外部に発注するより、
自社で内製する方がタイムリーな変更にも対応できます。サーバー側での
高度な処理を伴うものは自社開発というわけには行きませんが、業務内容
の変化に応じてリッチなUIを随時更新していくという作業内容を考えると
顧客にとっては自社での内製というのも魅力的な選択肢になってきている
のではないかと考えています。
・利用シーンの洗い出すことの重要性
リッチクライアントを実現する技術はさまざまです。リッチクライアント
関連の技術は見た目に訴えるものですので、ともすると一つの技術を一見
だけでそれに惚れ込んでしまい、他の技術の調査がないがしろになってし
まうことがあります。Ajax(JavaScript)、Flash、EclipseRCP、Curl等
それぞれの技術には得意分野と不得意分野があります。なぜ、Ajaxを採用
するのか？なぜ、Flashにしたのか？それによって得られるメリット及び
失われる利便性はないか？を求められる利用シーンとユースケースを網羅
した上で検討しないといけません。
例えば、既存のWebアプリケーションはURLに全ての情報が包含されたREST
スタイルになっていたとします。これを安易にリッチ化して「画面遷移が
なくなりました!」といっても、今度は特定の記事情報をダイレクトに指し
示したURLをメールなどでやりとりするという従来のユースケースが再現
できなくなったりすることがあります。現状の利用シーンを洗い出すとい
うことをおろそかにして性急なリッチ化を行なうと、返って使い勝手を低
下させてしまいます。書籍等に掲載されているユーザービリティの原則を
機械的に当てはめ、顧客の業務の流れを無視した画面デザインに終始して
しまうと思わぬ落とし穴に嵌まることがあります。
以上の傾向を踏まえた上で、役割別に採るべき戦略を考えてみます。
・パッケージベンダー
グループウェアベンダーの中にはFlash対応を謳うものが既にいくつか
出てきています。これらはいずれも「攻め」というよりは自社の製品が
古臭いものと見なされないための「守り」の戦略と考える方が妥当です。
当然ながら自社の旧バージョンからのスムースな移行が可能であること
が大前提となります。さらに「攻め」を考えるのであれば他社製品から
の移行ツールを合わせて出すことで、リッチクライアントブームに乗り
遅れたベンダーからシェアを奪うというシナリオが考えられます。
ですが、Strutsなどのオープンソースフレームワークの上に開発された
Webアプリケーションのリッチ化(これが最もボリュームの大きい部分で
はないかと思いますが)に対して、完成された一枚岩の製品を提供する
ことは得策ではありません。何故ならサーバー側の移行に相当なコスト
が掛かってしまうからです。(もし仮に製品をオープンソースにしたり、
部分的なフレームワーク設計を導入したとしても、移行に要する手間は
さほど変わりません) この市場を狙うのであれば、サーバー側には依存
しない形でリッチなUIを実現するコンポーネントセットなどを提供する
必要があります。この辺りの現状認識が足りないまま「とにかくFlash
化した製品を出せば売れる」と考えてしまうと痛い目に遭いそうです。
・フレームワークと開発環境
これらはいずれもコモディティ化の進んでいる分野です。ライブラリを
まとめただけのフレームワークやエディタに毛が生えたレベルのツール
では有償での提供は難しいでしょう。有償にするのであれば、テストの
自動化やドキュメントの自動生成、ソース管理や要求管理といった開発
ライフサイクル全体をサポートする開発環境を提供したり(例 VS.NET)
コーディングや設定の手間を高度に自動化したツール(例 HowsのAjax
Builder)といったレベルが求められてくると思われます。便利に使える
ライブラリやフレームワーク、開発ツールが既に無償で提供されている
という事実を知らずに、それと同レベルのものを工数を掛けて開発して
有償で売ろうとしてしまうというのも新しい技術分野に参入した際には
やってしまいがちなので気をつけないといけません。
・教育とトレーニング
新しい技術が出てくると、教育やトレーニングの市場が発生します。
ですが、有用な情報や価値あるテクニックは最前線の開発者のBlog
などに掲載されていることが少なくありません。自社製品の提供と
教育・トレーニングをセットにして価値を上げるという戦略を摂る
パターンもありますが、その場合には自社内に実案件に関する豊富
なノウハウの蓄積があることが前提となります。決まりきった技術
情報やガイドラインは誰でも入手が可能な状態です。ブームに便乗
した小手先の教育やトレーニングでは見向きされません。この分野
では長年リッチクライアントやユーザービリティについて顧客と共
に真剣に取り組んできたSIerやコンサル会社でないと取り組むのは
難しいでしょう。新規参入で技術TIPSを中心に教育・トレーニング
を行い、その成果を持って自社製品に誘導していこうというのは思
いつきやすい戦略ですが、これだけ情報収集が容易になった現状で
は現実的とは言えません。
・SIer
リッチクライアントにおいては「作るコスト」がどんどん下降して
くると思われます。それに伴い『作る』だけでは単価が下がる一方
という状態になります。これを打開するためには機械的なUI改善に
留まらず、顧客の業務改善まで深く踏み込んだシステム構築を行う
ことが重要ではないかと思われます。顧客の業態に適した業務改善
のノウハウを資産(アセット)として自社内に蓄え、それを展開して
いくことで、書籍に書かれているようなユーザービリティの改善点
に留まらない顧客の現場に即した改善提案とシステム構築ができる
というのがインテグレーションの大きな付加価値になるのではない
かと思います。これについても長年の努力が必要なので、それなり
に年数を積んだリッチクライアント分野の老舗SIerでないと実現は
難しいと思われます。
結局のところ、「既存Webアプリケーションのリッチ化」という意味
でのリッチクライアントがブームになった際にそれを享受できるのは
・リッチクライアント技術の基盤を提供する会社(Adobe、アクシスソフト等)
・他には真似できない高度なリッチクライアント開発技術を提供する会社(Hows等)
・顧客の業務まで深く入り、アセットを蓄積してきた老舗のSIer
といったところではないかと思われます。
逆に
・とにかくリッチ化すれば売れると考えているWebアプリパッケージベンダー
・『作る』ことに特化しており、顧客の業務に対する提案ノウハウを蓄積していないSIer
といったところが安易に多大なコストを掛けて参入するのは得策ではないと思われます。
新規参入については
・パッケージベンダーの場合はオプション製品といったコストが掛からず既存
の顧客にもインパクトの少ない形でまずは参入し、自社のノウハウを積みな
がら競合他社の状況も見つつ今後の策を考える。既にオープンソースや無償
で存在するライブラリやフレームワークと同等のものを開発してしまわない
ように日頃の情報収集に多くの時間を裂くようにする。
・SIerの場合は顧客の業務を理解することを最優先に考え、顧客業務に基いた
ニーズを満たすリッチクライアント技術を的確に選択するノウハウと業務に
関する「アセット」を蓄積することに注力する。リッチクライアント実装の
際のフレームワークやライブラリは既存のものを極力利用し、自社内で同じ
ものを作ってしまわないように気をつける。
といったことが言えるのではないかと思います。
