【エンジニア対談】リアルタイム技術と大規模配信の裏側を支えるCRIのバックエンド

クラウド、リアルタイムコミュニケーション、AI、⼤規模配信――。
世の中の“当たり前”を⽀える技術の裏側には、バックエンドエンジニアの地道で奥深い作業と⼯夫があります。

今回、登場するのはクラウド／Web 技術を軸に、新規サービスから運⽤までを⼀気通貫で担うクラウドソリューション開発部（以下CSOL 開発部）でバックエンドを担うM.N さんとR.H さん。

⾃社開発と受託開発の両⽅を⼿がけ、幅広い業界で多くの技術に触れてきた⼆⼈に、仕事内容、技術の⾯⽩さ、そして「ＣＲＩでエンジニアとして成⻑する感覚」について語ってもらいました。

■お⼆⼈はなぜＣＲＩ・ミドルウェアに？

M.N：前職ではゲーム開発に携わっていましたが、次第に「別の形で、Webサービスやクラウド技術に向き合いたい」と思うようになりました。
転職活動の中で、ＣＲＩは⾳や映像といった明確な強みを持ちながら、Web技術にも本気で取り組んでいる会社だと感じました。そのバランス感が、⾃分に合っていると感じたのが、⼊社の決め⼿でした。

R.H：僕はもともとインフラ寄りで、オンプレやサーバー管理からキャリアをスタートしました。徐々にインフラとバックエンドを両⽅⾒るようになり、⾃然と今の⽴ち位置に落ち着いた感じです。バックエンドはフロントとデータをつなぐ「縁の下の⼒持ち」。派⼿ではないけれど、性格的にも合っていると思っています。
転職活動中にＣＲＩから声をかけてもらったのがきっかけで⼊社しました。当初は別の部署で⼊社を検討していましたが、CSOL開発部の話を聞く中で、インフラとバックエンド、両⽅の経験を活かせる環境だと感じました。「ＣＲＩなら、これまでの仕事の延⻑線上から、もう⼀段成⻑できそうだ」と考え、⼊社を決めました。

■想像と違った？ CSOL に来て驚いた「⼀⼈あたりの裁量」

二人が口をそろえて挙げたのが、CSOL開発部の一人あたりの裁量の大きさです。

R.H： 機能単位で「⼊⼝から出⼝まで携われる」ケースが多いですね。インフラも含めて⾃分で⾒ていることが多いです。前職では、⼀つの機能でも5⼈以上関わることがあり、⼊社して間もない時は裁量の⼤きさに驚きました。

M.N：CSOLは、仕様を誰かが決めて、それを実装するだけ、という分業ではありません。 開発者⾃⾝が仕様に意⾒を出し、設計から関わる。良くも悪くも、制限が少ないんです。だからこそ、設計の責任は重いですが、その分「サービスを作っている実感」は強いですね。

■許諾×受託×多業界。視野が広がるバックエンドの現場

CSOL開発部の特徴は、⾃社プロダクト（許諾製品）と受託開発の両⽅を扱い、業界も限定されないこと。

R.H： 受託開発では、様々な企業のエンジニアとお会いします。設計書や運⽤の考え⽅も会社ごとに違う。その「流儀」を⾒ることで、視野が⼀気に広がりました。
印象に残っているのは、あるクラウドから別クラウドへの移⾏案件です。オンプレからクラウドへの移⾏はよくあるのですが、クラウド間移⾏は⽐較的珍しいケースですね。設計から移⾏まで担当しましたが、デプロイに8時間かかり、正直きつかったです。無事に移⾏できたときは達成感がありました。

M.N： 許諾製品を提供する場合でもお客様の業界はアパレル、⾞、QA、家電など様々です。「動画を配信する」「リアルタイムでやり取りする」という同じ技術でも、業界が違えば求められる品質や価値が全く違う。その違いをどう設計に落とすかが、バックエンドの⾯⽩さです。

■リアルタイム技術・⼤規模配信──難しさは「速さ」だけじゃない

ＣＲＩの業務の特徴はWebRTC・WebSocketといったリアルタイム技術や、⼤規模配信基盤を前提としたバックエンド開発が「⼀部の特殊な案件」ではなく、⾳や映像を扱うＣＲＩの事業と地続きで⽇常的に登場する点です。

M.N： リアルタイム性が必要になるのは、遅延そのものが価値を壊してしまう場⾯ですね。例えば、⼀瞬の遅れが結果に影響するケースや、複数⼈で同時に操作する共同編集が該当します。ＣＲＩの場合、「⾳が聞こえる」、「映像が再⽣される」だけでなく、その体験が“違和感なく成⽴しているか”まで問われます。
最近では、AIによる⾳声対話システムの案件がありましたが、そこでも「どれだけ早く応答を返せるか」が体験の質に直結します。バックエンド側での設計や技術選択が、そのままＣＲＩの価値提供につながります。

R.H： ⼤規模な配信は性能の話に⾒えて、実は設計とコストの話でもあります。例えば、配信の⾮公開制御をどこで判定するのか。ＣＲＩでは、配信規模が⼤きくなることを前提に考えるケースが⼤半のため、初期段階から考えておくことが重要になります。
CDNのエッジで毎回処理するのか、それともキャッシュと組み合わせて必要なときだけ評価するのか。配置を誤ると、リクエストごとに処理が発⽣してしまい、レイテンシーやコストが⼀気に跳ね上がります。
動画配信では、クラウドコストの⼤半を配信コストが占めることは珍しくありません。だからこそ、ＣＲＩでは「動くかどうか」ではなく、「この設計で⻑く運⽤できるか」、「事業として成⽴するか」まで含めて、設計段階から考えています。

■基盤技術と設計──「当たり前をちゃんとやる」

リアルタイム性や⼤規模配信のように、体験品質やコストがシビアな領域に向き合う上で⽋かせないのが、⼟台となる基盤づくりです。CSOL開発部では、コンテナ実⾏基盤（k8s/ECS）を前提に、AWSを中⼼としたクラウド基盤、IaC、CI/CDまでを“⽇常の道具”として使い、安定した運⽤と開発のスピードを両⽴させています。

M.N： コンテナは必須なので、k8s / ECS は当たり前に使⽤します。以前、別のクラウドを使っていたこともありますが、⽐較するとAWSはやはり⾼機能で使いやすい。インフラもコンソールを⼿で触るのではなく、IaCでコードとして管理しておく⽅が圧倒的に管理しやすいです。
有名なサービスを運営している企業でも、まだ⼿動でAWSを使⽤している会社があると聞きます。それぞれ事情があると思いますが、ＣＲＩの使い⽅だとIaCでの管理が最適ですね。CI/CDも同じで、あるとないとでは⼤違いです。

R.H： 基盤が整っていると、バックエンドの設計に時間を投じることができます。⾃社サービスの新規開発ではドメイン駆動設計（DDD）を採⽤していますが、正解が決まっているわけではありません。定期的にミーティングを開き「これはどういう意味だっけ?」「どこまでをこの責務として持つのか?」など、⾔葉の定義や境界を探り、“動けばOK”ではなく、運⽤や説明可能な形式に落とし込むようにしています。
基盤（k8s/ECS・AWS）と運⽤（IaC・CI/CD）を当たり前に整えることで、設計の議論に集中できる環境を作っているのが、CSOL開発部の⼤きな特⻑だと思います。

■AI 活⽤──個⼈の便利さで終わらせない

AI活⽤も、CSOL開発部ではかなり踏み込んで⾏われていますよね。

M.N：コードレビューやテスト⽣成など、AIはさまざまな分野で使⽤しています。特にテストはプロダクションコードに⽐べて多少の重複や作り直しを許容しながら、必要な観点を迅速に増加させられます。AIとの相性がとてもいいですね。
特に意識しているのは、AIを“個⼈の便利ツール”で終わらせないことです。ローカル環境だけで使うのではなく、Slackなどの共有の場で動かし、レビューできる形にする。そうすることで、チームのワークフローとして成⽴させています。

R.H： 実装やテストのスピードは格段に向上しました。AIに同じ指⽰を出しても、⼈によって異なるコードが返ってくるので、その差分をどう扱うか、という新しい課題も⽣まれています。
またAIで変更が容易になった分、無理に共通化せず、それぞれ最適化した⽅が速いケースも出てきました。だからこそ、設計や判断などの重要性は、以前よりも増していると感じます。

M.N： もう⼀つ当社で特徴的なのが、AIツールの導⼊が「現場起点」で提案できることです。新しいAIサービスやAPIを使⽤したい場合、技術戦略室（※）などに相談し、セキュリティやライセンス⾯に問題ないことを確認したうえで正式に導⼊可能です。
最初から全社導⼊という形でなくても、「この開発⼯程に効きそう」、「こういう使い⽅なら価値が出る」といった提案が受け⼊れられる⼟壌がＣＲＩにはあります。社内で使⽤しているコードレビュー⽤の内製AIツールなども、そうしたアイデアから⽣まれました。
AI時代だからこそ、「なぜ使うのか」「どう組み込むのか」を説明し、チームとして責任を持ち活⽤する。その姿勢を⼤切にしています。

※技術戦略室…全社の開発成果を最⼤化するために、技術資産や開発環境、品質やガバナンスなどを横断的に⽀えるＣＲＩの部署

■チャレンジを後押しする⽂化と、開発しやすい雰囲気

技術的なチャレンジを⽀えているのは、ツールや制度だけではありません。⼆⼈が共通して挙げたのが、ＣＲＩの開発現場ならではの“空気感”です。

M.N： ＣＲＩには「チャレンジ奨励制度（※）」という仕組みがあります。制度そのものはさておき、この制度があることで、⽇常的にアイデアを出しやすい雰囲気があると感じています。業務の中で感じた課題や、「これ、仕組み化できそう」といった気づきを、そのまま形にして提案できる。
実際、過去にはコードレビューを仕組み化するための内製ツールを作成したり、AIを⽤いた開発⽀援の仕組みを試してみたりと、業務の延⻑線上にあるチャレンジが発表につながったことが多数ありました。

R.H： メンバー同⼠の距離が近く、黙々と個⼈で閉じこもるというより、⾃然と会話が⽣まれる環境があることも⼤きいですね。設計の相談、ちょっとしたアイデアを雑談ベースで話す。そういった積み重ねが開発のしやすい環境作りにつながっていると思います。
ソフトウェアだけでなく、ハードウェア開発のチームとも物理的に近い距離にあるので、「作る」ことが好きな⼈にとっては刺激の多い環境です。

※チャレンジ奨励制度…社員の⾃発的な挑戦を後押しする制度で、新規事業や既存サービスの改善につながるアイデアを提案・実⾏できます。年に2回発表する機会があり、成果は社内で発表・表彰され、将来正式な製品にブラッシュアップされ顧客に提供されることも少なくありません。

■「⼀緒に議論できる⼈」と働きたい

最後に⼆⼈が語った「ＣＲＩに向いている⼈」。これは、特別なスキルや経歴というより、⽇々の開発で⼤切にしているスタンスの話でした。

M.N： ⼀緒に議論して問題解決できる⼈ですね。設計をはじめ、実装、運⽤など、どんなフェーズでも意⾒が⾷い違う場⾯は必ず出てきます。そういうときに、どちらが正しいかではなく、「なぜ、そう考えているのか」「どこが論点なのか」を整理して、納得感を持って⽅向性を合わせられることが⼤事だと思っています。
ＣＲＩでは、とりあえず動けばOK、というよりも「理解できているか」を重視する空気があります。理解できていないものは、⻑く運⽤できないし、安⼼して任せられない。だからこそ説明したり、図にしたりと、⾔語化する⼒は⼊社後も⾃然と鍛えられていきます。

R.H： 複数⼈で開発していると、「ユーザーにとって本当に必要なサービス、機能は何か?」で意⾒が割れることがよくあります。CSOL開発部は、各メンバーそれぞれに仮説や信念があるので、なおさらですね。
だからこそ、相⼿を⾔い負かすのではなく、「では、どうすれば両⽴できるか」「どこまでなら妥協できるか」を⼀緒に考えられる⼈と働きたいです。
技術だけでなく、背景や意図を説明できること。その上で、周りを巻き込みながら前に進める⼈は、CSOL開発部で確実に⼒を発揮できると思います。