J-Stream Equipmedia（ジェイストリーム・イクイップメディア。以下、EQ）は、OVP(Online Video Platform)と呼ばれるSaaS型サービスで、2012年のサービス提供開始から今年で10年目を迎える。動画領域では4-5年で主要技術が一変することも珍しくないなか、サービス開発の裏側では日々技術の変革が起きている。今回は、2人のフロントエンドエンジニアにEQの新機能追加や開発への想いについて聞いた。
時代とともに変化し続けきた動画配信。コロナ環境下では、1.8か月での新機能リリースも
EQは2012年からサービス提供を開始した自社開発のSaaS型OVPプロダクトです。管理画面上から動画ファイルをアップロードして配信できる形式に変換する「トランスコード」部分と、それをWebブラウザやアプリなどで視聴する「プレイヤー」部分の、大きく二つの機能から成り立っています。
この大きな二つの機能の他、ライブ配信を行うEQ Liveや、視聴分析を行うEQ VA（Video Analytics）など複数のサービスで成り立っている、動画配信に関する機能を網羅した総合的なプラットフォームです。
開発に際しては、様々なデバイスへ対応する為、デバイスの仕様や知識はもちろん、複数のコーデックや配信方式などを理解する必要があります。また、ユーザー企業のご担当者が、動画に詳しくなくても迷わず理解できるよう、設定方法や見え方などのUI/UXへの知識やスキルも必要です。
技術的な面白さという点では、エンコードに関してはスピードや高画質化、プレイヤーに関しては字幕や広告挿入といったことがあげられます。同時に開発の根幹としては、ユーザー企業の声を反映し改善していく「プロダクトの成長」という部分に携わります。キャリアパスとしてはプロジェクトマネージャーやディレクター、プロデューサーなどを目指す方にも最適な部署であると言えますね。
今回の2人は主にフロントエンド部分の開発を担当していますが、時代の変化に応じて日々サービスも変化させています。
コロナ禍への対応としては、企業や団体において動画活用が急速に広がりました。ご契約企業からも、より簡単なライブ配信機能に関する要望が多く寄せられました。そのような中、昨年5月には、後述します社内の共通開発基盤を手がける「J-Stream Cloudチーム」と連動して、開発期間1.8か月での疑似ライブ機能の新規リリースも行いました。
疑似ライブは文字通り「疑似的なライブ」を行う為の機能です。オンデマンドファイルを時間設定する事で、時間になるとライブ形式で収録済みの動画が配信されるというものです。
コロナ環境下においては、感染症拡大防止の点から、多くの企業が働き方を変える中で、コミュニケーション不足の課題が急増しました。その中で、ライブ配信の持つ速報性や臨場感が注目されたのですが、技術面の不安から導入に二の足を踏むケースも多かったのです。
というのも、通常、ライブ配信とは、その性質上コンテンツの制作と配信を同時に行うものです。制作だけでも生放送となるとさまざまな段取りがあり、多くの手間を要します。映像や音声のスイッチングやPAなどを考えると配信の部分まで気が回らなく、気がづいたら配信が止まっていた、といったことも一般的にはよくある話です。
しかし、ビジネスでの活用ということを考えると、「うまく配信できませんでした」では済みません。冗長化も含め幅広く考えていくと、ライブ配信は、実は簡単な事ではありません。
K.N.さんは新卒で入社し、ライブエンジニアとして現場対応を行っていた経験もあるので、そのあたりの感覚が鋭いですよね。プロダクトの開発に異動してからも、現場担当だった経験に基づいて具体的で実践的な企画をたくさん考えてくれています。
自分が以前所属していたライブの部署は、「プロフェッショナルライブ」というサービスで、現場の制作から配信までをライブエンジニアが請け負う高難易度のミッションでした。一方、EQでのライブのコンセプトは「動画が初めての企業にとっても、手軽に簡単に利用できる」という逆のものです。このコロナ禍において、ライブ配信も「手軽に簡単に活用できる」ように、EQへ実装させる事は極めて重要かつ緊急性の高いミッションでした。
疑似ライブ機能自体は、要件定義から1.8か月程、実装自体は1か月ぐらいで実現しました。当時の開発体制は、Ｊストリームもテレワークを導入していたため、全員がリモートワークでした。初めての体制ではありましたが、OODA思想の元、アジャイル開発方式にて実際に動くものを作り、それをSlackやTeamsで共有しながら進め方をチームで協議して進めていきました。結果、当社としても異例のスピードでのリリースを実現することができました。
社内共通基盤を使用したという要因は大きいですね。REST APIをベースとした社内用クラウド「J-Steam Cloud」の活用です。疑似ライブ機能の追加では、「J-Stream Cloud」の中にある「Composer」という機能を核に開発を進めました。一から機能を作り上げる必要はなく、EQでの使い方や状況にあわせてComposerをどう取り込んでEQに組み込むか。いかに開発工数を少なくするかに焦点を当てて設計を行えたことが大きいですね。
機能をフェイズ分けして、お客様からの要望を段階的にリリースできた点も大きかったですね。「J-Stream Cloud」のモジュール化により、機能追加やアプリケーション改修の際に既存システムへの影響が少なかった事で検証にかかる工数も大幅に削減できました。
EQは10年近く続いているサービスなのでレガシーな部分も残ってはいますが、「J-Stream Cloud」に合わせてモダンな共通開発環境への移行も進めています。今後はこれくらいのスピードが当たり前になるくらいに開発体制を整備していきたいですね。
潤沢なインフラと幅広い技術領域を生かし、顧客の声をもとにエンジニアリングの幅を広げる
大きく3つほどあるのですが、ひとつはネットワークの環境が太いところですね。動画を扱っているので、当然検証などでも大きな帯域が必要になります。ましてや4K/8Kなどの動作確認にはそれなりの回線が必要です。
またエンジニアが自由に使える仮想環境なども多く用意され、それらもVagrantなどを使用して好きなものを使えます。グローバルIPを付与する事もできるので、LTE回線での確認なども気軽にできる環境もあり、それも合わせるとかなりエンジニア的にはストレスフリーな環境ですね。
開発自体は主にPHPを用いて構築されています。ただこの辺りも昔からあまり変更されていない部分ですので、JavaScriptやTypeScript、Reactを用いてフロントの刷新なども進めています。サービスバックエンドとしてはPHPのCakePHPからLaravelフレームワークへの変更を進めています。
以前はあえてレガシーであり続けることで、使い慣れた操作感を無くさないようにという運営ポリシーもあったのですが、より良い使用感などを実現する為に、また開発効率の向上なども含めてどんどんとモダン開発に移行を開始しています。この辺りも前述のように開発環境の整備が進んだことで実現しています。
二つ目としては、幅広い職種のエンジニアと一緒に仕事ができる事かと思います。プレイヤーのスペシャリストもいれば、動画のエンコードが得意なバックエンドエンジニア、ネットワークが得意なインフラエンジニアなど多種多様なエンジニアがいます。
動画ファイルの処理をしているサーバでは字幕再生、自動翻訳、スマホ画面の回転、倍速再生など色々な処理を行っているのですが、一部クラウドでのSaaS機能を利用しつつもほとんどを自社開発できているのは、多様なスキルを持ったエンジニアがいる恩恵です。
動画はある意味では特殊な知識になりますので、普通の開発ではそんな事まで知らないだろうなんてことも段々身についてくる。そうすると「なんだか自分もテクニカルな事をやっているなぁ」なんて思えてきて、気持ち良くなってくるんですよね（笑）
その点では、私はＪストリームにきてからCDNについてかなり詳しくなりましたね。EQの解析機能では、CDNで大量のログを収集し、種類ごとに加工してデータベースに加工しています。動画の視聴ログは、重要なデータ資産として注目される中、細かなデータを得るために日常的にCDNに触れられた経験は有意義だったなと思います。
社内では「EQチーム」と便宜上言う事もありますが、各チームで閉じているわけでもなく、バックエンドの社内クラウドチームやインフラ部などとも密に連携しコミュニケーションも活発に行っています。SREの考え方を浸透させつつ、技術的な部分に関してはみんなで話をしながら進めています。
前職ではフロントエンドだけの会社で、実はＪストリームに入る前はインフラやサーバなどはよくわかりませんでした。言語としてはJavaScriptやC#がメインだったので、入社後に一人で煮詰まっていた時期もあったんですが、バックエンドのエンジニアから「この処理はこれ一行でできるよ」といわれて愕然としつつも、自分がまだ踏み込めてない領域を知ったんです。そんなことが頻繁にありますから面白いですよ。
業務で知ったことを自己学習し、また業務に生かすという事を繰り返せるので、エンジニアとして成長できているなという実感はとてもありますね。今まではフロントエンドやアプリケーションのスペシャリストとしてキャリアを積んできましたが、フロントエンドを極める為には実はそれなりにバックエンドも知らなければいけない。フルスタックまではいかなくても、ある程度全体を見られるようになるのは重要だと感じました。
Ｊストリームで開発経験を積む面白さの三つ目は、お客様の声をダイレクトに聞けることだと思います。これは、自社の開発のベースでもあり、他社の開発と差別化を生む大きなものだと思います。
EQはB2B向け動画プラットフォームとしては国内最大級の規模で導入実績があり、現在までの累計アカウントは2,000以上になります。その顧客の声の中に次の開発のヒントが多く含まれていると思っています。メディアやコンテンツプロバイダ、一般企業など多くの企業から幅広い使われ方をされており、様々なデータがとれます。
マーケティングの観点からも、行動解析としてちゃんとログを取り問題などを早めに分析する。どの機能がどう使われているかを分析しつつそこに集中して開発を行っていく。なんとなくこの機能が流行っているから等で進めるのではなく、SLIやSLOをベースにプロダクト全体の健康状態をみながら考えていく事を徹底する。それらをエンジニア主導で動かせるように運営体制を作り始めています。
自分も以前はライブエンジニアとして全国を飛び回っていたのですが、その際にライブの現場でお客様から直接お話を聞ける機会もありました。疑似ライブなどの開発に関しても、独特の緊張感など現場の空気を知っているからこそ、開発の意義を納得して開発できたりもしました。
エンジニアが技術だけの事を考えていればいい時代ではなくなってきています。加えて動画は「配信できて当たり前」の世の中です。新しいサービスの企画や顧客のニーズに応えるにも、最適な技術を選んで形にするという点では、エンジニアの視点がますます重要になってきています。EQを作っているＪストリームのフロントエンドエンジニアは、その視点を養い、ビジネスとしても成長できるために必要な環境が揃っているのではないかと思います。
「他社に先駆けてやろう」、というのが ‟自社らしさ”
私の中で一番鮮明に記憶しているのは、FlashからHTML5への移行ですね。そのインパクトは凄かった。当時はFlash全盛期で、EQの動画配信でも多くのFlash技術を採用していました。これを、サービスを止めることなくHTML5を使用したHLS配信に置き換えていきました。
当時は国内でHTML5対応をしているサービスやプロダクトなんてほとんどありませんでした。そんな中他社に先駆けて「やろう！」と決断をしたのはＪストリームらしいなと思います。
既存の数十万以上に及ぶ膨大な動画ファイルをFlash形式からHLS形式へ変換する仕組みを作り、それらを問題ないか検証をしていきました。地味に大変でしたね（笑）
この時はまれにみる大規模な技術の仕様変更という事もあり、お客様にどうわかりやすく伝えるかも議論をしましたね。お客様にとっては変わらないように見えても、裏側の仕組みは大きく変わっていますから。それをどう伝えればいいのか…と。
その時の経験を生かして新たな開発のヒントにしているものもありますね。
他社がやっているからうちもやろう、というのももちろん必要だとは思いますが、Ｊストリームらしさとしては、そういう「他社がやってないからこそやろう」という開発を増やしていきたいですね。今もフロントエンドのSPA化や、iOSやAndroidのアプリ開発体制の拡充なども進めていますし、常に現状で満足せずより良いプロダクトへ進化させ、動画配信のパイオニアとしての意識を大事にしていければと思います。
EQチームでの開発は、いろんな技術を集めて組み合わせ、どうやってサービスを提供していくか、プロダクトマネージャーやプロデューサーに通じる力を身につけていけると思います。これからもお客様の声に耳を傾け、開発の最前線として最適なサービスを提供するプロダクトを運営していきたいと思います。
