フロントエンド開発者は品質改善やTime to Recover短縮のために何ができるのか：Webフロントエンドエンジニアだけでスマホアプリ開発（終）

　メッセージアプリではTime to Recoverの短縮を図るために「Sentry」を導入しています。Sentryをより効果的に活用するには、「障害発生から対応完了までのどの時間を短縮できるか」をよく理解する必要があります。

障害対応完了までの時間の内訳

　上図のように、Sentryを活用することで、障害の迅速な検出と再現手順を導き出すまでの時間の短縮が期待できます。

　筆者たち開発者は利用者に対し、修正したアプリケーションを少しでも早く提供すべきです。そこで開発チームでは、Time to Recover短縮のため、Sentryを活用した障害対応プロセスを構築しました。

• エラー検出の通知をなるべく早く認知する

　その一環としてまず、Sentryがエラーを検出すると、連携している「Slack」にエラーの概要をポストするようにしています。そして、ポストされたエラーに対して迅速に対応する必要があるかどうかを判断するために、日替わりの当番でSentryのログ監視担当を分担しています。担当は、Slackにエラーがポストされたらなるべく早く確認し、影響ユーザー数や「端末固有の問題かどうか」を調べ、必要に応じてエスカレーションします。

　加えて、チームにジョインして間もないメンバーもいざというときに対応できるよう、当番の担当を経験豊富なメンバーとペアにしたりしています。こうして障害発生時には、障害対応経験のあるメンバーとないメンバーのペアで「どのように調査していくか」の方針や対応方法を共有しながら進められるようにしています。これにより、障害対応の属人化の低減を目指しています。

• 再現手順を分かりやすくするためにBreadcrumbsを活用する

　Sentryには「Breadcrumbs」という機能があります。これと「Redux」を下記のように連携させ、「どんな操作をしたときにエラーが発生したか」を記録するようにして、再現手順の調査を迅速に行えるようにしました。

import * as Sentry from '@sentry/react-native'
import { AnyAction, Dispatch, Middleware } from 'redux'
import { State } from '../modules/reducer'
 
export default (): Middleware<Dispatch, State> => () => (next) => (action: AnyAction) => {
  Sentry.addBreadcrumb({
    category: 'Action',
    message: action.type,
  })
  return next(action)
}

　このときBreadcrumbsには任意のペイロードを使えてしまうので、個人の特定につながったり、プライバシーに関わったりする値を誤って送信しないように、原則的には「action.type」しか送信しないようにしています。

アプリケーション操作中に通信ができないエリアに移動した際のエラー

緊急度の高い問題が起きたときのために「React Native」の強みを生かした「Hot Code Push」

　「Hot Code Push」とは、ネイティブ部分のソースコードはそのままに、JavaScript部分だけのソースコードを差し替えて、審査なしでアプリケーションに変更を加えられるような仕組みです。これは、App Storeの審査ガイドラインにおいては幾つかの制約を守った上であれば活用してよいことになっています。そのガイドラインに従ったライブラリとして、「Visual Studio App Center」の「React Native」用Hot Code Pushライブラリを活用しています。

　Airシフトモバイルアプリでは、緊急度の高い問題が起きたときに迅速に対応できるよう、あらかじめHot Code Pushの仕組みを導入しています。また、本番アプリに対してだけではなく、社内配布版に対してもHot Code Pushを行い、開発チーム以外のメンバーにアプリを触ってもらう際円滑に確認できるようにもしています。

テスト実施時間短縮に向けた今後の取り組み

　今後の課題として挙げられるのは、テスト実施時間の短縮です。現状、デグレードが発生しないように、関数レベルでの回帰テストは充実しています。

メッセージアプリの単体テストのカバレッジ

　しかし、ソースコードをブラックボックスとしたときのQAテストは、人の手によって実施している状況です。人の手で実施しているからこそ発見できるバグもあるので、一概に全てを自動化すればよいとは考えていませんが、仕様的に非常に単純な箇所はe2e（エンドツーエンド）テストなどを記述しておくことで簡略化したり、QAテストの前段階のスモークテストとしてのe2eを用意したり、「Airシフト」Web版で実施しているVisual Regressionをメッセージアプリでも実施したりといったことができると、テスト実施時間の短縮につながるのではないかと考えています。QAテスト実施前に、幾つかの自動化されたテストでデグレードが検出できれば、手戻りや引き継ぎなどにかかるリードタイムの短縮ができる見込みがあります。

まとめ

　本連載では、Airシフトメッセージ用アプリを検討・開発・運用するに当たっての工夫を紹介してきました。リリースまでのリードタイムをなるべく短くする工夫や、開発チームの状況を考慮した技術の選定、運用を視野に入れたライブラリの選択、リリース後運用するに当たって繰り返しのエンハンスに耐え得るための工夫など、幅広く紹介できたと思います。

　筆者たちが取り組んでいた内容が、少しでも皆さんの参考になれば幸いです。