ユーザの退会理由をあれこれ考えない
ユーザの退会理由をあれこれ考えない
退会ユーザを追いかけると迷走する／自分ならどういう時に退会するかを考える／「欲しいもの」と「使いたくないもの」は表裏一体
どうも、TAKUYAです。InkdropというMarkdownエディタを一人で作っています。先日、総売上が400万円を超えました。いつもありがとうございます。
継続課金モデルでサービスを運営していると必ず直面するのが、課金ユーザの退会です。一般的に継続課金型のチャーンレートは6%前後で高いと言われています。チャーンレート(Churn Rate)とは退会率のことです。
チャーンレートはビジネスの継続性に関わる重要な指標です。このチャーンレートが成長率を上回らないように気をつける必要があります。個人開発において、どうすればこのチャーンレートを低く抑えることができるでしょうか。本稿で自分の考えを書きたいと思います。
Inkdropも未成熟の頃はチャーンレートがとても低く安定していました。でも最近では上記と似たようなレートを示すようになりました。やはり退会する人が増えると焦りを感じたり不安になります。そしてなぜ退会していくのか、原因をあれこれ考えてしまうようになりました。
しばらくして、それは全くの時間の無駄だと気づきました。答えは初心にありました。わざわざニッチの領域を選び、個人でモノを作って売るのはなぜかと言えば、それが好きだからに他なりません。自分が欲しいものを作るという前提に立った時、退会していく人をやみくもに追うのはコンセプトから遠ざかるような行動です。
例えば、アカウントの削除ページに退会理由のアンケートを設置することもやろうと思えば出来ます。じゃあそれを聞いて、ユーザの不満を全て解決すれば済む問題なのでしょうか？ — いいえ。これは以前書いた「実装しない」機能の決め方にも通ずる話です：
退会していくユーザの意見をすべて取り入れることは、結局のところ機能要望を手当たり次第に取り入れることと同義です。こだわりやシンプルさは失われて、プログラムは不必要に複雑化します。課金ユーザの減少を焦るあまり本来のコンセプトを忘れるのは本末転倒です。
短期的な目線で捉えすぎている可能性もあります。アプリの伸び率には波があるものです。退会率も同じく、一時的に高まることは充分にありえます。それは株価の変動に似ています。そういえばAppleも最近株価が大きく下がりましたが、投資家のウォーレン・バフェットは逆に買い増ししていました。この事は、中長期的目線に立つことがいかに重要かを教えてくれます。
先述の通り、退会ユーザから原因を探るのはやめたほうが良さそうです。ではどうすれば良いのかというと、あくまで「欲しいものを作る」という前提で考えます。すなわち、自分のアプリを「使いたくないものにしない」ように気をつけるという事です。
自分の経験上から、使いたくないアプリとはどんなものか、どういう体験をすると利用をやめるのかについて列挙します。そして、それらに該当しないように注意を払います。例えば、僕なら以下のようなアプリは使いたくありません。
- しょっちゅう仕様を変える — UIが頻繁に変わったり、ショートカットキーなどの挙動が変わったら嫌です。せっかく慣れてきたのにまた合わせなくてはなりません。ストレスです。
- バージョンアップが頻繁すぎる — あまりに頻繁に新バージョンの通知が出てくるとうんざりします。アップデート作業を何度もしたくありません。
- 致命的なバグが混入される — 以前のバージョンでは問題なかったのに、アップデートして上手く動かなくなったら嫌です。レグレッションは大きな失望を買います。
- コア機能の不満点がずっと解消されない — 中心的な機能のパフォーマンスに問題があったり不具合があったとします。それらが延々と解消されなければ他への乗り換えを検討します。
ポイントは、これらは開発初期には気にしなくても許される問題だった事です。Inkdropのユーザの増加やアプリの成熟に従って、変更点に伴う影響範囲を考慮する重要性が高まりました。どうやら僕は、成長期の開発戦略を立て直す必要があることが分かりました。すなわち：
- 仕様変更は慎重に — 思いつきや見切り発車でほいほい変更しない。特にエディタの挙動。
- 重要なバグ修正以外のバージョンアップは月イチぐらいに抑える — 改善点を早く届けたいという気持ちをグッとこらえる。もし必要ならベータ版の配信を検討する。
- 動作確認はじっくり入念に — 変更箇所だけでなく周辺の機能にも気を配る。場合によっては数日〜数週間様子を見る。
- コア機能の改善を最優先にする — ユーザは周辺の機能について言及する傾向があるが、それはコア機能がうまく動いている前提である事を忘れない。
こうやって考えると、思い当たる節がいくつか出てきました。僕は初期の頃のようにユーザのバグ報告をアテにする傾向がありました。そして手元での動作確認を怠ったために、致命的なバグを何度か混入してしまいました。そして大急ぎでアップデートを配信するという事を繰り返していました。これではユーザも落ち着いて利用できず、利用体験が損なわれてしまいます。
Inline HTMLの不安定さを長らく放置していたのも失敗の一つです。ノート中にHTMLを記述すると、たまにアプリ全体が反応しなくなる不具合がありました。自分はあまりInline HTMLを使わないので、この問題の深刻さを理解していませんでした。しかしそれはMarkdown標準の機能なので、不完全な実装で提供すべきではなかったのです。
自分ならどういう時に退会するかを考えて、それに該当しないように配慮する — これは自分にとってとても良い気づきでした。退会ユーザが出るたびにあれこれ考えて狼狽する必要はもうありません。
自分の想定した以外の退会要因には原則対処しません。キリが無いからです。誰かにとってのNGは、全員にとってのNGとは限りません。チャーンレートをゼロにするのは不可能です。自分が納得の行くものを作ってそれでもダメなら、それは単に合わなかっただけと判断できます。自分が喜ばせようとしている相手は、あくまで自分と似ている人たちです。それを常に念頭に置く必要があります。
大事なのは守備範囲をはっきりと決めて、それに集中することだと思います。その基準は自分中心で良い。なぜなら「欲しいもの」と「使いたくないもの」は表裏一体だからです。
あなたの個人開発の参考になれば幸いです。
