様々なサービスやプロダクトを開発してきた実体験をまとめるシリーズです。
後から考えればそうだったな。どうしてあの時は気づかなかった、もしくは意図せずやってたんだろうな、ということばかりで、また同じ間違いや無作為な開発をしないようにしようという自戒を込めています。
これらの自戒は去年、シリコンバレーやベルリン、深圳などに訪れ、異なる文化背景を持つ人たちの開発スタイルや物の考え方に触れたりすることである程度のまとまりを得ました。
たくさんあるので、時間を見つけては少しずつ書いていこうと思います。
今回のテーマは、サービスやプロダクトが持つ20%と80%の役割分担（チームワーク）の話です。
※この割合はサービス毎に違うかもしれません。
これはサービスが内包する機能の割合です
よく最近、プロダクト・マネジメントを行う前段の準備として必要なことを解説するのにこんな表を使います。
プロダクトの各種機能には役割があって、それをどういう切り口で分割しようか、という話です。
あるBtoBtoCサービスではこんな感じになりました。
この表自体はプロダクトの機能を役割分離したものですが、この整理はサービスの機能を見渡して整理する時にも使うことができます。
これによって見えるのは、どの機能同士が近くにあって、どの機能は一緒にすべきでない、などの機能同士の相性です。
たとえば、表中の 「効率的な案件設定」 のようなデータを効率的に更新（update）することができる機能がDashboardに内包されていたとします。
そこで、 Dashboardに顧客は何をしに訪れているのか （出来上がる前のプロダクトや、リニューアルが目的であれば Dashboardは何をすべき機能なのか ）を観察・考察します。
一方で、 データを効率的に更新するということはどういうことか を考えます。
ある例ではこのような結論に至ります。
- Dashboard ：取り扱っているデータの全体観を把握する機能
- そこでデータを見ていると「自分が次に何をすべきなのかがわかる」こと。
- できるだけ高い集中力を必要とせずに気づき気付きを得られること。（だからデータをビジュアライズする）
- データを効率的に更新することができる機能 ：できるだけ短時間で多くのデータに正確な影響を与えることができる機能
- 影響範囲が広いため、高い集中力の下で作業する必要がある
- 間違いに気付きやすく、必要十分なデータ量を一括でに処理できる
- （今回は本筋外ですが、本当はこういう機能を人間が使うような設計にしてはいけない）
結論として、この２つの機能は要求前提（使う際の心持ち）が違いすぎて、お似合いではないと言えます。
すなわち、異なった要求前提を持つ役割同士は近い場所（画面）に存在するべきではありません。
こうした機能と要求前提（顧客はそこに何をしに訪れているのか）に対する観察は、より人間に寄り添った機能設計をするためのヒントを掘り起こしてくれます。
機能を便益（ベネフィット）につなげるために、顧客の心持ちはとても重要です。
心持ちとその時に使っている機能がチグハグな場合、顧客のベネフィットには繋がらないのです。
機能の20%がしっかり利用者の便益に直結していれば、80%のサービス価値のはそこで表出できる
どのようなベネフィットを提供しているか はいわばサービスやプロダクトのOffensiveな特徴で、顧客をサービスの世界観に引き込む強力な武器です。
そして多くのサービスの機能の中で、 本当に顧客にベネフィットを提供すべき機能はおおよそ20%程度 です。
ECサービスを例にとって見てみます。
ECサービスには非常に多くの機能がありますが、顧客にベネフィットを提供すべきなのは「物を買って、家に届くまで」の流れのみです。
- 考察し
- 探し当て
- 決済し
- 届く
この４つの体験を、どんなテーマで設計し、どのくらいの精度や喜びをもって顧客に体現してもらうか、ということに尽きます。
それは、ECサービスがお金を払って欲しい物を手に入れる場所だからです。
言い換えると
- 欲しいものが何かを知るために：より十分に考察でき
- 見つけたものを探すために：より早くターゲットを探し当て
- 自分のものになるという手続き：よりスムーズに決済を完了し
- 実感を持って完了する：いち早く届く
ということに（少なくとも2017年は）なります。
しかしながら、ECサービスにはもっと多くの機能があります。
- TOPページ
- 規約の開示
- 初めての方へ
- ガイドライン
- Q&A
- 決済が失敗した時のケア
- 物が届かなかった時のケア
- お問い合わせ機能
- Chat
- 〇〇とは
- Etc…
※ここでは、ECサービスのなかで、エンドユーザー向けのみを対象に捉えています。それがなぜなのかは別なポストで解説しますが、エンドユーザー向けのサービスとサイト管理者向けのサービスは別なサービスとして捉えるべきだからです。
こうしたエキストラな機能の全てはECサービスの中で、考察し、探し当て、決済し、届く、という一連の機能が不十分なため必要になっています。
言い換えれば、４つのエレメンタリーな機能群をしっかり魅力的に磨き、パッケージングすることで、こうした付帯的な機能群は劇的にその比重を減らすことができます。
その結果、迷うことなくストレートに享受されたい価値を得られる顧客がどんどん増えるわけです。
それが便益のチューニングです。サービスが提供する便益のほとんど全ては、このためにあります。
このチューニングはできるだけ高い精度で体験をコントロールしながら実現しなくてはなりません。
だから、20%という数字は決して小さくなく、このくらいの機能群の規模にしておかないと限られた人数のエンジニアリング・デザインチームはそれを磨ききれなくなります。
僕のチームでは、こうして極限までベネフィットを担当する機能群を絞り込んで行って、それでも磨ききれなかった時にエンジニアリング・デジアンチームのヘッドカウントが足りないと判断します。
それができていないチームはどんどん人ばかりが増えていき、その分開発効率が悪くなります。
ここを間違うと、結構厳しい状況を簡単に生み出してしまいますので、本当に注意が必要です。
では残りの機能80%は何のためにあるのか？
ここで間違ってはいけないのが、残りの80%の機能は不要なのかというと、そんなことはないという点です。
ただ、役割が担うミッションが大別できます。
20%の機能群が持つべきミッションは「顧客にベネフィットを提供すること」でした。
では80%の機能が持つ役割は、どんなミッションを追っているでしょう？
- TOPページ
- 規約の開示
- 初めての方へ
- ガイドライン
- Q&A
- 決済が失敗した時のケア
- 物が届かなかった時のケア
- お問い合わせ機能
- Chat
- 〇〇とは
- Etc…
改めて先ほどのページ群を並べてみました。
これらの機能に共通していることは「そこに訪れる顧客は何かしら困ってる、もしくは行き詰っている」ということです。
なぜTOPページがそこに含まれているのかと感じる人もいるかと思いますが、ECサービスのTOPページは「サイトに訪れた目的が特になくて、受動的に行き詰っている人が訪れる場所」だからです。簡単にいうと、暇つぶしにきてるのです。その心境は、顧客に目的がないという点で、困っている状態によく似ています。
そして、この状況に陥っている顧客は決してベネフィットを享受することができません。
本来的なベネフィットを享受できる場所へ戻してあげる（リカバリする）必要があるのです。
これこそが、80%の機能群が持つミッションです。
このミッションを達成するために最も重要なのは、体験や、ましては得られもしない便益に向けたチューニングなどではありません。
プロダクトが持つ20%のベネフィットラインで享受できる価値が強力であればあるほど、顧客はどんなに探しにくい状況でもそのラインに戻るための情報を渇望するでしょう。これは、斜めから見ればサービスの強さそのものを表しています。
だから、情報の探しやすさなどはさほど重要ではなく、むしろなんとかベネフィットラインへ戻ろうとしている顧客の どんな困りごとにも答えられる情報の網羅性が何よりも重要なのが残りの80%の機能群 なのです。
また、利用されている頻度も非常に重要な着眼です。
これらの機能は「できるだけ使われないように」しなければなりません。
※ただし、利用者の利用単位ごとの継続時間が長いことは、そこに強力なベネフィットや価値を提供できている現れになります。
メルカリなどは非常によい例で、ベネフィットラインから外れない限りは何処よりも強力な価値への最短経路を提供していますが、一度そのラインからはすれたユーザーは仮出品を作って返金を行なったり、「専用」と書かれた謎の出品物を作ったりと、様々な工夫をユーザー自身が凝らしてそのベネフィットラインに戻ろうとしています。
これはUXの先回り戦略ともいうべき設計です。ベネフィットラインの体験を全て先回りしてパッケージ化し、そのラインの利便性にスポットしてチューニングしています。
これは極端な成功例ですが、その結果もはやプラットフォームが用意したリカバリの枠を超えた独自のリカバリ方法が確立してしまっているくらいに、ベネフィットに魅力があるのです。
では私たちはどんなことを考えながら日常の開発を進めれば良いのか
これらの整理は運用途中のサービスが途中で始めても、十分に意味があります。
次にこんな機能をつけよう、といったアイデアが出た際に、どこにつけるべきかが明確になるからです。
これはいわば、サービスやプロダクト内の機能毎のチームワークを設計している、という事です。
機能はそれそのものの有用性も重要ですが、それがどこに存在していて、どう行った心持ちで使われているのかは、もっと重要なんです。