はじめに
まさき。です。
突然ですが、私には過去に大して利益を得られてないツールにお金を払って悲しい想いをしたり、副業で時間をかけて作ったものが全然使われてなくてがったりした経験があります。
それからは、同じような気持ちを持った人を減らしたいという思いが強くなりました。
日々の業務でもここらへんは人一倍意識しているつもりです。
最近、自分の所属するPJでもアウトプットよりもアウトカム(成果)を意識しよう！という動きが活発であり、作って終わりじゃなくて「使ってもらえていること」に以前よりも意識を配ることが多くなってきました。
PJでユーザーストーリーマッピングの輪読会があったり、個人的にリリースした機能が使われていることをDBのレコードの増減などを監視して調査する機会もあり、リリースした機能が使われることについて改めて考える機会が多々ありました。
そこで、この記事では、継続的に機能が利用されるということはどういうことかを考えつつ、利用状況を計測して次のアクションを考えてみることにします。
機能を使ってもらえているということ
限られたリソース(時間も人も)を駆使してリリースしたのに、思っていたよりもその機能が使ってもらえていないと悲しいですよね。使ってもらえていても1回だけとか、お試しで使っただけってのもなかなか悲しいものがあります。そこで、継続的に機能が使ってもらえるということはどういうことかを深掘りしてみることにします。
それは、リリースされたその機能に対してユーザーがなんらかの価値を感じてもらえている状態でしょう。ここでの価値とは、提供しているサービスにも依りますが、弊社のネクストエンジンで言えば、ネットショップ運営に関わるコスト(複雑な作業工程や単純だけど繰り返し手でやらないといけない作業)を削減したり、リリースによって新たにできるようになったことで新たに販売機会が増える、損失を被る機会を減らせると言ったことが挙げられそうです。
ユーザーに価値を感じてもらう
では、この価値を機能リリースによって感じてもらうにはどうすればいいのでしょうか？
価値を届けたいと考えているユーザーを決めて、そのユーザーの潜在課題(ユーザー自身も気づいていない課題)や顕在課題(現在困っている課題)は何かを考えることが必要です。ただ、ネットショップの運営に関する知識などのドメイン知識はどうしてもユーザーの方が豊富なので、開発者が1から頭で考えるより、運営しているユーザーにアンケートを取ったりインタビューしたり、ネットショップの運営をしているところを見せてもらったり、それができなくてもユーザーとお話ができるセールスやカスタマーサポートの担当者と話すなどして、ユーザーやユーザーを比較的知っている方々から学ぶ必要がありそうです。
機能リリースは仮説を実証するために
価値を届けたいユーザーと解決したい課題が決まれば、それを解決する手段の一つとして機能リリースという選択がとれます。ここであえて選択が取れると言ったのは、マニュアルを強化したり、使い方の解説記事を増やすだけで課題を解決できるのであれば、必ずしもリリースという選択をしなくても良いからです。
自分が解決しようとしている問題、問題を解決してあげているつもりの相手である顧客やユーザー、そして頭のなかに思い描いている解決方法が、すべて仮説なのを知っている。
ユーザーストーリーマッピング, JeffPatton, pp.71
とあるように、この時点でのターゲットユーザーや解決したい課題、解決策は仮説でしかないと考えた方が良いようです。そこでこの仮説を実証するために使える機能を実験的にリリースして、ユーザーの反応を見て学ぶのが良いようです。使ってもらえているかを見ていくわけですね。たとえユーザーから不満の声が上がっても、それは使ってもらえているということであり、改善のヒントになるのでそこから次の仮説を立てることができます。
機能が使われているかを知る
使われるとはどういうことかがわかったところで、実際に機能が使われているかを見ていきましょう。リリースした機能を利用することでDBにレコードが新たに追加されるのであれば、それを見ていきましょう。その機能を使ったことがわかるログを仕込んだり、GAやアクセスログからその機能を利用するためのURLが叩かれていることを確認するのも手ですね。弊社では、BigQueryでデータ基盤が整備されており、ユーザーのDBデータを安全かつ気軽に確認することができます。BQで発行したクエリの取得結果をビューとして保存しておき、GoogleSpreadSheetと連携しピボットテーブルにして見やすくすることも容易にできます。
コネクテッド シートの使用
たとえば、私は先述したコネクテッドシートで最近リリースした「店舗別ページの予約アップロード機能」を利用してくれているユーザーの利用状況(利用回数だったり、処理を自動化する対象件数、最後に使った日時など)をリアルタイムで取得してます。
データを見るときには、使われていても使われていなくてもなぜそうなっているのかをリリース時に立てた仮説と照らし合わせながら考えることが大事だと考えています。
以下では、利用状況の結果ごとに何が言えそうなのか、何が必要そうなのかを挙げます。
機能の利用者数が少ない、増えていない場合
リリースした機能を使ってくれているユーザーが少なかったり、リリース前後で変わっていない場合は、すくなくとも以下の4つの要因が考えられそうです。
- そもそも機能がリリースされたことが知られていない
- ユーザーの抱えている課題がこの機能リリースで解決できることに気づいていない
- その機能を利用できる条件を満たしているユーザーが少ない
- その機能に価値を感じられるユーザーが少ない
そもそも機能がリリースされたことが知られていない
これに関しては、機能リリースがあったことを、集客をするための媒体で告知したり、ユーザー向けにお知らせを配信したりする、画面に案内を表示するなど、とにかく認知してもらうために必要なことをやっていく必要がありそうです。
こちらに関しては、実際に関連機能を使っているユーザーであれば、気づくことができる位置に新機能ができたよ！使ってみて！という表示を出すリリースが最近行われました。
ユーザーの抱えている課題がこの機能リリースで解決できることに気づいていない
ユーザーは機能リリースがあったことをお知らせなどで気づいているのですが、残念ながら自分がこの機能の恩恵を受けられると気づいていないケースもありそうです。この場合も、この機能はこんなときにつかえますよ、と具体的なユースケースをブログやマニュアルなどで示してあげるのが良いと思います。
その機能を利用できる条件を満たしているユーザーが少ない・価値を感じられるユーザーが少ない
機能Aの一部の機能である機能aを使いやすくするリリースをしました！が、機能Aをそもそも使いこなしてないと機能aは使えないんです！ってケースだってあります。その際には、機能aがリリースされたので、機能Aを使ってみませんか？という形で機能Aの訴求をすることになりそうです。が、その場合はたいてい機能Aを使うハードルが高いので、機能A自体を使ってもらえるようにするというアクションも同時に行っていく必要がありそうです。
この場合は、対象とするユーザーがそもそもいなかった、間違っていた可能性もあるので、仮説を見直す必要がありそうです。
継続して使われてなさそう
機能の利用者数は増えているんだけど、1回限りしか使われてなかったり利用頻度が低い場合は、機能がリリースされたからお試しで使ってみたけど、自分らの運用に合わないとユーザーが判断している可能性があります。
単に、ユーザーの運用上、その機能を使うような機会があまりない場合、そもそも課題だと思っていたものはユーザーにとっては課題ではなかった可能性があります。
一方で、使う機会はあるんだけど、機能が不足していたり、条件が厳しすぎて実運用に耐えないと判断して使っていないケースも考えられます。その機能を使うと余計に手作業が必要になるような場合は、数回使っただけで使わなくなることが容易に想像できます。このケースであれば、ユーザーインタビューなどで課題が洗い出せるかもしれませんし、不満の声を上げてくれているかもしれません。
ユーザーに継続して使ってもらえていそう
もし、リリースした機能をユーザーが継続して使ってくれているのであれば、おめでとうございます、あなたの立てた仮説は正しく、ユーザーに価値が届く状態になったのでしょう。この場合も、どんなユーザーに使ってもらえてそうか、想定したユーザー以外が使っていないか、その場合はどんな価値を提供できていそうかを考えるのが良いと思います。更に機能の利用を訴求するためのヒントになる可能性があるので、ユーザーインタビューでそこらへんを明らかにするのが良いのではないでしょうか。
まとめ
価値を提供したいユーザーを定め、そのユーザーが抱えていそうな課題とそれを解決できそうな解決策を仮説としてもっておき、リリースによってその仮説を確認するのが良さそうということを述べました。また、利用状況の計測結果に対し、考えられうる状況と対策を挙げました。
リリースするときは、仮説を立てて、その仮説の実証、その結果の考察までをワンサイクルにしてユーザーから学びながら継続的に価値を提供していけるようにしていきたいです。
NE株式会社のエンジニアを中心に更新していくPublicationです。 NEでは、「コマースに熱狂を。」をパーパスに掲げ、ECやその周辺領域の事業に取り組んでいます。 Homepage: ne-inc.jp/
Discussion