作った機能が使われない｜機能の定着率を測って直す

リリース当日はチームで盛り上がったのに、2週間後に数字を開いたら利用者が二桁に届いていない。心当たりはありませんか。

そこで多くのチームがやってしまうのが、すぐに作り直しに入ることです。UIを変え、説明文を書き直し、また2週間かける。

でも、使われない理由の大半は機能そのものではありません。存在を知られていないか、たどり着けないか、たどり着いた先で価値が伝わらなかったか。

だいたいこの三つのどれかです。だとすれば最初にやるべきは作り直しの計画ではなく、どこで止まっているのかの切り分けになります。

この記事では、定着率をどう定義するか、どこが詰まっているかをどう切り分けるか、そして機能を変更せずに直す道をどう探すかを順に説明します。作り直すのは、最後の手段です。

使われていないを、三つの数字に分解する

使われていない、という言葉は何も指していません。まずは分解します。

到達、初回利用、継続利用。この三段に割るだけで、同じ症状がまったく別の問題に分かれます。

到達は、機能の入り口まで来た人の数です。メニューを開いた、告知バナーを踏んだ、機能紹介ページを見た、といった行動を指します。

初回利用は、実際に一度でも操作を完了した人の数。継続利用は、そのあと決められた期間内にもう一度使った人の数です。

ここまで来て、ようやく定着と呼べます。一度使われたことと、定着したことは別物です。

リリース直後の跳ね上がりに騙されない

告知メールやアプリ内バナーを出せば、初回利用は必ず跳ねます。物珍しさで開いた人が混ざるからです。

その数字を見て成功と判断し、3週間後に静かに沈んでいることに誰も気づかない。よくある光景ですよね。

だから見るべきは、リリース週を除いた数字です。告知の効果が切れたあとに残った利用が、その機能の素の実力になります。

判断の目安としては、リリースから2〜4週後の週次利用者数が、リリース週の3割を下回るなら黄信号と考えています。もちろん機能の性質によりますが、基準を先に置いておくと議論が早く終わります。

もうひとつ、初日から数えないでください。告知が全員に届くまでには数日かかりますし、週次で使う機能なら1週間見ないと1回目すら回ってきません。

計測の起点は、告知が一巡した翌週。ここを揃えないと、チームごとに違う数字を持ち寄ることになります。

定着率の分母を決めるところが、一番むずかしい

定着率を出しましょう、という話になると、まず分子で揉めます。実際に難しいのは分母のほうです。

全ユーザーを分母にすると、そもそもその機能に用のない人まで含まれます。逆に絞りすぎると、どんな機能でも良い数字が出てしまう。

分母を決めるときは、次の三つを自分に問いかけてみてください。

• その機能を使う前提条件（プラン、権限、データ量）を満たしている人は誰か
• その条件を満たしていない人は、何割いるのか
• 満たしていない人を増やすことが、この機能の目的に含まれるか

三つ目が肝心です。前提条件そのものを緩めるのが本当の課題なら、定着率を測る前にやることがあります。

四つの指標を、役割で使い分ける

分母を変えると、同じ現象がまったく違う数字になります。整理しておきましょう。

報告に使うのは一番下の定着率だけで十分です。ただし改善の議論をするときは、必ず上の三つに割って持っていく。

定着率が5%でした、では会話が続きません。到達率が35%で、そこから初回利用が43%で、継続が37%です、と言えば次の一手の話が始まります。

なお、継続の期間をどう取るかは機能によって変わります。毎日使う機能なら7日、月次の締め作業に使う機能なら60日と、その機能の自然な使用サイクルに合わせてください。

決めた定義は、口頭で共有せず短いメモに残しておきます。書くのは対象ユーザーの条件と、継続とみなす窓の長さの二つで足ります。

これがあると、三か月後に別の担当が計算しても同じ数字が出ます。逆に残していないと、担当が変わった瞬間に数字も静かに変わります。

そして数字が変わると、過去の判断まで丸ごと疑わしくなります。定義を守ることは、比較できる状態を守ることでもあります。

認知・導線・価値のどれが詰まっているのか

三段に割ると、詰まっている場所が自動的に決まります。ここが切り分けの中心です。

症状と疑う場所の対応を、表にしておきます。

一番下の行は見落とされがちです。全体では10%でも、特定の業種だけ40%なら、それは失敗ではなく対象を間違えていただけの可能性があります。

平均の裏側を、属性で割って確かめる

全体の定着率は、性質の違う集団をまとめてならした平均でしかありません。平均のままでは、直す場所がどうしてもぼやけます。

割り方は無数にありますが、最初は登録時期、プラン、利用規模、流入経路の四つで足ります。ここで大きな差が出た軸だけを、次に深掘りします。

たとえば検索から来た人と広告から来た人で、定着率が倍ちがうことがあります。機能の出来ではなく、使い始める手前で作られた期待値が違っていた、という話です。

差の出なかった軸は、そこで打ち切ってかまいません。全部の軸を掘ると時間が足りませんし、差の無い分割からは打ち手が出てきません。

認知の詰まりは、プロダクトの外側にもある

新機能を知ってもらう経路は、プロダクト内のお知らせだけではありません。サイトの機能紹介ページ、メール、SNS、検索と、外側にもいくつも並んでいます。

ここは意外と抜けます。プロダクト内の告知だけを見て、認知はもう足りているはずだと判断してしまうからです。

機能紹介ページに何人来ていて、そのうち何割がログインや申し込みの導線に進んだか。これはウェブ側の解析で普通に測れる範囲です。

Strideのようなサイト計測ツールなら、機能紹介ページのPVや流入元の内訳、そこからフォームやログイン導線への到達までを追えます。ただしログイン後にその機能を実際に触ったかどうかは、プロダクト内のログやプロダクト分析ツールの担当領域です。

ウェブ側とプロダクト内側で、計測の持ち場が分かれていることは最初に共有しておいてください。ここが曖昧なまま議論すると、誰の数字が正しいのかで時間を溶かします。

導線の詰まりは、たいてい手前にある

入り口までは来ているのに使われないとき、犯人は機能の中身ではなく、その手前の一手間であることがほとんどです。

連携設定が要る、サンプルデータが無くて空の画面が出る、説明のモーダルが3枚続く。どれも、開いた瞬間に帰る理由になります。

とくに空の画面は強敵です。初めて開いた人にとって、何も入っていない画面は使い方が想像できない場所でしかありません。

最初の体験の設計そのものについては、オンボーディング改善｜最初の体験で離脱させない設計で扱っています。

判断のコツは、初回利用までに必要な操作の回数を数えてみることです。3回を超えているなら、たいてい減らす余地があります。

減らせないなら、順番を入れ替えます。設定を先に求めるのではなく、まず動く画面を見せて、必要になった時点で設定を求める形にします。

この入れ替えだけで初回利用率が動くことは珍しくありません。機能の中身には一行も手を入れていないのに、です。

数値例で、直す場所と伸びしろを見積もる

言葉だけでは判断できないので、数字を置いてみます。架空の機能Xの1か月分です。

機能X（対象ユーザー 1,200人 / 直近30日）

  対象ユーザー            1,200
  入り口に到達              420   到達率        35%
  初回利用                  180   到達→初回     43%
  2回目以降の利用            66   初回→継続     37%

  定着率 = 66 ÷ 1,200 = 5.5%

失った人数で並べると、到達で780人、初回利用で240人、継続で114人です。数の大きさだけ見れば、認知を直すのが正解に見えます。

でも、それだけで決めてはいけません。改善したときに定着ユーザーが何人増えるかを、案ごとに試算します。

A案：告知を増やして 到達率 35% → 50%
  到達 600人 → 初回 258人 → 継続 95人（+29人）

B案：初回体験を直して 到達→初回 43% → 60%
  到達 420人 → 初回 252人 → 継続 93人（+27人）

C案：価値を伝え直して 初回→継続 37% → 50%
  初回 180人 → 継続 90人（+24人）

三つとも、増える人数はほぼ同じでした。通過率の低さと、伸びしろの大きさは一致しないということです。

理屈は単純で、上流を底上げしても、その効果は下流の低い通過率で削られていきます。到達を180人増やしても、43%と37%を通り抜けて残るのは30人ほどにしかなりません。

だとすれば、判断軸はどれが一番早く安く試せるかに移ります。A案の告知文の差し替えは今日できて、C案の価値の作り直しは1か月かかる。

ここまで並べて初めて、優先順位の議論が数字の話になります。段階ごとの通過率と失った人数を並べる読み方は、ファネル分析の基本｜離脱ポイントの見つけ方と改善の進め方と同じ考え方です。

上流を直すと、下流の率が下がることがある

ひとつ注意があります。A案で到達を増やすと、初回利用率も継続率も下がるのが普通です。

もともと関心の薄い層が流れ込むからですね。率が下がったのに、人数は増えているという状況が起きます。

このとき率だけを見て失敗と判断すると、正しい施策を潰します。認知施策の評価は、率ではなく定着した人数で見てください。

直す前に、変更しないという選択肢を検討する

ここが、この記事で一番伝えたいところです。切り分けの結果が認知や導線なら、機能そのものは何も変えなくていいのです。

告知の置き場所を変える。空の画面にサンプルデータを一件だけ入れておく。

説明モーダルを3枚から1枚に減らす。どれも機能の作り直しではありません。

順番としては、機能の外側から内側へ手を入れます。告知と文言が最初、次に入り口の導線、そのあとに初回体験、最後にようやく機能の中身です。

外側ほど、変更が小さく、効果が出るまでが速い。この順番を守るだけで、無駄な作り直しがかなり減ります。

もうひとつ効き目があります。外側から順に試していくと、機能の中身に手を入れる頃には、何が効いて何が効かなかったかの記録が溜まっているのです。

いきなり作り直した場合、その記録は一行も残りません。次に同じことが起きたとき、またゼロから議論を始めることになります。

そして最後まで残った選択肢が、何もしないことです。使われていないと分かっただけでも、それは十分に価値のある結果になります。

変更するなら、比べられる形で

サイト側の見せ方を変えるときは、変更前と後を比べられる形にしておくと後の議論が楽になります。告知バナーの文言や置き場所くらいなら、A/Bテストで並べて試すのが手軽です。

Strideの場合、A/Bテストはサイトを開いたままノーコードで作れますが、これも対象はウェブページ側の要素です。プロダクト内の画面を出し分けるなら、アプリ側の仕組みが必要になります。

いずれにせよ、変更したら必ず同じ指標で測り直す。これを守らないと、直したつもりの施策が積み上がっていきます。

数字が理由を教えてくれないときの進め方

継続率が低いと分かっても、なぜ戻ってこないのかは数字からは出てきません。ここから先は、人に聞くしかない領域です。

一度使ってやめた人を数人選んで、行動の履歴を丁寧に読む。それだけで仮説の質がかなり変わります。

一人の記録から仮説を立てるやり方はN1分析とは｜一人の行動から改善のヒントを得るにまとめています。行動が読めたら、次は短いアンケートで直接聞くのが効率的です。

聞くことは一つで十分です。この機能を使わなくなった一番の理由は何ですか、と自由記述で聞くだけにします。

選択肢を作り込むと、こちらの想定の中にしか答えが返ってきません。想定の外を拾うのが目的なのだから、そこは開けておきます。

Strideのアンケート機能は、サイト側の特定ページで表示条件を絞って出せます。プロダクト内で聞きたい場合は、アプリ側に埋め込む手段を用意してください。

定着率が向いていない機能もある

最後に、この指標の限界に触れておきます。すべての機能を定着率で評価するのは間違いです。

年に一度のデータ移行、退会前の引き止め、障害時の代替手段。こうした機能は、使われないほうが健全です。

請求書の出力のように月に一度しか出番のない機能を、7日継続率で測っても意味がありません。測る前に、その機能が繰り返し使われるべきものかを確認する。

繰り返し使うことが前提でない機能は、成功率や所要時間で評価するほうが実態に合います。指標そのものの選び方はプロダクト指標の設計｜北極星指標とKPIツリーの作り方でも扱っています。

この見極めは、できればリリース前に済ませておきたいところです。あとから指標を選び直すと、都合の良い数字を後付けしたように見えてしまいます。

撤退ラインは、リリース前に決めておく

使われていない機能をどうするかで揉めるのは、判断基準が後出しになるからです。作った本人が判断すれば、当然もう少し様子を見ましょうになります。

だから、リリース前に決めます。何週後に、どの指標が、どの水準に届かなければ、改善を打ち切って撤去を検討するか。

判断の会議に入る前に、次の四つだけ確認してください。

• 告知が本当に対象ユーザーに届いていたか（到達率で確認する）
• 初回利用の手前に、削れる手順が残っていないか
• 使い続けている少数がいるなら、その人たちは誰か
• 撤去した場合に困る人の数と、維持にかかる手間

三つ目を飛ばすと、少数でも強く依存している利用者を切ってしまいます。全体で3%でも、その3%が主要顧客なら判断は変わりますよね。

会議で合意を取るときは、判断そのものより、判断に使う数字の定義を先に握るほうが早く終わります。分母は誰か、期間は何日か、リリース週を含めるか。

この三点が揃っていれば、結論が撤去でも継続でも、誰も後から蒸し返しません。逆にここが曖昧なまま結論だけ出すと、翌月にまた同じ議論が始まります。

撤去を決めたときは、それを失敗として片づけないでください。どの仮説が外れたのかを一行で残すだけで、次の企画の精度が上がります。

想定した課題が存在しなかったのか、課題はあったが優先度が低かったのか、解き方が合わなかったのか。この三つは似ているようで、次に取るべき行動がまるで違います。

そして残った時間を、次の機能に回す。使われない機能を抱え続けるコストは、コードの保守だけでなく、メニューが増えて他の機能が見つけにくくなることにも及びます。

作った機能が使われないのは、チームの失敗ではありません。仮説が一つ確かめられただけです。

大事なのは、その結果を三つの数字に分けて読み、機能を変えずに直せる部分から先に手をつけること。作り直しは、そのあとで十分間に合います。