すべてのスクリーンにABEMAを！未開拓デバイス向けアプリケーション開発への挑戦

クロスデバイスチームでは主にCEデバイス（家庭用電化製品）を中心に複数のデバイスにまたがりABEMAアプリを開発・提供しています。

このセッションでは、チームで誰も知見のない未開拓のデバイス開発に対して不確実性をどう排除していったのか、新規デバイスへのユースケースにどう向き合ったのか、少人数で多くのデバイスを開発するためにどういうことを考えて開発しているかなどを紹介します。

https://developer.abema.io/2021/sessions/hsglnmXTjo/?utm_medium=social&utm_source=slideshare

Transcript

2. 五藤 佑典 YUSUKE GOTO https://ygoto3.com/ @ygoto3_ • California State University, San Bernardino グラフィックデザイン専攻 • ソフトウェアエンジニア @ サイバーエージェント • ABEMA 開発本部 ◦ Cross Device チーム あらゆるデバイスに ABEMA を展開するための技術を提供するチーム ◦ Streaming Client チーム ABEMA の再生品質を軸に UX エンジニアリングにコミットするチーム ◦ 動画技術エバンジェリスト 世界各国に足を運び動画技術に関する情報をキャッチアップし、 社内外の動画サービスの発展に貢献するロール ◦ DesignOps 推進バックエンド 大規模組織でスケールできるプロダクトデザイン開発組織を構築する活動
3. in Video Technology and Product Design
4. 板橋 清信 KIYONOBU ITAHASHI keyiiiii @keyi8773 • 2012年 サイバーエージェント中途入社 • ABEMA 開発本部 ◦ ABEMA 開局 〜 2017 年 Web クライアントチームで ABEMA 立ち上げ ◦ 2018 年 〜 現在 Cross Device チームでさまざまなデバイス開発 • テックリード • グロースエンジニア
5. 実装だけでなく、グロース戦略まで考える グロースエンジニア Cross Device チーム デバイス A デバイス B デバイス C グロース戦略まで考えないとサービスの 成長も運用コスト面でも難しくなる
6. すべてのスクリーンに ABEMA を CHAPTER　01
7. テレビの再発明 尊重する価値 • 報道 • 同時性 • 生中継 • 無料 時間からの解放 • タイムシフト • 追っかけ再生 • 倍速再生 場所からの解放 • スマートフォン • タブレット • PC • スマートテレビ • スマートディスプレイ • スマートスピーカー • ゲームコンソール
8. 画面がある場所全てがターゲット 場所からの解放 • スマートフォン • タブレット • PC • スマートテレビ • スマートディスプレイ • スマートスピーカー • ゲームコンソール
9. 20 以上のサポートデバイス • iPhone • iPad • Apple TV • Android Smartphone • Android Tablet • Android TV • Fire Tablet • Amazon Fire TV • Google Chrome • Mozilla Firefox • Internet Explorer • Microsoft Edge • Apple Safari • Google Chromecast • Google Daydream View • Amazon Echo • LINE Clova Desk • SONY BRAVIA • Panasonic VIERA • TOSHIBA REGZA • LEOPALACE21 Life Stick • CCCAIR Air Stick • ...
10. 20 以上のサポートデバイス こんなにいっぱい どうやって開発しているのか？ • iPhone • iPad • Apple TV • Android Smartphone • Android Tablet • Android TV • Fire Tablet • Amazon Fire TV • Google Chrome • Mozilla Firefox • Internet Explorer • Microsoft Edge • Apple Safari • Google Chromecast • Google Daydream View • Amazon Echo • LINE Clova Desk • SONY BRAVIA • Panasonic VIERA • TOSHIBA REGZA • LEOPALACE21 Life Stick • CCCAIR Air Stick • ...
11. マルチプラットフォーム的アプローチ • 全てのプラットフォームに同じように ABEMA を実装する iOS のコード Android mobile のコード Web PC のコード Android TV のコード Linux-based TV のコード
12. マルチプラットフォーム的アプローチ • 全てのプラットフォームに同じように ABEMA を実装する iOS のコード Android mobile のコード Web PC のコード Android TV のコード Linux-based TV のコード ... プラットフォームを増やすごとに エンジニアリソースが必要
13. New Device チーム • デバイスの新規開拓を行うチーム ◦ あらゆるデバイスに ABEMA を搭載することがミッション ◦ 初期はマルチプラットフォーム的アプローチでアプリケーション開発
14. New Device チーム • デバイスの新規開拓を行うチーム ◦ あらゆるデバイスに ABEMA を搭載することがミッション ◦ 初期はマルチプラットフォーム的アプローチでアプリケーション開発 サポートするプラットフォームが増え、 リソース枯渇
15. クロスプラットフォーム的アプローチ • クロスプラットフォーム的な開発 ◦ 1 つのコードを複数のプラットフォーム向けにビルドする マルチプラットフォーム的 アプローチ クロスプラットフォームな アプローチ
16. New Device チーム Cross Device チーム
17. Cross Device チーム • マルチプラットフォーム的アプローチではなく クロスプラットフォーム的アプローチを • マルチデバイスに使えるサービス開発に留まらず クロスデバイスに使えるサービス開発を
18. ユースケース駆動開発 • テックスタックではなくユースケースを軸に設計を考える
19. ユースケース駆動開発 • テックスタックではなくユースケースを軸に設計を考える • ユースケースが同一のものを同じコード設計で開発する The mobile usecase Android iOS The PC usecase HTML Living Standard The connected TV usecase Android HTML Living Standard Unity
20. ユースケース駆動開発 レイヤードアーキテクチャ • ハードウェア／OS 層 • GUI システム層 • ドメイン／ユースケース層 ドメイン ユースケース GUI システム ハードウェア OS
21. ドメイン ユースケース GUI システム ハードウェア OS ユースケースでコード設計を 1 つに統一する クロスプラットフォームな GUI フレームワークを絞る ハードウェア／OS に依存する部分を 最小にする
22. GUI システム CHAPTER　02
23. GUI システム GUI アプリケーションの関心事の中心 イベントループ処理 ライフサイクル管理 UI ウィジェット
24. GUI システム GUI アプリケーションの関心事の中心 イベントループ処理 ライフサイクル管理 UI ウィジェット 未開拓デバイスであってもメジャーな GUI フレームワークを サポートしていれば勝率は数倍に上がる GUI フレームワーク
25. GUI フレームワーク 3 種の神器 クロスプラットフォームな GUI フレームワーク HTML Living Standard / HTML5 Android Unity uGUI
26. GUI フレームワーク 3 種の神器 クロスプラットフォームな GUI フレームワーク • HTML Living Standard / HTML5 ◦ IPTV 関連のさまざま標準規格から参照される HTML の標準仕様 • Android ◦ モバイル端末で実績がある GUI ベース OS • Unity uGUI ◦ ゲームコンソールへのリーチに強み
27. GUI サポートの例 Android Unity uGUI HTML Living Standard / HTML5
28. GUI サポートしていない場合の選択肢 • 各プラットフォームが提供するグラフィックス API を使い GUI システム構築 • GUI フレームワークの搭載検討 ◦ オープンソースかつメディアに強い GUI フレームワーク ▪ WPE ▪ Google Cobalt ▪ Qt
29. GUI サポートしていない場合の選択肢 • 各プラットフォームが提供するグラフィックス API を使い GUI システム構築 • GUI フレームワークの搭載検討 ◦ オープンソースかつメディアに強い GUI フレームワーク ▪ WPE ▪ Google Cobalt ▪ Qt GUI の基盤だけで 高コスト
30. ドメイン ユースケース GUI システム ハードウェア OS クロスプラットフォームな GUI フレームワークを絞る
31. ドメイン／ユースケース CHAPTER　03
32. • 初めてのゲームコンソール ◦ チーム内にはもちろん、社内にも知見を持った人があまりいない • 初めての開発環境 + 言語 ◦ Unity + C# の業務経験が初めて • リリース目標が割とタイト ◦ あまり長く開発期間を設けることができない • 少人数チームでのマルチデバイス対応 ◦ 開発リソースをあまり増やせない制約 不確実性高い問題 誰も知見の無いデバイス開発において
33. 1. ユースケースの洗い出し（作るものを決める） a. ABEMA として提供する機能は決まっているが、どういうユースケースになるか整 理し作るものを決める 2. スケジュールを意識した実装（作る） a. ブロッキングが発生しづらい・組み換え可能な状態にする 開発ロードマップ 不確実性を排除するための
34. ユースケースの洗い出し
35. 1. ユーザーストーリーの洗い出し ABEMA で提供する機能をもとに、CE（家庭用電化製品）デバイスとしてどういうユーザース トーリーになるのが適切か議論 ユースケースの洗い出し
36. ユーザーストーリーの洗い出し • セグメントを定義（新規ユーザー・復帰ユーザーなど） • ユーザーの＜行動＞と＜心理＞をセットで議論
37. ユーザーストーリーの洗い出し
38. 2. カスタマージャーニーマップ作成 • ユーザーの視点から課題を見つけ解決案を見つけ出す • UXデザインの整理 • 既存の ABEMA（モバイル・Web）のファクトも取り入れる これらを実現する ユースケースの洗い出し
39. カスタマージャーニーマップの項目定義 • ファネルを定義 ◦ サービスへの関心度を可視化 • KPI 設計 ◦ ファネルに到達したかどうかの定義
40. ファネルを定義 よりユーザーの関心が高い
41. KPI 設計 ユーザーがどんなアクションを取ればファネルに到達するのかを分析・定義 「探す」の KPI 設計の例
42. カスタマージャーニーマップ作成 • ユーザーのアクション • ユーザーの感情（ポジティブ／ネガティブ） • プロブレムの洗い出し の記述
43. カスタマージャーニーマップ ファーストドラフトの例
44. 検証 モックアップ (ProtoPie) 作成 ユーザーテスト カスタマージャーニーマッ プ作成 PDCA サイクル
45. ユーザーテスト → カスタマージャーニーマップに反映 ユーザーテストを繰り返し精度を上げる
46. 3. ユーザーインサイトツリー • ユーザーのインサイト（その時どう思ったのか）とアクションを直接線でつなぎパターンを 洗い出す • より重要なアクションへの誘導、ニッチなインサイトの発見など より詳細な機能単位で分析する上でカスタマージャーニーマップだけではチーム内での 認識合わせが難しくなったためユーザーインサイトツリーを発明し、分析する上で併用した ユースケースの洗い出し
47. ユーザーインサイトツリー アクション（赤） インサイト（黄色） 新たに発見したアクション（水色）
48. ユーザーインサイトツリー • サービスとして重要なアクションの決定 • 各ページに対してどのような機能が必要か、まで定義する 詳細ページの例
49. 4. サイトマップ作成 ユーザーのサービス全体の回遊設計 ユーザーインサイトツリーはページ内や機能の詳細な回遊分析を、サイトマップはサー ビス全体の回遊を設計する ユースケースの洗い出し
50. サイトマップ
51. 5. カンプ作成 デザイナーがデザインカンプを作成 ユースケースの洗い出し
52. 1. ユーザーストーリーの洗い出し 2. カスタマージャーニーマップ作成 3. ユーザーインサイトツリー 4. サイトマップ作成 5. カンプ作成 これらをチーム全員でデザインしていくオープンデザインとして毎週開催 コロナ禍ということもあり miro + zoom 上ですべて議論 • ドキュメント化が進んだ （認識の齟齬が起きないようにできるだけローコンテキストで話をする必要性） ユースケースの洗い出し
53. 今後の戦略 カスタマージャーニーマップやユーザーインサイトツリーで可視化したことによって今後のグ ロース戦略が立てやすい状態になった 実際のユーザー行動とカスタマージャーニーマップ・ユーザーインサイトツリーとの差分 をみてどこを改善すればいいか戦略が立てやすい ユースケースの洗い出し
54. 実装
55. わからないことだらけの初めての開発 実装 不確実性を極限まで 減らしていくことが必須！
56. 1. ICONIX プロセス ユースケース駆動開発。開発のフローが予め定義されているので迷う必要がない • 要求定義 ◦ 現状の ABEMA でのドメインモデルの洗い出し ◦ オープンデザインでみんなで洗い出したユースケースをレビュー・修正 • 予備設計 ◦ ロバストネス図の作成 本来はここから詳細設計を経て実装に移っていくが、開発期間も限られているので予備 設計（ロバストネス図作成）と平行して開発着手 実装
57. ドメインモデル図 集約と汎化の関係性を可視化
58. ドメインモデル図
59. すべてのユースケースを記述し、関係性を可視化する ユースケース記述 ユースケースを記述し、代替コースがある場合は明記する
60. ユースケース記述 すべてのユースケースを記述し、関係性を可視化する
61. ロバストネス図 ユースケース毎にロバストネス図を作成
62. ロバストネス図 すべてのユースケースに対してのロバストネス図
63. 2. クリーンアーキテクチャ • 少人数チームで複数のデバイスを管理しないといけない ◦ デバイス毎に異なるアーキテクチャで実装するのは辛い ◦ ロジックを共通化できるところは共通化し、デバイスに密依存するところはできる限り 切り離したい • チーム全員が新規デバイスに対する知識を理解してから開発着手では間に合わない ◦ ある程度走りながらキャッチアップしても問題ないようにしないといけない 実装 クリーンアーキテクチャを導入
64. 2. クリーンアーキテクチャ • 層ごとに関心を分離させられる ◦ 内側を共通ロジックで持つことができれば外側はどんなデバイスであっても理論的 には動作させることができる • 意思決定を遅らせることができる ◦ 詳細についてはできるだけ決定を遅らせることができる ◦ サービスにとってのコアの部分（ドメイン・ユースケース）の実装をしながらデバイス 固有の問題をキャッチアップする余力を作る 実装
65. 2. クリーンアーキテクチャ • インターフェースさえ決められれば別々で開発をすすめることができる ◦ ブロッキングをできるだけ発生させない開発ができる • ユースケース実装に集中 ◦ ICONIX プロセスでのユースケース記述・ロバストネス図に対応する形でドメイン層 を実装することで粒度を間違えない 実装
66. クリーンアーキテクチャ • 層ごとに実装し、ドメイン層に関心を集める • 層をまたぐデータの受け渡しは必ずインターフェース を介してやりとりする
67. クリーンアーキテクチャ • 外側の層は（理論上）レゴブロックのように組 み換え可能 • 今後実装するデバイスにおいても共通の コード（もしくは同じロジック）で実装可能 今回の Switch 開発だけでなく、 今後開発する別デバイスにおいても 不確実性を減らすことができる
68. 実装 1. ICONIX プロセス 2. クリーンアーキテクチャ これらを戦略的に導入し、最小限の不確実性（新規デバイス固有の問題）に留められる ようにできました
69. ドメイン ユースケース GUI システム ハードウェア OS ユースケースでコード設計を 1 つに統一する クロスプラットフォームな GUI フレームワークを絞る
70. ハードウェア／OS CHAPTER　04
71. ドメイン ユースケース GUI システム ハードウェア OS ユースケースでコード設計を 1 つに統一する クロスプラットフォームな GUI フレームワークを絞る
72. ドメイン ユースケース GUI システム ハードウェア OS ユースケースでコード設計を 1 つに統一する クロスプラットフォームな GUI フレームワークを絞る ハードウェア／OS に依存する部分を 最小にする
73. ハードウェア／OS ドメイン ユースケース GUI システム ハードウェア OS 未開拓デバイスはハードウェアも OS も 初めて触れるものばかり ソフトウェアで カバーできないシステム領域
74. ハードウェア／OS 動画サービスではハードウェア／OS の どんな箇所が課題化するのか ドメイン ユースケース GUI システム ハードウェア OS
75. ハードウェア／OS 動画サービスではハードウェア／OS の どんな箇所が課題化するのか ドメイン ユースケース GUI システム • 動画再生 • コンテンツ保護 • 通信処理 ハードウェア OS
76. 動画再生 コーデックなど権利問題が多い動画処理に関わる API は 大体プラットフォームから提供されている
77. 動画再生 https://www.ffmpeg.org/legal.html
78. 動画再生 コーデックなど権利問題が多い動画処理に関わる API は 大体プラットフォームから提供されている 動画再生に関する処理はプラットフォーム提供の API を利用する • **Decoder / **Codec • **Extractor • … etc
79. 動画再生 コーデックなど権利問題が多い動画処理に関わる API は 大体プラットフォームから提供されている 動画再生に関する処理はプラットフォーム提供の API を利用する • **Decoder / **Codec • **Extractor • … etc 場合によっては、 GUI フレームワークが用意する描画用 バッファへの繋ぎ込みも個別で必要
80. 動画再生：同時デコード数の制限 アプリケーションに許可されている同時デコード数に制限 • 家電など利用用途が限定されているデバイスの場合は SoC の性能が利用用途に最適化されているケースが多い • 同時デコード数を増やしたい場合など、ユースケースを分割せざるをえない例となる
81. 動画再生：同時デコード容量の制限 動画の解像度をスクリーンサイズに合わせていいとは限らない • 前述のデコード数同様に同時デコード時のデータ量にも制限は存在する 瞬間的なデコード量のバースト • エンコード設定で平均ビットレートだけ指定しているケースなど、映像品質を優先して瞬 間的なビットレートバーストで再生不具合が生じる ◦ 特に家電製品の場合は同時録画など周辺機器でのデコード処理への影響も考慮 する必要がある
82. コンテンツ保護 セキュリティレベルが高い DRM システムの提供はハードウェア依存 TEE (Trusted Execution Environment) により メイン OS とは隔離された実行環境で 動画コンテンツの復号処理が行われる https://developer.arm.com/ip-products/security-ip/trustzone/trustzone-for-cortex-a
83. コンテンツ保護 セキュリティレベルが高い DRM システムの提供はハードウェア依存 TEE (Trusted Execution Environment) により メイン OS とは隔離された実行環境で 動画コンテンツの復号処理が行われる https://developer.arm.com/ip-products/security-ip/trustzone/trustzone-for-cortex-a メイン OS がハックされても 動画データは保護される
84. コンテンツ保護 セキュリティレベルが高い DRM システムの提供はハードウェア依存 • Google Widevine の Security Levels の例 Level 1 復号含めた全てのビデオ 処理を TEE の中で行う Level 2 復号は TEE の中で行う が、解読されたバッファが OS に返された後ビデオ処 理が行われる Level 3 復号含めた全てのビデオ 処理を OS の中で行う
85. 通信 ABEMA はインターネットテレビ • インターネット通信ができないとサービス自体が提供できない
86. 通信 ABEMA はインターネットテレビ • インターネット通信ができないとサービス自体が提供できない デバイスによっては 通信機能の制限が想定以上に厳しい
87. 通信 ABEMA はインターネットテレビ • インターネット通信ができないとサービス自体が提供できない デバイスによっては 通信機能の制限が想定以上に厳しい スマートフォン、Web ブラウザ向けの開発に 慣れていると想定外なことも ...
88. 通信 通信への制限は ユースケースにも影響してくる ドメイン ユースケース GUI システム ハードウェア OS
89. 通信：待機モード復帰時の通信制限 消費電力を抑えるための待機モード（スリープモード）からの復帰時 アプリケーション動作に関わるいくつかの機能がコールドスタンバイ状態
90. 通信：待機モード復帰時の通信制限 消費電力を抑えるための待機モード（スリープモード）からの復帰時 通信接続確立状態になるまでに相当の時間がかかる アプリケーション動作に関わるいくつかの機能がコールドスタンバイ状態
91. 通信：待機モード復帰時の通信制限 消費電力を抑えるための待機モード（スリープモード）からの復帰時 通信接続確立状態になるまでに相当の時間がかかる 通信接続が確立するまでの代替ユースケースが必要 アプリケーション動作に関わるいくつかの機能がコールドスタンバイ状態
92. 通信：同時接続数の制限 ソケットや TLS 同時処理数に制限があるケースがある • 同時接続を回避させるために ◦ アプリケーション側の接続管理（シリアル処理など） ◦ 接続数が少ないタイミングでのプリフェッチ ◦ 1 画面に同時に表示する情報の削減 ◦ リクエスト頻度を削減する UI デザイン • GUI フレームワークとネイティブライブラリで各々で接続管理している場合は 同期処理も必要
93. 通信：組み込み証明書の搭載有無 対象 OS に SSL に使用している CA 証明書が搭載されているとは限らない • どんなデバイス対応にも言えることだが、新しいデバイスでは要確認 ◦ プラットフォーマー側での証明書搭載可能か？ ▪ 可能であっても手続きに時間がかかる場合も ◦ アプリケーション側に証明書インポート API があるか？ ▪ あったとしてもインポート処理のオーバーヘッドは問題ないか
94. ドメイン ユースケース GUI システム ハードウェア OS ユースケースでコード設計を 1 つに統一する クロスプラットフォームな GUI フレームワークを絞る ハードウェア／OS に依存する部分を 最小にする