パニックにならずにモバイルアプリをリリースする：段階的ロールアウト、リモート設定、バージョン監視

モバイルアプリの新バージョンをストアにプッシュした。3時間後、クラッシュレポートが殺到し始める。低RAMのAndroidデバイスにおけるエラー率が0.5%から8%に跳ね上がった。チームは原因究明に奔走するが、修正にはコード作成、テスト、レビュー提出までさらに1日かかる。その間、何千人ものユーザーがアプリを開くたびにクラッシュを経験している。

このシナリオは、モバイルファーストの組織では非常によくある。バックエンドサービスなら数分でデプロイをロールバックできるが、モバイルアプリはストアのレビュープロセスに数時間から数日かかる。ユーザーがすぐにアップデートするとは限らない。何週間も、あるいは何ヶ月も古いバージョンを使い続ける人も多い。コンテナを入れ替えたり、サーバーの変更を元に戻したりするわけにはいかない。

では、すべてのユーザーがアップデートするのを待たずに新機能をリリースするにはどうすればいいのか？そして、何か問題が発生したときに、別のビルドを提出せずに被害を食い止めるにはどうすればいいのか？

段階的ロールアウトで小規模から始める

最初の防御線は段階的ロールアウトだ。新バージョンを一度に全ユーザーにリリースするのではなく、まずは少数の割合から始める。例えば、まず5%のユーザーにアップデートを配信する。クラッシュ率、エラー率、ユーザーからの苦情などのメトリクスを監視する。すべてが問題なければ、25%、50%、そして100%へと増やしていく。

Google Play StoreとApple App Storeはどちらも、コンソールインターフェースを通じて段階的ロールアウトをサポートしている。社内配布システムを持つ一部の組織では、独自の段階的リリースメカニズムを構築している。原理は同じだ。影響範囲を限定する。何か問題があっても、影響を受けるのは一部のユーザーだけだ。

しかし、段階的ロールアウトだけでは盲点がある。問題が表面化するまでに数日かかることもある。ある機能がほとんどのユーザーには問題なく動作しても、1週間使用した後にのみ現れる特定の条件下で壊れる可能性がある。その頃には、すでにリリースを全ユーザーに展開しているかもしれない。

機能をリモートで制御する

ここでリモート設定の出番だ。リモート設定を使うと、新しいバージョンをリリースしなくてもアプリの動作を変更できる。サーバー上で設定値を定義し、アプリは起動時または定期的にその設定を読み込む。設定で制御できるものは、表示する機能、呼び出すAPIエンドポイント、レンダリングするUIコンポーネント、有効にする実験的なフローなど、何でもある。

典型的な実装では、バックエンドでホストされるJSONファイルまたはキーバリューストアを使用する。アプリは起動時にこの設定を取得し、それに応じて動作を調整する。問題のある機能を無効にする必要がある場合は、サーバー上の設定を更新する。次にユーザーがアプリを開いたとき、その機能は消えている。ストアのレビューも、アップデートの待ち時間も不要だ。

リモート設定は、モバイルアプリのフィーチャーフラグに特に有効だ。デフォルトでオフになっている機能をリリースし、テストのために10%のユーザーに対して有効にし、自信がつくにつれて徐々に割合を増やすことができる。問題が発生した場合は、即座にオフにできる。

しかし、リモート設定は、各ユーザーが実行しているアプリのバージョンを把握している場合にのみ機能する。バージョン3.2で動作するフィーチャーフラグは、バージョン3.0には存在しないかもしれない。すべてのユーザーに対して盲目的に機能を有効にすると、古いバージョンにはその機能のコード自体が存在しないため、クラッシュする可能性がある。

ユーザーが実行しているバージョンを把握する

アプリバージョン監視はこの問題を解決する。モバイルアプリからのすべてのリクエストには、ヘッダーまたはクエリパラメータにアプリのバージョンを含める必要がある。バックエンドはこの情報をログに記録し、ダッシュボードに集約する。アクティブユーザー間のバージョン分布を確認し、バージョン間のエラー率を比較し、古いバージョンをいつ廃止するかを決定できる。

例えば、バージョン3.0のクラッシュ率が4%であるのに対し、バージョン3.1は0.3%しかないことに気づくかもしれない。これは、3.1のクラッシュ修正が効果的だったことを示している。3.0のユーザーにアップデートを促したり、バージョンが古すぎてセキュリティ上問題がある場合は、重要な機能へのアクセスをブロックすることもできる。

バージョン監視は、段階的ロールアウトの判断にも役立つ。バージョン3.2を5%のユーザーにリリースし、2GB未満のRAMを搭載したデバイスでのみクラッシュ率が急上昇しているのを確認したら、ロールアウトを一時停止し、問題を修正してパッチをリリースできる。バージョン監視がなければ、クラッシュが全体的に増加していることはわかっても、どのバージョンが原因かはわからない。

これら3つのプラクティスがどのように連携するか

段階的ロールアウト、リモート設定、アプリバージョン監視は、モバイルリリースのための3層のセーフティネットを形成する。

以下の図は、典型的なリリースシナリオにおいて、これら3つのプラクティスがどのように連携するかを示している。

段階的ロールアウトは、新バージョンの初期リスクを処理する。明らかな問題を、大多数のユーザーに影響が及ぶ前に早期に発見できる。

リモート設定は、継続的な制御を提供する。バージョンが完全にロールアウトされた後でも、別のリリースサイクルなしで動作を調整できる。

アプリバージョン監視は、両方の決定を行うために必要な可視性を提供する。誰がどのバージョンを使っているか、各バージョンのパフォーマンスはどうか、いつ介入すべきかがわかる。

これらのプラクティスがなければ、モバイルチームはしばしば反応的なサイクルに陥る。ビルドを提出し、レビューを待ち、クラッシュが急増してパニックになり、修正に奔走し、別のビルドを提出し、また待つ。各サイクルには数日かかる。その間、ユーザーは苦しむ。

モバイルリリースのための実践的チェックリスト

次回のモバイルリリース前に、このチェックリストを確認しよう。

• 段階的ロールアウトの割合と、次の段階に進むための基準（例：クラッシュ率1%未満、重大なバグの報告なし）を定義する。
• 迅速に無効にする必要があるかもしれない新機能のために、リモート設定キーを設定する。
• すべてのAPIリクエストに、ヘッダーまたはパラメータでアプリバージョンが含まれていることを確認する。
• バージョン分布、バージョンごとのクラッシュ率、バージョンごとのエラー率を示すダッシュボードを作成する。
• ロールバック計画を文書化する：どの設定値を変更するか、どの割合に戻すか、誰がそれらの変更を行う権限を持つか。
• リモート設定メカニズム自体をテストする。アプリが設定の欠落や不正な形式を適切に処理することを確認する。

まとめ

モバイルファーストの組織は、リリースをバックエンドのデプロイと同じように扱うことはできない。ストアのレビュープロセス、ユーザーのアップデートラグ、多様なデバイスはすべて、異なる戦略を必要とする。段階的ロールアウトは、不良リリースの被害を限定する。リモート設定は、リリース後も機能を細かく制御できるようにする。アプリバージョン監視は、実際の現場で何が起こっているかを教えてくれる。これらを組み合わせることで、モバイルリリースは高リスクなイベントから管理可能なプロセスへと変わる。これらがなければ、たった一つの不良ビルドが、非常に長い夜を招くことになる。