iOS/Android上で変化に強いプロダクトを提供するための工夫 〜 Yahoo!広告での事例

こんにちは。Yahoo!広告を担当しているソフトウェアエンジニアの加藤です。

iOS/Androidにアドテクノロジーといった領域は変化が激しいため、それが楽しくもありますが、大変です。自分たちだけではコントロールが難しいOSの仕様変更や不具合対処など、外部起因の変化に対して強いプロダクトをiOS/Android上で提供するために、実践している工夫を紹介します。

私が担当するYahoo!広告での事例とはなりますが、この3個に絞ってご紹介します。可能な限り広告以外でも適用可能な工夫として説明します。

1. アプリやアプリで利用されるSDKに不要な知識を持たせないようにしよう
2. 変化が起こり得るタイミングでは、E2Eテストをしよう
3. OSもOSSも、提案や実装の段階から変更内容をキャッチアップしよう

広告チームが変化を早期検知するプロセスを目指している背景　

私が担当するYahoo!広告ならではの要素ですが、主に2つあります。

1. 金銭が直接絡むサービスでは、安定稼働を強く求められる
2. 広告業界は過渡期で、OSプラットフォーマーや法律など外部起因の環境変化が非常に激しい

広告は金銭が直接絡む以上、なにかインシデントが発生した際に、それが事業において大きなリスクとなる可能性があります。よって、安定して機能提供することが強く求められます。また、外部起因の変化が頻繁に発生し、非常に影響を受けやすい事業領域です。今回はテーマから少し外れてしまうため深くは説明しませんが、今の広告業界はAppleやGoogle、ブラウザベンダーやIAB Tech Lab※1といった各プレイヤーが、プライバシー中心の新たな標準を再構築しようとしている正に過渡期と言える変化が激しい状況です。※2

そのため、いつの間にか未知の変化により莫大な機会損失や売上毀損が発生している、というような事態に陥ってしまう可能性があります。よって、常日頃からのリサーチは必須と言える状況です。

※1　IAB Tech Labは、米国ニューヨークに本拠地を置く非営利のインタラクティブ広告業界団体であるThe Interactive Advertising Bureau（IAB）が設立したデジタルメディアとデジタル広告業界のソリューション、またグローバルな業界技術基準の確立と推進を促進するための技術協議連合会です。ヤフーは日本企業として初めてボードメンバーとして参画しており、グローバル企業とともに共通の課題を根本的に議論・検討し、得られた知見を共有することで日本のデジタルマーケティング市場の健全な発展を目指しています。

※2　The Privacy Sandbox、Private Click MeasurementやSKAdNetworkなど毎日のように新しい提案やそれらに関する議論が繰り広げられています。こういった活動に興味がある方は、https://wicg.io/をのぞいてみると良いかもしれません。

とはいえ、変化に強くなるのは困難

ただ、変化に強いチームを作るのも簡単ではありません。例えばFacebookがContinuous Deployment of Mobile Software at Facebookというタイトルで2016年に発表した論文に下記の記述があります。

1. The frequency of software updates may be limited because(i) software updates on mobile platforms are not entirely transparent to the end-user, and(ii) the time needed for app reviews to take place by the platform owner; e.g., Apple reviews for iOS apps.
2. Software cannot be deployed in increments one module at a time; rather all of the software has to be deployed as one large binary; this increases risk.
3. Risk mitigation actions are more limited;for example, hot-fixes and roll-backs are largely unacceptable and can be applied only in the rarest of circumstances as they involve the cooperation of the distributor of the software (e.g., Apple).
4. The end user can choose when to upgrade the mobile software (if at all), which implies that different versions of the software run at the same time and need to continue functioning correctly.
5. Many hardware variants — especially for Android — and multiple OS variants need to be supported simultaneously.The risk of each deployment is increased significantly because of the size of the Cartesian product: app version × (OS type & version) × hardware platform.

翻訳するとこのような内容です。

1. ソフトウェアの更新頻度は下記の理由により制限される可能性がある
   • モバイルプラットフォームのソフトウェア更新はエンドユーザーにとって完全な透明性を担保していない
   • プラットフォーム側のソフトウェアレビューというステップがある
2. ソフトウェアは1つのモジュールずつアップデートができない
   • 代わりに全てのソフトウェアは大きな1つのバイナリとしてデプロイされる
   • それによってリスクが高まる
3. リスク緩和のための方策が制限される
   • 例えばホットフィックス（修正用緊急配布モジュール）やロールバックはほとんど受け付けられない
   • PF側のソフトウェアが関係しているような非常に稀な場合のみ機能する
4. エンドユーザーはいつ、またはアップデート自体行うかどうかを選べる
   • つまり開発側は複数のバージョンのソフトウェアが同時に存在・機能することを担保しなければならない
5. 複数のハードウェア（特に Android）、複数のOSバージョンを同時にサポートしなくてはならない
   • 組み合わせで考えると、（アプリバージョン）x（OS タイプ・バージョン）x（ハードウェアプラットフォーム）で考慮するべきケースが飛躍的に増える
   • 各デプロイのリスクが著しく高まる

iOS/Androidアプリのデプロイは、このような性質を持つためチャレンジングと言えます。

ここからはより具体的な課題とそれに対する工夫について紹介していきます。

SDKの計画外デプロイへの耐性づくり

課題: SDKに手が入るたびに、アプリへの再組み込みが発生してしまう

iOS/Androidアプリ向けSDKという形式にて提供されるソフトウェアの場合、変更点をデプロイするためには、アプリへの組み込みというステップが追加されます。広く使われているSDKですと、その導入先アプリの数も膨大となり、より影響範囲が広がります。前述した通りリスクは高まるので、SDKの計画外デプロイは可能な限り減らしたいところです。

工夫: アプリやアプリで利用されるSDKに不要な知識を持たせないようにしよう

この課題に対するアプローチとして、私たちのプロダクトでは「アプリやアプリ上で利用されるSDKに不要な知識は持たせない」というポリシーで機能をデザインするよう意識しています。（ここで言う知識とは、いわゆるビジネスロジックと呼ばれるものや、PF/OS仕様を指しています）

イメージとしては、アプリやSDKは何も考えず、クライアントとして配信サーバのレスポンスに従い振る舞うといったところです。

このようなポリシーでリリースしておくと、その後に何かしらの変化が発生した場合にサーバの方で対応可能となる可能性が高まるため、アプリの計画外デプロイを避けられる可能性も高まります。

Yahoo!広告の一例として、以下のものはアプリや広告SDK側に持たせていません。これらは広告配信サーバからのレスポンスによって制御できるデザインとなっています。

• 表示する広告
• 広告タップ後の振る舞い方
• 計測方法
• etc.

このおかげで、アプリやSDKの計画外デプロイを何度か回避できています。広告タップ後に発動するある機能が期待に通り動作しない、といったOS不具合を検知した時に、広告配信サーバのレスポンスで代替機能に切り替える対応をすることができました。

インシデントを未然に防ぐプロセスづくり

課題: ユーザー視点では、原因がOSだろうが不具合は防ぐべき

OSの不具合が原因で、その上で動くアプリやSDKに問題が発生したとしても、アプリのユーザーからしてみればアプリの利用を妨げる不具合に違いはありません。
『OSの不具合なので』と言い訳したくなるところですが、ユーザーファーストの精神で可能な限り未然に防ぐべきです。

工夫: 変化が起こり得るタイミングでは、E2Eテストをしよう

ヤフーにはE2Eテストを専門に担当するチームがあります。そちらのチームと連携し、何かしらの変化が起こり得ると考えられる下記タイミング（可能な限り当日）にて、iOS/Android向けに提供される既存機能が問題なく動作しているか確認するE2Eテストを実施しています。

• iOS
  • Beta含む新しいバージョンのOSがリリース
• Android
  • Beta含む新しいバージョンの新しいOSのリリース
  • DevとBeta含む新しいバージョンのChromeアプリのリリース（AndroidのWebViewとして利用されるため）
  • DevとBeta含む新しいバージョンのAndroid System WebViewアプリのリリース（AndroidのWebViewとして利用されるため）

これらのリリース情報はRSS配信されています。こちらにあるので、参考にしてください。

• リリース情報のRSS（外部サイト）
  • iOS
  • Android（OSリリース含むAndroidアプリデベロッパー向け情報全般）
  • Chrome

検知結果が、業界全体をインシデントから救ったことも

たまたま広告の担当者が、広告表示に影響あるOSの不具合に気づいたことがありました。インシデントにはならなりませんでしたが、気づかず世に出ていたらゾッとするようなケースが過去存在しました。ほんの一例ではありますが、未然にインシデントを防ぐことができたケースとして、OM SDK（Open Measurement SDK）に影響を与えるAndroid WebViewの不具合があります。

ヤフーの広告SDKにはOM SDKを統合しているため、E2EテストでもそのOM SDKの機能に関するテストを実施しており、そこで検知できました。

検知後はOM SDK提供元であるIAB Tech Labに事象をレポートすることで連携し、IAB Tech LabからこちらのIssueにてChromiumチームにはたらきかけていただきました。（AndroidのWebViewには前述した通りChromiumの実装が利用されているため、Chromium側での対応が必要となる場合があります）

詳細なやりとりは該当のIssueを読んでいただければと思うのですが、結果的にChromiumチームにリリースブロッカーとして扱ってもらい、その対応がされたChromiumが正式版としてリリースされたため、未然にインシデントを防ぐことができました。OM SDKはヤフー以外にも数多く統合される業界標準と言えるSDKなので、ヤフー以外のOM SDK利用者のインシデントも未然に防ぐことができたと言える大きな成果となりました。

変化によるインシデントは未然に防ぐのが理想ですが、OSの不具合など自分たちだけでコントロールができない事象がある以上、すべてを未然に防ぐことは不可能です。よって、何かしらインシデントが発生したとしても、それを早期に検知するという取り組みも重要となってきます。広告プロダクトでは、SLOやサービスメトリクスを定義し、それらをモニタリングすることでインシデントの早期検知に努めています。

並行して、人力では実施コストの大きいケースのE2Eテストを対象にAppiumを使った自動化も進めています。出社に制限のあるコロナ禍にも対応できるように自動E2Eテスト環境構築に取り組んでおり、形になりましたらこちらの取り組みも共有できればと検討しています。

変化に対するアンテナ強化

課題: OSプラットフォーマーが発信する情報のキャッチが遅い

冒頭でも述べた通り、iOS/Androidやアドテクノロジーといった領域は非常に変化が激しい領域です。キャッチアップするまでの少しの差で、その後の対応に使える時間も変わってくるため、いかに早く変化をチャッチアップするか、という工夫が重要になってきます。

工夫: OSもOSSも、提案や実装の段階から変更内容をキャッチアップしよう

まず当然の取り組みとして、OSプラットフォーマーからの情報源である以下の購読は必須です。こちらもOSの更新情報同様にRSS配信されています。気が向いた時に見にいくのではなく、組織として変化をキャッチアップし続けるために、Slack内でRSS購読しています。

• iOSやAndroid全般のRSS（外部サイト）
  • iOS
  • Android

さらに、iOSのWKWebViewやAndroidのWebViewにはOSSとして開発されているWebKitやChromiumが利用されているため、提案や議論、実装は可能な範囲で追いかけましょう。この辺りもRSSを購読しておくと追いかけやすいです。

• ブログのRSS（外部サイト）
  • WebKit
  • Chromium
• 提案、議論、実装（外部サイト）
  • WebKit
  • Chromium

最近のアドテクノロジーに関する議論は、オープンになっているものが多いので、特に影響が大きそうな事象は提案という段階から追いかけましょう。冒頭でもリンクした https://wicg.io/が追いかける上で便利です。

その他の取り組み

変化に強くなるためには、受け身になるのでなく、その変化をリードする側に回るというアプローチもあります。

課題の項目でも言及した通り、ヤフーはグローバルな業界技術基準の確立と推進を促進するための技術協議連合会であるIAB Tech Labに日本企業で初めてボードメンバーとして加盟した企業です。ヤフーとして、IAB Tech Labでのグローバル企業との協業や日本最大級のメディア「Yahoo! JAPAN」に広告を配信可能なYahoo!広告のさらなる発展といった取り組みによって、デジタルマーケティング市場の健全な変化の推進を目指しています。

おわりに

今回は、変化に強いプロダクトをiOS/Android上で提供するためにYahoo!広告で実践している工夫について紹介しました。私たちのチームは、このようなリスクヘッジの工夫を積み重ねていくことで、無駄なデプロイのやインシデントを回避できる組織になりました。

銀の弾丸と言えるようなアプローチはそうそうないため、当たり前と言えるようなことをサボらずに継続していくのが大事だと考えています。今回紹介した取り組みが何か1つでも皆様の参考になれば幸いです。

最後まで読んでくださり、ありがとうございました。