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

by CyberAgent

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

五藤佑典 YUSUKE GOTO https://ygoto3.com/ @ygoto3_ ● California State University, San Bernardino グラフィックデザイン専攻 ● ソフトウェアエンジニア @ サイバーエージェント ● ABEMA 開発本部 ○ Cross Device チームあらゆるデバイスに ABEMA を展開するための技術を提供するチーム ○ Streaming Client チーム ABEMA の再生品質を軸に UX エンジニアリングにコミットするチーム ○ 動画技術エバンジェリスト世界各国に足を運び動画技術に関する情報をキャッチアップし、社内外の動画サービスの発展に貢献するロール ○ DesignOps 推進バックエンド大規模組織でスケールできるプロダクトデザイン開発組織を構築する活動

Slide 3

Slide 3 text

in Video Technology and Product Design

Slide 4

Slide 4 text

板橋清信 KIYONOBU ITAHASHI keyiiiii @keyi8773 ● 2012年サイバーエージェント中途入社 ● ABEMA 開発本部 ○ ABEMA 開局〜 2017 年 Web クライアントチームで ABEMA 立ち上げ ○ 2018 年〜現在 Cross Device チームでさまざまなデバイス開発 ● テックリード ● グロースエンジニア

Slide 5

Slide 5 text

実装だけでなく、グロース戦略まで考えるグロースエンジニア Cross Device チームデバイス A デバイス B デバイス C グロース戦略まで考えないとサービスの成長も運用コスト面でも難しくなる

Slide 6

Slide 6 text

すべてのスクリーンに ABEMA を CHAPTER　01

Slide 7

Slide 7 text

テレビの再発明尊重する価値 ● 報道 ● 同時性 ● 生中継 ● 無料時間からの解放 ● タイムシフト ● 追っかけ再生 ● 倍速再生場所からの解放 ● スマートフォン ● タブレット ● PC ● スマートテレビ ● スマートディスプレイ ● スマートスピーカー ● ゲームコンソール

Slide 8

Slide 8 text

画面がある場所全てがターゲット場所からの解放 ● スマートフォン ● タブレット ● PC ● スマートテレビ ● スマートディスプレイ ● スマートスピーカー ● ゲームコンソール

Slide 9

Slide 9 text

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 ● ...

Slide 10

Slide 10 text

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 ● ...

Slide 11

Slide 11 text

マルチプラットフォーム的アプローチ ● 全てのプラットフォームに同じように ABEMA を実装する iOS のコード Android mobile のコード Web PC のコード Android TV のコード Linux-based TV のコード

Slide 12

Slide 12 text

マルチプラットフォーム的アプローチ ● 全てのプラットフォームに同じように ABEMA を実装する iOS のコード Android mobile のコード Web PC のコード Android TV のコード Linux-based TV のコード ... プラットフォームを増やすごとにエンジニアリソースが必要

Slide 13

Slide 13 text

New Device チーム ● デバイスの新規開拓を行うチーム ○ あらゆるデバイスに ABEMA を搭載することがミッション ○ 初期はマルチプラットフォーム的アプローチでアプリケーション開発

Slide 14

Slide 14 text

New Device チーム ● デバイスの新規開拓を行うチーム ○ あらゆるデバイスに ABEMA を搭載することがミッション ○ 初期はマルチプラットフォーム的アプローチでアプリケーション開発サポートするプラットフォームが増え、リソース枯渇

Slide 15

Slide 15 text

クロスプラットフォーム的アプローチ ● クロスプラットフォーム的な開発 ○ 1 つのコードを複数のプラットフォーム向けにビルドするマルチプラットフォーム的アプローチクロスプラットフォームなアプローチ

Slide 16

Slide 16 text

New Device チーム Cross Device チーム

Slide 17

Slide 17 text

Cross Device チーム ● マルチプラットフォーム的アプローチではなくクロスプラットフォーム的アプローチを ● マルチデバイスに使えるサービス開発に留まらずクロスデバイスに使えるサービス開発を

Slide 18

Slide 18 text

ユースケース駆動開発 ● テックスタックではなくユースケースを軸に設計を考える

Slide 19

Slide 19 text

ユースケース駆動開発 ● テックスタックではなくユースケースを軸に設計を考える ● ユースケースが同一のものを同じコード設計で開発する The mobile usecase Android iOS The PC usecase HTML Living Standard The connected TV usecase Android HTML Living Standard Unity

Slide 20

Slide 20 text

ユースケース駆動開発レイヤードアーキテクチャ ● ハードウェア／OS 層 ● GUI システム層 ● ドメイン／ユースケース層ドメインユースケース GUI システムハードウェア OS

Slide 21

Slide 21 text

ドメインユースケース GUI システムハードウェア OS ユースケースでコード設計を 1 つに統一するクロスプラットフォームな GUI フレームワークを絞るハードウェア／OS に依存する部分を最小にする

Slide 22

Slide 22 text

GUI システム CHAPTER　02

Slide 23

Slide 23 text

GUI システム GUI アプリケーションの関心事の中心イベントループ処理ライフサイクル管理 UI ウィジェット

Slide 24

Slide 24 text

GUI システム GUI アプリケーションの関心事の中心イベントループ処理ライフサイクル管理 UI ウィジェット未開拓デバイスであってもメジャーな GUI フレームワークをサポートしていれば勝率は数倍に上がる GUI フレームワーク

Slide 25

Slide 25 text

GUI フレームワーク 3 種の神器クロスプラットフォームな GUI フレームワーク HTML Living Standard / HTML5 Android Unity uGUI

Slide 26

Slide 26 text

GUI フレームワーク 3 種の神器クロスプラットフォームな GUI フレームワーク ● HTML Living Standard / HTML5 ○ IPTV 関連のさまざま標準規格から参照される HTML の標準仕様 ● Android ○ モバイル端末で実績がある GUI ベース OS ● Unity uGUI ○ ゲームコンソールへのリーチに強み

Slide 27

Slide 27 text

GUI サポートの例 Android Unity uGUI HTML Living Standard / HTML5

Slide 28

Slide 28 text

GUI サポートしていない場合の選択肢 ● 各プラットフォームが提供するグラフィックス API を使い GUI システム構築 ● GUI フレームワークの搭載検討 ○ オープンソースかつメディアに強い GUI フレームワーク ■ WPE ■ Google Cobalt ■ Qt

Slide 29

Slide 29 text

GUI サポートしていない場合の選択肢 ● 各プラットフォームが提供するグラフィックス API を使い GUI システム構築 ● GUI フレームワークの搭載検討 ○ オープンソースかつメディアに強い GUI フレームワーク ■ WPE ■ Google Cobalt ■ Qt GUI の基盤だけで高コスト

Slide 30

Slide 30 text

ドメインユースケース GUI システムハードウェア OS クロスプラットフォームな GUI フレームワークを絞る

Slide 31

Slide 31 text

ドメイン／ユースケース CHAPTER　03

Slide 32

Slide 32 text

● 初めてのゲームコンソール ○ チーム内にはもちろん、社内にも知見を持った人があまりいない ● 初めての開発環境 + 言語 ○ Unity + C# の業務経験が初めて ● リリース目標が割とタイト ○ あまり長く開発期間を設けることができない ● 少人数チームでのマルチデバイス対応 ○ 開発リソースをあまり増やせない制約不確実性高い問題誰も知見の無いデバイス開発において

Slide 33

Slide 33 text

1. ユースケースの洗い出し（作るものを決める） a. ABEMA として提供する機能は決まっているが、どういうユースケースになるか整理し作るものを決める 2. スケジュールを意識した実装（作る） a. ブロッキングが発生しづらい・組み換え可能な状態にする開発ロードマップ不確実性を排除するための

Slide 34

Slide 34 text

ユースケースの洗い出し

Slide 35

Slide 35 text

1. ユーザーストーリーの洗い出し ABEMA で提供する機能をもとに、CE（家庭用電化製品）デバイスとしてどういうユーザーストーリーになるのが適切か議論ユースケースの洗い出し

Slide 36

Slide 36 text

ユーザーストーリーの洗い出し ● セグメントを定義（新規ユーザー・復帰ユーザーなど） ● ユーザーの＜行動＞と＜心理＞をセットで議論

Slide 37

Slide 37 text

ユーザーストーリーの洗い出し

Slide 38

Slide 38 text

2. カスタマージャーニーマップ作成 ● ユーザーの視点から課題を見つけ解決案を見つけ出す ● UXデザインの整理 ● 既存の ABEMA（モバイル・Web）のファクトも取り入れるこれらを実現するユースケースの洗い出し

Slide 39

Slide 39 text

カスタマージャーニーマップの項目定義 ● ファネルを定義 ○ サービスへの関心度を可視化 ● KPI 設計 ○ ファネルに到達したかどうかの定義

Slide 40

Slide 40 text

ファネルを定義よりユーザーの関心が高い

Slide 41

Slide 41 text

KPI 設計ユーザーがどんなアクションを取ればファネルに到達するのかを分析・定義「探す」の KPI 設計の例

Slide 42

Slide 42 text

カスタマージャーニーマップ作成 ● ユーザーのアクション ● ユーザーの感情（ポジティブ／ネガティブ） ● プロブレムの洗い出しの記述

Slide 43

Slide 43 text

カスタマージャーニーマップファーストドラフトの例

Slide 44

Slide 44 text

検証モックアップ (ProtoPie) 作成ユーザーテストカスタマージャーニーマップ作成 PDCA サイクル

Slide 45

Slide 45 text

ユーザーテスト → カスタマージャーニーマップに反映ユーザーテストを繰り返し精度を上げる

Slide 46

Slide 46 text

3. ユーザーインサイトツリー ● ユーザーのインサイト（その時どう思ったのか）とアクションを直接線でつなぎパターンを洗い出す ● より重要なアクションへの誘導、ニッチなインサイトの発見などより詳細な機能単位で分析する上でカスタマージャーニーマップだけではチーム内での認識合わせが難しくなったためユーザーインサイトツリーを発明し、分析する上で併用したユースケースの洗い出し

Slide 47

Slide 47 text

ユーザーインサイトツリーアクション（赤）インサイト（黄色）新たに発見したアクション（水色）

Slide 48

Slide 48 text

ユーザーインサイトツリー ● サービスとして重要なアクションの決定 ● 各ページに対してどのような機能が必要か、まで定義する詳細ページの例

Slide 49

Slide 49 text

4. サイトマップ作成ユーザーのサービス全体の回遊設計ユーザーインサイトツリーはページ内や機能の詳細な回遊分析を、サイトマップはサービス全体の回遊を設計するユースケースの洗い出し

Slide 50

Slide 50 text

サイトマップ

Slide 51

Slide 51 text

5. カンプ作成デザイナーがデザインカンプを作成ユースケースの洗い出し

Slide 52

Slide 52 text

1. ユーザーストーリーの洗い出し 2. カスタマージャーニーマップ作成 3. ユーザーインサイトツリー 4. サイトマップ作成 5. カンプ作成これらをチーム全員でデザインしていくオープンデザインとして毎週開催コロナ禍ということもあり miro + zoom 上ですべて議論 ● ドキュメント化が進んだ（認識の齟齬が起きないようにできるだけローコンテキストで話をする必要性）ユースケースの洗い出し

Slide 53

Slide 53 text

今後の戦略カスタマージャーニーマップやユーザーインサイトツリーで可視化したことによって今後のグロース戦略が立てやすい状態になった実際のユーザー行動とカスタマージャーニーマップ・ユーザーインサイトツリーとの差分をみてどこを改善すればいいか戦略が立てやすいユースケースの洗い出し

Slide 54

Slide 54 text

実装

Slide 55

Slide 55 text

わからないことだらけの初めての開発実装不確実性を極限まで減らしていくことが必須！

Slide 56

Slide 56 text

1. ICONIX プロセスユースケース駆動開発。開発のフローが予め定義されているので迷う必要がない ● 要求定義 ○ 現状の ABEMA でのドメインモデルの洗い出し ○ オープンデザインでみんなで洗い出したユースケースをレビュー・修正 ● 予備設計 ○ ロバストネス図の作成本来はここから詳細設計を経て実装に移っていくが、開発期間も限られているので予備設計（ロバストネス図作成）と平行して開発着手実装

Slide 57

Slide 57 text

ドメインモデル図集約と汎化の関係性を可視化

Slide 58

Slide 58 text

ドメインモデル図

Slide 59

Slide 59 text

すべてのユースケースを記述し、関係性を可視化するユースケース記述ユースケースを記述し、代替コースがある場合は明記する

Slide 60

Slide 60 text

ユースケース記述すべてのユースケースを記述し、関係性を可視化する

Slide 61

Slide 61 text

ロバストネス図ユースケース毎にロバストネス図を作成

Slide 62

Slide 62 text

ロバストネス図すべてのユースケースに対してのロバストネス図

Slide 63

Slide 63 text

2. クリーンアーキテクチャ ● 少人数チームで複数のデバイスを管理しないといけない ○ デバイス毎に異なるアーキテクチャで実装するのは辛い ○ ロジックを共通化できるところは共通化し、デバイスに密依存するところはできる限り切り離したい ● チーム全員が新規デバイスに対する知識を理解してから開発着手では間に合わない ○ ある程度走りながらキャッチアップしても問題ないようにしないといけない実装クリーンアーキテクチャを導入

Slide 64

Slide 64 text

2. クリーンアーキテクチャ ● 層ごとに関心を分離させられる ○ 内側を共通ロジックで持つことができれば外側はどんなデバイスであっても理論的には動作させることができる ● 意思決定を遅らせることができる ○ 詳細についてはできるだけ決定を遅らせることができる ○ サービスにとってのコアの部分（ドメイン・ユースケース）の実装をしながらデバイス固有の問題をキャッチアップする余力を作る実装

Slide 65

Slide 65 text

2. クリーンアーキテクチャ ● インターフェースさえ決められれば別々で開発をすすめることができる ○ ブロッキングをできるだけ発生させない開発ができる ● ユースケース実装に集中 ○ ICONIX プロセスでのユースケース記述・ロバストネス図に対応する形でドメイン層を実装することで粒度を間違えない実装

Slide 66

Slide 66 text

クリーンアーキテクチャ ● 層ごとに実装し、ドメイン層に関心を集める ● 層をまたぐデータの受け渡しは必ずインターフェースを介してやりとりする

Slide 67

Slide 67 text

クリーンアーキテクチャ ● 外側の層は（理論上）レゴブロックのように組み換え可能 ● 今後実装するデバイスにおいても共通のコード（もしくは同じロジック）で実装可能今回の Switch 開発だけでなく、今後開発する別デバイスにおいても不確実性を減らすことができる

Slide 68

Slide 68 text

実装 1. ICONIX プロセス 2. クリーンアーキテクチャこれらを戦略的に導入し、最小限の不確実性（新規デバイス固有の問題）に留められるようにできました

Slide 69

Slide 69 text

ドメインユースケース GUI システムハードウェア OS ユースケースでコード設計を 1 つに統一するクロスプラットフォームな GUI フレームワークを絞る

Slide 70

Slide 70 text

ハードウェア／OS CHAPTER　04

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

ハードウェア／OS ドメインユースケース GUI システムハードウェア OS 未開拓デバイスはハードウェアも OS も初めて触れるものばかりソフトウェアでカバーできないシステム領域

Slide 74

Slide 74 text

ハードウェア／OS 動画サービスではハードウェア／OS のどんな箇所が課題化するのかドメインユースケース GUI システムハードウェア OS

Slide 75

Slide 75 text

ハードウェア／OS 動画サービスではハードウェア／OS のどんな箇所が課題化するのかドメインユースケース GUI システム ● 動画再生 ● コンテンツ保護 ● 通信処理ハードウェア OS

Slide 76

Slide 76 text

動画再生コーデックなど権利問題が多い動画処理に関わる API は大体プラットフォームから提供されている

Slide 77

Slide 77 text

動画再生 https://www.ffmpeg.org/legal.html

Slide 78

Slide 78 text

動画再生コーデックなど権利問題が多い動画処理に関わる API は大体プラットフォームから提供されている動画再生に関する処理はプラットフォーム提供の API を利用する ● **Decoder / **Codec ● **Extractor ● … etc

Slide 79

Slide 79 text

動画再生コーデックなど権利問題が多い動画処理に関わる API は大体プラットフォームから提供されている動画再生に関する処理はプラットフォーム提供の API を利用する ● **Decoder / **Codec ● **Extractor ● … etc 場合によっては、 GUI フレームワークが用意する描画用バッファへの繋ぎ込みも個別で必要

Slide 80

Slide 80 text

動画再生：同時デコード数の制限アプリケーションに許可されている同時デコード数に制限 ● 家電など利用用途が限定されているデバイスの場合は SoC の性能が利用用途に最適化されているケースが多い ● 同時デコード数を増やしたい場合など、ユースケースを分割せざるをえない例となる

Slide 81

Slide 81 text

動画再生：同時デコード容量の制限動画の解像度をスクリーンサイズに合わせていいとは限らない ● 前述のデコード数同様に同時デコード時のデータ量にも制限は存在する瞬間的なデコード量のバースト ● エンコード設定で平均ビットレートだけ指定しているケースなど、映像品質を優先して瞬間的なビットレートバーストで再生不具合が生じる ○ 特に家電製品の場合は同時録画など周辺機器でのデコード処理への影響も考慮する必要がある

Slide 82

Slide 82 text

コンテンツ保護セキュリティレベルが高い DRM システムの提供はハードウェア依存 TEE (Trusted Execution Environment) によりメイン OS とは隔離された実行環境で動画コンテンツの復号処理が行われる https://developer.arm.com/ip-products/security-ip/trustzone/trustzone-for-cortex-a

Slide 83

Slide 83 text

Slide 84

Slide 84 text

コンテンツ保護セキュリティレベルが高い DRM システムの提供はハードウェア依存 ● Google Widevine の Security Levels の例 Level 1 復号含めた全てのビデオ処理を TEE の中で行う Level 2 復号は TEE の中で行うが、解読されたバッファが OS に返された後ビデオ処理が行われる Level 3 復号含めた全てのビデオ処理を OS の中で行う

Slide 85

Slide 85 text

通信 ABEMA はインターネットテレビ ● インターネット通信ができないとサービス自体が提供できない

Slide 86

Slide 86 text

通信 ABEMA はインターネットテレビ ● インターネット通信ができないとサービス自体が提供できないデバイスによっては通信機能の制限が想定以上に厳しい

Slide 87

Slide 87 text

通信 ABEMA はインターネットテレビ ● インターネット通信ができないとサービス自体が提供できないデバイスによっては通信機能の制限が想定以上に厳しいスマートフォン、Web ブラウザ向けの開発に慣れていると想定外なことも ...

Slide 88

Slide 88 text

通信通信への制限はユースケースにも影響してくるドメインユースケース GUI システムハードウェア OS

Slide 89

Slide 89 text

通信：待機モード復帰時の通信制限消費電力を抑えるための待機モード（スリープモード）からの復帰時アプリケーション動作に関わるいくつかの機能がコールドスタンバイ状態

Slide 90

Slide 90 text

通信：待機モード復帰時の通信制限消費電力を抑えるための待機モード（スリープモード）からの復帰時通信接続確立状態になるまでに相当の時間がかかるアプリケーション動作に関わるいくつかの機能がコールドスタンバイ状態

Slide 91

Slide 91 text

通信：待機モード復帰時の通信制限消費電力を抑えるための待機モード（スリープモード）からの復帰時通信接続確立状態になるまでに相当の時間がかかる通信接続が確立するまでの代替ユースケースが必要アプリケーション動作に関わるいくつかの機能がコールドスタンバイ状態

Slide 92

Slide 92 text

通信：同時接続数の制限ソケットや TLS 同時処理数に制限があるケースがある ● 同時接続を回避させるために ○ アプリケーション側の接続管理（シリアル処理など） ○ 接続数が少ないタイミングでのプリフェッチ ○ 1 画面に同時に表示する情報の削減 ○ リクエスト頻度を削減する UI デザイン ● GUI フレームワークとネイティブライブラリで各々で接続管理している場合は同期処理も必要

Slide 93

Slide 93 text

通信：組み込み証明書の搭載有無対象 OS に SSL に使用している CA 証明書が搭載されているとは限らない ● どんなデバイス対応にも言えることだが、新しいデバイスでは要確認 ○ プラットフォーマー側での証明書搭載可能か？ ■ 可能であっても手続きに時間がかかる場合も ○ アプリケーション側に証明書インポート API があるか？ ■ あったとしてもインポート処理のオーバーヘッドは問題ないか