継続的なグロースハック「クラウド会計ソフトfreee」のユーザビリティ改善事例

クラウド型の会計ソフト・給与計算をはじめ、複数のバックオフィス支援サービスを展開されているfreee 株式会社「クラウド会計ソフトfreee」のグロースハックによるユーザビリティ改善事例を、グロースチームへのインタビュー形式で紹介します。

「グロースハック」と聞いてもあまりピンと来なかった方や、A/Bテストのような取り組みを大事だと思ってはいるけれどもどんな施策がよいのかわからず困られているといった方々にとって、Web改善ヒントになれば幸いです。

＼ナイルのサイト改善提案の紹介はこちらから！／

厳密さよりスピード重視！freeeのグロースハック体制

インタビューを受けるグロースチームの方々。左からエンジニア轡田氏、エンジニア大平氏、マーケティング鈴木氏

※本記事では、3名の方々の回答を取りまとめて紹介させていただいております。また、画面改善前の画像は一部残っているものをご用意いただきました。

グロースチームの体制について教えてください

――　freeeのグロースチームは何人ですか？

4人です。マーケティング1名、エンジニア2名、デザイナー1名が集まり、企画から実装までしています。時には1人で役割を兼任することもあります。またチーム外にはなりますが、データアナリストいて、データをレポートしてくれています。

――　KPIは何を設定されていますか？

基本的には「お客さんが、しっかりサービスをつかいこなしているか」に繋がるKPIを見ています。その中間指標として、「特定の機能を利用したか」といったことや、関連サービスの利用状況なども見ています。

――　グロースチーム以外の部門とも調整をしながら進められているのですか？

グロースチームに決裁権があるので、ある程度のことは自分たちの裁量で進められます。共有や打ち合わせはしますが、自分たちの判断で実行できるので、スピードが速いとされるベンチャー企業の中でもかなり高速で進められていると思います。

施策について教えてください

――　同時に動かす施策はどれぐらいありますか？

エンジニアリングできるのが2人なので、同時に動かせるのは2つです。細かいA/Bとかも含めると月に30くらいの施策を実施していますね。毎日何かしらの作業を行っています。

――　2つの施策がバッティングすることはないのでしょうか？

施策の順番は気をつけています。優先順位を決める段階で、同時に善し悪しを比較できないものはずらします。

――　施策を見る期間はどれぐらいですか？

長いと一週間程度です。短くて2日ぐらいです。統計的な有意差を求めるとサンプル数が多く必要になりますが、それだと短い期間で改善ができないんですよ。だからどんどん進めていく。「厳密さより、スピード重視」です！

――　施策の進捗管理はどうされていますか？

進捗に１週間も掛かるものはあまりなくて、「仕上がり6割」でもいいから早く出すことを大事にしています。人数が少ないという事情もあるので、フレキシブルにやっています。普段の共有はGoogleスプレッドシートで、細かい進捗確認は朝会などでやっています。

――　施策は数字を改善できるまでトライしますか？

そうですね。ただダメだったら戻すこともあります。時には捨てる勇気も必要ですね。

――　その判断はどこでしますか？

データで判断します。ポテンシャルがありそうな案はアップデートしてまた議論を戦わせたりしますが、その辺りはチームで話し合って決めます。

――　A/Bテストはツールを利用されていますか？

WebではAパターン、Bパターンとユーザごとに表示を切り替えたりして、AとBでどちらがより利用されるかをテストしています。モバイルについてはA/Bテストのサービスを活用してテストをしています。

――　改善版の画面はデザイナーが作成するのでしょうか？

そうです。ただ改善案のコンセプトは施策のオーナーが考えます。その上で施策を試す時には、一つに極力時間を掛けないようにしています。

――　上手くいかないケースはどのようなものがありますか？

上手くいかないのは「ダサいから変えよう！」みたいな場合です。改善の意図がフワフワしているので、ダメだった時に学びが少ないんですね。改善目標がぼんやりしていると、「デザインなのか」それとも「わかりづらかったのか」ダメな原因が判断できないんです。

コンセプトがハッキリしていれば、仮に失敗してもそのコンセプトについて学びが得られるし、見直しも含めて次に活かすことができます。

――　チームで大事にしていることはありますか？

グ ロースチームでは、方向性がぶれないようにミッションステートメントを決めています。それが「エジソン感」です。このミッションステートメントは「目的に 向かって、圧倒的な速さで枠にとらわれない施策を大量にリリースし改善を続けていく。それすなわち、エジソン」というものです。

エジソンのように、「たくさん失敗して、その中から学びを得て、次の成功に活かす」そういう姿勢を僕達も見習おうという意味です。そこで「エジソン」と名づけました。

個人事業主と法人のニーズ違いを発見。新規登録の離脱率を大幅改善

――　新規アカウント登録、サインアップフローの改善例はありますか？

freeeには、自動経理機能というものがありまして。以前はサインアップフロー上で「銀行口座の登録」を促すようにしていました。銀行口座を登録すれば自動連携でデータが入るので、運営側としては「便利」だと思っていたんです。それがサービスのウリでもあったので。

ところが、登録が半強制のようなフローだったので利用数は増えたんですけど、一方で「離脱率が上がっているようだ」ということが分かってきました。「誰にでも必要なわけじゃないらしい」とハッキリしてきたんです。

――　離脱率が上がっていた原因は？

当初は「クラウド会計」に興味を持ってくれるアーリーアダプター（初期採用者）がユーザで問題がなかったのですが、ユーザが増えてくるにつれて機能開発も進んで、新規ユーザに期待されている機能が自動経理機能だけではなくなっていたんです。

いつの間にか、「ユーザニーズが多様化」していたんですね。特に個人事業主と法人でニーズが異なっていました。個人事業主だと自動経理はニーズが大きくて登録をしてくれるのですが、法人はそれ以外を目的に利用して下さる方も多く、離脱が増えていった可能性がありました。

――　ニーズの違いはどうやって気づいたのですか？

社内のカスタマーサポート担当に話を聞きました。すると、どうやら法人では、銀行口座の登録時に、パスワードを入力しなければならないために「銀行のパスワードを入れないと利用できないサービス」と思い込んでいたようなんです。

――　勘違いされていたということですか？

そうです。銀行口座の登録は、あくまでもおすすめの登録方法であって絶対の方法ではなかったんです。だから思い切って「自動経理の機能をすすめないフロー」に変えました。結果、離脱率が大きく下がり、それに伴って色々な数字が大幅に改善しました。

UXの重要性。ログインスプラッシュの見直しで各種KPIを改善

――　サインアップフローの改善以外に効果の大きかった施策はありますか？

効果が大きかった施策の一つに、標準プラン（有料プラン）のメリットを促す、ログインスプラッシュ（※）の改善があります。

（※）ログインスプラッシュ：ユーザのログイン後に画像を表示させる機能。

ログイン直後の画面

その中でも、標準プラン（有料プラン）で利用できるチャットサポートはアンケート満足度が90%以上と非常に高く、価値ある体験をユーザに提供できているのですが、ログイン後の案内を上手くできておらず、チャットサポートの良さを体験しないまま離脱してしまうお客様が結構いました。

そこで、「一連のユーザー体験を悪化させない」ように考えた結果、表示のタイミングはログイン直後にするのが望ましいという結論になりました。案内のタイミングを変えた結果、全体のKPIが改善してかなり上手くいきました。

ログイン直後の画面に案内を表示

――　チャット機能の案内改善は、表示タイミングの見直しだけですか？

ログイン後の画面右下にもチャット案内が出ているのですが、その文脈を変えたところ利用率が上がりました。「伝え方を変えることでユーザーの印象が良くなった」事例だと思います。

長い説明文よりユーザー体験を優先。機能の利用率を10％改善

――　freeeはアプリもあると思いますが、改善事例はありますか？

アプリのというわけではないのですが、freeeには、モバイルでレシートや領収書、請求書の写真を撮ると、自動で入力してくれる機能があります。初期の頃は専用アプリをインストールして使ってもらう想定だったのですが、PC側で案内をして利用を促すのが難しいという課題がありました。

――　わざわざアプリを入れないといけないのは手間かもしれませんね

結局、改善策として、「この機能はまずは使ってもらうのが一番だろう」と考えて、アプリに限らず「PC上でもドラッグ＆ドロップで簡単に使える」ようにしました。ユーザに体験してもらうことを優先させたわけです。

その結果、レシート写真のアップロード率が10％改善しました。

全部「必須」なら記載なくてもよい！？フォームをすっきりさせたら失敗しました

――　改善じゃなくて改悪になった事例をひとつ教えていただけますか？

登録時の入力フォームで「必須」マークを載せるか否かを試したことがあって。もともとあった「必須」を全部外したらスッキリすると思ったんですけど、数字は悪化しましたね（笑）。

スッキリしているかどうかではなく、「ユーザに必要な情報はちゃんと伝えた方が良い」という学びがありました。

新サービスの告知を小さく開始。分析結果を踏まえてインパクトの大きな改善を実施

――　色々な機能を追加されているようですので、新機能のリリースから改善までの例があれば教えていただけますか？

法人顧客を増やすための施策で「丸ごとサポートプラン」というサービスを立ち上げたのですが、やはりグロース的に開始することにしました。最初は小さく電話番号のみを記載して様子を見ながら始めたんです。

――　電話番号表記だけして、申し込みフォームは用意しなかったということですか？

そうです。その後、申し込みフォームを用意する流れにしました。ある程度オペレーションが固まった後で、周知の為にLPを作成したり、CVを全てトラッカブル（計測可能）にしたりしました。

――　その後の改善はどのように進められたのですか？

「申し込みフォームの項目が多くて長いから、申し込みが伸びないのではないか？」と社内で言われていたんですね。でも、フォームの入力達成率を分析すると全然途中で落ちていなかったんです。「1つでも項目を入力したユーザーは、最後まで入力」してくれていたんですね。これは面白かったです。

それで、「フォームの改善をするよりもフォームへの導線改善を重視」しました。すると、最初から比べて、約3倍程度の申し込みが来るようになりました。

細かな施策を打ち続けるグロースチーム。ユーザーテストの位置づけとは

――　ユーザーテストの扱いや考え方について教えていただけますか？

グロースチームとしては、ユーザテストの事例は少ないです。

ただ、最近始めた試みですが、ユーザテストのコストが掛かる点を解決するために、毎週のように増えている社内のスタッフに使ってもらうテストをしています。そこで出てきた結果を施策として打っていていますが、それはかなり効いています。

社員の方のユーザーテスト後のまとめ

――　ユーザーテストは、局所的な改善活用が多い？

グロースチームで見ているのは新規ユーザの登録シナリオですね。とはいえ登録シナリオはやれることが限られているので、新規ユーザの体験を一通りやってもらうようにしています。

――　判断指標に人数は用いていますか？

人数ではあまり判断しません。ユーザテストは定性調査なので、参考情報と位置づけています。どちらかといえばユーザが感じたことの「理由」がとても大事ですね。

だから、ユーザーテストの結果が「納得いくものだったら1人でも施策を打つし、納得いかないものだったら打たない」と決めています。課題に対して納得感が持てるかどうかを判断基準にしています。例え10人に「ダメ」と言われても気にしないこともありますね。

freeeのように改善を推し進めていきたい方へメッセージ

freee流になりますが、自分たちの価値基準として「（ユーザとして）マジで価値があるか？」というのを常に問えればよいということがあります。私たちは「ユーザにとって価値があることをやる」ということがとても大事だと思っています。だから「価値がないものはやらない」です。

「それ、まじで価値ある？」

もちろんブラックな手法とかもやろうと思えばできるんですけど、本質的にはユーザの課題解決だけを考えるわけで、少なくとも私たちは近視眼的な手法は選ばないです。

あとはエジソンのように諦めない。それと好奇心旺盛というところですね（笑）。チームや担当に好奇心があれば実績は自然と伸びていくんじゃないかなと思ってます。今回の事例が少しでもお役に立てば嬉しいですね。

まとめ

今回は「こんなに公開していいの？」というぐらいfreeeの改善事例について教えていただきました。インタビュー時に見せていただいたスケジュール表では細かな施策が数日単位で進められていて、現在も高速でトライ＆エラーを繰り返しているということがよくわかりました。

そして、多くの会社にとってうらやましいと思われるのがグロースチームの決裁権。「ある程度のことはチームの裁量で決められる」という言葉が、freee社の改善を支えているのは間違いないようです。

本記事が、サイト改善に励まれている企業様の考え方や取り組みのヒントになれば幸いです。

※グロースチームの考え方や体制については、別サイトの「freee流グロースハック。月間30本もの施策を行う秘訣とは。 | growth hack japan」でご紹介しています。

＼ナイルのサイト改善提案の紹介はこちらから！／