アプリの“使いやすさ”は
“数値”として見積もれるのか
リッチクライアント・カンファレンスIV
Aトラックパネルディスカッションレポート
〜自社のWebアプリの使い勝手を評価してみましょう〜
@IT編集部
2008/10/28
2008年9月19日、東京・目黒雅叙園にて@IT編集部主催による「リッチクライアント・カンファレンスIV」が行われた。本稿では、Aトラックのパネルディスカッション「自社のWebアプリの使い勝手を評価してみましょう」の模様をレポートする(基調講演やBトラックのパネルディスカッションの模様は記事「セキュリティ、開発負荷削減、エンドユーザー支援が鍵」を参照)。
パネリストとして出席したのは、アドビシステムズ マーケティング本部クリエイティブソリューション部 Webグループ ディベロッパーマーケティングスペシャリストの轟啓介氏、カール RIAエバンジェリストの三野凡希氏、日本ネクサウェブ セールス・マーケティング マネージャー 淡路良平氏、マイクロソフト デベロッパー&プラットフォーム統括本部 デベロッパービジネス本部 エバンジェリスト 川西裕幸氏の4氏。モデレータは前@IT発行人の新野淳一氏が務めた。
パネルディスカッション「自社のWebアプリの使い勝手を評価してみましょう」の様子 |
「RIAにすると何が良くなるのか」を説明するには?
1つ目のディスカッションのテーマとして新野氏は、「ユーザーエクスペリエンス(以下、UX)向上のROI(Return On Investment、投資収益率)」を挙げた。このパネルディスカッションは、「リッチクライアント・カンファレンスIV」の最後の時間帯のものだったが、それまでの基調講演や4氏による個別のセッションを見ると、全体的に「リッチクライアント/RIAに代表される表現力豊かなユーザーインターフェイス(以下、UI)のアプリケーションを使うことによってUXが向上すると、ビジネスに良い効果がある」ということが強調されていた。
■ UXとROI
モデレータの新野淳一氏 |
SIerやコンサルタント、開発者の立場に立つと、これまでに業務アプリケーションの開発方法論には、UXの向上という要素はほとんどなかった。これに「UXの向上」という要素を提案すると、余計なコストや工数が掛かると思われてしまう。そこで新野氏は「顧客にどうROIを説得したらよいのか。あるいは、UX向上は主に顧客(開発依頼者側)が主体的に考えるべきことなのだろうか」と4氏に問い掛けた。
まず轟氏は「ROIの話をするのは難しい。なぜかというと、UX向上によってどれだけ売り上げを上げられるかという話になると判断ができないからだ。逆に、コストをどれだけ抑えられるか、という話の方が現実的だ」と答えた。操作が直感的なアプリーションだと、サポートセンターが必要なくなったりトレーニングに掛かるコストが削減できるということだ。
これには、三野氏も同意し、次のように付け加えた。「ある経営層の顧客にRIAの画面を見せたときに『なんだ、C/Sシステムと何も変わらないじゃないか』といわれたことがある。プラットフォームがWebかどうかの違いはあるが、C/SとRIAは使いやすさという点ではあまり違いがないので、トレーニングのコストを抑えることができる。抑えられるコストの数値を明確にイメージしやすい」
淡路氏は「UXを向上させるターゲットをどこに絞るかで事情は違ってくるのではないだろうか。例えば、企業ページのリニューアルにおいてUXを向上させるか、または基幹システムの業務推進をスムーズにさせるという意味でUXを向上させるかなどによって、使う技術や手法が変わってくる。一概に、こうだと決められるものではない」と述べた。ROIの話をするにはあらかじめ、“物差し”を決める必要があるということだ。
マイクロソフト デベロッパー&プラットフォーム統括本部 デベロッパービジネス本部 エバンジェリスト 川西裕幸氏 |
川西氏はROIについて数値化の話を次のように強調した。「本日の聴講者は企業系システムの開発者、またはそれにかかわる人が多いかと思うが、そういった人に必要なのは結局、要件を数値化することだ。それができないとROIを見積もれないし“結果”として分からない」
その数値とは、効率性かもしれないし、いかに失敗する数が少ないかかもしれない。コンシューマ向けであれば、いわゆるECサイトに訪れたユーザーの何%が購買までたどり着くかという数値かもしれない。さらに川西氏は「そういった数値を明確にしなければ、新しいシステム/UIにする意味がない。何のためにUXを向上させるのかを考えると、それは何らかの利益を得るためなので、数値を明確にする必要がある」といい切った。
■ RIAへの移行を促す際に困ったこと
次に新野氏は「RIAへの移行を顧客促す際に“困った”ことは?」という質問を4氏にぶつけた。
これについてまず三野氏は、「C/Sではなく、いわゆるHTMLベースのWebシステムを使っている顧客を相手にする場合、コンシューマ向けだと『UIが良くないとユーザーに使ってもらえないと』と説得しやすいのだが、ビジネス向けだと『そんな機能は要らない』または『UIに余計なものを加えると逆に使いにくくなるのではないか』と疑問を持たれたことがある」という例を紹介した。逆に、C/Sの業務アプリケーションに慣れた顧客の方がRIAの良さをすぐに分かってもらいやすいのだろう。
次に淡路氏は、「10年前からリッチクライアントを使っている」という顧客がいたと明かした。10年前にはリッチクライアントという言葉はなかったはずだ。これはどういうことなのか。
「よく話を聞くと、PowerBuilderや初期のVisual Basic(以下、VB)などいわゆる“ファットクライアント”、つまりC/Sを使っていて、いままでのWebシステムや新しい技術に取り組もうとして、できること・できないことの評価に苦労していたとのことだった」(淡路氏)。その顧客は例えば、プロトタイプを作ってみたがパフォーマンスが出なかったとか、コスト的に稟議の承認が下りなかったなど、いろいろとチャンレンジしてきたそうで、「RIAのような技術が市場に広まってきて、『ようやく自分たちでも取り組みやすくなった』といってくれる顧客もいる」(淡路氏)
このような「そんな機能は要らない」「RIAへ移行したかったが難しかった」という“困った”事例以外にも、次のような事例もあった。「『いままでのデスクトップアプリケーションでできたことは当然RIAでもできるよね』といってくる顧客がいた。そこで、『やれない』とはいえず、『やれないことはないですよ』といったことはある」(轟氏)
カール RIAエバンジェリストの三野凡希氏 |
そうなると、三野氏の事例のように、そんな「ぜいたくな機能は要らない」と断る顧客と「これぐらいはできるよね」という真逆の意見の顧客はどちらが多いのか、という疑問につながる。新野氏が三野氏に聞いてみると、「『これぐらいできるよね』という顧客の方が多い」と三野氏。さまざまなRIA製品の出現による相乗効果も含めて、市場が大きくなってきているのが要因なのだろうか。「そんな機能は要らない」といわれるよりは、ハードルが高い提案をしてくれる方がベンダにとっては喜ばしい傾向だと思われる。
「例えばAdobe AIRのようにCurlもローカルの資源にアクセスできるが、数年前ならWebアプリケーションがローカルの資源にアクセスするなんてとんでもない。何たるセキュリティへの考慮の甘さだと思われがちだった。しかし、最近はそういった感覚が『マヒしている』というのは、いい過ぎかもしれないが、なじみやすくはなってきているのではないだろうか。それが良いか悪いかはよく分かりませんが」と三野氏は苦笑いをした。
さらに、「製造業系の設計部門を統合するシステムを提案されたときの話だが、そういった顧客はもともとCADを使っているので、表現力に対する発想が非常に柔軟だった。われわれの発想を上回るものを要求され、『できません』とはいえず『難しいですね』といったことがあります」という三野氏の事例に、新野氏は「RIAの市場としてはCADのC/Sが狙い目かもしれませんね」と付け加えた。
川西氏はさらに付け加えて「いわゆる帳票系のシステムは割と保守的で、10年も同じ人がデータ入力しているから『もう現行のUIやシステムを変えなくていいよ』という顧客がいた。しかし、それはとても危険なことで、その10年やっている人が明日入院するかもしれないし、退職するかもしれない。そうすると、別の人に一から教育しなければならなくなる。そう考えると『別に使いにくいUIでいい』という考え方はとても危険をはらんでいる」
「それはRIAへ移行を促すのに良いせりふかもしれない」と新野氏は1つ目のディスカッションを締めくくった。
UX向上はどのように進めればよいのか?
次のディスカッションのテーマとして、「UX向上の方法論、組織論について」が挙げられた。具体的に使い勝手を評価するのは、どうやればよいのか。どのようにUXの専門家を育成すればよいのか。改善にはどのような組織、開発体制が望ましいのか、ということだ。
■ UXの指標と数値化
例えば、ユーザビリティテストというものがある。あるアプリケーションの前に見ず知らずの人を連れてきて、ある目的の操作を指定して実行してもらい、操作をいくつ間違えたか、目的の操作を達成するのに時間はどれくらいかかったか、というものだ。新野氏は「ユーザビリティテストのようなUX評価のノウハウがあるか。または、要件に『目的を達成するのに平均でどれくらい時間がかかるか』といったことは書けるものなのか」とまず、川西氏に尋ねた。「実際にはまだ見たことがないが、そう書かれるべきだと思う。例えば、トレーニングにかかる時間、作業にかかる時間や間違える確率などの数値だ」(川西氏)
ある業務については分かっているが、そのために作られたアプリケーションについては分かっていないという人を連れてきて、ある目的に向かってそのアプリケーションを操作するのにどれくらいの時間がかかるか、というのが分かりやすい指標と考えられる。
これに対して、轟氏は「もっと大事なのは、2回目、3回目と同じ操作を行って、どれくらい時間を短縮できるかということだ。つまり、アプリケーションがユーザーをトレーニングできるのか、成長させられるのかという視点が大事なのではないだろうか。1回目は操作が遅くても2回目、3回目で劇的に速くなっているというのは良いことだ。それが顕著に見られるのはゲームのアプリケーションで、マニュアルなどを見ずに何げなく始めてみても、気付いたら非常にうまくなっているものだ。それと同じことが業務アプリケーションでもできるのではないだろうか」と強調した。
日本ネクサウェブ セールス・マーケティング マネージャー 淡路良平氏 |
淡路氏は「ユーザビリティテストを行う際に、コンシューマ向けのサイト/アプリケーションと業務アプリケーションでは注意するべき点が全然違う」と述べた。例えば企業ページでは、「初めてページに来て利用する」というユーザーを前提にするべきだし、会員サイトであれば、ログイン情報を入力するUIが必要でログイン後には特定の人に対するポータルサイトが表示されるなどの視点でのUXの向上が必要となる。一方業務アプリケーションでは、多機能なものが必要なくどれだけシステムを簡素化して業務効率を上げるかがコスト削減につながるポイントになってくる。
「例えば、入力項目がたくさんある業務アプリケーションの場合、1つの項目の入力が終わると勝手にカーソルが次の項目に移動しキー操作だけでどんどんデータが登録されていって次の画面に移動するといった、業務のスムーズ化・時間短縮化の機能がユーザーにはうれしい機能となってくる。逆に、コンシューマ向けアプリケーションではたくさんの機能を自分で試しながら使いたいという面があるので、やはり業務向けとコンシューマ向けでは、別々に考える必要がある」(淡路氏)
■ RIAプロジェクトの開発・運用・育成体制
ここで三野氏は「業務アプリケーションというものは、もともとUIだけを作るための部隊がないが、コンシューマ向けでは存在する。業務アプリケーションでも、同じような体制を作ることが重要ではないだろうか」と話題を開発・運用・育成体制に移した。
それについて淡路氏は「業務アプリケーションの開発者というのはどちらかというと堅く、業務フローをどう進めていくかというのを重視していて、デザイン/UIは、“その次”になる。RIAを作るとなるとデザイナと話す機会が多いのだが、やはりデザイナは開発者と発想が全然違っていて見た目やビジュアル面から考える。このため、両者にはギャップが生じる。開発者とデザイナの勉強会/打ち合わせなどを行ってギャップを埋めることが、UXの専門家を育成するのに必要ではないだろうか」と説明した。
川西氏は付け加えて「開発チームの中にUXに“責任”を持つ人が必要だ。それは、デザイナかもしれないし、プログラマかもしれないし、プロデューサーかもしれないが、もともとの役割は関係ない。要は、ある製品の仕様としてUXというものがあるので、それに責任を持つ人がいないことが問題だ」と指摘した。
Webブラウザの制限と、それを超える“何か”
ここで話題は大きく変わって「現在のWebテクノロジについて」と、テーマが技術寄りのものとなった。
■ 現在のWebテクノロジはもう“十分”か?
HTML、JavaScript/Ajax、Flash、Curl、Silverlightなど、現在のWebの表現力やロジックは、十分なUXをもたらすものになっているのか。もし十分でないとすれば、何が足りないと考えるか。また、Web技術はいずれ、例えばVBアプリケーションのような表現力や機能を備えるようになるのか。あるいは現在、技術としてはすでにその域に達していて、後はユーザーの開発能力次第なのか。
これについては、まず淡路氏が口火を切った。「技術の革新というものは非常に速く、これで十分だと思っても、また2・3年後に新しい技術が出てくるので、ゴールというものはないと感じている。時代に応じて必要な技術を取り込むことが重要ではないだろうか」
三野氏は「技術的にはもしかしたら十分なところまで達しているのかもしれないが、アプリケーションが追い付いていないと、個人的には思う。RIAは技術的には深いところまできているが、それを十分に使い切れているアプリケーションがまだないのではないだろうか。それはなぜかというと、アプリケーションを多くのユーザーに見て使ってもらう機会がまだまだ少ないからではないだろうか。そのためにカールとしては、Curl Apps Galleryというサービスを始めた。そういったユーザーにもっとRIAを見て使って評価してもらう機会を増やすことによって、コアな技術がアプリケーションに応用されていくのではないだろうか。そのためには、われわれベンダ側がもっと技術や使い方を提案してアピールしていく必要があるだろう。といっても、現在の技術ですべてが十分というわけではなく、業務アプリケーションでは、より強固なセキュリティ機能やオフライン機能が求められるし、3Dといった新しいUI技術も拡張されるべきだ」と続けた。
アドビシステムズ マーケティング本部クリエイティブソリューション部 Webグループ ディベロッパーマーケティングスペシャリストの轟啓介氏 |
轟氏は具体的なアプリケーションを例に出し、「個人的にはGoogle Docsが便利だと思っていて、プレゼンテーションを作成しようと、その途中で思わず画像をデスクトップからドラッグ&ドロップしようとしたら、それができなかった」と話した。もちろんこれは、Google DocsというよりもWebブラウザの問題でできないのだが、これだけWebアプリケーションが世に広まってくると、それもできるのではないかと当然のように思ってしまうのもうなずける。「Webブラウザはもっと進化する余地があると思うので、セキュリティの問題をうまいことクリアしてドラッグ&ドロップなどができるようになってほしい」(轟氏)
川西氏は「いまある技術の表現力は十分だと思うが、あるコストの範囲内で効率的に作れるかという問題は別だ。その要因としては、WebブラウザやHTMLの制限が大きい」と指摘した。
■ 今後、Web/RIA技術はどうなる?
最後に新野氏が提示したディスカッションのテーマは、以下のような今後についてのもの。いま話題のFirefox 3.1やIE 8、Google Chrome、Safari、Adobe AIR、Silverlight、Ajax、HTML 5、Gearsなどなど、新しいWebブラウザやテクノロジの登場をどう評価するか。あるいは、注目している次世代テクノロジはどんなものか。未来はどのようになっていくのか。これらのテーマについて新野氏は「ぜひ、自社技術以外のものにも言及をお願いする」と付け加えた。
「アドビシステムズ以外の技術でいうと、Gearsに注目している。SQLite搭載やオフライン機能などAdobe AIRに非常に似ているところがあり、違いはJavaScriptとActionScriptの違いぐらいではないかと思う。こういった機能を搭載する流れから、未来に対する方向性が見えてくるのではないだろうか」(轟氏)
「Berylの3Dデスクトップ機能やGoogle ChromeのJavaScript高速化に注目している。RIA開発に最も大変なのはパフォーマンスを速くすることだ。JavaScriptのチューニングに労力を削らなくても、高速なJavaScriptのアプリケーションができてしまうかもしれないということは、JavaScript開発者の皆さんにとっては非常に良い環境ができてきたといえるのではないだろうか。また、Curlと同じようにWebブラウザの制限を超えたデスクトップ機能を備えているAdobe AIRにも注目している」(三野氏)
「自分のセッションではOfficeの話しかしなかったので、ここでいわせてもらうと、Silverlight 2に注目している。JavaScriptだと型が定義できないし、UIを作るのにもコーディングが大変だが、Silverlight 2はC#やVBで使っていたコードのほとんどがそのまま使えるし、デバッグが楽で保守もしやすく効率性がいい。先ほどいったWebブラウザやHTMLの制限に加え、JavaScriptの制限もかなり和らげてくれる良いツールではないだろうか」(川西氏)
淡路氏は「いろいろなWebブラウザが出てきているが、それぞれの動作の違いを吸収するエンジン/プラットフォ−ムが出てきてほしい。そうすれば、顧客にも長期にわたって製品を提案しやすくなる」と述べ、新野氏は「確かに、これだけ多種類のWebブラウザが出てくると、Webブラウザによる動作の違いというのは、今後の重要なテーマとなるだろう」とセッションを締めくくった。
■ 関連リンク
ユーザビリティのヒント Webアプリケーションのユーザーインターフェイスデザインに役立つさまざまなヒント集。自動販売機でジュースを買うときの不要な動作から考える |
Webアプリケーションのユーザーインターフェイス 従来のデスクトップアプリケーションでのGUIやインタラクションの原則から、Webアプリケーションのデザインを考えよう |
“リッチクライアント”に至るまでの軌跡と現在(いま) いまさら聞けないリッチクライアント技術(6) 今回はフォーラム名にもある“リッチクライアント”の成り立ちとAjax、Flashなど現在活躍している主な技術を一覧で紹介します 「リッチクライアント & 帳票」フ ォーラム 2007/11/26 |
いまさら聞けない「Webブラウザ」超入門 いまさら聞けないリッチクライアント技術(11) インターネットに接続するために、当然のように利用するWebブラウザ。Webサーバとのやりとりから、その仕組みを知っておこう 「リッチクライアント & 帳票」フ ォーラム 2008/4/14 |
いまさら聞けないオフラインWeb、スタンドアロン型とは いまさら聞けないリッチクライアント技術(14) Webアプリだって、オフラインで使いたい!に応えるオフラインWebアプリ。Google Gears、Adobe AIR、Prismの3つを紹介 「リッチクライアント & 帳票」フ ォーラム 2008/7/17 |
RIA&帳票はSaaSを巻き込みPCを超えて多様化する SODEC 2008 リッチクライアント&帳票レポート 最新のRIA&帳票の技術をSODECからお届け。RIAと帳票の連携、SaaSやPC以外の端末との融合が今後とも注目です 「リッチクライアント & 帳票」フ ォーラム 2008/6/4 |
RIA/リッチクライアントの明日はどっちだ? RIA in Developers Summit 2008 レポート 先日開催されたデブサミのセッションの中からRIA/リッチクライアントに関するものを中心にいくつかレポートする 「リッチクライアント & 帳票」フ ォーラム 2008/2/20 |
リッチクライアント&帳票 全記事一覧へ |
- 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データの選択、挿入、削除、コピー、移動、ソートに使うメソッドの使い方などを解説する
|
|