あるとよい機能はない方がよい

UXデザインのコンサルティングではよく品質優先度マッピングというものを行います。これは開発プロジェクトの上流工程において、実装を検討している機能をリストアップし、そのひとつひとつについて想定する利用者の割合や利用頻度の観点からグルーピングし、実装の優先度を決める作業です。

これを行う目的は、UIをできるだけシンプルに保つことにあります。ユーザーが求める機能をすべて盛り込むと、当然UIは複雑になり、誰にとっても使いにくいものになります。また蓋然性のバランスが取れていない要件はプログラムを複雑にし、バグが増える原因になります。

UIデザインにおけるパレートの法則（結果の大部分は全体の一部によって生み出される）は、「ユーザーの80%は全機能の20%しか使わない」というものです。その20%に注力し他の優先度を下げることで、製品の利便性は向上するはずです。

Core, Important, Nice to Have

品質優先度マッピングの結果、各機能の優先度は次の三段階に分類されます。

• Core
  • 中心的機能。それがないと製品として成立しないもの。
  • 起動直後の状態ですぐに実行できるようにする。
• Important
  • 特徴的機能。それがないとその製品を市場に出す意味がないもの。
  • 起動直後の状態から1〜2ステップで実行できるようにする。
• Nice to Have
  • あると尚よし、という機能。
  • 優先度の低い機能としてあえて深い階層に隠す。

アジャイルなプロセスであれば当然、Core から開発をはじめ、それができたら次に Important を作ることになります。

そこで私が言うのは、「Nice to Have な機能はできるだけ実装しない方がよい」ということです。あるとよい機能はない方がよい。”Nice to have is not to have.” なのです。

なぜなら、ユーザーにとって道具はできるだけシンプルな方がよいはずだからです。

機能が少ない方がユーザーは使い方を習得しやすいですし、シンプルであるほど自分なりの使い方を工夫することができ、道具をもっと自分のものにすることができるでしょう。ユーザーの能動性は学習効率を高め、その結果生産性が高まる好循環を生み出します。

製品を成立させる中心的な機能、およびそれを他の製品と区別する特徴的機能がしっかりと作られているなら、それ以外の機能は少ない方がよいのです。

そして機能が少ないということは、単純に、開発コストも少なくすみ、早くリリースできるということです。

デザイナーやプログラマーは重要な部分に集中してクォリティを追求することができます。

明快なコンセプトが重要

しかしこの考え方をシステムのオーナーと共有するのはとても難しいことです。機能の多さと製品の競争力は比例すると考える人は多いのです。

例えば企画段階で出されたいろいろな機能アイデアについてそれぞれ Core, Important, Nice to Have のどれに該当するか分類してくださいというと、何十もの機能をすべて Core と Important に割り振る人が多くいます。あれば尚よしなどという機能はありません、すべて必要です、という具合です。

もし本当にそう考えているなら、それは企画に問題があるということになります。コンセプトが明確ではないということです。コンセプトが単純明快であれば、Core と Important はかなり限られたものになるはずです。より少ない要素でその製品が存在する意義を説明できるということですから。

その場合は、もう一度企画に立ち返ってコンセプトを練り直すことを提案します。特に、ある製品の最初のバージョンでは、厳選した Core と Important でリリースすることが望ましいのです。本当に魅力的なコンセプトであればそれだけで競争力は十分あるでしょうし、そうすることで開発期間を最小にできると同時に、余計な機能がないので後からピボットするのも容易になります。

明快なコンセプトと必要最小限の実装でスピード感をもって製品を市場に出すという方法は、リーンスタートアップとも呼ばれ、昨今のウェブサービス／モバイルアプリでは当たり前になりつつあります。また例えば発売当初は機能が少ないと言われた iPhone が、その操作性の良さから大きな商業的成功をおさめたことも記憶に新しいところでしょう。

最初から必要以上に機能を詰め込んでしまうと、一度つけた機能を後から取り除くことは難しいので、サービスを育てにくくなってしまいます。

ある程度バージョンを重ねた製品であれば、ユーザーの成長にあわせて Nice to Have な機能を追加していくことに一定の意義があることもあるでしょう。もしくはすでに同種の競合製品が多く存在していて、小さな機能性の違いがユーザーの意思決定に大きな影響を及ぼすこともあります。その場合は Nice to Have な機能の追加を検討する余地があるかもしれません。

それでも、もし Core と Important が競合製品よりも優れているのなら、むしろそれ以外を排除してシンプルさを保つことで、コンセプトに共感するファンを増やし、結果的に製品の寿命をのばすことにつながるはずです。

UXについての価値観を共有する組織

とはいえ、このような考え方は一種の理想論であり、現実には、様々な組織内の事情によって、Nice to Have な機能を排除するのはなかなか難しいものです。特に有料で販売している製品やすでに多くのユーザーを抱えているサービスでは、後から機能を削ることは現実的ではないかもしれません。

また業務アプリケーションでは、本来ひとつのシステムとしてまとまりをつけようがないほどの多様な機能が業務要件として確定してしまっていて、システムの利便性を高めるには業務自体の構成やフローを見直さなければならないことも多くあります。

そいういった場合には、優先度の低い機能はあえて深い階層に隠すなどしてUIにメリハリをつけ、80%のユーザーの利便性を損なわないようにする必要があるでしょう。

そしてそれ以前に、あらかじめ品質優先度についての価値観をチーム内でうまく共有し、仕様を決定していく各段階でスムーズに合意形成ができるような、UX活動に最適化された組織作りが重要になってくるのです。