「Wordユーザーの80％は全機能の20％しか使わない」はモバイルでも真実か：デスクトップアプリと同じやり方は通用しない

モバイルアプリにはデスクトップアプリとは異なるユースケースがあり、デスクトップアプリほどの物理的スペースもない。デスクトップアプリのやり方を踏襲したのでは、成功は望めない。

[Bryan Barringer，TechTargetジャパン]

　モバイル端末とデスクトップとは全くの別物だ。だが、企業向けのWindowsデスクトップアプリとモバイルアプリのこととなると、口で言うほど簡単ではない。アプリ開発チームは、アプリケーションをどのプラットフォームに対応させるかについて、その選択に伴う派生的な影響を含めて検討しなければならない。リリースまでに実装すべき機能はプラットフォームごとに異なるかもしれないし、ときには同じアプリケーションのロードマップをOSごとに分けて管理しなければならない可能性すらある。

関連記事

• オフィススイートに5万円払うのは時代遅れなのか？
• 徹底レビュー：切羽詰まった状況でスマホ版「Microsoft Office Mobile」は役に立つのか？
• 徹底レビュー：iPad版「Microsoft Office」を本気で使う　PC版Officeはもう不要か
• 「iPad版Microsoft Office」の完成度の高さで“PC不要論”が加速
• 実は無料版も　知らないと損をする「Microsoft Office」再入門

　例えば、100個の機能を搭載する製品のロードマップを想像してみよう。必要な調査は既に全て済ませており、MVP（Minimum Viable Product：必要最低限の機能のみを持つ製品）を作成するには、まずどの機能を開発すべきかは理解している。つまり、その製品の最初のバージョンにどの機能を実装すべきかをきちんと把握しているという状態にあるとする。

　ここで最も重要な疑問は「従業員や顧客などのエンドユーザーが、このアプリケーションをどのプラットフォームで使うか」だ。ユーザーインタフェース部分でどの機能を提供し、また幾つの機能を実装できるかを判断する上で、この疑問への答えは極めて重要となる。

デスクトップアプリの定説「80対20」の法則

　Windowsデスクトップアプリとモバイルアプリの違いを説明するための例として、私は米Microsoftの「Microsoft Office」を引き合いに出す。「デスクトップ版Wordユーザーの80％は全機能の20％しか使わない」というのはよく言われる話だ。この数字自体は厳密ではないのだろうが、要は「デスクトッププラットフォームには広大なユーザーインタフェースがあり、その余裕があるからこそ、開発者は大量の機能を詰め込める」ということだ。WindowsデスクトップPCやノートPCのように大きな画面や外付けモニターを使える環境であれば、対応アプリケーションは何百もの機能を提供できるが、それらの機能が実際に使われるかどうかはあまり重視されない。

　製品管理の観点からすれば、ユーザーの80％が全機能の20％しか使わないとしても、デスクトップアプリであれば許容範囲だろう。だがモバイルアプリには、この「80対20」の法則は当てはまらない。可能な限りの機能を全て詰め込むためには、スマートフォンやタブレットには圧倒的にスペースが少ない。提供機能のうち80％が使われていない場合、貴重なスペースの無駄遣いとなる。そうした状態では、一度はインストールされたアプリもすぐにアンインストールされてしまうだろう。

　前述した100個の機能を含む製品のロードマップを80対20の法則でみると、デスクトップアプリであれば、ユーザー体験を損なうリスクを負わずに80個の機能を実装できる。だが、同一アプリのモバイル版については、わずか20個の機能で成否が決まることになる。

　つまり、デスクトップアプリとモバイルアプリでは同じ成功率を得るために実装すべき機能の数に大きな差があるということだ。従って、アプリの各バージョンに実装する機能の選別には真剣な議論と調査、ユーザー体験（UX）分析が必要となる。

関連記事

• モバイルアプリ開発は“よちよち歩き”の成熟度でしかない
• 「HTML5でモバイルアプリ開発」は是か非か？　ネイティブアプリと比較
• モバイルアプリ開発を加速する「mBaaS」のメリット／デメリット
• モバイルアプリの社内開発が頓挫、その時、中小企業が動いた

UX分析を活用する

　ユーザー体験（UX）分析は、アプリ開発に投資する関係者が議論に使うためだけのものではない。開発者はユーザーのニーズや求められるプラットフォームに基づき、個々の機能を実装する影響を検討する必要がある。

　実際、UX分析で極めて重要なのは、ターゲットユーザーのユースケースとペルソナ（人物像）を設定することだ。開発者は実社会での観察や調査、ペルソナ作成用のフォーカスグループに基づき、ユーザーのアプリケーション体験を補完できる機能や損なう機能を判断できる。この洞察は、最初のバージョンにどの機能を実装すべきかを判断するための意思決定プロセスにおいて大いに役に立つ。

　Microsoft Officeの例で確認しておこう。モバイルデバイス向けにOffice製品をリリースする最善の方法をめぐっては、Microsoftの優秀なアプリケーション開発チームでさえ、急勾配の学習曲線を押し進める必要があった。デスクトップ版Officeに、われわれ皆が使い慣れた機能やお気に入りの機能がどれだけあるかを考えてみてほしい。開発者はそのうちどの機能をモバイル版に採用すべきかを判断し、さらに、その最善の実装方法を検討する必要がある。ユーザーが希望する有用な機能を全て盛り込むわけにもいかず、Microsoftは結局、モバイル向けのOfficeを最初に発表してから、使い物になる製品をリリースするまでに1年近くを費やした。

　アプリケーションにどの機能を実装するかの判断は、気の遠くなるような作業だ。だが検討と分析を十分に重ねることで、開発者にとってもユーザーにとってもより良い結果が得られることになる。