ハクソク

世界を動かす技術を、日本語で。

ユーザーが気にするのはアプリケーションの20%だけ

240日前原文(idiallo.com)

概要

  • 子供時代のパソコン体験から学んだ Excel の意外な使い方
  • ソフトウェア利用は 80/20の法則 が当てはまる
  • 多機能化による ユーザーの不満 と機会
  • 新興企業やオープンソースが 特定ユーザー層 に特化する戦略
  • 拡張性とカスタマイズ性 が現代ソフトウェアの鍵

子供時代のExcel体験と学び

  • 家庭用パソコンの 容量不足問題 との日常的な格闘
  • .iniファイル 削除によるシステム障害と再インストール経験
  • 父親からの「 MS Excelを必ずインストール」という指示
  • Excelの用途不明で 難解なインターフェース に戸惑い
  • Wordで表を作成したくても方法が分からず、 Excelで表作成→Wordに貼り付け という裏技を習得
  • 当時の自分にとっての Excelの唯一の価値 は「表をWordに貼り付けること」
  • Excelの多機能性を知る人もいれば、 家計簿管理 など異なる用途で使う人も存在

ソフトウェア利用の80/20ルール

  • 80/20の法則 ：大半のユーザーは機能の20％しか使わない
  • しかし、 使う20％は人それぞれ異なる
    • 例：作家はWordで下書きのみ、アナリストはExcelでピボットテーブルのみ、PowerPointユーザーはアニメーション機能を使わない
  • 各ユーザーが自分の 重要な20％ を最も大切だと感じている
  • 新機能追加やアップデートで 自分の20％が損なわれることへの不満
    • アプリが重くなる
    • 必要ない機能が増える
    • メモリ消費増加
  • 他の80％を使わないだけでなく、 邪魔だと感じることも多い

マイノリティのニーズと新たな市場

  • Google検索 でも同様の問題
    • 厳密なキーワード検索が困難
    • 大多数には満足されているが、 少数派の不満 は無視されがち
  • 「1％のユーザー」の声は無視されがちだが、 巨大なユーザー数の中では大きな市場
  • Kagiのような新興企業は 大手が無視する20％ に特化して成功
    • Googleが拾いきれない パワーユーザーや専門家 向け市場
    • 「全員に勝つ必要はなく、自分たちの20％に完璧に応える」戦略

特定分野に特化する企業とOSSの強み

  • Figma ：Adobe全体を置き換える必要はなく、 コラボデザイン に特化して成功
  • Notion ：最強のワープロやデータベースを目指すのではなく、 ハイブリッドツール として独自路線
  • 成功したソフトウェアは 機能追加と複雑化 で隙間を生み出し、 特定20％が埋もれる
  • オープンソースは 特定用途向けの最適化 が容易
    • 例：Blenderを 建築ビジュアライゼーション専用 にカスタマイズ

拡張性とカスタマイズ性の重要性

  • VS Code ：基本はシンプルなエディタ、 拡張機能で各自の20％を実現
  • Slack や Discord も同様に 統合やボット でユーザー独自の環境構築
  • どのユーザーがどの20％を必要とするかは予測困難
  • 全員に合わせた万能ソフトは肥大化し、結局多くのユーザーを不満にさせる
  • 各ユーザーが自分用に 最適な20％を見つけて拡張できる仕組み が理想
  • すべての機能を全員に使わせる必要はなく、 必要な人に最高の体験を提供することが重要
  • 機能の無駄を恐れず、ユーザーが自分の使い方を見つけられる自由さ が現代ソフトウェアの価値

まとめ：愛される20％を作るために

  • すべてのユーザーが ソフトウェアの一部しか気にしない という現実を受け入れる
  • 全機能を理解・利用させようとせず、 ユーザーが本当に必要とする部分 に集中
  • どの部分が愛されるか分からなくても、 ユーザー自身が自分の20％を見つけて愛せる環境作り が大切

Hackerたちの意見

機能の肥大化と戦う代わりに、あなたのソフトウェアが想像もしなかった使われ方をされることを受け入れるのもアリだよね。だから、相互運用性が一番大事な機能なんだと思う。この記事を読むと、主な問題はソフトウェアやバージョン特有のファイルフォーマットにあるって感じる。三つのツールを組み合わせるのは全然気にしないけど、そのツールたちがパイプラインの一部として使われるのを嫌がってるみたい。Unixの夢って、なかなか難しいよね。

自分の仕事がどう使われるかを予測するのが苦手だから、「裸の部分を舗装する」ことが多いんだよね。[0] https://littlegreenviper.com/the-road-most-traveled-by/#pavi...

└

デザイアパスは、ITポリシーやガバナンスを書くときにもおすすめだよ。でも、複雑な環境ではスケールしにくいし、長期的にはコストがかかることもあるから注意が必要だね。

└

これはただのテレメトリーだけど、リアルでオプトアウトの方法はないよね。最初じゃなければ、誰かの足跡を辿ることもできるかも。

ちょっと古いSpolskyのブログ記事に似た内容だね。: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... https://www.joelonsoftware.com/2006/12/09/simplicity/

└

これは二つ目（シンプルさ）にすごく似てるね。公平に言うと、著者はこれらの以前の投稿に気づいてなかったかもしれないけど。「最近の子供たち」はクラシックをあまり読まない気がする。知らない人のために言うと、Joel Spolsky、Steve McConnell、Don Norman、他にもたくさんの人たちが、私たちの職業について真剣に考えて、その思いを文章にしているんだ。ちょっと見てみる価値はあるかもね。

└

Joel Spolskyの作品がこんなに時代を超えても色あせないのはすごいよね。中には間違ってたものもあったけど（例えば、彼はグラフィックカードの製造が薄利多売になるって予測してた[0]）、ほとんどは今でも真実だと思う。書かれた当時よりも、今の方がもっと真実かも。[0]: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v 彼を擁護すると、'ビデオチップ'が今の強力な5080とは全然違うものだった頃には、もうすでに違ってたんだよね。

マーケティングには「修正パレート」という相関関係があって、簡単に言うと80/20じゃなくて60/20なんだ。つまり、20%のヘビーユーザーが60%の製品を消費するけど、80%の人たちは実際には40%を消費するってこと。それは無視できるほど小さくないから、ライトユーザーや不定期ユーザーにも対応しなきゃいけないんだ。: https://marketingscience.info/value-paretos-bottom-80/

└

こういう原則を真実として捉えるのではなく、反復的なフィードバックループの一部として見るのはいつも面白い。1. 観察: 80%のユーザーはソフトウェアの40%にしか触れない。2. 結論: その60%の一部をカットしよう、ほとんど使われていない機能だから。3. 観察: 80%のユーザーは残りのソフトウェアの40%にしか触れない。4. 結論: さらにカットしよう…みたいな感じ。実際には、最も重要なのはユーザーがあなたのソフトウェアが自分の問題を解決できると認識することなんだ。お金を使わせたいなら、少し形を変えたら問題を解決できるかもって感じさせる必要がある。そういう異なる問題は、使われていない機能でカバーされているかもしれない。例えば、3Dソフトウェアを見てみると、骨のリギングシステムは2%のユーザーが1%の時間しか使わないかもしれないけど、その機能がないと他のソフトウェアと比べて、必要がなくてもあなたのソフトウェアを考慮しないユーザーがかなりいるんだよね。

Kagiは全員に対してGoogleに勝つ必要はなかった。特定のユーザー層に完璧にサービスを提供するだけでよかった。彼らは、Googleが無視している人たちのための理想的な20%になることに焦点を当てた。これ、実はプロダクト・マーケット・フィットを見つけるための重要な洞察なんだよね。

└

Kagiは、Google検索ユーザーの90%以上にとってはいい代替品だと思う。ニッチな理由は、有料製品で無料のものと競っているからだけだね。

ほんとその通り。でも、エンタープライズに売り始めると、全てが変わるんだ。欠けている「ハイジーン機能」*があると、全ての契約がダメになることもあるし、エンタープライズごとにそれが違う。*トイレみたいなもので、絶対必要なんだ。1日3分使うけど、なかったら家に住めない。

└

俺たちは同じ製品を二度売ったことがないと思う。プロダクトロードマップは「最後に話した人が求めたもの」って感じ。技術的負債は、顧客がほとんど使わない「必須機能」の5,000個のほぼ生産レベルのグラブバッグを維持することになってるけど、彼らはそれがないと契約が成立しないって言ってるんだよね。まあ、負債って感じ。

子供の頃、よく家のコンピュータを壊してた。2GBのストレージしかなかったから、スペースを空けるためにファイルを削除するのに必死だった。似たような経験をしている人は多いけど、こういう発言が大体の年齢や扱っていたシステムを示すのが面白い…俺のは40MBだ。

└

これは2005年以前の野生で毛むくじゃらな時代の人たちに当てはまると思う（たぶん）。でも今の状況を考えると、もう頭打ちになってる。少なくとも2005年以降、大半の人はノートパソコンを持っていて、一般的には250GB、500GB、1TBのストレージが多い（世代差よりも高級な構成の方が大きな違いがある）。今はスマホやタブレットで64GB、128GB、256GBに親しんでいる人が多いだろう。もうすぐ、マスマーケットの計算時代に突入するだろうね。「成熟した」時代が初期の頃より長くなる（1980年 - 2005年 = 25年、2005年 - 現在 = 20年超）。ストレージに関しては、大きな飛躍はあまり起こらない（50MBから1GBは大きな変化だけど、500GBから1TBはまあまあ）。

セインフェルドのエピソードを思い出す。ジェリーが父親に「ウィザード」っていう高価な多機能PDAを渡すんだけど、父親はすぐにはその使い道がわからない。ジェリーは、レストランでのチップを計算するための電卓があるとか、色々できるって説明するんだけど、父親は「200ドルのチップ計算機だ」と結論づける。ジェリーは「他にも色々できるんだ！」って抗議するけど、年寄りたちはまるで彼の声が聞こえないみたいに振る舞うんだよね。

でも、みんなが同じ20%にこだわっているわけじゃないんだよね。もう一つ考慮すべきことは、ユーザーはアプリを使ってみるまで、どんな機能があるか分からないってこと。ユーザーはアプリの中身じゃなくて、インストールした後に入っていると思う機能を基にアプリをインストールするんだ。これは重要な違いだよ。君が機能に一生懸命取り組んでいるその努力は、実際に人々にアプリを使わせるまで報われないんだ。特にMVPを作ろうとしているときは、機能が不足していることがユーザーがアプリをインストールしない理由になることはほとんどない。実際の問題は、メッセージやマーケティングなどにあることが多い。あるいは、アプリがユーザーの興味を引くようなことを何もしていないかもしれない。どんな理由であれ、君の機能セットはそれに関係ない可能性が高いよ。機能を増やしても、これらの問題は解決しないんだ。簡単に聞こえるけど、これを間違える会社を見てきたよ。最もシンプルなMVPは、何も実装する前にユーザーにサインアップしてもらうことなんだ。アイデアを検証するための一般的なパターンだね。メッセージが正しいことを確認する最良の方法は、ユーザーがサインアップした後に失望することなんだ。これはまだ悪いことだけど、少なくともメッセージが正しいことが分かるし、君が売っているものが価値があると人々を納得させることができるんだ。もちろん、これは別の問題にもつながる。君のメッセージが約束するものが実際にある前にアプリをローンチすることだ。実際には存在しない多くのことを約束すると、少なからず人々を失望させることになるかもしれない。関連するポイントとして、多くの機能はあってもいいけど、収益化が難しいものが多い。特にSaaSアプリケーションでは、実際には人々が支払いたくないような「あるといいな」機能がたくさんあるんだ。顧客の希望を要件として扱うには、かなりの注意が必要だよ。彼らは本当に得られるものを評価しているのか？それにお金を払うつもりがあるのか？重要な痛みのポイントを解決しているのか？などなど。彼らが何を求めているのかを正確に理解することが、求められているものをそのまま提供するよりも大事なんだ。

└

でも、みんなが同じ20%にこだわっているわけじゃないんだよね。それがこの記事の主なポイントだよ。

└

でも、みんなが同じ20%にこだわっているわけじゃないんだよね。あんた、そのコメント全部を見出しだけで書いたの？

僕が働いていたあるSaaSでは、ユーザーが実際に使っている機能のサブセットに基づいて分析するという無謀な取り組みに1、2日を費やしたことがあるんだ（製品の複雑さを少しでも減らして、デザインできるコアなアーキタイプに絞り込むことを期待して、面倒な機能を排除することを目指してね）。結果は、重み付けされたランダムな選択と大差なかったよ。ログインページを超えて（それでもカスタマイズオプションがいくつかあったけど）、実際に関心を持っている20%は、誰一人として同じではなかったんだ。