- ほとんどのユーザーは、アプリケーション機能のうち自分に必要な約20％だけを使っており、その20％はユーザーごとに異なる
- 残りの80％の機能は邪魔な要素と見なされることもあり、むしろ不便さや不満を引き起こす
- ニッチ市場を正確に狙えば、強力なユーザー基盤を構築できる
- 大企業が見過ごした20％をうまく解決して高い忠誠度の市場を作った Kagi、Figma、Notion のような事例は、新たな市場機会を示している
- VS Code、Slack、Discord は、拡張性とパーソナライズを通じて、ユーザー自身が自分だけの20％を最適化できるよう支援している
- 核心は、万人向けの製品ではなく、各自が望む部分を深く満たすツールを作ることであり、これが機能肥大化の問題を避ける道である
幼少期の体験とソフトウェアの使われ方
- 筆者は子どもの頃、2GB の保存容量を管理するために不要なファイルを消しては、よくコンピュータを壊していた
.ini ファイルのような重要なシステムファイルを消してしまった後は、Windows と Office 97 を最初から入れ直さなければならなかった
- 父は Excel のインストールを必ず忘れないようにと言っていたが、筆者にとって Excel はWord に表を貼り付けるための道具にすぎなかった
- Excel の数多くの機能の中で、自分に意味があったのは表のコピー／貼り付けだけだった
- 知人も Excel を家計簿としてしか使ったことがなく、ほかの機能には手を出さなかった
みんな違う20％
- ソフトウェアの利用には「80/20 の法則」がある。ほとんどのユーザーは**全機能の20％**しか使わない
- ただし、各ユーザーが重視する20％はそれぞれ異なり、自分が使う部分こそ最も重要だと考える
- 例: Word では表作成は使うが差し込み印刷は使わない、Excel ではピボットテーブルは使うがスクリプトは使わない、PowerPoint ではアニメーションは使わない
- 新機能の追加や UI 変更を伴うアップデートによって、アプリケーションが遅くなったり不要な機能が増えたりしたと感じて不満が生まれる
- 使わない80％の機能が、かえって20％のワークフローを妨げる要素とまで見なされることがある
完璧な結果への渇望
- こうした現象は Microsoft に限らず、ほかの IT 企業でも同じように見られる
- たとえば Google Search で正確なキーワード検索をしたいとき、不要な関連語の検索結果がかえって不満につながる
- 企業側から見れば「ユーザーの1％の要望」と片付けられるかもしれないが、10億人の1％は1000万人という巨大な市場である
- Kagi は、Google が見過ごしている小さな市場に特化し、プライバシーを守り、広告のない品質重視の検索という差別化で市場を攻略した
- 巨大企業の隙間を突けば、小さなユーザー集団を満足させるニッチ市場を形成できる
- 全員を満足させる必要はなく、特定集団の20％の体験を完璧に満たす戦略を立てることは可能である
忘れられた20％を見つける
- 多くの革新的な企業は、大企業が取りこぼしている特定のユーザー層を集中的に狙っている
- Figma はコラボレーティブデザインの領域で Adobe を上回ることに注力し、Notion も特定ユーザーの要求に最適化されたハイブリッドツールとして地位を築いた
- 成功したソフトウェアは時間とともに機能が増えるが、その過程で特定ユーザーの20％が埋もれてしまうニッチが生まれる
- オープンソースソフトウェアは、特定のワークフローに特化したカスタムビルドを作れるため、この分野で強みを発揮する
- 例として、Blender では建築ビジュアライゼーション専用の軽量版を開発することもできる
正しい20％のための設計
- この哲学は VS Code でうまく実装されている
- 基本機能はシンプルなテキスト編集に集中しているが、拡張機能によって各自が望む開発環境を構築できる
- すべてのユーザーが自分だけの20％をカスタマイズできる構造になっている
- Slack の Integration、Discord のボットも同じ原理で、ユーザーが自ら体験をカスタマイズできるよう支援している
- そもそも、すべてのユーザーの20％を予測するのは難しいが、拡張性とカスタマイズ性を提供すれば、それぞれにとって最適な活用が可能になる
結論: すべてのユーザーのための製品より、それぞれの「必要な20％」に集中する
- すべての機能をうまくやろうとすると、結局は重くなり、不満が増えるソフトウェアに行き着く
- それぞれの機能が、その機能を求める特定のユーザーに完璧に機能することに集中するのが重要だ
- ユーザーはどうせ全機能の一部しか使わないのだから、特定の機能を本当に卓越したものにすることに集中するほうが、むしろ効果的である
- ソフトウェアが予想しなかった形で使われる可能性を認め、その多様性を受け入れる文脈で企画する必要がある
- すべてをユーザーに押し付けるのではなく、本当に愛される部分だけに集中して開発することが、より大きな満足につながる
2件のコメント
何でもかんでもパレートの法則に当てはめるんですね;; 15%かもしれないじゃないですか？（笑）
Hacker Newsのコメント
以前働いていたあるSaaS企業で、ユーザーが実際に使っている機能の一部だけを基準に分析を試みたことがある。いくつかの主要なユーザー類型に合わせて製品の複雑さを減らし、厄介な機能も取り除こうとした。結果として、ログイン画面を除けば、各人が重要だと考える20%はまったく一致していなかった。分析結果は重み付きランダム抽出と大差なかった
本当にその通りだと思う。だけどエンタープライズ顧客に製品を売り始めると、状況は完全に変わる。"衛生要件的な機能"が1つ欠けているだけで商談が流れることがある。しかも、その必須機能はエンタープライズごとに異なる。ここでいう衛生要件とは、トイレのように誰にでも必要な最低限の必須要素のたとえ
Spolskyのブログ記事を思い出させる、よく似た話だ
strategy-letter-iv-bloatware-and-the-8020-myth
simplicity
個人的な趣味アプリを自分で作ってみたことがあり、ときどき磨いて公開したいと思うことがある。でも自分のアプリを宣伝したり広めたりする気がまったくないので、公開そのものに意味がないと感じている。実際にはもっと大きな理由として、自分自身が使わない残り80%の機能を実装する気がないからでもある
マーケティングにはModified Paretoという考え方がある。80/20ではなく60/20だ。20%のヘビーユーザーが製品価値の60%を消費し、80%のライトユーザーは40%を消費する。無視できるほど小さい比率ではないので、ライトユーザーにも必ず目を向けるべきだ
value-paretos-bottom-80
という具合だ。実際には、ユーザーがそのソフトウェアは自分の問題を解決できると「認識」することのほうがずっと重要だ。もしお金を払ってもらいたいなら、そのソフトウェアが潜在的にユーザーのさまざまな問題も解決できると感じさせる必要がある。そうした多様な問題には、ユーザー自身が使わない機能が関わることもある。たとえば3Dソフトウェアのリギングシステムは、2%のユーザーが1%の時間しか使わないとしても、その機能がなければそもそも製品を検討すらしない人がいるかもしれない
自分は自分の成果物が実際にどう使われるかを予測するのが苦手なので、よく "Desire paths" にたとえられる、現れた経路に道を舗装するやり方だけを好む
the-road-most-traveled-by-paving
「機能の増殖を防ごうとするより、ソフトウェアが想像もしなかった形で使われうることを受け入れるべきだ」という点に共感する。だから私は、相互運用性（interoperability）こそソフトウェアで最も重要な要素だと考えている。本文の主要な問題は、ソフトウェアごと、バージョンごとのファイル形式の閉鎖性にあるように思える。私は複数のツールを組み合わせて使うこと自体は苦にしないが、ツール同士がパイプラインの中でうまく連携できないのが問題だ。Unixの夢は本当に難しいと思う
ある程度の規模があるアプリで、すべての機能が100%活用されることはほとんどない。私の経験では、ほぼすべてのアプリケーションに10〜30%ほど、完全には活用されていない部分がある。たいていは開発チーム以外には理解しにくい形になっているか、ワークフローがひどく非効率的か、あるいはあまりに基本的な機能すぎて、それを本当に必要とする会社にはそのソフトウェアを買うだけの資金力がそもそもないかのどれかだ
その通り。ただ、多くのユーザーがそれぞれ異なる20%の機能を重要視しているので、現在のユーザー数を維持するにはすべての機能を残しておく必要がある。それでも、保守や開発に多くの時間を食うわりにほとんど使われていない機能を削れば、ROIは向上する
でも、ユーザーが必ず同じ20%を重要だと考えているわけではない。もう1つ考えるべきことは、ユーザーは実際にアプリを使ってみる前には、どんな機能があるのかをあまり知らないという点だ。インストールの決定は、アプリに実際に入っている機能ではなく、インストール前に自分で期待している機能に基づいて行われる。これは重要な違いだ。機能に労力を注いでも、その成果を得られるのは実際にはユーザーを獲得した後になる。
MVP（Minimum Viable Product）を作るときには特に重要だが、ほとんどの場合、インストールや継続利用を妨げているのは機能不足ではない。たいていはメッセージの伝え方、マーケティング、あるいはそもそもユーザーを引きつける価値がないことだ。機能をやみくもに追加しても、こうした問題は解決しない。単純に見えて、多くの会社が見落としている点だ。
最も単純なMVPは、まず何も実装せずに人々に事前登録してもらうことだ。こうすれば、メッセージが正しく伝わっているかを検証できる。登録後に失望されたとしても、少なくともメッセージはきちんと届いていたことになる。
ただしその場合、MVPが約束したほどには完成していない状態で公開することになり、未完成の約束によって失望を生むリスクがある。また、多くの機能は実際にはなくても困らないことが多く、特にSaaSでは、実際にお金を払うほど必須ではない機能が多い。顧客の要求をそのまま必須要件として受け取るのではなく、彼らが本当に「価値がある」と感じているのか、実際に対価を払う意思があるのか、本当に重要な痛みを解決するのかを必ず明確に把握する必要がある。顧客の要求がなぜ出てきたのかを理解することは、その機能をすぐ作ることよりはるかに重要だ