@IT編集部主催による「リッチクライアント・カンファレンスIV」が行われた。本稿では、Aトラックのパネルディスカッション「自社のWebアプリの使い勝手を評価してみましょう」の模様をレポートする(基調講演やBトラックのパネルディスカッションの模様は記事「セキュリティ、開発負荷削減、エンドユーザー支援が鍵」を参照)。モデレータは前@IT発行人の新野淳一氏が務めた。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年前にはリッチクライアントという言葉はなかったはずだ。これはどういうことなのか。Basic(以下、VB)などいわゆる“ファットクライアント”、つまりC/Sを使っていて、いままでのWebシステムや新しい技術に取り組もうとして、できること・できないことの評価に苦労していたとのことだった」(淡路氏)。その顧客は例えば、プロトタイプを作ってみたがパフォーマンスが出なかったとか、コスト的に稟議の承認が下りなかったなど、いろいろとチャンレンジしてきたそうで、「RIAのような技術が市場に広まってきて、『ようやく自分たちでも取り組みやすくなった』といってくれる顧客もいる」(淡路氏)このような「そんな機能は要らない」「RIAへ移行したかったが難しかった」という“困った”事例以外にも、次のような事例もあった。「『いままでのデスクトップアプリケーションでできたことは当然RIAでもできるよね』といってくる顧客がいた。RIAエバンジェリストの三野凡希氏そうなると、三野氏の事例のように、そんな「ぜいたくな機能は要らない」と断る顧客と「これぐらいはできるよね」という真逆の意見の顧客はどちらが多いのか、という疑問につながる。新野氏が三野氏に聞いてみると、「『これぐらいできるよね』という顧客の方が多い」と三野氏。さまざまなRIA製品の出現による相乗効果も含めて、市場が大きくなってきているのが要因なのだろうか。「そんな機能は要らない」といわれるよりは、ハードルが高い提案をしてくれる方がベンダにとっては喜ばしい傾向だと思われる。AIRのようにCurlもローカルの資源にアクセスできるが、数年前ならWebアプリケーションがローカルの資源にアクセスするなんてとんでもない。何たるセキュリティへの考慮の甘さだと思われがちだった。最近はそういった感覚が『マヒしている』というのは、いい過ぎかもしれないが、なじみやすくはなってきているのではないだろうか。それが良いか悪いかはよく分かりませんが」と三野氏は苦笑いをした。「製造業系の設計部門を統合するシステムを提案されたときの話だが、そういった顧客はもともとCADを使っているので、表現力に対する発想が非常に柔軟だった。われわれの発想を上回るものを要求され、『できません』とはいえず『難しいですね』といったことがあります」という三野氏の事例に、新野氏は「RIAの市場としてはCADのC/Sが狙い目かもしれませんね」と付け加えた。川西氏はさらに付け加えて「いわゆる帳票系のシステムは割と保守的で、10年も同じ人がデータ入力しているから『もう現行のUIやシステムを変えなくていいよ』という顧客がいた。それはとても危険なことで、その10年やっている人が明日入院するかもしれないし、退職するかもしれない。すると、別の人に一から教育しなければならなくなる。「それはRIAへ移行を促すのに良いせりふかもしれない」と新野氏は1つ目のディスカッションを締めくくった。UX向上はどのように進めればよいのか?次のディスカッションのテーマとして、「UX向上の方法論、組織論について」が挙げられた。具体的に使い勝手を評価するのは、どうやればよいのか。どのようにUXの専門家を育成すればよいのか。改善にはどのような組織、開発体制が望ましいのか、ということだ。ユーザビリティテストというものがある。あるアプリケーションの前に見ず知らずの人を連れてきて、ある目的の操作を指定して実行してもらい、操作をいくつ間違えたか、目的の操作を達成するのに時間はどれくらいかかったか、というものだ。新野氏は「ユーザビリティテストのようなUX評価のノウハウがあるか。要件に『目的を達成するのに平均でどれくらい時間がかかるか』といったことは書けるものなのか」とまず、川西氏に尋ねた。「実際にはまだ見たことがないが、そう書かれるべきだと思う。トレーニングにかかる時間、作業にかかる時間や間違える確率などの数値だ」(川西氏)ある業務については分かっているが、そのために作られたアプリケーションについては分かっていないという人を連れてきて、ある目的に向かってそのアプリケーションを操作するのにどれくらいの時間がかかるか、というのが分かりやすい指標と考えられる。これに対して、轟氏は「もっと大事なのは、2回目、3回目と同じ操作を行って、どれくらい時間を短縮できるかということだ。アプリケーションがユーザーをトレーニングできるのか、成長させられるのかという視点が大事なのではないだろうか。1回目は操作が遅くても2回目、3回目で劇的に速くなっているというのは良いことだ。それが顕著に見られるのはゲームのアプリケーションで、マニュアルなどを見ずに何げなく始めてみても、気付いたら非常にうまくなっているものだ。それと同じことが業務アプリケーションでもできるのではないだろうか」と強調した。淡路氏は「ユーザビリティテストを行う際に、コンシューマ向けのサイト/アプリケーションと業務アプリケーションでは注意するべき点が全然違う」と述べた。企業ページでは、「初めてページに来て利用する」というユーザーを前提にするべきだし、会員サイトであれば、ログイン情報を入力するUIが必要でログイン後には特定の人に対するポータルサイトが表示されるなどの視点でのUXの向上が必要となる。業務アプリケーションでは、多機能なものが必要なくどれだけシステムを簡素化して業務効率を上げるかがコスト削減につながるポイントになってくる。「例えば、入力項目がたくさんある業務アプリケーションの場合、1つの項目の入力が終わると勝手にカーソルが次の項目に移動しキー操作だけでどんどんデータが登録されていって次の画面に移動するといった、業務のスムーズ化・時間短縮化の機能がユーザーにはうれしい機能となってくる。ここで三野氏は「業務アプリケーションというものは、もともとUIだけを作るための部隊がないが、コンシューマ向けでは存在する。それについて淡路氏は「業務アプリケーションの開発者というのはどちらかというと堅く、業務フローをどう進めていくかというのを重視していて、デザイン/UIは、“その次”になる。RIAを作るとなるとデザイナと話す機会が多いのだが、やはりデザイナは開発者と発想が全然違っていて見た目やビジュアル面から考える。このため、両者にはギャップが生じる。開発者とデザイナの勉強会/打ち合わせなどを行ってギャップを埋めることが、UXの専門家を育成するのに必要ではないだろうか」と説明した。川西氏は付け加えて「開発チームの中にUXに“責任”を持つ人が必要だ。それは、デザイナかもしれないし、プログラマかもしれないし、プロデューサーかもしれないが、もともとの役割は関係ない。要は、ある製品の仕様としてUXというものがあるので、それに責任を持つ人がいないことが問題だ」と指摘した。Webブラウザの制限と、それを超える“何か”ここで話題は大きく変わって「現在のWebテクノロジについて」と、テーマが技術寄りのものとなった。現在のWebテクノロジはもう“十分”か?HTML、JavaScript/Ajax、Flash、Curl、Silverlightなど、現在のWebの表現力やロジックは、十分なUXをもたらすものになっているのか。十分でないとすれば、何が足りないと考えるか。Web技術はいずれ、例えばVBアプリケーションのような表現力や機能を備えるようになるのか。現在、技術としてはすでにその域に達していて、後はユーザーの開発能力次第なのか。これについては、まず淡路氏が口火を切った。「技術の革新というものは非常に速く、これで十分だと思っても、また2・3年後に新しい技術が出てくるので、ゴールというものはないと感じている。三野氏は「技術的にはもしかしたら十分なところまで達しているのかもしれないが、アプリケーションが追い付いていないと、個人的には思う。RIAは技術的には深いところまできているが、それを十分に使い切れているアプリケーションがまだないのではないだろうか。それはなぜかというと、アプリケーションを多くのユーザーに見て使ってもらう機会がまだまだ少ないからではないだろうか。Galleryというサービスを始めた。いったユーザーにもっとRIAを見て使って評価してもらう機会を増やすことによって、コアな技術がアプリケーションに応用されていくのではないだろうか。そのためには、われわれベンダ側がもっと技術や使い方を提案してアピールしていく必要があるだろう。いっても、現在の技術ですべてが十分というわけではなく、業務アプリケーションでは、より強固なセキュリティ機能やオフライン機能が求められるし、3Dといった新しいUI技術も拡張されるべきだ」と続けた。Docsが便利だと思っていて、プレゼンテーションを作成しようと、その途中で思わず画像をデスクトップからドラッグ&ドロップしようとしたら、それができなかった」と話した。DocsというよりもWebブラウザの問題でできないのだが、これだけWebアプリケーションが世に広まってくると、それもできるのではないかと当然のように思ってしまうのもうなずける。「Webブラウザはもっと進化する余地があると思うので、セキュリティの問題をうまいことクリアしてドラッグ&ドロップなどができるようになってほしい」(轟氏)川西氏は「いまある技術の表現力は十分だと思うが、あるコストの範囲内で効率的に作れるかという問題は別だ。その要因としては、WebブラウザやHTMLの制限が大きい」と指摘した。今後、Web/RIA技術はどうなる?最後に新野氏が提示したディスカッションのテーマは、以下のような今後についてのもの。5、Gearsなどなど、新しいWebブラウザやテクノロジの登場をどう評価するか。注目している次世代テクノロジはどんなものか。未来はどのようになっていくのか。これらのテーマについて新野氏は「ぜひ、自社技術以外のものにも言及をお願いする」と付け加えた。「アドビシステムズ以外の技術でいうと、Gearsに注目している。AIRに非常に似ているところがあり、違いはJavaScriptとActionScriptの違いぐらいではないかと思う。ChromeのJavaScript高速化に注目している。RIA開発に最も大変なのはパフォーマンスを速くすることだ。JavaScriptのチューニングに労力を削らなくても、高速なJavaScriptのアプリケーションができてしまうかもしれないということは、JavaScript開発者の皆さんにとっては非常に良い環境ができてきたといえるのではないだろうか。2はC#やVBで使っていたコードのほとんどがそのまま使えるし、デバッグが楽で保守もしやすく効率性がいい。先ほどいったWebブラウザやHTMLの制限に加え、JavaScriptの制限もかなり和らげてくれる良いツールではないだろうか」(川西氏)淡路氏は「いろいろなWebブラウザが出てきているが、それぞれの動作の違いを吸収するエンジン/プラットフォ−ムが出てきてほしい。すれば、顧客にも長期にわたって製品を提案しやすくなる」と述べ、新野氏は「確かに、これだけ多種類のWebブラウザが出てくると、Webブラウザによる動作の違いというのは、今後の重要なテーマとなるだろう」とセッションを締めくくった。関連リンクユーザビリティのヒントWebアプリケーションのユーザーインターフェイスデザインに役立つさまざまなヒント集。インターネットに接続するために、当然のように利用するWebブラウザ。Webアプリだって、オフラインで使いたい!に応えるオフラインWebアプリ。最新のRIA&帳票の技術をSODECからお届け。(2017/7/12)資料を作る際に、「グラフ」は必要不可欠な存在だ。(2017/6/26)素数判定のロジックからbreak文やcontinue文の利点と使い方を解説。