Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

モバイルアプリ開発における継続的デリバリー、そしてDevOps時代のための開発とテスト【Agile 2018】

Agile 2018参加レポート 第3回

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

 世界最大級のアジャイル開発の祭典「Agile 2018」がアメリカのサンディエゴで開催されました。日本でもめずらしくなくなってきたアジャイル開発ですが、北米で開催されるこのイベントには、2000人を超える開発者、テスター、プロダクトマネージャ、プロジェクトマネージャなど、ソフトウェア開発に関わる人達が世界から集まってくるカンファレンスです。本稿では、「Testing & Quality」トラックのセッションを中心にレポートします。

目次

安全にモバイルアプリを継続的デリバリーするためには?

 MicrosoftのPrincipal Engineering ManagerであるKarl Krukow氏による「Can we deploy mobile native apps multiple times per day with confidence?」では、モバイルアプリを継続的インテグレーション(Continuous Integration:CI)、継続デリバリー(Continuous Delivery:CD)するために必要なポイントが良くまとめられた、初心者向けのセッション構成でした。いかにして、アジャイルなリリースパイプラインを作っていけばよいのでしょうか?

 モバイルアプリの開発プロセスにはさまざまな段階を含みます。

  1. 変更ビルド
  2. テスト
  3. ベータバージョンの配布
  4. Google PlayやAppStoreへの配布準備
    1. リリースノート更新
    2. スクリーンショット更新
  5. Google PlayやApp Storeへのアップロード
  6. アプリの審査依頼
  7. Appleなどによるアプリレビュー
  8. 公開
  9. ユーザーによるアプリのアップデート

 上記のように、リリースまでのパイプラインを眺めてみると、「2. テスト」では、モバイルアプリ特有のテストが必要になります。アジリティ(俊敏性)を担保しながら、品質をここでも維持するためには一工夫が必要です。

 そして、「6. アプリの審査依頼」や「7. Appleなどによるアプリレビュー」は、開発する側でコントロールできません。さらに、忘れてはいけないのが、「9. ユーザーによるアプリのアップデート」です。Webアプリと違い、「リリース=更新される」わけではなく、ユーザーによる任意のタイミングで(ユーザによっては自動更新している場合もありますが)アプリが更新されるため、これも開発する側でコントロールできません。

 コントロールできないプロセスがボトルネックになると、「フィードバック」「新しいアイデア」「実験結果」がすばやく手に入らず、ビジネスに悪いインパクトを与えてしまう可能性があります。

 それぞれの課題について見ていきましょう。まずは、有名なモバイルアプリのリリースタイミング(Release Cadence。Cadenceは歩調やリズムという意味で、繰り返しを基本とするアジャイル開発でよくでてくるキーワードの一つです)を見てみます。

 ほとんどのアプリが、2週間以内のタイミングでリリースを続けているのが分かります。そして、Google Mapのような高いユーザレートを維持するアプリもあります。

 まず、アプリの品質について考えます。先述しましたが、モバイルアプリはさまざまな観点の品質保証が必要です。

  • テスト端末:世界には24000以上のデバイスがあり、1000を超えるデバイスメーカーが存在する
  • 解像度:上記に同じくさまざまな解像度が存在します
  • OSのVersion:ほとんどの場合、4~5種類のOSが同時に存在します

 テスト端末の管理や利用をスムーズにするために、ご自身でテスト端末を集めたデバイスファームを構築することも可能です。ただし、連続して使ってバッテリーが爆発しそうになったり、購入や運用のコストがかさむ問題もあり、なかなか手を出すのは難しいです。

 テスト実行についてはどうでしょう? テストを速く実行するためには、マニュアルテストのテスト自動化が不可欠です。しかし、さまざまなフレームワークや環境が存在し、どれを選ぶかは組織やチームによって異なります。

 次に、アプリの審査依頼とアプリレビューを見てみます。過去をふりかえると、5日以上のサイクルタイム(レビュー期間)がかかっていましたが、現在は平均して1日で終わるようになりました。中には数時間でレビューが終わったという報告もあります。1日であれば十分早くなったと考えて良いと思います。

 最後に、ユーザーのアップデートについてはどうでしょうか。こちらでコントロールはできませんが、A/BテストやFeature Toggle(機能を出したり消したりをアプリ提供側でコントロールする方法)を使えば、リリース後のアプリのコントロールが可能です。

 さらに、強制的にアップデートを促す仕組みをいれたり、アプリを安全に停止するための仕組み(Kill Switchなど)もあれば、比較的自由度を保ちながらアプリ管理できます。

 もう一度、モバイルアプリ開発における課題点をまとめてみます。

  • テストはアジリティと品質の担保が必要
  • アプリの審査依頼とアプリレビューは、最近では1日以内になりボトルネックが解消されてきました
  • ユーザーによるアプリのアップデートも、Feature Toggleなどを使えば、ある程度のコントロールが可能です

 今回注目すべき点は、やはり「テスト」です。特に開発⇒ビルド⇒テスト部分は、それぞれが独立したフェーズになっているため、「スムーズにつなぐ」必要があります。

 ここで登場するのがCloud Mobile CIです。スピーカーがMicrosoftの方なので、Visual Studio App Centerを推していますが、メルカリでも検証を進めているGoogleのFirebaseや過去に利用していたAWS Device Farm、現在利用しているbitrise(参考:「AndroidのCI時間を10分短縮し、開発を爆速にするためのKarakuriを作った話」)など、さまざまなサービスがあり、モバイルアプリ開発におけるCI/CDを支えてくれます。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

バックナンバー

連載:「Agile 2018」レポート
All contents copyright © 2005-2019 Shoeisha Co., Ltd. All rights reserved. ver.1.5