この記事は Android Studio プロダクト マネージャー、Steven Jenkins による Android Developers Blog の記事 " Android Studio Flamingo is stable " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Android Studio Flamingo (英語) 🦩 安定版のリリースについてお知らせします。Android Studio は、Android アプリ開発の公式 IDE です。
今回のリリースには、ライブ編集で pixel-perfect な UI を構築するうえで役立つ改善、アプリの調査をサポートする新機能、IntelliJ のアップデートなどが含まれています。Android Studio Flamingo🦩 でどのように生産性が高まるかの詳細については、このまま記事をお読みいただくか、次の動画をご覧ください。そしてさっそく、最新の安定版をダウンロード (英語) しましょう！
UI ツール
Jetpack Compose とマテリアル 3 テンプレート – Jetpack Compose は新規プロジェクト向けの推奨ツールキットになっていたので、テンプレートはデフォルトで Jetpack Compose とマテリアル 3 が使われるようになりました。
ライブ編集 (Compose) 試験運用版 – Compose を使ってインタラクティブにアプリを開発します。コードの変更は、アタッチしているデバイスやエミュレータに直接プッシュされます。変更のプッシュはファイルの保存時または自動的に行われ、リアルタイムで UI の更新を確認できます。ライブ編集は試験運用版であり、エディタ設定から有効化できますが、既知の制限事項があります (英語) 。この機能の改善を続けられるように、フィードバックの送信をお願いします。詳細はこちらをご覧ください。
テーマつきアプリアイコンのプレビュー対応 – ツールバーのシステム UI モード セレクタを使って壁紙を切り替え、選択した壁紙にテーマつきアプリアイコン (英語) がどう反応するかを確認できます（注: アプリのターゲットを API レベル 33 以降にする必要があります）。
ダイナミック カラーのプレビュー
アプリをダイナミック カラー (英語) に対応させ、@Preview コンポーザブルで新しい wallpaper 属性を使うと、壁紙を切り替えて、さまざまな壁紙に UI がどう反応するかを確認できます（注: Compose 1.4.0 以降を使う必要があります）。
Build Analyzer のタスク分類 – Build Analyzer で、マニフェスト、Android リソース、Kotlin、Dexing などのカテゴリに基づいてタスクがグループ化されます。カテゴリを時間で並べ替え、展開して対応するタスクの一覧を表示できるので、さらに細かく分析するうえで役立ちます。どのカテゴリがビルド時間に最も大きな影響を与えているかを簡単に確認できます。
プロファイリング可能なビルドのワンクリック自動作成と実行 – アプリをプロファイリングする場合は、デバッグ可能ビルドをプロファイリングすることは避ける必要があります。デバッグ可能ビルドのプロファイリングは開発時には有効ですが、結果は正しくない場合があります。そのため、ユーザーが実行するデバッグ可能でないビルドをプロファイリングします。プロファイリング可能なビルドのワンクリック自動作成と実行により、この操作が便利になります。プロファイリング可能なアプリをワンクリックで簡単に構成し、プロファイリングを実行できます。完全なデータでアプリをプロファイリングするオプションを選択すると、デバッグ可能ビルドでプロファイリングをすることもできます。詳しくは、ブログ (英語) をご覧ください。
SDK 拡張機能の lint サポート – SDK 拡張機能とは、モジュール化されたシステム コンポーネントを活用し、以前にリリースされた API レベルのパブリック SDK に API を追加する機能です。今回より lint がサポートされ、SDK 拡張機能の問題をスキャンして修正できるようになります。Android Studio は、SDK 拡張機能を使って起動した API に対して、正しいバージョンのチェックを自動生成します。
Android Gradle プラグイン 8.0.0 – Android Studio Flamingo には、新しいメジャー バージョンの Android Gradle プラグインが搭載されています。このプラグインでは多くの改善が行われていますが、たくさんの動作の変更点 (英語) もあり、Transform API が削除 (英語) されています。プロジェクトで AGP のバージョンをアップグレードする前に、変更が必要な点について確認するようにしてください。
Network Inspector によるトラフィックのインターセプト – デフォルトで、Network Inspector にすべてのタイムラインのトラフィック データがすべて表示されるようになります。ルールを作成して管理すると、ステータス コード、レスポンスのヘッダーやボディなど、さまざまな応答が発生した場合のアプリの動作テストに役立てることができます。ルールは、アプリに到達する前にインターセプトする応答や、応答の変更方法を決定します。それぞれのルールの横にある [Active] ボックスをチェックすることで、どのルールを有効化、無効化するかを選択できます。ルールは、変更するたびに自動保存されます。
Layout Inspector のフォアグラウンド プロセスへの自動接続 – Layout Inspector が自動的にフォアグラウンド プロセスに接続します。クリックしてアプリにアタッチする必要はなくなります。
IntelliJ プラットフォーム アップデート – Android Studio Flamingo (2022.2.1) には、IntelliJ 2022.2 プラットフォーム リリースが含まれています。IDE のパフォーマンスが向上しているほか、macOS で Metal API を使ってレンダリング パフォーマンスを向上することなどが可能になっています。また、Kotlin でコード ハイライト、補完、使用箇所の検索をするときの IDE のパフォーマンスも向上しています。こちら (英語) の IntelliJ リリースノートをご覧ください。
この記事の内容をまとめると、Android Studio Flamingo (2022.2.1) には、以下の機能強化や新機能が搭載されています。
ライブ編集 (Compose) - 試験運用版
テーマつきアプリアイコンのプレビュー対応
Jetpack Compose とマテリアル 3 テンプレート
ビルド
Build Analyzer のタスク分類
プロファイリング可能なビルドのワンクリック自動作成と実行
SDK 拡張機能の lint サポート
Android Gradle プラグイン 8.0 の互換性を破る変更
調査
App Quality Insights のアップデート
Network Inspector によるトラフィックのインターセプト
Layout Inspector のフォアグラウンド プロセスへの自動接続
IntelliJ
IntelliJ プラットフォーム 2022.2 アップデート
詳細は、Android Studio のリリースノート、Android Gradle プラグインのリリースノート、Android Emulator のリリースノートをご覧ください。
さっそく Android Studio Flamingo (2022.2.1) をダウンロード (英語) して、ワークフローに新機能を組み込みましょう。いつものように、気に入った機能や問題点、新機能の提案などのフィードバックは大歓迎です。バグや問題を見つけた方は、問題を送信してください。また、既知の問題もご確認ください。Android 開発の最新情報については、Twitter や Medium (英語)、YouTube (英語) で私たちをフォローすることもお忘れなく。
Reviewed by Mari Kawanishi - Developer Marketing Manager, Google Play
この記事は Bethel Otuteye による Android Developers Blog の記事 " Giving Users More Transparency and Control Over Account Data " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Google Play では、デベロッパーがユーザーの信頼を得ることができるようにするために、最近もたくさんの取り組みを始めています。具体的には、アプリのプライバシーやセキュリティ方針をシンプルでわかりやすく示しています。2023 年 4 月 5 日、この作業を土台に、ユーザーに対してアプリ内データの透明性と制御性を向上させることを目的として、新しいデータ削除ポリシーを導入したことをお知らせします。
アカウントを作成できるアプリでは、近日中に、アカウントとデータの削除を開始できるオプションの提供が義務づけられます。これはアプリ内からオンラインで行える必要があります。特に重要になるのがウェブ要件です。ユーザーがアプリを再インストールしなくてもアカウントとデータの削除を依頼できるように、データ セーフティ フォームにリンクします。
Google Play のデータ セーフティ セクションでは、すでにデベロッパーがデータ削除オプションについて説明できるようになっています。しかし、ユーザーはそれよりも簡単に、かつ一貫した方法で、削除を依頼できることを望んでいます。このポリシーによって、さらに直感的に操作できるようにすることにより、どのようなデータ制御ができるのかを私たちが共有するユーザーに知ってもらい、アプリと Google Play の信頼をさらに広げたいと考えています。
新しいポリシーで謳われているように、アカウントの削除依頼に対応するときは、そのアカウントに関連するデータも削除しなければなりません。そのため、デベロッパーが提供する選択肢が増えることにもなります。完全にアカウントを削除したくないユーザーは、その他のデータ（活動履歴、画像、動画など）のみを削除することもできます（該当する場合）。セキュリティ、不正防止、規制への準拠などの正当な理由で一部のデータを保持しなければならないデベロッパーは、データの保持期間を明示する必要があります。
ユーザーがデータを制御できる範囲が広がるのはすばらしいことですが、デベロッパーにはその準備を整える時間が必要になることも承知しています。特に既存の削除機能やウェブ版がない場合は、それが当てはまります。今回、情報とリソースを共有しているのはそのためです。
第一段階として、デベロッパーの皆さんには、12 月 7 日までにアプリのデータ セーフティ フォームでデータの削除に関する新しい質問に回答することをお願いいたします。Google Play ユーザーには、来年の早い段階で、ストアの掲載情報に変更が反映されます。データ セーフティ セクションと新しいデータ削除エリアに表示される更新版のデータ削除バッジもその 1 つです。
さらに時間が必要なデベロッパーは、ポリシー準拠の期限を 2024 年 5 月 31 日まで延長する申請を Google Play Console から行うことができます。
2023 年 4 月 5 日にお知らせしたデータ削除などのポリシー変更の詳細については、以下の方法でご確認ください。
いつもながら、Google Play を全員が信頼できる安全なプラットフォームにすることにご協力いただき、ありがとうございます。
この記事は Google Play Games、ディレクター、Arjun Dayal による Android Developers Blog の記事 "Com2uS brings a seamless multi-platform gameplay experience with Google Play Games on PC" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
サマナーズウォー：クロニクルは、韓国のゲーム デベロッパー Com2uS が制作し、2023 年 3 月に全世界に向けてリリースされたモバイル MMORPG です。サマナーズウォー シリーズは、これまでに 1 億 8,000 万ダウンロードを突破して 27 億ドル以上を売り上げています。ファンタジーの世界でさまざまな召喚獣を育てて他のプレーヤーと対戦する、世界で最も人気のモバイルゲームの 1 つです。
Com2uS は、常に新しいコンテンツやアップデートをリリースすることで新鮮さと面白さを維持しており、そのプレーヤー コミュニティは 10 年近くにわたって拡大し続けています。Com2uS は、いつでもどこでも楽しめる最適な環境を提供するため、クロニクルに PC 版を追加することを決断しました。Google Play Games (ベータ) でモバイルゲームを拡張して PC でプレイできるようにし、臨場感あふれるハイエンドのゲーム エクスペリエンスを既存のプレーヤーに提供するとともに、新たなユーザーにリーチすることにしたのです。
PC 版 Google Play Games (ベータ) を利用すると、モバイル版と PC 版を、同じ Android ビルドを使って簡単かつスムーズに統合できます。数多くのデベロッパー ツールが用意されており、いくつかの最適化手順を実施するだけで PC 版のゲーミング エクスペリエンスを作成できます。PC 版 Google Play Games (ベータ) プレイリスト (動画/英語 - 日本語字幕あり) を視聴し、実装に関する手順の詳細を確認しましょう。
Com2uS チームは、タブレットや折りたたみ式デバイスなど、大きな画面で楽しむための入力サポートも追加しました。サマナーズウォー：クロニクルは現時点で、キーボードとマウスに加え、ユーザーからの要望が多かったゲーム コントローラもサポートしています。クロス プラットフォーム対応であることを念頭に、ユーザー エクスペリエンスを最適化することも重要でした。たとえば、すべてのプラットフォームで簡単に操作できる直感的なゲーム インターフェースにすること、サイズの異なる画面ごとに UI を調整すること、ゲームの操作についてわかりやすい説明を提供することなどが必要になりました。
プラットフォームごとにグラフィック設定を最適化するために Com2uS がメインのグラフィック API として選択したのが、マルチプラットフォーム対応の高パフォーマンスな Vulkan です。ハイエンドのモバイル デバイスを使用するプレーヤーでも、過熱を防ぎバッテリーを長持ちさせるため、柔軟な画質設定を好む傾向にあります。Com2uS は Vulkan を使用することで、主要なユーザー層が PC でもモバイル デバイスでも最適な画質でプレイできるようにしています。
Com2uS は PC 版デベロッパー エミュレータを使用してユーザーと同等の環境を再現し、さまざまなプレーヤー設定でビルドをテストしてデバッグすることができました。このエミュレータは、複数のアスペクト レシオを効率的にテストできるように設計されています。開発やデバッグにおいては、Google Play ストアから直接アクセスすることも、ADB を介してアクセスすることも可能です。サマナーズウォー：クロニクルは Unity で開発されているため、エミュレータを自動的に検知して直接デプロイすることができました。PC 版 Google Play Games エミュレータは、近日中にすべてのデベロッパーの皆様にご利用いただけるようにする予定です。なお、Unity、Unreal、Cocos などのゲームエンジンも引き続きサポートいたします。
2022 年 11 月、Com2uS はサマナーズウォー：クロニクルの PC 版とモバイル版を同時にリリースしました。プレーヤーはすでに、Google Play Games (ベータ) を通じ PC とモバイルの両方でゲームを楽しめるようになっています。PC 版のリリースによって、大きな画面とより高性能なハードウェアでのプレイが可能になり、新たなレベルのゲーム体験が提供されるようになりました。
また Google Play Games サービスにより、プレーヤーは新しいデバイスでゲームを起動してもゲームの進行状況を自動的に同期でき、どこにいても特典や Google Play Points の収集を継続できます。
日本のすべてのプレーヤーを対象に Google Play Games (ベータ) への登録受け付けを開始しています！PC 版 Google Play Games (ベータ) で、臨場感あふれるシームレスなマルチプラットフォーム ゲーム体験をプレーヤーに提供しましょう。ベータ プログラムへの参加をご希望の場合は、今すぐこちら (英語) からお知らせください。
2023 年 4 月 19 日時点、PC 版 Google Play Games (ベータ) は 14 カ国でダウンロードが可能です。
詳しくは g.co/googleplaygames をご覧ください。ゲームタイトルは地域ごとに異なる場合があります。
この記事は Android team による Android Developers Blog の記事 " U-NEXT sees 1.5X increase in tablet installations after boosting support for large screens " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
日本最大級の国内ストリーミング サービスかつデジタル コンテンツ サービスである U-NEXT は、ユーザーが好むコンテンツを表示するための新しい手法を常に模索しています。U-NEXT では、映画、アニメ、ライブ配信、マンガ、雑誌、電子書籍など、1,200,000 以上の作品を単一のアプリで利用できます。
UX を改善するための手法を常に模索し続けている U-NEXT は最近、Android タブレットや Chromebook などの大画面デバイスや折りたたみ式デバイスの市場が拡大している点に着目し始めました。そこで、U-NEXT のエンジニアは、大画面デバイスや折りたたみ式デバイスの独自の強みを活かして、コンテンツの視聴方法を改善できるのではないかと考えました。たとえば、大画面デバイスで利用できる優れたマルチウィンドウ機能を組み込むことで、多種多様な情報を表示できるようになったり、折りたたみ式デバイスの UX を改善すれば、従来の紙の本のような読書体験をうまく再現できるかもしれません。
ただ、大画面デバイスや折りたたみ式デバイスで U-NEXT のアプリを使用している際に、バグが発生することもありました。たとえば、U-NEXT を大画面デバイスで開いた場合に、重要なボタンが隠れてしまい、これらのナビゲーション ツールがページのどこにあるかユーザーが探さなければならなくなっていました。
そこで、UX を大幅に見直して Android の大画面デバイスや折りたたみデバイスにより対応できるようにするために、U-NEXT のチームは、既存のバグを一掃してから、大画面を最大限活用できる機能を追加するという 2 段階でプロジェクトに取り組みました。
バグを一掃する
アプリ内の重要なナビゲーション ボタンが見えなくなるという問題に対処するために、U-NEXT のエンジニアは ConstraintLayout (英語) を使用して、表示領域を制限する境界を設定しました。これにより、UI 要素が画面外に押し出されてしまうことを防止でき、また、画面のサイズによらずに適切な向きで表示されるようになります。
また、U-NEXT のアプリが大画面デバイスで適切に表示されないこともありました。たとえば、ユーザーが閲覧できる動画の一覧を表示するページは、通常、ヘッダーとキュレートされた動画一覧で構成されます。本来は動画の一覧がページ上のほぼ全体に表示されるはずですが、大画面の場合、ヘッダーが画面上のほとんどのスペースを占有してしまっていたため、動画コンテンツの操作がしづらくなっていました。U-NEXT のチームは、大画面でのヘッダー画像の幅を制限することで一覧の表示スペースを確保し、大画面デバイスを使用するユーザーが操作しやすくして、この問題を解決しました。
ユーザーが U-NEXT のアプリで書籍を読む場合、画面のタップ操作で横方向のスクロールバーを表示でき、文章内を迅速かつ簡単に移動できます。ただ Chromebook の場合、このナビゲーション ツールは表示されませんでした。
U-NEXT の Principal Engineer、三輪 智也氏は次のように述べています。「もともと、ユーザーのタップ時に Chromebook が全画面表示になっているかどうかの判定には、SystemUiVisibility を使用していました。全画面表示ではないことを SystemUiVisibility が検出した場合に、コントローラが表示される仕組みでした。ただ、Chromebook では SystemUiVisibility が変更されても、このリスナーが呼び出されないため、コントローラが表示されませんでした」
そのため、Chromebook で SystemUiVisibility が変更された場合に、コントローラの表示を処理する方法を変える必要がありました。このバグを修正することで、Chromebook で画面をタップすると、SistemUiVisibility の変更とコントローラの表示 / 非表示処理が同時に行われるようになったため、ユーザーが直面していた問題が解決されました。
U-NEXT のデベロッパーが対処した最後のバグは、視聴時にユーザーが折りたたみ式デバイスを折りたたんだ際に、動画が一瞬途切れてしまうというものでした。コンテンツの視聴時にデバイスを折りたたんでもシームレスに処理されなければなりませんが、ディスプレイを折りたたむ際にアクティビティを自動で削除して再作成するため、動画が一瞬途切れていたのです。
U-NEXT のデベロッパーは、この構成の変更を Android で自動的に処理するのではなく、手動で処理するようにアプリを変更しました。チームは、onConfigurationChanged() を使用して変更をオーバーライドし、UI 要素の削除と再作成が自動的に行われないようにしました。これにより UI 要素が維持され、動画の再生が途切れないようになりました。
さまざまなフォーム ファクタを活用する
U-NEXT はユーザー エクスペリエンスが大幅に向上することを期待し、機能刷新の一環として、従来型のナビゲーション バーをナビゲーション レール (英語) に置き換えました。
三輪氏は次のように述べています。「快適なユーザー エクスペリエンスを提供するという点に関して言えば、目的の箇所に手が届きやすいということが重要になります。従来型のナビゲーション バーの場合、中央にあるボタンに手が届きづらいです。ナビゲーション レールであれば簡単に手が届きます。」
次に U-NEXT のチームは、読者が折りたたみ式デバイスで電子書籍を読んでいる際に、コンテンツを 2 ページの見開きで表示できるように改善を加えました。折りたたみ式デバイスが縦向きの場合、通常は 1 ページのみが表示されます。ただ、ほとんどの折りたたみ式デバイスには 2 ページを表示できる十分なスペースがあります。そのため、U-NEXT のデベロッパーは、縦向きか横向きかによらずに、あるいは、デバイスが少し折りたたまれている状態でも常に 2 ページの見開きが表示されるようにしたいと考えました。
また、U-NEXT のチームは、大画面デバイスや折りたたみ式デバイスでのユーザー エクスペリエンスをさらに改善するために、生活の質を上げられるちょっとしたアップデートも加えました。このアップデートには、大画面デバイスでの Google Play アプリ内課金への対応の強化、ピクチャー イン ピクチャー (英語) の表示の最適化などが含まれています。
Android であれば最適化が簡単
U-NEXT チームは、大画面デバイスや折りたたみ式デバイス向けにアプリを簡単に最適化できたことに驚いていました。U-NEXT は、Android のデベロッパー リソースを活用することで、時間と労力を最小限に抑えながら、U-NEXT のアプリを使用してさまざまなデバイスでコンテンツを視聴する方法を改善できました。
三輪氏は次のように述べています。「そこまで難しくはありません。ナビゲーションを導入することは比較的簡単でしたし、アプリが基本的な画面の回転に対応していれば、折りたたみ式デバイスへの対応も一般的にそれほど難しくはありません。」
大画面により対応するように U-NEXT アプリをアップデートしてから、タブレットでのインストール数は 1.5 倍になりました。また、大画面デバイスを使用するユーザーの視聴時間も、10% 以上増加しています。
今後、U-NEXT のチームは、マウスやキーボードとの互換性の向上、詳細なリスト表示の導入による検索機能の強化、テーブルトップ モードのサポートの推進、簡単にコンテンツを共有できるドラッグ＆ドロップ機能の実装など、引き続き大画面デバイス向けの機能を強化していく予定です。
U-NEXT は、最近のマテリアル デザイン 3 (英語) のアップデートをはじめ、Android の増え続ける大量のドキュメントにさらにリソースが追加されたことを歓迎しています。これによって、大画面デバイスや折りたたみ式デバイスを利用するユーザーが拡大し続ける状況にもさらに対応しやすくなります。
大画面デバイスへの最適化を今すぐ開始する
大画面デバイスや折りたたみ式デバイスなど、新しいフォーム ファクタを使用するユーザーの数は増加しています。そのようなデバイスを使用するユーザーをサポートする方法は Android の大画面ギャラリーの例を参考にしながら学べます。
この記事は 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 つです。たとえすばらしいインフラストラクチャがあったとしても、ユーザーがその機能を使わないなら、何の役にも立たないからです。
