生配信管理システムのフロントエンド~配信現場に合わせたアジャイル開発~/Frontend of live management system: Agile optimized for live studio
by
take-k
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
icons8.com
Slide 2
Slide 2 text
はじめに ABEMAでは生放送の現場で使うための自社で開発した生配信管理ツールを使ってい る。そのツールの開発した際に、現場のニーズに十分答えられるようにアジャイルな 開発体制を構築した。 本セッションでは生配信管理ツールの開発で実践したアジャイルなプラクティスと使 用技術について説明し、アジャイルな開発をして得た知見を紹介する。
Slide 3
Slide 3 text
1. ABEMAの生配信管理ツールについて 2. アジャイルな開発の体制作り 3. アジャイルに適したフロントエンド技術
Slide 4
Slide 4 text
1. ABEMAの生配信管理ツールについて 2. アジャイルな開発の体制作り 3. アジャイルに適したフロントエンド技術
Slide 5
Slide 5 text
生放送 24時間365日20チャンネル 以上でリニア放送を行って いて、日によっては50以上 の番組が生放送している。
Slide 6
Slide 6 text
生放送の現場 多様な収録環境 自社のスタジオやテレビ朝日のスタジオ、 外部に機材を持っていて放送する場合も ある。 迅速なオペレーションが要求される システムへの操作も現場の担当者にとっ て使いやすいものでなければならない。
Slide 7
Slide 7 text
オペレーションの例 CMの挿入 生放送ではCMは現場のタ イミングで挿入する。確 実な操作感が得られるよ うに専用ハードウェアを 用いる。 フタ画の挿入 フタ画は番組の開始前や終了後などに差 し込む静止画像。管理システムから挿入 することでスタジオなどの配信機材を常 に立ち上げておく必要がなくなる。 従来のスタジオの機材だけでは対応できない
Slide 8
Slide 8 text
例:CM挿入(地上波) カメラ 切り替え機 地上波 映像 スタジオ CM 納品CM CM 操作 CM挿入まで5,4,3・・・
Slide 9
Slide 9 text
例:CM挿入(ABEMA) カメラ エンコーダー クラウド HLS・DASH CM1 映像 スタジオ・外現場 広告システムから入稿 CM2 管理ツール CM挿入信号 操作 CM1 CM2 CM挿入まで5,4,3・・・
Slide 10
Slide 10 text
管理ツール 生配信で必要なオペレーシ ョンが可能なWEBアプリケ ーション。 編成情報の確認や配信の開 始・終了・配信系統の切り 替え・CM挿入・エンコーダ の操作を行なう。
Slide 11
Slide 11 text
管理ツールの構成 カメラ エンコーダー スタジオ・外現場 DC Feeder 配信サーバー 管理ツール A系 B系 CM信号・エンコーダー操作 系統切り替え・CM消化・フタ画挿入 編成情報 CMボタン 信号
Slide 12
Slide 12 text
管理ツールの開発 生放送のリアルタイムな性質により、使い勝手の良さが重要だが、現場の人もどうい ったものが使いやすいかはあらかじめわかっているわけではない。 専用ハードウェアとの通信など過去に経験のない技術要素も存在していて、スケジュ ールの見積もりが立てづらい。 →不確実性に対処できるアジャイルな開発の体制が必要
Slide 13
Slide 13 text
1. ABEMAの生配信管理ツールについて 2. アジャイルな開発の体制作り 3. アジャイルに適したフロントエンド技術
Slide 14
Slide 14 text
チームビルディング ドメインエキスパート 技術より配信ドメインに詳しいチームが 開発を主導する。 ステークホルダーとの協業 現場の責任者も積極的にチームに参加し てもらい、時には現場のユーザーにヒア リングを行いフィードバックを行う。 フロントエンド(Streaming Client) バックエンド(コンテンツ配信) ステークホルダー(技術局)
Slide 15
Slide 15 text
開発目標の設定 横断的なチームにおける目的意識の共有 組織を横断したチームだったので目的意 識を揃えるためにチームのビジョンを設 定した。忘れないようにスクラムイベン ト毎に確認していた。 アジャイル的な開発の理解の促進 潜在的な課題解決には開発メンバーが思 っている以上にコミュニケーションが必 要になる時がある。アジャイル的な開発 を強く意識した目標を立てる。
Slide 16
Slide 16 text
チームのコミュニケーションの設計 スプリントレビュー 成果物を触ってもらい、ステークホルダ ーからフィードバックをもらう スプリントプランニング レビューを受けてタスクを決める デイリースクラム 開発で進捗の共有・実装懸念点を議論 スプリントレトロスペクティブ ポイント消化率を計測し振り返る Daily Scrum 1 w e e k Sprint Review & Retrospective & Planning Daily Scrum Daily Scrum Daily Scrum Sprint Review & Retrospective & Planning Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum
Slide 17
Slide 17 text
モック環境 スプリントレビューでは成 果物をステークホルダーに 提出するのが理想だが、バ ックエンドの対応を待つ必 要がある場合がある。 その場合でも使い勝手をレ ビューしてもらえるように、 クライアントで完結する環 境を用意しておく。
Slide 18
Slide 18 text
リモートコミュニケーションの設計 各種MTGは議事録ベースでシェアしてチ ーム内の知識の差を減らすようにする。 右図はNotionの議事録のテンプレートを 作成し、開発の負担を減らしつつスクラ ムイベントをこなせるようにした。 Notion の Database を使った議事録と Template https://www.notion.so/
Slide 19
Slide 19 text
ペアプログラミング環境の用意 必要に応じてコードを共同編集できるプ ラットフォームでエンジニア間のコミュ ニケーションを促進。 右図は Visual Studio Code の Live Share Extension を使ったペアプログラミング。 ● Webフロント初心者のメンタリング ● フロントとバックエンド間の実装 Visual Studio Code の Live Share Extension の画面
Slide 20
Slide 20 text
ポイント消化率の計測 タスクのデータベースとスプリントのデ ータベースを関連づけることでスプリン ト中のストーリーポイントの合計を出す ことができる。 Sprint毎のポイント消化率 NotionによるSprintの合計の算出
Slide 21
Slide 21 text
アジャイルな開発に適したツール スクラムといったアジャイルな開発プロセスは必要な手順が多く、運用するだけでも 相当なコストが発生する。しかし開発規模によりスクラムマスターをおくのは難しい 場合も多い。 一方で Notion のような開発プロセスの運用負荷を大幅に下げることができる開発ツ ールも存在する。 →開発の目的に則した技術選定も重要
Slide 22
Slide 22 text
1. ABEMAの生配信管理ツールについて 2. アジャイルな開発の体制作り 3. アジャイルに適したフロントエンド技術
Slide 23
Slide 23 text
AWS Amplify Git のブランチを指定するだ けで CI・CD・ホスティン グ 環境が作成ができる。 Amplify Library で GraphQL や認証のクライアントを提 供している。 Developer Git push AWS Amplify Console Application users AWS AppSync Amazon Cognito Amplify Library API https://www.amazon.com/aws
Slide 24
Slide 24 text
バックエンドの構成 生配信管理ツールのバック エンドの構築方法は Track A の直前の山中のセッショ ンをご覧ください。 https://developer.abema.io/2021/sessions/HXQDdvvFWy/
Slide 25
Slide 25 text
Previews AWS Amplify の機能で GithubのPull Request 毎に feature 環境を自動で作成し てくれる。 PRレビュー時の動作確認だ けでなく、ステークホルダ ーのためのモック環境を構 築も便利。 Amplify Console の Previews 画面
Slide 26
Slide 26 text
GraphQL GraphQLの型定義ファイルをフロントと バックエンドが両方管理するリポジトリ として、それぞれのsubmoduleとして取 り込み自動生成する。 フロント・バックエンドで互いにレビュ ーしあって共通言語として仕様を定義で きる。 Github で フロントとバックエンドで GraphQL の Schema をレビューし合う
Slide 27
Slide 27 text
参考:GraphQLのコード生成 @graphql-codegen/typescript Schema types から TypeScript の型を生成 @graphql-codegen/typescript-operations Operations types から TypeScript の型を生成 @graphql-codegen/typed-document-node Operations types からクエリの引数の TypeScript の型を生成 amplify-graphql-docs-generator Schema types から Operations types を生成する。プロジェクトの初期段階で Query の結果が要求するリクエストと一致する場合に便利。
Slide 28
Slide 28 text
Vue 3 Vue CLI による環境セットアップが容易 で初心者にも分かりやすい。 Single File Components や Composition API, Reactivity API などで凝集度の高い コンポーネントが実装ができる。 Vue 3 の Single File Components の例 https://v3.vuejs.org/guide/single-file-component.html
Slide 29
Slide 29 text
Atomic Design + Store パターン StudioTool.vue アプリ内の Store template organisms molecules atoms CMControl.vue CMAction.vue CMButton.vue ①ポーリングで情報を取得 ③Publish props props ②Storeを 更新 バックエンド
Slide 30
Slide 30 text
WebHID Chrome 87(2021年1月) からサポートさ れた機能。Report Descriptorを定義する ことでUSBで接続したデバイスの通信が 可能。 右図のブラウザの専用ダイアログから接 続を行う。
Slide 31
Slide 31 text
アジャイルな開発に適した技術選定 これまで紹介した技術のように ● DevOps を行い環境を整備する ● GraphQL や WebHID のように公表された言語を使用する ● コード規約やアーキテクチャを定める といったことで開発の負荷を下げつつチーム内のコミュニケーションを円滑にできる。 目的に応じて適切な技術を選択することで、アジャイルな開発にも大きく貢献する。
Slide 32
Slide 32 text
おわりに 生配信管理ツールのように特定の目的のために必要なソフトウェアが存在する。開発 にあたってはソフトウェアの目的に沿った開発体制の構築が重要である。 日々新しい技術や開発ツールもリリースされている。それらの技術を使いこなし、プ ロジェクトの目的に落とし込むことで大きな効果を発揮できる。
Slide 33
Slide 33 text
No content