不要な要素を取り除くことの重要性
(gkogan.co)- 複雑化した製品は、説明を増やすよりも 不要な要素を取り除くこと で改善できる場合があり、Pineconeの料金計算機の事例がそれを示している
- 料金計算機は使用量ベースのコストを事前に見積もるための仕組みだったが、小さな入力ミスだけで想定費用が最大 1,000倍 まで膨らみ、登録を妨げていた
- 社内では説明やデフォルト値を追加して問題を直そうとしたが、その修正が別の混乱を生み、専用のSlackチャンネルには 550件以上 のメッセージが積み上がった
- 計算機を取り除いた A/Bテスト では、非表示の訪問者は登録する可能性が16%、問い合わせる可能性が90%高く、料金関連のサポートチケット増加もなかった
- いったん追加された要素は価値が下がっても残りやすいため、製品・プロジェクト・プロセスにおいて大きな塊を取り除く判断を意識的に見直す必要がある
Pinecone料金計算機の削除事例
- Pineconeは使用量ベースの料金体系では、ユーザーが実際のコストを事前に正確に把握しにくいため、料金ページに コスト計算機 を配置していた
- 見込みユーザーに会って確認したところ、一部のユーザーは計算機で非常に高い想定費用を見て登録をあきらめていた
- そのユースケースはPineconeの基準では比較的小さいものだった
- 計算機は想定以上にわかりにくく、敏感だった
- 小さな誤解や入力ミスだけでも、想定費用が最大 1,000倍 誇張されることがあった
- 計算機はユーザーに誤った確信を与え、ユーザーはドキュメント確認、チームへの問い合わせ、実際の利用による検証なしに、計算機の値を実際のコストのように受け取っていた
- 素早い対応として説明、免責文、詳細情報、デフォルト値を追加したが、ひとつの混乱を減らそうとする試みが別の混乱を生んだ
- 社内の議論も大きくなり、専用のSlackチャンネルには 550件以上 のメッセージが積み上がり、会議や文書作成にも多くの時間がかかった
- ある人が「計算機は本当に必要なのか？」と尋ねたが、当初は多数意見の中に埋もれてしまった
- その後、計算機とそれによる問題をなくしても価値が失われないかを確認するために A/Bテスト を実施した
- 計算機を見なかった訪問者は、計算機を見た訪問者よりも登録する可能性が 16% 高かった
- 問い合わせる可能性は 90% 高かった
- 料金関連のサポートチケット増加はなかった
- 社内アンケートでは、会社の構成員10人中7人が計算機のあるバージョンのほうがよいと予想していたが、テスト結果は逆だった
取り除くのが難しい理由
- 多くの組織は問題を解決するとき、引き算 よりも足し算を先に思い浮かべる
- 削除で大きな利益を得られるとしても、直感的な選択肢になりにくい
- 関連研究として People systematically overlook subtractive changes が引用されている
- 報酬体系も通常は何かを追加する方向に合わせられており、削除にはインセンティブが少ないことが多い
- 削除にも報酬があるべきだという例として Negative 2000 Lines Of Code もあわせて示している
- ある要素を追加しようと強く主張した人は、それが価値を加えていないという事実を認めにくい
- 他の人が追加を主張した要素を削除しようとすると、その人の判断や作業を攻撃しているように見えるため、そのままにされやすい
- すでに存在するものは、そうであるだけの十分な理由があると想定され、見直されないことが多い
- 現在の状態に慣れてしまうと、削除を十分に考える前に変化そのものを避けがちになる
- 非本質的な要素を大胆に切り落とす単純化は、顧客応答率の改善、より信頼できるシステム、より速い成長と売上につながる可能性がある
- 小さな削減よりも、プロジェクト・製品・プロセスの大きな塊を取り除く選択が必要であり、チームの強い反発がある削除ほど大きな利益が隠れているかもしれない
1件のコメント
Hacker News の意見
この計算ツールが良かったのか悪かったのかは分からないが、根拠は一見かなり筋が通っていない
ユーザーに製品コストが大きくなり得るという事実を隠せば、登録が増えるのは当然だ。実際に改善したかどうかは、後で不満の残る請求書を受け取るかにかかっており、それは登録ページでの短い A/B テストでは分からない
検索結果のスニペットから情報を削除したらクリック率が上がった、という類の事例もよく見る。もともとスニペットにあった情報を見るには今はクリックしなければならないのだから、クリックが増えるのは当然だが、実際にどちらがより良いのかは忘れられてしまう
ジレンマは「そうしたケースをどう直すか」であり、解決策は「ひどい計算ツールをなくそう」だった。1000倍のコストを隠したのではなく、誤った1000倍の見積もりのせいでユーザーを失うことを避けたのだ
自動車ディーラーがオンラインで価格確認しにくくし、メールや来店へ誘導するのがその例だ。計算ツールは比較購入を容易にするが、多くの企業はそれを好まない。意識的であれ無意識であれ、考慮すべき動機だ
ユーザーに透明であればあるほど混乱するに決まっている。比較基準そのものが、ユーザーを屠殺場へ追い込める愚かな家畜のように扱うものだからだ。この基準では、ユーザーを考える人間として扱う機能は、どんなものでも混乱を生み、コンバージョン率を損なうことになる
当然、価格ページは見苦しくなったが、「登録が増えている」という理由で問題ではなくなった。この場合、計算ツールは用語に慣れていない人には負担だったかもしれないが、「どう単純化するか？」という直感的な判断が先にあるべきだった。すべてを統計的に分析して証明しなければならないという A/B テスト文化は好ましくない
そもそもユーザーが残っていなければ、後で満足しているのか不満なのかをどうテストできるのか。ループを閉じてエンゲージメントを増やせば、その後のやり取りを通じて顧客を適切に教育し、満足させられる可能性も高まる
記事の大きな知恵を広めたくて賛成票を入れたが、境界はすぐ曖昧になり得る
「この部分を取り除くと、価値ある何かが失われるだろうか？」という考え方は、初期プロジェクトでは時に逆効果だった。特にコードとデータは将来価値を見積もるのが難しいからだ
ある新規プロジェクトで、投稿タグ用の追加メタデータカラムを持つ初期 SQL スキーマを作ったことがあるが、翌週にシニアエンジニアが YAGNI 原則を持ち出してすべて削除した。当時のロードマップにはなかったので技術的には正しかったが、元の作業は1時間ほどで、データを維持するコストはほぼゼロだった
1年後、そのカラムを必要とする機能を作ったのは結局自分で、今度はユーザーがいる本番 DB のマイグレーションまで含めて同じことをやり直さなければならなかった。だから逆に「この部分を取り除くと、価値ある何かが生まれるだろうか？」も考えるべきだ。この記事では答えが明確だったが、私の場合はそうではなかった
SpaceX には、似た概念を捉える指標があると記憶している。削除された機能のうち、二度目に再追加された機能の割合だ。削除した機能がすべて再追加されるなら機能再犯率100%で、削りすぎということだし、70%も高く、30%も高い
だが 0% も悪い。不要な機能を十分に削除しようとしなければ、結局肥大化するからだ。製品初期にはこの割合が高めで、成熟するにつれてゼロではない低い割合へ下がっていくのがよさそうに見える
現時点で最善の製品に必要な正確な機能セットは分からないのだから、不要なものを削るために確率的なアプローチを取ってもよい。必要なら再追加すればよく、そういうことがあまり頻繁に起きない限り、最初に削除した判断を疑う理由はない
あるいは現実に両方試して結果を見る代わりに、仮説と言語化されていない事前信念の代理指標をめぐって、6か月間会議だけしてもいい
「使っていいのか？消していいのか？」となり、誰かは古いフィールドを再利用して大事故を起こした Knight Capital を思い出す。だから既存フィールドは残す方が常に安全になり、結局
metadataとmetadata_1ができる。翌年にはなぜメタデータフィールドが2つあるのか誰も分からず、さらに混乱する私が経験した最悪のコードベースは、複雑な将来用途を念頭に設計されたものだった。この例でも、コードベースがカラムを必要としたのは1年後だった。だから将来の必要を予想したコード片はすべて削除するという前例が正しいと思う。たとえ結局また必要になったとしてもだ
ある人にとっては時期尚早な最適化であり、別の人にとっては「以前似たパターンを見たので、その時にあればよかったものを追加する」になる。どちらが正しいのかを安定して見分ける方法はなさそうだ
説明された状況には大きく3つの結果がある。第一に、フィールドが最初に実装した方法そのままで役に立つ。第二に、機能は実装されるが、別のフィールドや別の実装で作られる。第三に、機能が実装されない
3つの選択肢の確率を同じと見ても、最初から作っておいたことが勝利になるのは3分の1だけだ。削除しなかった場合、その間に実装した他の機能がメタデータカラムと正しく動作するか確認するのに、どれほどの認知コストがかかったかも考えるべきだ
今回はあなたの判断が正しく、プロジェクト理解が優れていたということだが、その決定が正しかったかどうかは、事後情報をすべて知った状態ではなく、当時利用できた情報で判断しなければならない
「社内投票では10人中7人が、計算機のあるバージョンのほうが良いだろうと見ていた」という箇所は興味深く、典型的な力学だと思う
全体として良い記事だったが、この点はもっと強調されてもよかった。関係者の30%が計算機を悪いものと見ているなら、多数派が問題ないと言っていても、潜在的に大きな問題の兆候だ
ここでは社内政治に注意すべきだ。人は政治的な得がなければ、普通は他チームを批判したがらない。だから「私たちのチームが作ったこれは正味で効果があるのか？」と会社に尋ねると、余計な波風を立てたくないため、デフォルトの答えは「はい」になりやすい
そんな状況で30%が価値を壊す可能性を示したなら、思った以上に重要だ。なぜそう見たのか、かなり深く検討すべきだ。このケースでは実際にその点を意識しており、良い結末になったが、この投票結果は最初から深刻な問題の証拠だった
利害関係が絡むとさらに複雑になる。営業はあらゆるダークパターンを有効にしたがり、カスタマーサポートはカートに延長保証が自動追加されて返金処理をするのにうんざりしているかもしれない
記事で、計算機を削除すればより多くの販売が完了するのでユーザーにとっても良いかもしれない、と述べていた箇所は笑えた。もしかするとユーザーが適切な価格ショックを受けて去るのが正しい選択だったのかもしれないのに、そこは無視しているわけだ
計算機のコードがプロジェクトの他の部分に比べてめちゃくちゃで、古いライブラリを使っており、更新すると壊れ、セキュリティ脆弱性があり、リソースを異常に大量消費し、ビルドシステムを壊すと想像してみればいい。誰もそれを扱いたがらない
この状況で良いアイデアかと尋ねれば、ほとんどの人は「いいえ」と答え、その厄介なものをなくしたいと思うだろう。そうなると70%は非常に良い数字だ。逆に、人々が作業するのを好む機能なら、70%は本当に悪い数字になる
もちろんそう考えていた可能性はあるが、それはかなり大きな飛躍だ。大差はないと見ていたのかもしれないし、計算機が誤った答えを出すケースがあるため成果が低いと推定していたのかもしれない
一般的なメッセージは興味深いが、この部分では少し引っかかる
「少し誤解したり入力を間違えたりするだけで、見積もりが最大1000倍まで誇張されることがある」というのは、実際の利用でも指標を少し誤解したり誤って評価したりすると、計画より1000倍の費用を払うことになるという意味なのか？
オンライン課金システムでは十分に現実的な話だ。GCPのプロトタイプを誤って設定して、2〜3ドル程度だと思っていたのに、数日気にせず放置したら100ドルを超える請求書が来たことがある
スライダーを少し動かすだけで予想価格が狂ったように増えるのを見れば、顧客が離脱するのも理解できる。ツールを削除すればサインアップには役立つだろうが、後でこうした問題に直面する顧客の助けにはならない
あるユーザーは秒間クエリ数を、検索回数 × 各検索のtop-kで計算するものだと思っていた。top-kは返してほしい結果数だ。top-kが10だとすると、秒間クエリ数に実際より10倍高い値を入れ、実際の請求額より約10倍高い見積もりを見ることになる
別のユーザーはベクトル数を、埋め込み数 × 埋め込み次元数で求めるものだと思っていた。1,536はよくある次元数なので、入力値が文字どおり1,536倍高くなった。実際の使用量はPineconeが正しく計算するため、そのように高く請求されることはない
ベクトル次元数はAIエンジニアには基本概念で、QPSはDB管理者には基本指標だが、PineconeにはAIが初めてだったり、DB管理が初めてだったり、あるいはその両方だったりするユーザーが多い
筆者は自分の助言を自ら実践すべきだ。記事の途中に割り込んでくる「Psst... Get the next post in your inbox」をなくし、スクロール時について回るばかげたボタンも削除すべきだ
そのページだけで購読できる方法を五つも数えた。本当に五つ必要なのか？コンテンツのど真ん中で顔の前に突きつける必要があるのか？人の邪魔をしてイライラさせれば購読者が増えると思っているのか？そういう購読者が欲しいのか？
何かを削除することは、たいてい明確だ。「もっともっと、金を稼ぐ、顧客を引き込む」という落とし穴のような思考から抜け出し、「ユーザーを尊重するには何が正しく、財布を搾り取る対象ではなく人間として扱いながらどう助けられるか」を考えればいい
ほとんどのビジネスはHN読者に快適さを提供するためではなく、金を稼ぐために存在することを忘れてはいけない
ユーザーを尊重するとは何かは別の、しかし完全に無関係ではない問いだ
専用Slackチャンネルができ、社内各所からの意見を含む550件超のメッセージが積み上がり、計算機を直すために何を追加すべきかについて会議に何十時間も、何千語も費やしたというのは、過剰採用の症状だ
人が多すぎると主導権が失われる。本当に重要なものを忘れ、委員会式の合意を得なければならないと感じるなら、人が多すぎるのだ
委員会式デザインも、委員会の中に限られる
顧客が有用にモデル化できないほど複雑な価格体系そのものを削除するほうが良いのではないか？
つまりAオプションがxドルでBオプションが10xドルのとき、ほとんどのユーザーが誤ってBが必要だと思うなら、計算機は誤解を招くツールになる
私は「価格はお問い合わせ」方式がかなり好きだ。大まかな価格帯をすぐ知りたいユーザーには腹立たしいが、標準価格やオンラインでは簡単に説明しにくい価格が交渉可能なケースを見分ける助けになる。ユーザーがそのまま通り過ぎていた状況も拾える。もちろん、ほとんどのECのような場合には向いていない
当社には製品が250個ほどあり、そのうち5つが売上の80%を担っている。
その5つの製品の開発チームはバグ修正に追いつくのがやっとで、重要な新機能を追加するのに苦労している。誰が頼もうと、ロードマップに何かを入れること自体が不可能な戦いになっている。
会社には開発者が数千人いるが、その大半は売上にほとんど貢献していない製品に張り付いている。
前に進むには、大半の製品を切り、残った主要な売上製品を推進するようチームを再編するのが正しいのは明らかに思える。ところがそういうことは起きておらず、起きる兆しも噂もない。社内政治は本当に厳しい。
似たような経験がある。かなり似通って見える複数の製品があるWebサイトで、人々が何を買うべきか決めづらく、そのせいで購入しないのではないかと懸念していた。
そこで、ユーザーがいくつかの質問に答えると最適な製品を1つか2つ推薦する製品推薦アプレットを作った。きちんと作るまでにはそれなりに手間がかかったが、完成後はうまく動いた。
サイトに載せたところ、コンバージョン率が急落した。A/Bテストをしてみると、明らかにコンバージョン率を損なっていた。なぜ損なったのかはまだ分からないが、実際にそうだった。そこでホームページからFAQセクションに移したところ、ほとんど誰も使わなくなった。
人々は優柔不断で、自分であれこれ試して見極める手間を省いてあげたのかもしれない。
サービスなら、確信がないのでとりあえず登録してみて、その後はサンクコストの誤謬を利用するAmazon Prime式の戦略が効いた可能性もある。あるいは、アプレットがなければ一番安い版で十分だろうと期待して登録したはずが、アプレットがその希望をすぐに打ち砕いたのかもしれない。
物理的な製品だったなら、悪い買い物を避けるのを助けたということかもしれない。
FAQで探すとは思わない。フッターならともかく、FAQではない。
興味深いケーススタディだが、より広い含意については懐疑的だ。Pineconeは他のベクトルデータベースサービスと比べて高いことで有名だ。横並びで価格比較をすると、市場にはより良い選択肢がいくつもある。
計算機を取り除いても、核心的な問題は解決しない。コストを見えにくくし、ユーザーが最初から選択肢を比較しづらくするだけだ。私の見方では、比較のステップを減らすことで、情報不足のユーザーが価格への影響を十分に理解しないままデータをアップロードしてしまう可能性がある。
単純化に価値がある場合もあるが、このケースではユーザーより会社にとって有利に見える。計算機を完全になくすより、正確性と使いやすさを改善したほうがよかったかもしれない。特にコストが急速に膨らみ得るB2Bサービスでは、価格の透明性が重要だ。