Open7

パフォーマンスが高いモバイルアプリチームはリリースをどの程度の頻度で行うべきか

ころむにーころむにー

Four Keys指標のデプロイ頻度における、エリートな指標はオンデマンドであり、一日数回デプロイするというレベルが挙げられている。

https://dora.dev/research/2023/dora-report/

P.12

一方、モバイルアプリはストア審査などがあるので、一日数回デプロイみたいなスピード感は現実的でない。
このあたりの実体を調査したい。

ころむにーころむにー

モバイルアプリのデプロイについて、他サーバーやWebフロントエンドと比較した際の特徴。

スピードが遅くなる要因

  • ストア審査がかかる。iOSは1・2日程度(例外的に、特急審査をかけると数時間程度)、Androidは数時間程度
  • 一度ユーザーの手元にインストールされたアプリは、基本的にロールバックする手段がないため、致命的な問題が起きないように事前にリスクを取り除いておく必要性が比較的高い
  • エンド ユーザーはアップデートをすぐにインストールしない
  • ロールアウトに時間差があるため、バグが許容されにくい
ころむにーころむにー

同様な考察。

https://medium.com/glovo-engineering/how-to-apply-dora-metrics-for-mobile-development-ab14aa07a48b

ストア審査のプロセスが自チームでは完全には制御できないもの

https://www.runway.team/blog/key-devops-metrics-how-to-measure-mobile-teams

モバイル チームのリリース頻度に関して言えば、目標とすべき良いベンチマークは通常、毎週または隔週です。

https://www.swarmia.com/blog/dora-metrics-for-mobile-apps/

変更のたびに App Store や Google Play にリリースするのは現実的ではないことを意味します。実際には、パフォーマンスの高いモバイル アプリ開発チームのほとんどは、1 週間または 2 週間のリリース周期を採用しています。

世界クラスのモバイル開発チームのベスト プラクティスを見ると、主要な DORA メトリックの定義と測定方法に当てはまらないことがわかります。週 1 回のリリース サイクルでは、「エリート」な展開頻度と変更リード タイムを達成できません。一部のユーザーだけが不良バージョンをインストールし、一部の機能が機能フラグを使用して出荷される複雑な環境で、変更失敗率や平均復旧時間などの高レベルの集計値を測定するのは、非常に手間がかかりますが、得られるメリットはほとんどありません。

DORA メトリクスを追跡するには、内部/ベータ リリース チャネルを使用します。

ころむにーころむにー

各種記事を見た際のおおよその合意点は以下。

  • 1日数回といったオンデマンドなデプロイは、ストア時間やアプリのロールアウトスピードから現実的でない
  • 週一、隔週のデプロイ頻度が最もハイレベルな頻度
  • 他プラットフォームよりも品質の高さを求められるため、1日でもデプロイ頻度を早めるより、一定間隔で安定してデプロイするのに注力することが重要
ころむにーころむにー

App Storeで実際にどのようなリリース頻度になっているかを分析してみたかったが、App Storeはスクレイピングが利用規約で禁止されているので、分析は厳しそう。

https://www.apple.com/legal/internet-services/itunes/jp/terms.html

コンテンツや本サービスのいかなる部分もスクレイピング、コピー、測定、分析、または監視を行うために、ソフトウェア、デバイス、自動プロセス、または類似もしくは同等の手動プロセスを使用することはできません。

Google Playは特に禁止されていなかったので、分析できるかもしれない。

https://play.google.com/intl/ALL_jp/about/play-terms/