マーケター必見!アプリ継続率を1.3倍にするための品質管理のポイント~オンラインセミナーまとめ~

【作成】2020/04/23  

いつもありがとうございます(^O^)カスタマーサクセス部の田中です!スマートフォンの爆発的な普及に伴い、多くの企業が自社サービスのアプリ開発を進めてきましたが、アプリ継続率(ユーザに継続して使われているかの数値)はいかがでしょうか(・∀・)b

せっかく苦労して作ったからには「完成したから終わり」ではなく、しっかりとユーザに使い続けてもらうことが重要です。2020年2月12日に行われたオンラインセミナーではヤフーのグループ会社であり、アプリのエラーやクラッシュ検知ツールを提供しているFROSK株式会社の仲井さんに「アプリ継続率を1.3倍にするための品質管理のポイント」をお話いただきました。是非ご参考下さい(^O^)♪

収益最大化の為の必須条件!新規獲得効率にもユーザ満足度にも効くアプリの品質管理法

FROSK株式会社の仲井 裕紀と申します。本日は「マーケター必見!アプリ継続率を1.3倍にするための品質管理のポイント」というテーマで、SmartBeatの話をさせていただきます。

FROSK株式会社ではB2D(Business To Developers)をコンセプトに「楽しく便利になるツール」を開発しています。現在はアプリ向けのエラー検知解析ツール「SmartBeat」を運営しておりまして、特に国内においてはたくさん使っていただいているような状況です。

自己紹介

続いて私の自己紹介をさせていただきます。現在はFROSKのプロダクトマネージャーを務めておりまして、たくさんのお客様にヒアリングをするという立場です。「有名アプリはどのようにグロースをされているのか」といったことをお聞きして、それを皆さんに発信していくことを仕事としています。

本日お話する内容の前提として

こちらの導入実績のスライドの右上に書いてあるように、SmartBeatは1日あたりのエラー検出数が3,000万件以上というサービスです。これだけたくさんのデータを収集しているサービスですので、本日はこのビッグデータをもとに解析した結果をお話しします。

アプリの品質とは

そもそもですが、アプリの品質とは一体どういうものなのでしょうか?私はアプリの品質とはいわゆるUXの話で、3つの要素に分けられると思っています。それが、「ビジネスコンテンツや見た目などのUIの部分」「表示のレスポンスや速さという速度の部分」「不具合があるかないか」というものです。

今回はその中でも「いかに仕様通りに作っているか」「落ちたりしないかどうか」といった、不具合に関してお伝えしていきます。

アプリの不具合?

不具合の原因は様々あると思っていまして、例えばクラッシュというものがあります。強制終了でアプリが落ちて、ホーム画面に戻ってしまうという現象。あるいは、UI上うまく表示されていなかったり、なぜかローディングしている最中に固まったりする。さらにはデバイスの大きさなどによって画像サイズが仕様と違う、といったことが起こってしまいます。

ロイヤルユーザを捕まえてくる前に、品質を整えておきましょう

なぜこのように品質を強調するかと言うと、実は「品質がいいアプリは、継続率が1.3倍以上も高い」のです。これに関しては、後ほどしっかり説明します。

有名アプリの真実

実際に有名アプリの例を見ていただくと面白いです。僕も大好きな位置情報系のアプリでは、レビューを見ていただくと☆1ばかりなのです。これは何も作為的に撮ったものではなくて、ただアプリストアを開いたらこの様になっていました。有名なアプリであっても、実は評価は3.5とあまり高くはないです。

一方で今年7周年を迎えたカジュアルゲームのアプリでは、☆5ばかりなのが分かります。評価も4.2ととても高いです。さらに「口コミで広がっていく」という良い循環がありまして、無料ランキングでも8位に入ったことがあります。

このアプリが何をしているかと言うと、実は広告に関してユーザにストレスを与えないための工夫として「広告を見るか見ないかをユーザが選択できる」ようになっているのです。これによってユーザのストレスを極限まで減らすことができます。さらに、不具合に関しても全て修正するという方針となっています。

まとめると「高レベルな品質管理」が必須になると思っているのですが、なかなか全てを直すことは難しいです。そこでここからは、どのように品質管理をしていくかご説明したいと思います。

本日お伝えしたい事

本日お伝えしたいことは次の3つでして、

  • クラッシュ率をKPIにする
  • 設定したKPIをベースに、継続して改善を実施する
  • KPIを基準にしてバージョンごとに確認し、ユーザの満足度を下げない工夫をする

というものです。

ここでいうクラッシュ率とは「全体のユーザの中でクラッシュしている人の割合」を指しています。本日はこれだけを覚えていただきたいです。

そして本日のアジェンダも3つありまして、まずは「効果が出ないのは、クラッシュが原因かも」ということで、なぜクラッシュが影響してくるのかについてお話します。

続いて「〇〇のせいで起きる!クラッシュの真相」と題して、クラッシュや不具合がなぜ起きるのか、という話をさせてもらいます。

最後が「アプリのクラッシュ問題への向き合い方」。有名アプリのレビュー改善やCSサポートをお話して、クラッシュや不具合などの品質問題にどう向き合っているのか見ていきます。

効果が出ないのは、クラッシュが原因かも

まずは「効果が出ないのは、クラッシュが原因かも」ということで、クラッシュがどのような影響及ぼすかお話ししていきます。

クラッシュ、いわゆる不具合というものが、ユーザの環境で実際起きているのか、皆さん気になると思います。

そこで不特定多数のエンドユーザさんにヒアリングをしてみると、実は図のような結果になりました。4割以上の方が週1回以上、さらに週1回未満の方も含めて約8割以上の方が「クラッシュやアプリが落ちた経験がある」と回答しているのです。このことからも「ご自身のアプリが落ちません」という話は間違いだといつもご説明しています。

クラッシュがアプリに及ぼす影響

アプリの運営において、やはり不具合やクラッシュにはネガティブな影響がたくさんあります。まず考えられるのは当たり前ですが「ユーザが離脱してしまう」ということです。

実際に「アプリがクラッシュしたことで、そのアプリを使わなくなったことがありますか?」とエンドユーザに聞くと、7割以上の方が「クラッシュしたせいで使わなくなった」と答えています。

一方で水色のグラフは「クラッシュして使わなくなった経験があまりない」という方ですが、3割ほどしかいらっしゃいません。ほとんどの方が、アプリがクラッシュすると使わなくなってしまうのです。

これは先ほど申し上げた、継続率、特に長期の継続率にも効いてきます。アプリのクラッシュの経験あり・なしをそれぞれ継続率としてグラフを作ってみました。

これは30日後の継続率を出しているグラフなのですが、右端の30日後の継続率は約1.3倍も違ってきます。このことからも、愛されるアプリ・長期に使っていただけるアプリを作るためには「アプリが落ちないこと」が長期的に効いてくるとご理解いただけると思います。

さらに新規ユーザに及ぼす影響というところでは「新規ダウンロード効率が悪化してしまう」可能性もあります。

クラッシュしてしまうと、新規ユーザの獲得効率が下がってしまうわけです。これは当たり前の話で、クラッシュするとみんながレーティングを下げて「すぐ落ちる」と書き込む。最初にご説明した位置情報型ゲームのように、みんな星1をつけてしまいます。

そうすると新規ユーザは「レーティングが低いからこのアプリは入れない」と感じてしまうのです。

また、怒ってレビューを荒らす方がいる一方で、ヘビーユーザの方であっても親切心からアプリのレビュー欄に「アプリが落ちますので直してください」といったことを書いてしまいます。

連絡するものがレビューのボードしかないわけです。他に伝える方法がないので書かざるを得なくなり、不本意なのにレビューが荒れてしまうといったことも実は起きています。

これによってどのような影響が出るか、実際にアプリストアで一般アプリを調べてみました。アプリのストア平均は約「3.5」ですが、レビューに「落ちる」を含むアプリは途端に「1.9」まで落ちてしまいます。

一般的にダウンロード効率でみると「3.5」と「1.9」の差は実は3倍以上も違います。したがって「落ちる」というレビューを少なくして点数を上げていくことで、CPAやCPIを3倍も改善することができるのです。

ちなみに参考までなのですが、Google Playには「Android Excellence」という仕組みがあり「クラッシュの回数をもとに、ランキングの順位や検索の順位を下げる」と公表されています。

さらに一部の有名アプリでは、クラッシュ数が多くなった場合にGoogleからリリース停止の通知が来ることもあります。プラットフォーム側もクラッシュや不具合に関しては手を打っているわけです。

クラッシュがアプリに及ぼす影響:まとめ

ここまでをまとめると、クラッシュを放置するアプリの運営は、穴の開いたバケツに水を貯めるようなものかなと思います。

ユーザである水をどんどん流されるのですが、ダウンロード効率が悪いのでバケツから漏れてしまいますし、捕まえているユーザも離脱してしまう。このような状況です。

さらにこの重ね合わせによって、PDCAが回せなくなることもあります。例えば「新規アプリをリリースしたものの、KPIが伸びない」ということは往々にしてあると思います。しかしその原因が今回出したUI/UXにあるのか、あるいはたまたま品質が悪かったからなのかが分からない。

継続率や新規獲得効率が悪い理由を切り分けられないと、次の一手が定量的に打てなくなるのです。

まとめると、クラッシュが発生すると、以下のようなことが起こってしまいます。

クラッシュが及ぼす影響:アプリだけの話ではない

また、アプリの体験によって、自社の「リアル顧客」を失ってしまう可能性もあります。例えば秋葉原の電気街で電気屋のアプリを開いたときに、そのアプリが落ちてしまったとします。その場合もう面倒くさくなって、目の前の電気屋に入りますよね。

つまり店舗でお金を使うお客さんであっても、実はそのアプリの体験がお金を払うか払わないかの判断に直結するのです。そうなるとリアルのお客さんをアプリによって失いかねませんし、販促費用が無駄になる可能性もあります。

先ほど申し上げたように、アプリの不具合が起きたりクラッシュが起きたりすると、既存ユーザは離脱し新規ダウンロード効率も悪くなってしまう。せっかくかけたコストや時間、お金が無駄になる可能性もあるというわけです。

ここまでの話で、アプリのグロースや成長にクラッシュ・不具合が影響しているとご理解いただけたかと思います。

〇〇のせいで起きる!避けられないクラッシュの真相

それでは次に「なぜクラッシュが起きるのか」「開発会社に任せきりではだめなのか」ということに関してお話しします。

クラッシュが起きてしまう要因としては、なかなか「全ての環境でアプリのデバッグやテストをできない」ということがあります。

こちらはAndroid端末の機種別シェアのグラフですが、上位20端末で全体の3分の1以下となっています。そもそも20端末でテストをするのも大変ですし、これを8割まで持っていこうとすると、200端末ほどテストしなければいけません。

さらにOSのバージョンと組み合わせると、2015年時点で24,000通りもあるのです。このことからも、事前にAndroid端末を集めてテストをするというのは、無理な話かなと思っています。

一方でiOSの場合は、アプリリリース後もユーザの環境がどんどん変わっていきます。こちらはiOS 11が出たタイミングからの普及率のグラフですが、青色のiOS 11の普及率を見ると、およそ10日前後で50%に到達していますね。

【参考】クラッシュにつながるOSアップデート事例

実際アップデートによって、クラッシュや不具合はたくさん出ています。例えばOSの仕様変更で不具合が出たり、APIの仕様変更であったり、あるいはOSの挙動が変更になったりもします。

iOS 13では特に多かったのですが、OS自体の不具合もあります。このようにクラッシュがたくさん出ていました。

さらにはプラットフォームのせいだけでなく、クラッシュや不具合は正しく状況が把握しづらいものでもあります。よくある例としましては、クラッシュした瞬間にエラーが取れればいいのですが、アプリが落ちるだけだとなかなか難しいです。

一旦は保存しておいて次回起動時に取ろうとしても、先ほど申し上げたようにクラッシュによってユーザが離脱する可能性があります。こうなると、本当のクラッシュの数が計測できなくなるのです。

さらにエラー急増時にはユーザの10倍以上も発生するため、そもそも自社でエラーを取得するのはコストが合わないのではないかと考えています。

みなさん何かしらのツールを利用されているかもしれませんが、私は一般的なツールでは不十分かなと思っています。まずAndroidに載せると使えるGoogle Developers Console。正直これだけでは論外というほど、ユーザの環境とかけ離れています。

例えばエラーの検出数で言うと、Google Developers Consoleに比べて「SmartBeat」を使ったユーザの環境だと約80倍エラーが発生しています。またエラーの種類数に関しては、約11倍異なっています。

したがって「Google Developers Consoleであまりエラーが出ていないから大丈夫」というのは論外かなと思っています。

さらに、G社のツールでもよくあるのですが

  • ユーザがクラッシュ後に離脱してしまった場合
  • Androidのメモリリーク
  • クラッシュのグルーピングが適切ではない場合

もエラーを検知できないことがあります。

さらに何かしらクラッシュが起きていると分かっても、情報量が足りず直せないといったことも起こりえます。

例えば某有名コミュニケーションツールのレビューを見てみると「知り合いかもをタップしたら固まって使えません」と書いてあります。しかしそれをどう直せばいいのかというのは、エンジニアから見てもなかなかわからないことが多いです。

また、カスタマーサポートの情報には「カートに入れるというボタンを押したら、画面が固まったあとに落ちました」といったものも多いと思います。しかしこの場合も、端末依存の話をされているのか、OSバージョン依存の話をされているのかなど、たくさんのパターンによって回答内容が変わってきます。

そもそもユーザの使用環境が特殊だったり、ユーザが勘違いしていたりするかもしれません。この情報だけでは原因が特定できないので、結局答えられないという状況になってしまいます。

そして情報はカスタマーサポートの方からユーザ担当、アプリの運営担当、開発担当へと伝言ゲームのように伝えられます。したがって一番詳細な情報が必要なアプリの開発担当に与える情報が薄くなりがちなのです。

開発担当はスタックトレースというソースコードレベルの発生箇所が必要なのに、それがわからないということが発生してしまう。

クラッシュの原因はプラットフォームのせいでもありますし、クラッシュ自体が取得しづらくて内容がわかりにくい、さらに直しづらいものということがご理解いただけたかなと思います。

アプリのクラッシュ問題への向き合い方

それではここからは「有名アプリがクラッシュ問題にどう向き合い、グロースしているのか」という話を、事例を交えつつお話していきます。

継続してアプリを運営する為の品質問題への向き合い方

グロースしているアプリに色々とヒアリングをさせていただくと、図にある4ステップに集約されてくることがわかってきます。

  • 自社のアプリの品質を正確に把握する
  • クラッシュ率をKPIとして管理する
  • 影響範囲の大きい不具合から効率的に修正する
  • 品質問題の影響範囲を最小限に留める工夫をする

というものです。

【事例】不具合を「社内で気づく」に

まずは「自社のアプリの品質を正確に把握する」というところです。つまり、どれだけエラーが出ているか・クラッシュしているのかを正確に把握してくださいという話です。

それを実際に行っている会社の例をお話しします。こちらは弊社のエラー検知ツールを使っていただいた会社です。もともとはお問い合わせや社員の端末で気づいたエラーでしたが、この不具合情報は、カスタマーサポート担当→マーケティング担当→IT担当→開発担当と伝言ゲームのようにやり取りされていました。そして少ない情報で影響範囲を判断し、対応されていたという状況でした。

そこからSmartBeatのような何かしらの検知ツールを使っていただくことで、クラッシュに気づきます。開発チームやユーザに相対するカスタマー担当が同じ画面を見るので、これを直す・直さない、直している・直していないというのがすぐにわかるようになりました。

さらに、発生数や離脱するといった影響範囲を定量的に把握できるので、ジャッジのスピードや精度が上がっていきました。

【事例】日常的に品質をモニタリング

次がECアプリの事例です。この会社では、社内のチャットにAPI連携して品質をモニタリングしています。つまり毎日品質の情報が来るわけです。

ですからそれをベースに判断のスピードを速めています。例えば「全バージョンの横断のクラッシュ率」「アプリバージョン別のクラッシュ率」「日ごとのクラッシュ率」「バージョンごとの詳細分析」などを連携されているので、品質や改善の必要性がその場で判断されています。そしてその社内チャットを見て、次にエンジニアが動く・動かないということも決定されているのです。

このように自社のアプリの品質を「速く・正確に・みんなで見る」ことで、判断スピードをどんどん上げて、直す・直さないという判断をアクティブに決めていただくことが重要なのかなと思います。

クラッシュ率をKPIとして管理

次が「クラッシュ率をKPIとして管理する」という話です。なぜここまでクラッシュ率を強調するかと言うと、実は落ちるレビューとクラッシュ率には相関関係があります。

こちらのグラフを見ていただくと「落ちる」というレビューがほぼないアプリの平均クラッシュ率は1.5%程度です。

一方で「落ちる」というレビューの割合が1%以上のアプリは、クラッシュ率が7.26%もあります。このことからも「100人に1人しか落ちません」というような状況を作っていただくことが重要になってくるのです。

例としましては、ゲームアプリの場合は2~3%程度。ゲームアプリ以外ですと0.5~1%程度。おそらくゲームアプリ以外の方が多いと思うので、この1%程度を目指していただけるといいのかなと思います。

【事例】クラッシュ率をKPIとして徹底的に改善

さらにYahoo!天気の事例を見てみると、業界平均クラッシュ率と比べても低かった0.53%から、さらに3分の1の0.18%まで下がっています。1,000人に1人しかクラッシュしない、そんな極限まで実は改善されています。

【事例】大規模アプリでは、品質低下を未然にキャッチ

続いて大規模ポータルアプリの例ですが、この会社は毎回段階リリースをしています。ユーザの割合が1~2%の段階で新しいバージョンのクラッシュ率が1%を超えるような状況になると、そのバージョンのリリースを止めるのです。そして修正してからリリースする。いかにレビューが荒れないかをキーにして、改善しているのです。

【事例】急激な品質の変化に注目!

こちらのゲームアプリの会社は、クラッシュ率やクラッシュの影響ユーザ数が急増するかどうかをとても見られています。例えばアプリ更新してクラッシュが多発していないか。アプリ更新をしない場合でも、外部からのダウンロードでアセットが増えてクラッシュしていないか。そしてやはり常に見られているのは、クラッシュ率が1%以下になるかということです。

その結果としてこのアプリのクラッシュ率は、iOSが0.07%・Androidが0.36%。点数も4.2や4.3と大変いい値になっています。

ということで、「クラッシュ率をKPIとして管理して1%以下を目指す」ことが重要だとご理解いただけたでしょうか?では続いて、どう直していけば早くクラッシュ率が1%以下になるのかご説明します。

影響範囲の大きい不具合から効率的に修正

結論から言うと「影響範囲の大きい不具合から効率的に直す」ということです。一般的に不具合にかけられるリソースは限られると思うので、その中でどの不具合から改善するかというのが重要かなと思います。

しかし実際によくある不具合の優先順位は「発見した順」「顧客からの問い合わせが多い順」「なんとなく重要そうな順」「偉い人が発見したものを優先」といったものが多いです。

これではユーザドリブンや定量的でないので、直したとしてもユーザの不満はなかなかおさまりません。そうではなくて、もっと合理的に全体ユーザのことを考えた、不具合対応の優先順位の付け方をしてください。

まずは発生回数の多い順、あるいは影響ユーザ数の多い不具合から直す。もしくは、急増していて今後まずくなりそうだから早めに直しておく。というように、定量的に優先順位を決めていただくことで、少ない修正工数でユーザの不満を大幅に削減できると思っています。

【事例】影響範囲の大きい不具合から効率的に修正した結果

こちらはO2Oのアプリですが、1〜2ヶ月の工数を品質改善にあてていただいた結果、たった3ヶ月で3%あったクラッシュ率が0.5%に落ちました。したがって3ヶ月頑張っていただくと、実は1%まで落ちるということが事例としてあります。

クラッシュは基本的に直していただければと思うのですが、中には直りきらないものもあります。それをどうするのかということを、最後お話ししていきます。

【事例】品質問題の影響範囲を最小限に留める工夫

まずはクラッシュ率に応じてレビュー依頼を管理する。例えばクラッシュ率が高いとき、つまり品質が悪いバージョンはレビュー依頼を出してはいけません。「この前落ちたから☆1かな」といったように、落ちたレビューしか書いてくれなくなります。

したがってクラッシュ率が低い、品質が良いときだけレビュー依頼を出す。「便利だから☆5かな」といったアプリのレビューをもらうようにしてください。

【事例】品質問題の影響範囲を最小限に留める工夫

さらに不具合に関しては、こちらからアナウンスしてしまうことも1つの手です。先ほども申し上げたように、落ちるという状況を「教えてあげなきゃ」と親切心でレビューに書いてしまう人がいます。

そこで、事前に「不具合が出ています」とアナウンスしてみてください。そうすることでユーザは「気づいているなら書かなくていいや」と思うので、レビューの低評価を防ぐことができるのです。

【事例】品質問題の影響範囲を最小限に留める工夫

少し複雑ですがお問い合わせについても、ユーザの問題と不具合を紐付けて確認いただくことが重要だと思っています。よくある従来の例では「アプリが落ちます」と言われても、どのエラーの話をしているのかわからない。「確認します」とお客さんに伝えても、その後返答することが出来ない。お客さんはどうなったのかがわからないので、結局不満は解消されないということがよく起きます。

一方で「落ちるという不具合」と「ユーザのIDや識別子」を連携しておくと、その不具合が直っているのか今後直すのか、あるいはバージョンアップで直るのかという話ができます。問い合わせというアクティブな行動をしてくれたお客さんの不満をさらに軽減することが可能なのです。

【再掲】品質改善の正しいサイクル

再掲になりますが、この図の4ステップをぐるぐる回していくことが重要でして、まずは実際のアプリの品質を正確に把握する。

次にクラッシュ率をKPIとして管理して、1%以下を目指していく。不具合に関しては、影響範囲の大きい不具合から効率的に直す。

そして最後に直りきらない不具合に関しては、影響範囲を留めるような工夫をする。この4ステップを回してください。

ここまではご理解いただけたかと思いますが、重要なのは「スピード」です。

【参考】人気アプリのアップデート頻度(2018年1月〜3月)

実際に有名アプリがどれほどのスピードでアップデートしているかを見たいのですが、こちらは2018年の1月から3月のデータになります。下のほうのゲームアプリでは、不具合を含むものは12回もあります。3ヶ月で12回ですから、約週1回という高速で改善サイクルを回すことが重要になってきています。

【おまけ】効率的にアプリの品質問題と向き合う為には

最後におまけとして、弊社のツール「SmartBeat」を活用することで効率化が可能です、ということをご紹介させていただければなと思います。

【おまけ】SmartBeatとは

SmartBeatで一番お伝えしたいのがリアルタイム検知です。クラッシュが起きた瞬間にエラーを取得するので、本当のクラッシュ数・不具合数をご理解いただくことが可能になってきます。

実は今日のために「落ちるアプリ」をご用意してきましたので、少しだけデモをしてみます。ポチポチと動かしていると、固まって落ちてしまいました。これを実際SmartBeatの画面で見てみますと、スライドのようにしっかりエラーが取れています。先ほどアプリを再起動していないのに取れました。

そして中を見ていただくと、スタックトレースと言われるエンジニアが必要なソースコードレベルの情報もたくさん出ています。さらに落ちた直前の画面のスクリーンショットや端末情報も見られます。したがって非エンジニアの方であっても「どこの画面で落ちたのか」「何が原因なのか」「どのような端末なのか」をご理解いただくことができるのです。

まとめますとSmartBeatは、リアルタイム検知で圧倒的な検知数を誇っており、豊富なエラーの情報で修正工数を大幅に削減することができます。さらにスクリーンショットを撮っていますので、非エンジニアの方でも「どこの画面で落ちたのか」一目でご理解いただけます。

さらに、アプリのバージョンごとの品質の可視化も自動で行っています。例えば図の一番左のバージョンは、クラッシュ率が0.51%なので品質が良かった。一番右のバージョンは、クラッシュ率2.21%なので品質が悪かった。ということが一目で理解できるのです。また、どこまでサポートすればいいのか議論になると思いますが、OSの主要ランキングやクラッシュランキング等も表示していますので、定量的にジャッジすることが可能になってきます。

さらにこちらは業界初なのですが、iOS・Android両プラットフォームのメモリリークの発生回数をモニタリングすることができます。例えばアプリのアップデートを伴わないような、外部からダウンロードしなければいけない現象。これはメモリリークが起きやすいです。そのような場合にも、どのぐらい落ちているのかをご確認いただくことができます。

対応しているプラットフォームとしましては、iOS・Android、あるいはゲームエンジン系に関してはほぼ対応しています。まだアプリがない方ですと、まずウェブサービスから始める方も多いですが、お客さんが使うブラウザ上のエラーも把握することが可能です。

導入実績

導入実績としましては国内・国外合わせて2,500アプリにご利用いただいておりまして、月間アクティブユーザ数・エンドユーザ数は2億人ほど使っているようなサービスです。ご利用企業様はヤフーを始め、大手ゲーム会社様やO2O系のアプリ様、金融系のアプリ様などにご利用いただいています。

以上になります。ありがとうございました。

質疑応答

Q.担当するアプリでクラッシュはあまり起きていないと思っていたのですが、一般的にSmartBeatを利用する段階でどれほどクラッシュしているものでしょうか?

実際にそう考えている方は多いです。しかし実際にSmartBeatを入れていただくと、クラッシュはかなり起きています。最初にクラッシュ率は1%以下を目指すとお話しましたが、実際にSmartBeatを入れて出てくるクラッシュ率は約10%です。20%という数値も当たり前のように出てきます。そこからどのように直す・直さないかというのを、いつも考えていただいていますね。

Q.クラッシュ率が1%ということは、例えば100人使っていたら1人がクラッシュするという意味でしょうか?

そうです。母数がユニークユーザ数で、分子がクラッシュ影響ユーザ数となっています。

Q.SmartBeatを入れる際には、SDKを導入するのでしょうか?

そうです。SDK(software development kit…ソフトウェア開発キット)を導入してアプリに組み込んでいただく形になりますね。したがってエンジニアの工数を確保していただく必要がございます。ただ弊社の営業担当でさえも導入できるほど簡単になっているので、10分程度で導入いただけるかなと思っています。

Q.そのSDKはどれほど重いでしょうか?

動作に関しては本当に軽くて、CPU利用率は1%増えるかどうかというレベルです。サイズも数KB程度ですので、現代のアプリにおいてはすごく小さなものかなとは思っています。

Q.結果的にそのSDKでエラーが起きたりはしませんか?

そうですね、それは気にされると思います。もちろんそういうことが絶対に起きないように気をつけて開発していますので、基本的には起きないです。十分テストした上でご提供しております。実際iOSに関しては全端末テストしていますので、おそらくほとんど起きないのではないかなと思います。

Q.軽微なクラッシュから何度も落ちるクラッシュといったように、1%の中にも重みが違うところがあると思います。そのときに何か判定したり、違いをつけたりしていますか?

違いに関してはそこまでつけていないですが、やはり急増しているエラーはクリティカルです。起動できない・プッシュでいきなり落ちるなど、急増しているものは表示しているので、何を直すべきかというのはご理解いただけると思います。

そして、やはりクラッシュ率1%以下というのを基準にしていただくことが重要です。どの画面で落ちるかは関係なく、ユーザさんには何かしら怒りが溜まってしまいます。いくら軽度なものであっても、たくさん起きているのであれば直していただくことが重要かなと思います。

Q.不具合があるときに事前にアナウンスをすると、報告レビューがなくなるという話が面白いと思いました。アナウンスはどのようにしているのでしょうか?

例えばゲームアプリでよくあるのですが、ログイン画面で現在わかっている不具合などが一覧に出ていますよね。このようにご自身でわかっている不具合を出しておくと、報告してくれるユーザさんは熱心なユーザさんなので理解してくれます。

Q.SmartBeatでは落ちる直前のキャプチャー画像が撮れるという話でしたが、私のアプリでは応募時に氏名や電話番号などの個人情報が発生します。その部分のスクショは撮りたくないのですが、マスキング等はできるのでしょうか?

弊社としても対応はしておりまして、画面単位でスクショを撮らないという設定をしていただくことが可能です。何を入力されるかがわからないので、マスキングではなく画面単位としています。

Q.4つのPDCAの中で、3つ目に「影響範囲の大きいところから直す」とあったかと思います。影響範囲が大きい課題かどうかは、先程のSmartBeatのUIですとどのように出てくるのでしょうか?

これは弊社の強みの1つなのですが、原因別にエラーをグルーピングしています。同じエラーがどれだけ出ているかがわかるので、例えば発生回数が多いエラーが一番上位に出るようにしています。

Q.エラーの原因というのは、御社の中で規定されている原因群があってそれに基づいて分類されているのでしょうか?

ソースコードレベルのスタックトレースを使って、エラー名やエラーの発生箇所をベースにグルーピングしています。アプリごとに実装方法も異なってくるので、うまくいろいろなアプリに対応するためにそのようにしています。

Q.エンジニアでない方から開発サイドに導入をプッシュするケースが多いのでしょうか?

多いですね。それがほとんどだと思います。 もちろんエンジニアの方から利用したいと話をいただくこともありますが、エンジニアの方は基本的に自分がしっかりできていると思っています。

そこに関してプライドもありますし、無理強いしなくていいと思われています。逆にマーケットの方も状況を知って、ワンチームで進めていくことが重要になるので、その中でマーケットの方からお声掛けいただくことが多いです。

Q.開発を外注した場合、外注先の会社でも使ってもらえますか?

もちろん使っていただけます。アカウントに関しては無制限に増やしていただくことが可能ですので、他のドメインの方をどんどん増やしていただいても問題ありません。

以上です♪わかりやすくお話しいただいた仲井さん、ご質問をいただいた皆様、ありがとうございました♪

仲井さんも「品質改善の正しいサイクルを回すスピードが重要」であるとお話しされておりましたが、弊社のアジャイルUXリサーチでもスピーディなご支援をしております♪ご質問はお気軽にどうぞ♪

田中比那子

株式会社ポップインサイトにて、北海道のリモート環境で、Expressサービスのカスタマーサクセスを担当。Webクリエイター上級資格あり。



アジャイルUXリサーチを始めよう

「UX改善したいけど人がいない」「CVR改善が伸び悩む」「社内で育てられない」というチームに最適!ユーザ視点の高速PDCAでビジネス成果を創出!


UXリサーチを学ぶ!Youtubeチャンネル

国内外の最新UXリサーチの事例やノウハウのオンラインセミナーをYoutubeチャンネルでどんどん発信!ぜひチャンネル登録してね!