開発環境 – Voice 動画配信の今を伝えるエンジニア情報サイト

ユーザーの声をダイレクトに聞き、自社プロダクトを成長させる

jst_recruit — Thu, 22 Apr 2021 06:12:38 +0000

J-Stream Equipmedia（ジェイストリーム・イクイップメディア。以下、EQ）は、OVP(Online Video Platform)と呼ばれるSaaS型サービスで、2012年のサービス提供開始から今年で10年目を迎える。動画領域では4-5年で主要技術が一変することも珍しくないなか、サービス開発の裏側では日々技術の変革が起きている。今回は、2人のフロントエンドエンジニアにEQの新機能追加や開発への想いについて聞いた。

時代とともに変化し続けきた動画配信。コロナ環境下では、1.8か月での新機能リリースも

――皆さんが手掛けているEQは、サービス提供開始から10年目ということで、過去、多くの機能追加などもありました。まずは「EQとは何か？」というところから始めたいのですが、今回は、エンジニア情報サイトという特性上、エンジニア切り口で、EQ の機能や特徴紹介をお願いできますか。

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チームでの開発は、いろんな技術を集めて組み合わせ、どうやってサービスを提供していくか、プロダクトマネージャーやプロデューサーに通じる力を身につけていけると思います。これからもお客様の声に耳を傾け、開発の最前線として最適なサービスを提供するプロダクトを運営していきたいと思います。

――次なる展開に向けていろいろとアイデアは広がっているようですね。今後のEQの成長を楽しみにしています。

【関連情報】

J-Stream Equipmedia サービス紹介ページ　

※別サイトのＪストリームコーポレートサイトへリンクします。

社内共通開発基盤をレガシーからモダン移行した変化と効果

jst_recruit — Thu, 01 Apr 2021 00:57:19 +0000

レガシーな開発環境を脱却するために、モダン開発をベースにして構築された全社共通の開発基盤「J-Stream Cloud(ジェイ-ストリームクラウド）」。その存在は、開発スピードと柔軟性を大幅に向上させ、開発体制に大きな変化をもたらしている。今回、構築を手がけた2人のエンジニアに話を聞いた。

開発環境構築のキーは、マイクロサービス、インフラのコード化

――今回のテーマは「J-Stream Cloud」ですが、これは以前はなかったものですよね。どういう経緯で作ることになったのか、まずは、その辺りから話を聞かせてください。

「J-Stream Cloud」は自社のプロダクト開発やサービス開発を支える共通開発基盤です。2018年頃から着手し、現在も日々改良を重ねています。

アジリティ面の特徴としては大きく２つあります。一つはSubversionからGitLabへ移行しモダン開発ベースでのマイクロサービス構成にて開発スピードと高い柔軟性を実現している事。もう一つは、DockerやKubernetesによるコンテナ技術やAnsibleなどを用い、Infrastructure as Codeをベースとすることで、CI/CDの概念によるインフラの構築や運用を自動化できる事です。

各機能をモジュール化し、それぞれをステートレスに設計する事で機能の依存性をできるだけ分離し、スケール性も確保しています。それと同時に、共通する部分は汎用的に作りこむ事で、どこかのプロダクトで作った機能をそのまま他のプロダクトでも再利用できるようにしています。

構築に関して使用されている技術は、着手当時から現在も色々変遷を重ねています。初期はRuby on RailsをベースにREST APIを実装していました。これは基本的なフレームワークのルールをより厳格なRailsによって社員に浸透させる狙いもありました。現在はある程度MVCなどの概念も理解が進んできておりますので、次の段階としては、将来的な機械学習などAI分野への進出を見越してPythonなどの言語への変換を進めています。

とはいえ、インタプリタ言語だけではもちろん高速な処理などは追いつきませんので、APIの内部処理として動く各マイクロサービスではJavaやGolangなどのコンパイル系言語も取り入れています。この辺りはnginxやRedisなどのミドルウェアも組み合わせて開発していますので、一般的な開発経験があればすぐに取り掛かれるようにという部分に焦点をあてて標準化させています。

「J-Stream Cloud」構築の背景には、Ｊストリームに特化した開発者ではなく、日本や世界で通用する開発者への成長を促す狙いがあります。いかにＪストリームで育ったエンジニアが他でも通用するか、また他で活躍しているエンジニアがそのままＪストリームで活躍できるか。オンプレミスのインフラや動画領域の経験など、コアコンピタンスな部分はどうしても特殊性は残りますが、それ以外のアーキテクチャはそれらの経験有無に影響されないので、スタートはきりやすいと思います。

――マイクロサービスアーキテクチャの導入により、開発者目線ではどう変わりましたか？

つい5-6年前までは、まだサービス単位でモノリシックに開発されていたので、とても触るのが怖かったですね。機能が密結合されており、何かを触ると他の部分で想定外の動作になるなど、どこまで影響があるのか誰も把握できない状態でした。

一つのコンテンツをアップすると同期されたタスクが同時に動き出すため、データベースからエンコードまで全レイヤーを見ることができないと開発できませんでした。もちろん技術的にもですが、非言語化された「過去の経緯」や「作成者の想い」なども知らないといけない属人的な開発スタイルに縛られていたともいえますね。

マイクロサービス化によって、新しい機能を追加する際に既存のコードを触る機会が大幅に減りました。大きなクラスを触っていたら想定外のところでそのメソッドが呼び出されていてバグが出るなどのリスクも無縁になりましたので、過去の経緯を気にせず単機能の開発に集中できるようになり、みんな積極的に機能開発を行うようになりました。

ステートレスなマイクロサービス化によって、スケールインやスケールアウトも容易になりました。また、CI/CDの整備によってデプロイリスクも軽減されましたので、開発者の心理として安全に集中した機能開発を行えるようにもなり、チャレンジする傾向が強くなってきましたね。チャレンジの数を増やせれば、成功の可能性も増やすことができる。そうやって技術者目線での新しい試みを増やすことが、会社としての強みを増やす事に直結しているんです。

リスクもそうですが、マイクロサービス化されたそれぞれの機能は再利用が容易なのも大きいですね。サービスごとに同じような機能を作る「車輪の再発明」のような事は、とても多く発生していました。同一サービスの開発チーム内でも、バックエンドエンジニアとインフラエンジニアが同じようなサーバを作っていたりもしましたしね。全社員が使用できる共通開発基盤にすることで、再利用が基本的な考え方となり、大幅に開発スピードは向上しました。

疎結合な開発体制が整ったことで、「動画のトランスコードに詳しい」というようなスペシャリティも発揮できやすくなるので、尖った特技なども活かしやすくなったかと思います。いろんな特技を持った人が参加する事で、小さな単位での機能レベルから底上げを図り、やがては大きな技術的変遷への対応、世の中のニーズへ決め細かくこたえられる。動画という技術の移り変わりの激しい領域だからこそ、マイクロサービス化は必然だったように思います。

今はリリース環境とステージング環境をKubernetes上で構築し、人的ミスを回避できるようにCI/CDによる自動化を取り入れています。導入当初はJenkinsなども使用していましたが、いまはArgoCDに変更するなど日々改善を続けています。

以前は、最初の一歩が重たい感じでしたよね。実機のサーバを調達して、開発するときにはtopコマンドなどでリソースの空きを確認し、historyなどを見ながら恐る恐る触る感じです。開発が終わってデプロイする際にも目視チェックなどを行っており、人的ミスが無いようにすごく神経を使っていました。それに比べれば、重たかった一歩はずいぶんと軽くできたのではと思います。

インフラのコード化に関しても、現在はフロントエンドやバックエンドの開発者が自分たちでサーバやミドルウェアの構築、テストやデプロイまでをコードで表現します。自動化などのメリットもそうですが、インフラエンジニアと開発者がコードを通じてやりたいことを相互に理解できるよう共通言語化されたのが大きいですね。コミュニケーションロスもなくなりました。

環境を作るまでの時間が圧倒的に短くなりましたね。コンテナなら、自分たちの開発端末にDockerをインストールしておけばそこでスクラップ＆ビルドを行い、納得できるまでコンテナのビルドチューニングを行える。そこで作ったコンテナはそのままステージングやリリース環境のKubernetes上でも使用される。Vagrantからlibvirtを使用してKVMの仮想サーバ自動生成も気軽にできるので、さっと動かしてみてダメなら壊して簡単にやりなおせます。

何かを思いついたら自分の隙間時間を使ってちょっと試してみる。ダメなら壊す。また思いついたら触ってみる。開発者にとってのチャレンジって構えて行う「大きな何か」ではなく日常的に繰り返す「小さなひらめき」ですから、それを後押しし実現できる開発環境が必要なんです。

技術変化の激しい動画領域で開発スピードを上げていく

――動画領域の開発では、「J-Stream Cloud」はどのようなメリットがあるものなのでしょうか？

一番は、技術や世の中のトレンドに素早く対応できることです。動画領域は技術変化が特に激しく、主流となる技術が4～5年で一変する事も珍しくありません。大きなシステムを作ってしまうと一部だけを変えようにも、全く関係のないところで想定外のバグが出たりなどで、世の中の変化のスピード的についていけない。

「J-Stream Cloud」では、例えばHLS配信においてもPlaylist作成部分を分離してあります。前段の処理をそのまま生かしつつ、Playlistのレンダリングの時点でMPEG-DASH用のPlaylist作成処理だけを追加しHLSと置き換えるイメージですね。そうすれば、そのままMPEG-DASH配信だけでなく、CMAFなど新しい規格にもすぐに対応が可能です。それらの機能をAPIで提供していますので、パラメータでHLSやMPEG-DASHかを選んでもらえればすぐに新しい機能をプロダクトに提供できます。

コロナ環境下では動画活用が急速に拡大しました。中でもインターネットライブをもっと手軽に使いたいという企業ニーズが一気に高まり、私たちも緊急開発を多く行いました。その中の一つに疑似ライブ（収録動画をタイムスケジュールに沿ってライブ配信する事）機能がありますが、これは自社プロダクトである「J-Stream Equipmedia（ジェイストリーム・イクイップメディア）」へごく短期間で追加できました。（※関連記事はこちら）

これはそもそも前述したようにレンダリングを別にしたエンジンを作っていたというのもあり、そこにフレーム制御でのカット機能を盛り込むことで機能の再利用を行った事によります。また当然、プロダクトの開発者であるフロントエンドエンジニアが全く動画について調べなくても良かったという、標準的なスキルによる分業化という事も大きいです。

動画由来のメリットという点では、動画データは滞納トラフィックが起こりやすいためスケールを考慮する必要があるのですが、その場合でも処理の重い部分だけをスケールする事でリソースの節約を行う事が可能になりました。必要な処理だけをいくつも複製できるので、一つのコンテナで障害が発生しても別のコンテナで処理を続行するなど、障害回避の構成を作るうえでも役立っていますね。

――Ｊストリームでの開発の面白みとは？

Ｊストリームのユニークな点は、オンプレミスの基盤と設備を持っている事です。動画配信と開発を同時にやっている会社は日本でも数少ないですからね。オンプレミスで一から自分で作る楽しさは格別です。

とはいえ、オンプレミスだけでやっていると全体スピードとしては落ちてしまう。「J-Stream Cloud」の構築ではまずはクラウドベースでスタートさえスピードアップを図りながら、徐々にオンプレミスへの移行を計画しています。インフラを柔軟に操作できるようになると、エンコードアクセラレーターなどの独自ハードウェアの組み込みや、キャリア網を使用したエッジコンピューティングなど、様々な利点がもっと出てくると思っています。

クラウドとオンプレミス、どうハイブリッドにしていくかですよね。クラウドの障害時にはオンプレミスに、またオンプレミスの障害時にはクラウドに逃がすなどを考慮すると、ハイブリッド化は必須になると思います。またクラウドも当然マルチクラウドであるとより堅牢になります。

5Gなどを見据えると、各キャリアのネットワークに合わせたインフラ設計も必要です。マルチクラウドでありマルチキャリアな汎用プラットフォームは、インフラを含めた設計が必須になりますし、それができるポジションにいるのがＪストリームの良さですかね。

直近の課題はそのあたりですね。まずは現在動いている物理サーバをなるべくたくさんコンテナに移行し、コンテナで動くことがまず当たり前の仕組みを作っていけるとよいのではと考えています。

データ処理、双方向配信、MEC……「J-Stream Cloud」の成長の方向性とは？

――今後、「J-Stream Cloud」へどのような機能拡充を考えていますか？

コロナ環境下での動画配信ニーズの高まりの中で、ライブやトランスコードなどの機能拡充の必要性を感じています。もちろんこれらの基本機能に関しては機能拡張を進めていければと思っていますが、ライブやトランスコードに関する詳細なフィードバックを提供できるように、高度な学習や予測なども取り入れていきます。今は配信するだけではなく、結果を問われる時代ですからね。

データ処理基盤ですね。現在でもCDNプロダクトの「J-Stream CDNext（シーディーネクスト）」ではKafkaやHadoopなどを使用してログの大規模処理を行っていますが、それはあくまで結果を可視化するだけのもので、学習や予測などの領域には手を出せていませんでした。Pythonをベースとした機械学習や深層学習などのエッセンスを取り入れていき、AIの活用を前提とした基盤を作れれば、面白いデータが出せるのではと思ってるんですよ。

ちょうど今、昨年入社の新卒メンバーにメインとなってもらい、ログ処理の基盤機能開発を進めている所です。彼の機械学習領域の経験を生かしてデータ部分を作ってもらっています。APIの使用データをPandasで読み込んだ後、scikit-learnなどで決定木にかけることでどういうパターンの際にどういうパラメータが望ましいかなどを自動判別するなど、徐々にAIの活用部分を増やしていければ面白いですね。

それ以外では、新たな配信方式への対応ですね。動画配信のプロトコルや仕様はここ10年で大きく変わりました。昔はFlashによるRTMPベース、今はHTTPベースのHLS配信方式がデファクトで使われていますが、ここ数年はWebRTCを使うとリアルタイムな双方向配信だけでなく、大規模な配信なども対応できるようになってきています。そういう動きに対して素早く対応できる体制や仕組みを作っていきたいと思っています。

双方向はやってみたいですね。1対多で配信者と視聴者が分かれている大規模配信はどこでもやっているけど、今は双方向性のあるものが求められています。見ている人がチャットで参加出来たり、音声通話でジョイント出来たりなどは昔からありますが、それ以外にも見るだけではなく参加できる為の様々なアクションを増やしていきたい、その為の機能開発を増やしていけると面白いでしょうね。

私はSREについて本格的に取り組みたいですね。監視を細かく行い、月にどれくらいエラーや障害が発生しているかを把握できるようにする。それで「何％まで抑えていこう、これくらいまでなら大丈夫だからもっとチャレンジしよう」と具体的に進めていければと考えています。

機能追加に関しても、今までは営業主体で顧客ニーズに応えるという、開発主体という視点で考えるとやや後手なところがありましたが、SREをベースにSLI(Service Level Indicators)を定義し、開発側からも先手を打って主体的に動けるためのデータを揃える事で、よりチャレンジの目標を明確にできるようにしたいですね。

あとは5G関連でのMECであったり、H.266などの配信フォーマットを実証実験してみたり、…となるとやはりマルチクラウド環境ですかね。

Ｊストリームは動画配信ネットワークから始まったこともあり、インフラの強い会社だという印象が強いのですが、共通の開発環境として「J-Stream Cloud」ができたことで開発力も確実に上がってきている。「J-Stream Cloud」構築の経験を通じて、開発環境がエンジニアにもたらす影響力を強く感じました。

新しい機能を作ることがメインだから、結構チャレンジしていかないといけないし、それをできる為の環境がそろっている、と。

ロールバックもできるから楽ですしね。

試行錯誤で悩んだ時も、APIを叩けばJ-Stream Cloudがポンと新しいコンテナを立ち上げてくれますから、安心してチャレンジしてもらいたいですね！

――今後の基盤拡充にも期待しています。ありがとうございました。

※在籍年数や役職を含む記載内容は、取材当時のものです。その後、状況が変化していることがあります。