この記事は Google Play、スタッフ ソフトウェア エンジニア、Harini Chandrasekharan による Android Developers Blog の記事 "Feature Engineering in the Google Play Store" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
10 年前の 2012 年にスタートした Google Play ストアは、Android の中核になっており、世界中で数十億人のユーザーと、世界中で増え続けるアプリやゲームのコレクションを結びつけています。
ここでは、世界最大の Android マーケットプレイスを支えるインフラストラクチャを設計するうえで必要なことを紹介するために、その舞台裏をのぞいてみることにしましょう。コンシューマー向けソフトウェアの世界を考えるなら、既製のエンジニアリング ソリューションでは、 Google のスケールが求める要件を満たすことが難しいことは当然です。そのため、Google のすべてのシステムは Google Play ストアのユニークな可用性、品質、遅延の要求を満たすために、慎重に作られ、機能を改善し続けることで磨かれています。
機能とは、フォーマット、コンテンツ、コンテンツの配置、ページ レイアウト、情報アーキテクチャなど、ユーザーが触れるものを指します。フォーマットとは、Google のレコメンデーション システム、広告主、販売者など、さまざまなソースから取得されるアプリのコンテンツをどのように UI に表示するかを表します。ここで目指すのは、ユーザーが Google Play ストアを操作しているときに最も関連性の高いアプリやゲームを提示できるように、適切なコンテンツと UI を組み合わせてオーダーメイドの体験を実現することです。
ユーザーを対象とした機能では、ユーザーの意見や選択、デベロッパーのエコシステムや需要がインフラストラクチャよりも速く変化することがほとんどです。そのような環境でエンジニアが直面する最大の課題は、スケーラビリティやパフォーマンスの制約の中で、陳腐化しないだけでなく、ユーザー領域のニーズにも応えられるインフラストラクチャをいかにタイムリーに設計するかという点です。そのようなダイナミックな領域におけるエンジニアリングの課題について、いくつかを詳しく取り上げることにしましょう。
Google Play ストアのようなデータドリブンな組織では、あらゆる重要なものを計測する指標が作られています。次に挙げるのは、成功を測定し、追跡する際に役立ついくつかの特性です。
プロダクトやビジネスの指標 - 対象のプロダクトやサービスに固有な指標です。新たな処理に対して A/B テストを実施し、この指標の変化を測定すれば、意思決定に多くのトレードオフが伴う場合などの信頼性が高まります。
パフォーマンス - レイテンシ、エラー率、可用性の測定は、ほぼすべてのサービスの根幹を成しており、それには正当な理由があります。このような基本指標から、ユーザー エクスペリエンスやプロダクトの認識を細かく追跡できるので、これを把握することは不可欠です。
システム健全性 - リソースの使用率やフリートの安定性を追跡する内部システム指標です。
最も重要なのは、Google Play ストアの要件までスケーリングでき、ユーザーのスムーズな操作と応答の速さに必要なパフォーマンス基準を満たすバックエンド システムを設計することです。エンジニアリングの観点から見れば、インフラストラクチャは継続的に進化してビジネスニーズを満たせるものでなければなりません。Google Play ストアも同じで、ストアのインフラストラクチャはこの 10 年で何度も進化を遂げ、現在ユーザーが利用している新機能に対応しています。それだけでなく、モダナイズによって、とりわけ重要なレイテンシの削減などの技術的負債の解消も行っています。
課題 : 多くの場合、機能には長期にわたる大量の反復作業が必要です。そのため、すべての機能要件を満たすインフラストラクチャの開発を計画するのは困難です。
実験主導のやり方では、大規模な機能をすばやく構築するための最適なアプローチによって、技術的負債が生じることが多くなります。技術的負債にはさまざまな形があります。うまく動作せず、クリーンアップできない過去の機能の遺産が積み重なり、パフォーマンスに影響が生じ、コードのエラーが起きやすくなり、テストが難しくなります。
課題 : 数百名のエンジニアを抱える大規模組織では、多くの機能が独立して並行に開発されることがほとんどです。
インフラストラクチャの再利用やイノベーションの共有は、大幅にスピードを落とさない限り、実現できない場合がほとんどです。多くの場合、プロダクトが急速に進化する領域では、システムを柔軟にするために組み込むさまざまなレバーやノブに大量の不確実性が存在します。レバーが多すぎると、システムの複雑さが大幅に増す場合があります。レバーが少なすぎると、反復作業にかかるコストが膨大になります。この 2 つの間のバランスを見つけることは、この領域のフィーチャー エンジニアリングの中核の 1 つです。
課題 : 多くの場合、優れたエンジニアリング ソリューションを開発する時間のために、機会費用が発生します。
実験にかかる時間は、ユーザー向けの機能ソリューションを設計するときに念頭におくべき、特に重要な指標の 1 つです。反復作業を速くし、レイテンシなどのパフォーマンス SLO を満たせる柔軟な設計が理想です。
実際には、特にユーザーに影響する変更の影響を見積もる場合は、大量の推測が必要になることがほとんどです。過去のデータや教訓を活用して確実に見積もれる状況もありますが、試したことのないまったく新しいアイデアに対しては十分な方法ではありません。
Google Play ストアがこういった課題をどう解決し、最先端のイノベーションを実現しているかを確認してみましょう。
市場投入までの時間（ユーザーに機能を届けるまでの時間）を最適化し、それがアプリのインストール数などのストアのビジネス指標にどう影響するかを A/B テストによって計測することが最も重要です。データに基づいて高速に反復することで、最終的な機能を調整し、目指す最終状態に向かうことができます。Google には、世界規模で A/B テストができる複数の自社製テクノロジーがあります。デベロッパーが分析ではなくコーディングに時間をかけることができるように、指標提示ツールとシームレスに統合され、A/B テストなどを簡単かつスムーズに行えるようになっています。
何を開発するのか、それが Google の品質標準を満たしているか、そしてエンジニアリング費用とそれが解決するユーザーのニーズを理解しているか、といった問いは、いずれも何かを設計する前に答えを出すべき重要な問いです。そのため、プロダクト マネージャーと密接に連携してフィーチャー エンジニアリングを実施する場合がほとんどです。プロダクトの成功に向けて重要なのは、妥当なエンジニアリング時間で構築でき、ユーザー ジャーニーに一致する完全な実用最小限の製品（MVP）に近づけることです。
反復作業を頻繁に行い、短時間で MVP を開発する方式には、いくつかの短所が存在することがほとんどです。その最も大きなものが技術的負債です。スピードアップのための最適化の際に手を抜くと、（開始できない指標のため）コードが陳腐化したり、試験運用版フラグのまま捨てられてしまったりすることがあります。これを放置すると、テストや保守、今後の開発速度に影響することが多くなります。また、優れた最新フレームワークを使うことで、最後の数ミリ秒のレイテンシを解消し、開発を簡単にして長期的なメリットにつなげることができます。昔から、リファクタリングや完全な書き換えによってインフラストラクチャを頻繁にモダナイズすることは、コードの設計不良の兆候と見なされることがあります。しかしこれは、フィーチャー エンジニアリングで必要になる大きなトレードオフの 1 つです。たとえすばらしいインフラストラクチャがあったとしても、ユーザーがその機能を使わないなら、何の役にも立たないからです。
Reviewed by Mari Kawanishi - Developer Marketing Manager, Google Play
