Clever Geek Handbook

モバイルアプリケーションの仮説検定の機能







モバイルアプリケーションの仮説テストにはどれくらい時間がかかりますか？ 数えましょう：







  1. ユーザーグループごとに異なるモードで動作するアプリケーションの開発。
  2. 結果をテストします。
  3. アプリケーションをアプリストアに配置し、承認を待っています。
  4. ユーザーがアプリケーションを更新するのを待っています。 2019年には、ほとんどの自動更新が有効になりますが、誰もが自動更新を使用できるわけではありません。
  5. 統計の収集と分析。
  6. 以下の開発と並行して、アプリケーションを勝利の仮説の状態にする...


開発者が2週間の反復でスクラムに取り組んでいる場合、これは通常、仮説のテストに1か月かかることを意味します。 他の方法論では、この期間を短縮できますが、大幅に短縮することはできません。







この状況により、多くの製品チームが努力している「週に5つの仮説」のリズムを達成することができなくなります。







以下では、このプロセスを高速化および改善する方法を説明し、使用可能な既製のソリューションをいくつか示します。







行こう







オンとオフを切り替える



詳細に飛び込む前に、追加の用語-Feature flag（Feature toggle）patternを導入する必要があります。







技術的背景のない読者には、説明が必要になる場合があります。







新しい機能を開発する際、プログラマはこの機能を有効にするアプリケーションコードに「スイッチ」を導入します。 通常、このソリューションは、一般的なプログラムコードで未完成の機能を無効にするために使用されますが、もちろん、仮説をテストするためにも使用できます。

実験のテストで機能フラグパターンを使用するには、次のものが必要です。







  1. 実験する機能を完全に開発しました。
  2. そのスイッチはデフォルト状態の「オフ」です。
  3. サーバーからのリモートスイッチ制御。


問題は、A / Bテストを実施する前に機能を開発する必要がある場合、どのくらいの時間を節約できるかということです。 実験の段階を解析してみましょう。













ここで何が見えますか？







まず、機能フラグを使用して、エラーを完全にテストする前にアプリケーションをアプリケーションストアにアップロードできます。 新しい機能がオフになったとき、アプリケーションが以前のように動作することを確認する必要があります-これは、以前に書かれた自動テストで実行できます。 残りは、アプリケーションがユーザーに配布されている間にテストできます。







次に、実験の完了後、機能フラグを使用して、フラグが使用されなくなる次のバージョンの準備ができるまで、すべてのユーザーの機能をオン/オフにすることができます。







この原理により、 Apptimizeサービスが機能し 、A / Bテスト用の既製のシステムを提供します。







分析する



実験を行うには、いくつかのことを行う必要があります。







  1. 実験が全員を対象としない場合は、ユーザーセグメントを選択します。
  2. オーディエンスのサイズを選択します。
  3. 実験によって検証されたデータだけでなく、データを収集します。 残りのビジネス指標は、実験が他の指標に影響しないようにするために必要です。
  4. 結果を収集して分析します。


Apptimizeの既製のソリューションを使用しない場合、最も単純なアプローチは、 分析用のFirebase向けGoogleアナリティクスと、個々の構成（セグメントとテスト）を設定するためのFirebase Remote Configの組み合わせです。 これらのツールは、連携して動作するように設計されています。







したがって、次のものが必要です。







  1. Firebase向けGoogleアナリティクスを使用して、ビジネス指標を追跡します。
  2. Firebase Remote Configを使用して、機能フラグを管理します。
  3. Firebase Remote Configを使用して、セグメントと実験パラメーターを指定します。
  4. 分析でFirebase Remote Configのキーを使用して、Googleアナリティクスのデータを分析します。 この機能は、これらのツールによって「そのまま」提供されます。


さらに最適化します



モバイルアプリケーションの仮説テストサイクルを短縮し、テストに費やす時間を短縮し、実験結果を広める方法を検討しました。 ただし、このアプローチでは、アプリケーションの承認と配布の時間をなくすことはできません。 このアプローチでの「週5つの仮説」の目標は、まだあまり現実的ではありません。







実験を高速化するには、アプリケーションを更新することなく、新しい機能を開発して送信できる必要があります。 これを実現するには、動的なユーザーインターフェイスを使用する必要があります。 ただし、このアプローチには問題があります。







一方では、外部から受け取った設定に応じて、インターフェースの構築には技術的な制限があります。 ほとんどのモバイル開発フレームワークは、不可能または非常に難しい宣言型アプローチを使用しています。







一方、アプリケーションストアポリシーは、アプリケーションストアのルールに違反する機能に使用できるため、任意のコードのダウンロードと実行を禁止します。







もう1つの制限は、Firebase Remote Configから転送されるデータの量です。 インターフェイス全体を転送するために使用することはできません。 特定のバージョンのインターフェイスの「キー」のみを格納することが最適であり、このコードを変更する場合は、サードパーティのサービスからインターフェイスをロードします。 それ自体では、モバイル開発フレームワークの選択を制限しませんが、追加の実装作業が必要です。







最適なソリューションは、ユーザーインターフェイスのみを動的に構築し、ビジネスロジックを固定したままにするアプローチです。 製品の実験の大部分は特にインターフェースに関連しているため、作業のペースを速く保つことができます。 同時に、上記のフラグ付きプロセスに従って、ビジネスロジックの改良が必要な実験を並行して実行できます。







技術的には、このアプローチは次の特徴を持つフレームワークで最も簡単に実装されます。







  1. デフォルトで宣言型のアプローチを使用しない、リアクティブで高性能なユーザーインターフェイス。
  2. FirebaseおよびFirebase Remote ConfigのGoogleアナリティクスのサポート。
  3. 開発全体をスピードアップするには、クロスプラットフォームソリューションが望ましいです。


最適には、Flutterフレームワークはこれらの基準を満たしています。 このアプローチの概念実証として、彼には動的なインターフェイスを作成できるライブラリがあります 。







Flutter、Firebase向けGoogleアナリティクス、Firebase Remote Configで作成された動的インターフェースを使用して、仮説テストを簡単に行うことができるウェブサイトと比較できるアプリケーションを開発できます。







More articles:


All Articles