Crashlytics を最大限に活用する 7 つのヒント
2017年10月11日水曜日
この記事は プロダクト マネージャー、Jason St. Pierre による The Firebase Blog の記事 "7 tips for getting the most out of Crashlytics" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
長年にわたり、デベロッパーやアプリチームは Crashlytics を活用してアプリの安定性を向上させてきました。おそらく、皆さんは既に Crashlytics UI の主な部分をご存知でしょう。クラッシュのないユーザーやセッション、問題リストを一日に何度も見ている方もいるかもしれません（皆さんだけではありません！）。
本投稿では、Crashlytics をさらに価値あるものにするプロフェッショナル向けの 7 つのヒントを紹介します。Crashlytics は新しい Fabric ダッシュボードの一部になっているので、問題のトラッキング、優先順位付け、解決をすばやく行うことができます。
クラッシュ インサイトは、7 月にベータ版を卒業して正式にリリースされました。クラッシュ インサイトでは、クラッシュに至った状況やその 理由 が明らかにされるため、クラッシュについて深く理解できるようになります。問題リストの問題に緑色の稲妻マークが表示されている場合、それをクリックすると考えられる根本原因や、トラブルシューティングに活用できるリソースが表示されます。
クラッシュのデバッグやトラブルシューティングは、時間がかかる困難な作業です。私たち自身もデベロッパーなので、厄介な問題が解決でき次第、ログアウトしてもっとおもしろいタスク（アプリの新機能の構築など）に戻りたいという気持ちはよく理解できます。しかし、Crashlytics で問題を「クローズ」することは忘れないようにしましょう！問題を正式にクローズすると、リグレッション検知によって問題のライフサイクルを詳しく見ることができるようになります。リグレッション検知は、以前にクローズした問題が新しいバージョンのアプリで再発した際に警告してくれます。これは、何かがうまくいっておらず、注意が必要であることを示す兆候になります。
一般的には、リグレッションを検知するために問題をクローズする必要がありますが、問題をクローズして ロックする ことで、修正する予定のない問題や優先度の低い問題について 通知されない ようにすることができます。影響が少なくほとんど発生しないバグや、コードには問題がなく自分たちでは制御できない問題などがこれに該当します。そういった問題を非表示にして Crashlytics チャートを整理するには、問題をクローズした後にロックします。この「無視機能」を利用すると、安定性のページをカスタマイズして、対応が必要となる重要な情報のみを表面化させることができます。
同じバージョンに複数のビルドが存在する場合もあるでしょう。そういったビルド バージョンは同じ番号で始まりますが、末尾には一意の識別子が含まれています（たとえば、9.12 (123)、9.12 (124)、9.12 (125) など）。これらすべてのバージョンのクラッシュを確認したい場合は、検索バーにビルド バージョンを手動で入力する代わりに、ワイルドカードを使って同じバージョンをグループ化すると、すばやく確認することができます。これを行うには、バージョン プレフィックスの末尾に星印（アスタリスク）を追加します（例: 9.12*）。たとえば、Android で APK の分割を行っている場合、ワイルドカード ビルドを指定すると複数のビルドのクラッシュをすばやく表示できます。
デベロッパーの皆さんは、毎日いくつかのビルドをデプロイしていることでしょう。開発 チームで扱うビルドの数が、数十や数百におよぶこともあります。モバイルチームのスピードや反応の早さには目を見張るものがあります。しかし、それには良くない側面もあります。たくさんのビルドから、特に重要な 1 つ（あるいは 2 つや 3 つなど）のビルドを探し出すのは時間の無駄です。そのため、Crashlytics では、重要なビルドを「固定」してビルドリストの一番上に表示できるようになっています。ビルドを固定すると、必要な間だけ、重要なビルドを一番目立つようにして見つけやすくすることができます。さらに、この機能を使うと、チームのメンバーのビルドリストでも自動的に一番上に表示されるようになるので、チームのメンバーと協調してクラッシュの修正がしやすくなります。
安定性の問題は、いつ発生するかわかりません。皆さんがワークステーションから離れているときに起きることもあるでしょう。Crashlytics は、スマートにビルドを監視し、1 つの問題が統計的にクラッシュの大多数を占めているかどうかを確認してくれます。そして、それに該当する場合は、ベロシティ アラートでアプリのホット フィックスが必要になることをお知らせします。ベロシティ アラートは、問題の重要度や影響が急激に増加した際にクラッシュ レポーティング ダッシュボードに表示されるプロアクティブなアラートです。メールによる通知も行われますが、ぜひ Fabric モバイルアプリもインストールしておいてください。プッシュ通知が送信されるので、外出中でも最新情報が受け取れるようになります。ベロシティ アラートには常に注意してください。そうすれば、どこにいても重要なクラッシュを見逃すことはなくなります！
Crashlytics SDK を使うと、ログ、キー、non-fatal、カスタム イベントを診断できます。これによって、クラッシュが発生した理由や、何がクラッシュにつながったかについての詳しい情報を得ることができます。ただし、ログ、キー、non-fatal、カスタム イベントは、別々の事象をトラッキングするためにデザインされたものです。そこで、これらの適切な利用法をご紹介します。
ログ: ログを分析すると、ユーザーがクラッシュ前に何をしていたかについて重要な情報を得ることができます。たとえば、ユーザーの行動（例: ユーザーがダウンロード画面を開く、ダウンロード ボタンをクリックする）や、行った操作の詳細（例: イメージのダウンロードやダウンロード元）などが考えられます。基本的に、ログはユーザーの断片的な操作記録であり、クラッシュ前に何が起きたかを示すものです。クラッシュが発生した際には、ログの内容が取得されてクラッシュに添付されるので、デバッグの際に便利です。iOS、Android、Unity の各アプリでログの診断を行う手順については、こちらをご覧ください。
キー: キーは、ある時点の情報のスナップショットであるキーと値のペアを示します。時系列に操作を記録するログとは違い、キーは検出された最新の値を記録するもので、時間とともに変化します。キーは上書きされるため、検出された最新の値のみを知りたい場合に使用するようにします。たとえば、ユーザーが完了した最後のレベル、ウィザードで完了した最後の手順、最後に表示したイメージ、最後に行ったカスタム設定などをトラッキングするために利用します。キーは、情報の要約にも活用できます。たとえば、ログが「ログイン、リトライ、リトライ、リトライ」となっている場合、キーを使うと「リトライ: 3 回」と表示することができます。iOS、Android、Unity の各アプリでキーを設定する手順については、こちらをご覧ください。
non-fatal: Crashlytics は自動的にクラッシュを記録しますが、致命的ではない（non-fatal）イベントも記録することができます。non-fatal イベントとは、エラーが発生したものの、アプリのクラッシュには至らなかったイベントです。
たとえば、アプリにディープリンクが存在し、それを開けなかった場合などが non-fatal を記録するシナリオに当たります。リンクの破損によってアプリがクラッシュするとは限りませんが、トラッキングしてリンクを修正することが望ましいでしょう。non-fatal を記録すべきでないシナリオは、ネットワーク エラーによってイメージの読み込みが失敗した場合など、対応できないものや特殊なケースではないものです。
non-fatal イベントは、スタック トレースを取得して優先順位付けやトラブルシューティングを行いたい問題に対して設定するようにします。
単に何かが発生した回数を数えたい（そしてスタック トレースは必要ない）場合は、カスタム イベントを使うことを推奨します。
ここで紹介した 7 つのヒントは、Crashlytics を最大限に活用するために役立つはずです。Crashlytics を使ってアプリの安定性を向上させることができるプロフェッショナル向けのヒントを他にも知っているという方は、ぜひ私たちにツイートしてください！皆さんが Crashlytics をどのように活用しているのか、ご報告をお待ちしています。
Reviewed by Khanh LeViet - Developer Relations Team
長年にわたり、デベロッパーやアプリチームは Crashlytics を活用してアプリの安定性を向上させてきました。おそらく、皆さんは既に Crashlytics UI の主な部分をご存知でしょう。クラッシュのないユーザーやセッション、問題リストを一日に何度も見ている方もいるかもしれません（皆さんだけではありません！）。
本投稿では、Crashlytics をさらに価値あるものにするプロフェッショナル向けの 7 つのヒントを紹介します。Crashlytics は新しい Fabric ダッシュボードの一部になっているので、問題のトラッキング、優先順位付け、解決をすばやく行うことができます。
1. クラッシュ インサイトをチェックしてトラブルシューティングを高速化する
クラッシュ インサイトは、7 月にベータ版を卒業して正式にリリースされました。クラッシュ インサイトでは、クラッシュに至った状況やその 理由 が明らかにされるため、クラッシュについて深く理解できるようになります。問題リストの問題に緑色の稲妻マークが表示されている場合、それをクリックすると考えられる根本原因や、トラブルシューティングに活用できるリソースが表示されます。
2. 解決した問題を「クローズ」してリグレッションを追跡する
クラッシュのデバッグやトラブルシューティングは、時間がかかる困難な作業です。私たち自身もデベロッパーなので、厄介な問題が解決でき次第、ログアウトしてもっとおもしろいタスク（アプリの新機能の構築など）に戻りたいという気持ちはよく理解できます。しかし、Crashlytics で問題を「クローズ」することは忘れないようにしましょう！問題を正式にクローズすると、リグレッション検知によって問題のライフサイクルを詳しく見ることができるようになります。リグレッション検知は、以前にクローズした問題が新しいバージョンのアプリで再発した際に警告してくれます。これは、何かがうまくいっておらず、注意が必要であることを示す兆候になります。
3. 無視したい問題をクローズしてロックし、問題リストを整理する
一般的には、リグレッションを検知するために問題をクローズする必要がありますが、問題をクローズして ロックする ことで、修正する予定のない問題や優先度の低い問題について 通知されない ようにすることができます。影響が少なくほとんど発生しないバグや、コードには問題がなく自分たちでは制御できない問題などがこれに該当します。そういった問題を非表示にして Crashlytics チャートを整理するには、問題をクローズした後にロックします。この「無視機能」を利用すると、安定性のページをカスタマイズして、対応が必要となる重要な情報のみを表面化させることができます。
4. ビルド バージョンを手動で追加する代わりに、ワイルドカード ビルドをショートカットとして利用する
同じバージョンに複数のビルドが存在する場合もあるでしょう。そういったビルド バージョンは同じ番号で始まりますが、末尾には一意の識別子が含まれています（たとえば、9.12 (123)、9.12 (124)、9.12 (125) など）。これらすべてのバージョンのクラッシュを確認したい場合は、検索バーにビルド バージョンを手動で入力する代わりに、ワイルドカードを使って同じバージョンをグループ化すると、すばやく確認することができます。これを行うには、バージョン プレフィックスの末尾に星印（アスタリスク）を追加します（例: 9.12*）。たとえば、Android で APK の分割を行っている場合、ワイルドカード ビルドを指定すると複数のビルドのクラッシュをすばやく表示できます。
5. 重要なビルドを固定して一番目立つようにする
デベロッパーの皆さんは、毎日いくつかのビルドをデプロイしていることでしょう。開発 チームで扱うビルドの数が、数十や数百におよぶこともあります。モバイルチームのスピードや反応の早さには目を見張るものがあります。しかし、それには良くない側面もあります。たくさんのビルドから、特に重要な 1 つ（あるいは 2 つや 3 つなど）のビルドを探し出すのは時間の無駄です。そのため、Crashlytics では、重要なビルドを「固定」してビルドリストの一番上に表示できるようになっています。ビルドを固定すると、必要な間だけ、重要なビルドを一番目立つようにして見つけやすくすることができます。さらに、この機能を使うと、チームのメンバーのビルドリストでも自動的に一番上に表示されるようになるので、チームのメンバーと協調してクラッシュの修正がしやすくなります。
6. 重要な安定性の問題について最新情報を受け取るため、ベロシティ アラートに注意する
安定性の問題は、いつ発生するかわかりません。皆さんがワークステーションから離れているときに起きることもあるでしょう。Crashlytics は、スマートにビルドを監視し、1 つの問題が統計的にクラッシュの大多数を占めているかどうかを確認してくれます。そして、それに該当する場合は、ベロシティ アラートでアプリのホット フィックスが必要になることをお知らせします。ベロシティ アラートは、問題の重要度や影響が急激に増加した際にクラッシュ レポーティング ダッシュボードに表示されるプロアクティブなアラートです。メールによる通知も行われますが、ぜひ Fabric モバイルアプリもインストールしておいてください。プッシュ通知が送信されるので、外出中でも最新情報が受け取れるようになります。ベロシティ アラートには常に注意してください。そうすれば、どこにいても重要なクラッシュを見逃すことはなくなります！
7. ログ、キー、non-fatal を適切なシナリオで利用する
Crashlytics SDK を使うと、ログ、キー、non-fatal、カスタム イベントを診断できます。これによって、クラッシュが発生した理由や、何がクラッシュにつながったかについての詳しい情報を得ることができます。ただし、ログ、キー、non-fatal、カスタム イベントは、別々の事象をトラッキングするためにデザインされたものです。そこで、これらの適切な利用法をご紹介します。
ログ: ログを分析すると、ユーザーがクラッシュ前に何をしていたかについて重要な情報を得ることができます。たとえば、ユーザーの行動（例: ユーザーがダウンロード画面を開く、ダウンロード ボタンをクリックする）や、行った操作の詳細（例: イメージのダウンロードやダウンロード元）などが考えられます。基本的に、ログはユーザーの断片的な操作記録であり、クラッシュ前に何が起きたかを示すものです。クラッシュが発生した際には、ログの内容が取得されてクラッシュに添付されるので、デバッグの際に便利です。iOS、Android、Unity の各アプリでログの診断を行う手順については、こちらをご覧ください。
キー: キーは、ある時点の情報のスナップショットであるキーと値のペアを示します。時系列に操作を記録するログとは違い、キーは検出された最新の値を記録するもので、時間とともに変化します。キーは上書きされるため、検出された最新の値のみを知りたい場合に使用するようにします。たとえば、ユーザーが完了した最後のレベル、ウィザードで完了した最後の手順、最後に表示したイメージ、最後に行ったカスタム設定などをトラッキングするために利用します。キーは、情報の要約にも活用できます。たとえば、ログが「ログイン、リトライ、リトライ、リトライ」となっている場合、キーを使うと「リトライ: 3 回」と表示することができます。iOS、Android、Unity の各アプリでキーを設定する手順については、こちらをご覧ください。
non-fatal: Crashlytics は自動的にクラッシュを記録しますが、致命的ではない（non-fatal）イベントも記録することができます。non-fatal イベントとは、エラーが発生したものの、アプリのクラッシュには至らなかったイベントです。
たとえば、アプリにディープリンクが存在し、それを開けなかった場合などが non-fatal を記録するシナリオに当たります。リンクの破損によってアプリがクラッシュするとは限りませんが、トラッキングしてリンクを修正することが望ましいでしょう。non-fatal を記録すべきでないシナリオは、ネットワーク エラーによってイメージの読み込みが失敗した場合など、対応できないものや特殊なケースではないものです。
non-fatal イベントは、スタック トレースを取得して優先順位付けやトラブルシューティングを行いたい問題に対して設定するようにします。
単に何かが発生した回数を数えたい（そしてスタック トレースは必要ない）場合は、カスタム イベントを使うことを推奨します。
ここで紹介した 7 つのヒントは、Crashlytics を最大限に活用するために役立つはずです。Crashlytics を使ってアプリの安定性を向上させることができるプロフェッショナル向けのヒントを他にも知っているという方は、ぜひ私たちにツイートしてください！皆さんが Crashlytics をどのように活用しているのか、ご報告をお待ちしています。
Reviewed by Khanh LeViet - Developer Relations Team