PLAY DEVELOPERS BLOG

HuluやTVerなどの日本最大級の動画配信を支える株式会社PLAYが運営するテックブログです。

HuluやTVerなどの日本最大級の動画配信を支える株式会社PLAYが運営するテックブログです。

就業型インターン参加レポート:動画配信サービスの裏側とエンジニアリングの本質

こんにちは!インターン生の畑です。 今回は、就業型インターンの参加レポートをお届けします。

なかなかに濃い期間でしたので、得られた学びのアウトプットも兼ねて書きました!

インターンについて

play.jp

期間

2025/9/17~2025/10/31 (約1.5ヶ月間)

出会い

私は現在大学院一年で絶賛就活中なのですが、とある逆求人イベントでPLAYの人事の方とお話ししました。TVerやHuluなどは自分も使ったことがありましたし、"動画配信"という事業領域はここでしか経験できないのでは?と思い応募しました。

参加が決まってから知ったのですが、就業型インターンは私が第一号らしく、「自分でよかったんですか!?」と思ったり(笑)。ありがたいことですm(__)m

業務内容

React Nativeを用いた自社動画配信サービスのフロントエンド開発

担当業務

主に、レンダラーとなるコンポーネント開発や、プレイヤー周りの機能追加(後述)などをさせていただきました。テレビで動作するアプリケーションの開発は初めてだったので、開発初期はシミュレータの操作など不慣れな部分もありましたが、社員の方のサポートもありスムーズに開発を進めることができました。

使用技術

  • React Native
  • TypeScript
  • Shaka Player

動画配信サービスの裏側

再生ビーコンなるものがあるらしい

動画配信サービスにおいては、動画再生時にセッションを作成し、再生中に定期的に再生位置や動画のIDなどを保存し、誰がどの動画のどの時間を見ているかを監視しています。

この機能により、ユーザの動画視聴履歴の取得や同時視聴制限が可能になるんですね。もしビーコンがないと...

  • 視聴履歴が取得できなくなり、毎回動画が最初から再生されてしまう。
  • アカウント情報を共有すれば、同じアカウントで何人でも動画を見れてしまう。
  • ユーザから「動画が見れない」とクレームがあった時に、本当に見れていないのかが確認できない。

など、動画配信サービスはビーコン無しには成り立たないと言えます。実際に今回はビーコン送信機能の実装もさせていただきました。普段何も考えずに動画を見ていますが、裏側ではこれだけの処理が回っているというのは素直に驚きました。まさに動画配信サービスの根幹を担う機能なので、ワクワクが止まりませんでした!

SDUI (Server-Driven UI)

また、今回のシステムではSDUI(Server Driven UI)というアーキテクチャを採用していました。 SDUIは、一言で言うならば、「UIをバックエンドから指定し、フロント側はただその通りレンダリングするだけ」ということです。

何じゃそりゃ?って感じですが、例えばバックエンドから下記のようなjsonを受け取るとします。

{
    "RendererA": {
        "width": 1920,
        "height": 1080,
        "fullscreen": true,
        "items": [
            {
                "RendererB": {
                    "text": "Hello, World!",
                    "font_size": 14,
                    "color": "#FF0000"
                }
            },
            {
                "RendererC": {
                    "thumbnail": "http://example.com/image.png",
                    "caption": "Sample Image",
                    "contentId": "video123"
                }
            }
        ]
    }
}

フロント側では、このjsonで指定されたコンポーネントを呼び出し、さらにその中の文字列やデザインプロパティもjsonから取得するという流れです。この例で言うと、フロント側に、RendererA, RendererB, RendererCというコンポーネントが実装されており、各コンポーネントがwidthやtextなどのプロパティをもとに描画します。順序や構造もjson通りになるため、例えばRendererBとRendererCを入れ替えれば動画の下に文字列が表示されます(下図)。すなわち、json側からUIが変更できるという話ですね。

SDUIイメージ図

なんでそんなことすんの?と思いますが、この設計はiOSアプリなどアップデートがユーザ起因のシステムにおいてよく使われる設計です。SDUIでない場合、UIを変更したいときに、毎回アップデートを出してユーザにダウンロードさせる必要があります。またアップデートのたびに審査が必要になるため、素早い機能リリースができなくなってしまいます。 そこでフロント側にはレンダラーだけ用意してデザインの指定を全てバックエンド側で行えば、jsonだけ変更すればフロント側は何も変更せずにアップデートが可能となるわけです。テレビ上で動作するシステムにおいてもアップデートが手間なため、今回のシステムもこの設計を採用していたのですね。

LTもしてきました!

10/16(木)に社内LT会「てっくじゃむ」にも登壇してきました!LTではエンジニアとしての仕事の向き合い方というテーマで発表したので、ここでも紹介したいと思います!

developers.play.jp

発表した内容は大きく3つ!

  • AIとの向き合い方
  • 規模の大きなシステムの洗礼
  • タスクの先にあるもの

AIとの向き合い方

ハッカソンや研究など今までの開発ではほとんどが0→1のプロジェクトで、規模の小さくAIがプロジェクト全体を把握しやすいため、AI頼りの実装でもそれなりのものができていました。 しかし、今回のインターンのように既存のシステムに対しての機能追加、改修となると、既存の関数を使う必要があったり、他の機能への影響を見て修正すべきファイルを決める必要があります。生成AIでは規模の大きなシステムの全体を把握することはできず、関係ないファイルを編集したり、勝手に似たような関数を作ったりと、かなり好き放題やられました。。。 やはり業務レベルになると生成AIでは太刀打ちできない場面が非常に多く、だからこそ人がAIの出力を精査する必要があるのだなということを実感しました。

てっくじゃむ 発表スライド 頁5

規模の大きなシステムの洗礼

一つ目の話とも繫がるのですが、実際自分が書く時にも、既存の関数を使えていなかったり、何がどこにあるのかというキャッチアップにはかなり時間を要しました。ジョインして初期なので仕方ない部分もありますが、これまでにないほど大きなシステムでの開発だったので、初期はかなり手間取った印象です。レビュー指摘などで大分理解できてきたものの、エンジニアとしてはまだまだ未熟なのだなと実感しました。

てっくじゃむ 発表スライド 頁7

タスクの先にあるもの

実際に機能開発をする時に、どうしてもタスクをこなすことに集中してしまい、チケットに書かれている要件を満たせば完了!というマインドになっていました。しかしエンジニアたるもの、チケットにない異常値も徹底して考慮すべきであることを実感しました。よくマネージャーに「これこうやったらどうなるの?」と聞かれて、「お、それは考えてなかったですね。」という会話がありました。私もまだまだだな、、と痛感しました。。 エンジニアとして常にシステムを使う側の視点を忘れず、ある種、意地悪なほどの視点を持って動作確認をすることが重要ですね!

てっくじゃむ 発表スライド 頁8

と、長くなりましたが、LTでは上記のことに加え、責務分離の原則などについてもお話ししました!

最後に

長期の就業型インターンは初めてだったので、自分の力が通用するのかという不安もありましたが、社員の皆さんに手厚くサポートしてもらいなんとか走り抜けることができました! 1on1を通して技術面以外でも今の自分に足りていないもの、逆に自分が持っているものに気づけ、そして何より、「動くものを作る」ことと「エンジニアリング」はこんなにも違うのか、と痛感した期間でした!動画配信サービスならではの設計や機能などPLAYだからこその経験もとても刺激的でした⭐️

インターン開始前からサポートしてくださった人事の方、マネージャーや開発チームの皆さん、メンターさん、心の底から感謝しております!!! この経験をもとに、これからエンジニアとして世界に羽ばたいて参ります🔥🪽🔧