こんにちは、私はスマートフォンアプリの開発を担当しています。本記事では、スマートフォン向けアプリ開発現場で日々実践している「市場品質の監視」について詳しくご紹介します。

1. 前提

製品やサービスの開発に「不具合」は付きものです。私たちのアプリ開発においても不具合修正は常に発生しており、市場へのリリース前にできる限り修正しています。しかし、全ての不具合を必ずしも事前に検出できないこともあり、市場へのリリース後にもユーザーの手元で新たな問題が発覚する場合があります。

そのため、特にユーザー体験に大きな影響を及ぼす重大な不具合が万が一市場に流出してしまった場合、いかに迅速に検知・対処できるかが重要な課題となります。そこで弊アプリ開発現場では、市場品質の監視に主に以下のGoogle系ツールを活用しています。

Firebase Crashlytics firebase.google.com
Firebase Performance Monitoring firebase.google.com
Google Analytics for Firebase firebase.google.com

それぞれの役割や運用方法について、以下で解説いたします。

2. 各ツールの役割、運用方法

2.1 Firebase Crashlytics

【役割】
Firebase CrashlyticsはGoogleが提供する、スマートフォンアプリのクラッシュ（強制終了）やANR（応答なし）を自動収集し、集計・分析するためのツールです。
アプリの市場品質監視・不具合解析に欠かせない存在です。本ツールを通して、クラッシュやANRが発生した際のStackTraceやアプリログを確認でき、解析することが可能です。場合によってはIssueを調べる際の手がかりとします。

【弊アプリにおける運用方法】 まずはじめに、弊アプリはFlutterを中心に構成しており、標準設定のままでは意図した例外が拾えなかったため、Flutter構成部分でのExceptionは自動集計ができない、という課題がありました。色々と調査しましたが残念ながら解決策は見つけられず、そこで手動でcatch & RecordError処理を追加しました。そうすることでCrashlytics上でもFlutter構成部分の例外イベントを集計し、クラッシュやANRと同様に監視できる仕組みを実現しています。

この例外イベントをRecordErrorするにあたり、「起動処理」「ミッション機能」「クーポン機能」などのどの機能・処理で発生したかの情報も付与するようにしています。Crashlyticsのアプリログと組み合わせることで、より詳細に不具合の傾向を把握できるようになりました。

この運用により、実際にユーザーの手元で発生している不具合の内容や発生数をリアルタイムで可視化できます。どの機能で多く発生しているかなどの影響範囲や重要度の分析も可能としています。

2.2 Firebase Performance Monitoring

【役割】
Firebase Performance Monitoringは、アプリの起動速度やネットワークリクエストのレスポンス速度／成功率など、ユーザー体験に直結する様々なパフォーマンス指標を監視できるツールです。

【弊アプリにおける運用方法】
弊アプリ開発現場でもリリース前に社内の複数端末でパフォーマンス観点でも動作確認を実施していますが、実際のユーザー環境は通信環境や端末の性能、メモリのひっ迫具合やOSバージョンなどが多様で、アプリ開発工程におけるテストと市場での実際の動作条件に差がどうしても存在しています。

そこで、アプリリリース後は特にですが、Performance Monitoringで各種パフォーマンス指標を継続監視しています。過去1週間の平均と比較などをしながら、もし予期しない遅延やレスポンス異常等が観測された場合は速やかに分析・対応しています。

なお起動速度に関しては、弊アプリでは標準指標ではなく、CustomTraceで我々が考える「起動時間」を計測しています。（アプリによっては標準指標だけだと使いにくいこともあると思います。）

2.3 Google Analytics for Firebase

【役割】
Google Analytics for FirebaseはWebやアプリで利用可能なアクセス解析ツールです。弊アプリ開発においてはアプリ内でのアクセス解析ツールとして、ユーザーの操作ログを細かく集計・分析できます。

【弊アプリにおける運用方法】
どの画面が利用されているか、どのボタンがどの程度押下されているかなど、さまざまなイベント（操作ログ・エラーログ）を監視しています。

市場品質の観測・監視という点では、どのエラー画面がどれくらい発生しているかなどの異常系イベントに力を入れています。標準機能でもベイズ推定をベースとした異常なイベントの増減をメールやSlackで通知することができます。弊アプリ開発においてはGoogle App Scriptを組み合わせて、アラート条件や通知内容をより柔軟・詳細に制御する独自監視も導入しています。

3. 実際の運用体制

弊アプリ開発現場では、各種ツールによる自動監視・アラート運用をベースに、週次で市場の品質状況の定期確認を数名で実施しています。また、新バージョンのマーケットアップ後の数日間は朝夕のタイミングで前述のツールにて問題ないかのチェックを行っています。（もちろん、事前に設定しているアラート機能が発行された場合はその時点で解析にあたります。）ユーザーの端末におけるアプリアップデートは主に夜間の自動アップデートとなります。そのため、リリース後すぐに問題が発生するわけではないことを留意して監視を行っています。

こうした体制によって、重大な市場不具合を早期に発見・対応できる運用サイクルの確立を目指しています。

また、各種ストアのコメントなども毎日出力して確認しており、各種ツールでの集計と同様の傾向になっているか確認しています。もし、ストアコメントと傾向が違うのであればツールでの集計が誤ってしまっている可能性もあるためです。

4. まとめ

スマートフォン向けアプリ開発においては、不具合の発生をゼロにすることは極めて困難です。
リリース前の入念なテスト・修正を行っても、ユーザー環境で新たな問題が発生してしまうことはあります。そのため、リリース後もできる限り迅速に不具合を検知し、影響範囲や重要度の把握、早期対応につなげる運用体制が不可欠となっています。
弊アプリ開発では上述したツールを利用しており、これらの取り組みを利用しながらユーザー体験向上に向けて市場品質監視体制の実施と改善を継続していきます。最後に、今後の展望として特にCrashlyticsにおいては解析のための情報が追加できないかを引き続き検討していきます。