自らの手で最適な環境をつくるため、自分たちでコードを書く。インフラエンジニアの枠を超え、進化し続けるインフラストリーミングチーム

ゲーム配信プラットフォーム「Mirrativ」を根幹から支えるインフラストリーミングチーム。日々発生する課題に真摯に向き合い、サービスの安定稼働と未来を見据えた進化を両立させています。今回は、そんなチームを率いるマネージャーの漢さん、Web/DBのインフラ領域を担当する清水さん、ライブ配信基盤領域を担当する松本さんの3名に、チームのリアルな働き方や文化、そして今後の挑戦について語っていただきました。

メンバー紹介

漢 裕介 : インフラストリーミングチームマネージャー。クライアント・サーバ・インフラ領域のフルスタックエンジニア。OSS活動・スタートアップを経て、DeNA。ゲーム開発・運営・インフラマネージャ。ゲームの大規模トラフィックやSHOWROOM等のライブ配信サービスの基盤を設計・運用。ミラティブではライブ配信基盤・インフラ基盤を担当。

清水 雅也: インフラエンジニア。ホスティング会社などでインフラの経験を積んだ後、2018年にミラティブへ。Web/DB周りのインフラ開発・運用をメインで担当。

松本 肇: インフラエンジニア。前職でライブ配信サービスの開発を経験後、2019年にミラティブへ。ライブ配信基盤関連のインフラをメインで担当。

インタビュアー
牧野 龍彦：インフラストリーミングチームが所属する基盤開発部の部長。東京大学大学院修了後、2013年にDeNAに入社。内製大型タイトルのリードエンジニアやPMを経験。2019年にミラティブへ入社。バックエンドエンジニアのMGRを経て、現在は基盤開発部の部長として、バックエンド・インフラ領域のマネジメントおよびライブゲーム開発に携わる。

それぞれの場所から、Mirrativの可能性を感じ入社を決意

ーーみなさんの自己紹介をお願いします。
漢：2018年の秋頃に中途で入社し、それからずっとインフラストリーミングチームのマネージャーをしています。主な役割は、ミラティブのインフラを作り、改善することです。ミドルウェアや配信基盤の開発から、ベンダーさんとの折衝まで、幅広く担当しています。

前職のDeNAには、サーバーサイドエンジニアとして入社しました。「インフラをやりたい」と言って入社したんですが、「まずはバックエンドで経験を積んでこい」と言われ、数年修行させてもらった後、念願のインフラエンジニアに転向しました。DeNAでは新規事業領域のインフラを担当していて、SHOWROOMやPocochaなど、さまざまなサービスの立ち上げに関わりました。その中の一つがMirrativだったんです。その後、MirrativがDeNAから独立するタイミングで「面白そう」と思いジョインしました。

清水：2018年5月に入社しました。チーム内の役割は、僕は主にAPI、ミラティブの裏側の制御部分の開発や運用を担当しています。経歴としては、学生時代にLinuxやオープンソースにハマったのがきっかけで、IT業界に入りました。1社目では、自社製品をAWS上でSaaSとして提供するための構築と運用をひたすらやっていましたね。2社目は、AWSのようなホスティング系の会社で、Webサービスやメールサービスなどの開発・運用・管理を担当していました。

ミラティブに入ったきっかけは、本当に偶然で。当時やってたソシャゲ（ソーシャルゲーム）の攻略情報を探してたら、X（旧Twitter）でMirrativの配信開始のツイートを見かけたんです。「なんだこれ？」と思って触ってみたら、めちゃくちゃ面白くて。そこからは、職業も年齢も全然違う、いろんなユーザーさんと話すのが楽しくて、すっかりハマってしまいました。

「ここ面白そうだな」と調べてみたら、なんと当時勤めていた会社の真下のビルにオフィスがあることが判明して（笑）。「近い！」と思って応募したら、その場ですぐに採用されました。

松本：僕は2019年の10月に正社員として入社しました。前職でもライブ配信サービスに携わっていて、Webやアプリの開発、当時流行っていたVueでのハイブリッドアプリ開発などをしていました。配信サーバーのモジュール開発なんかもやってましたね。

ミラティブに興味を持ったのは、スマホだけでゲーム配信ができるという、当時としては画期的なサービスだったからです。PCと専門機材がないとゲーム配信ができなかった時代に、スマホだけで実現していることに衝撃を受けました。また、情報収集する中で漢さんがDeNA時代に発表した資料を読む機会があって、ミラティブで働く人たちの技術力の高さにもすごく魅力を感じていたんです。

入社当初は、漢さんが作った低遅延配信の通信プロトコルやサーバー実装に合わせて、iOS/Androidアプリの視聴プレーヤーや配信処理の実装、リリースを担当していました。そこから徐々にライブ配信基盤全般を見るようになり、インフラの仕事も幅広く手掛けるようになりました。

目指すのは「特定のクラウドに依存しない、分散したインフラ」の構築。大きな目標に向かって、一歩一歩山を登っていく。

ーーチームの体制や働き方について教えてください。
漢：僕らのチームは名前の通り「インフラチーム」と「ストリーミングチーム」が合体しているんです。なので、Mirrativで言うところの「インフラ」にあたるサーバーやネットワークの基盤部分は清水さん、配信の技術部分の「ストリーミング」は松本さん、という分担をしています。

清水：タスク管理は、GitHubのProjects機能を使ったKANBANで行っています。各々がどんなタスクを持っているかが一目でわかるようになっていますね。

漢：チームとしては、大きな目標から逆算して日々のタスクを決めています。例えば、今僕らが目指しているのは、「特定のクラウドに依存しない、分散したインフラ」の構築です。災害リスクも考えると、GCPだけで動き続けるのは怖いよね、と。この大きな目標を「山の頂上」とするなら、今は3合目か4合目くらいまで来た感じかな。

清水：僕はその登山道を一歩一歩作っているような感覚ですね。

松本：チームでは「Time Tagger」というツールを使って、どのタスクにどれくらい時間を使ったかを記録しながら作業を進めています。夕方にはチームの夕会があって、その日の進捗を共有しますね。週に一度の定例会では、その週にやったことや、メンバー間で共有すべき課題などを話し合っています。

漢：基本的にはフルリモートです。特に決まった出社ルールはありません。半年に1回くらい、全員で集まって振り返りをしたり、次の計画を立てたりするオフサイトがあるくらいですね。

「当番制」ではない。ユーザーのために自発的に動く文化

ーー24時間365日の障害対応はどのように行っているか教えてください
漢：僕らは、システムからのアラートを24時間365日、一番最初に受け取るチームです。なぜなら、そのアラートがインフラ起因なのか、アプリケーション起因なのかを一番正確に切り分けられるのが僕らだから。いつ鳴るかわからないアラートに常に備えて、Slackの通知は毎日気にして見ています。誰かがお風呂に入っていたら「今からお風呂入ります！誰か見てくれ！」みたいに声を掛け合ってカバーしたりもします。

牧野：当番制ではないんですね。

漢：そうなんです。「当番制」にしてしまうと、どうしても義務感が出てしまう。僕らのサービスは、ユーザーさんがいて初めて成り立つtoCサービスです。アラートが鳴るということは、その裏でユーザーさんが困っているということ。だからこそ、「自分がなんとかしなきゃ」「すぐに直そう」という気持ちで、自発的に向き合ってほしい。その想いから、あえて当番制にはしていません。

牧野：深夜や休日に対応した場合のケアはどうしてますか。

漢: 休日に一定時間以上働いた場合は代休が取れますし、フレックス制なので、深夜対応した次の日は朝ゆっくり業務を開始する、なんてことも自由です。そのあたりはかなり柔軟ですね。個人の裁量を信頼しているので、勤怠も制度の範囲内で柔軟にしています。

ーーチームの文化について、他に特徴的なものはありますか？
清水：とにかく「トラブルを放置しない」ことですね。インフラって、突然サーバーが落ちたり、トラフィックが急増したり、大小さまざまなトラブルがつきものなんです。たとえその場で根本原因がわからなくても、応急処置でもいいから何か手を打つ。ログを増やして次の発生に備えるとか、とにかく「今より絶対良くするぞ」という意識がチーム全体に根付いていると感じます。

松本：あとは、「サービス全体にとって何が最適か」を常に考える姿勢が強いですね。個人で仕事するというよりは、チームやサービス全体を見て、ベストな選択をしようとします。その拠り所として、「インフラポリシー」というチームの原則があって、みんながそれに則って最適なものを作ろうとしています。

▼インフラポリシーの詳細はこちら

漢：二人が言ってくれた通りですね。僕がチームに一番根付かせたいと思っているのが、「臭いものに蓋をせず、原因の真因を探す」ということです。これをやらないと、同じ問題が何度も発生して、結局自分たちが苦しむことになる。

松本さんが言ってくれた「インフラポリシー」は、実はミラティブの全社的な行動指針の誕生より前から存在していて、一度も変わっていないんですよ。それくらい、僕らのチームの根本的な考え方になっています。

なぜ自らコードを書くのか？「内製」がもたらす本当の価値

牧野：インフラエンジニアがコードを書く、というのはミラティブのインフラチームの大きな特徴ですよね。世間一般のインフラエンジニアはあまりコードを書かないイメージがありますが、なぜミラティブのインフラチームはコードを書くんですか？

漢：コードを書くようになったきっかけから話すと、昔は僕らもTerraformやitamaeといったツールを使っていたんです。でも、これらのツールだと、どうしてもアジリティが足りなかった。ちょっとした変更を加えたいだけなのに、結構な修正が必要で大変だったりする。それよりも、僕がAPIを叩いたプログラムを書けば、VMの起動が1分で終わる。「もうTerraformやめよう」と、そこから僕らのスタイルが始まりました。

既成のツールを使っていると、「足りない部分」が出てくるんです。その「足りない」を自分たちの力で作れるか、誰かにお願いするか。圧倒的に、自分たちで解決できた方がやれることの幅が広がるし、スピードも速いですよね。

清水さんは、ミドルウェアをガンガン作っています。VMを管理するサーバーとか、その中で動くデーモンサーバーとか。そうやって自分たちで細部まで作り込むことで、結果的に安定したインフラに繋がっていくんです。

清水：他の企業が作ったツールを使うのは、導入だけ見ればすごく楽です。でも、何かトラブルが起きた時、中身がブラックボックスで「作った人にしかわからない」という状況に陥りがちで。自分たちで内製すれば、細部まで挙動を把握できるので、トラブルにもすぐ対応できるし、機能拡張も自由自在。「自前で作る」ことには、計り知れない価値があると実感しています。

漢：まさにそうで、世の中のインフラエンジニアはIaC（Infrastructure as Code）を実践していると思うんですが、僕らはもう一歩先の「Infrastructure as Programming」を目指しています。コードでインフラを管理するのではなく、プログラミングでインフラを制御する。あらゆるものを自動化し、自分たちの手で最適な環境を作り上げています。

その象徴的な取り組みが、毎年恒例の社内ハッカソンですね。過去には、ユーザーさんの通信環境を計測する「スピードテスト」機能や、今まさに社内で大活躍しているVPNシステムを、たった1日で作りました。去年はWasm（WebAssembly）をどう活用できるか、今年はAI関連のテーマで、技術的な挑戦を楽しんでいます。

インフラの枠を超える。領域を横断し、サービス価値を最大化する

ーーこれだけ内製で開発していると、かなり忙しいのではないかと思うのですが、どうやってバランスを取っていますか？
漢：僕らは、他のチームのように「いつまでにリリース」という厳密なスケジュールに縛られることが少ないんです。それよりも「品質」を最優先している。良いものができていないなら、スケジュールを延ばす。品質が担保できないものはリリースしない。このスタンスだからこそ、無理な働き方にならずに済んでいるんだと思います。

ーーサービスが10年続き、規模も大きくなる中で、今後インフラ領域で「変えていくこと」と「変えないこと」は何でしょうか？
漢：変えないことは、今話してきた僕らの文化そのものです。「良いものを作る」という姿勢、「臭いものに蓋をしない」という徹底した原因究明、ユーザーに対する責任感。これらは絶対に変わりませんし、変えたくありません。

一方で、変えていくことはたくさんあります。清水さんが話したマルチクラウド化もそうですし、特定の技術への依存を減らして、もっと柔軟なインフラ構成にしていきたい。

そして、個人的に力を入れたいのがAIの活用です。実はもう、開発環境ではアラートを受け取ると、その原因を自律的に調査してくれる「インフラAIエージェント」が動いているんですよ。これももちろんオリジナルです。なかなか良いエージェントサービスが世の中になかったので、作っちゃいました。将来的には、SRE業務の一部をAIが担うような、人とAIが共存する世界を目指していきたいですね。

ーー個人として、今後挑戦したいことは何ですか？
松本：ストリーミング技術の専門性を高めていくのはもちろんですが、それに留まらず、インフラ全体の安定性や開発効率の向上にも、もっと貢献していきたいですね。

清水：僕は、いわゆる「インフラの領域だけ詳しい人」にはなりたくないんです。ミラティブに来て、Go言語を書くようになりましたが、やっぱり本業のバックエンドエンジニアには敵わない。でも、彼らにもっと歩み寄って、彼らの気持ちがわかるようになれば、もっと良いものが作れるはず。インフラの上で動くアプリケーションのことを深く理解できるエンジニアになりたいです。

漢：僕も二人の話に近いですね。サービスとして良いものを作るには、インフラだけ、ストリーミングだけ知っていてもダメなんです。バックエンドがどういう通信をしているか、どんなDBの使い方をしているかを想像することで、初めて最適な提案ができる。「内製Redis互換サーバ」や「egress proxy(ingressの記事はこちら)」といった仕組みも、そうした視点から生まれました。

今後は、例えば僕らが持つ画像解析のような高性能な処理を、バックエンドのメンバーがもっと気軽に使えるようなプラットフォームを作りたい。チームや領域の垣根を越えて、社内の技術リソースを誰もが活用できるような、そんな環境を整えていきたいと思っています。

牧野：インフラチームがバックエンドの領域に歩み寄ってくれるのは、バックエンドチームからしても大歓迎です。きっちり分業するより、お互いがちょっとずつ垣根を飛び越えることで、開発スピードは格段に上がりますから。

漢: まさにそう。僕もバックエンド出身だからわかるんですが、お互いの領域を知っていると、エンジニアとしての深みが全然違ってくるんですよね。

最後のメッセージ：インフラから、サービスの未来をデザインする仲間を求む

ーーそれでは最後に、この記事を読んでいる未来の仲間へ向けて、メッセージをお願いします。
漢: これからのインフラエンジニアは、インフラだけを見る時代ではありません。プログラミングはもちろん、ストリーミング、バックエンド、セキュリティなど、あらゆる領域にアンテナを張り、サービス全体を最適化していく重要なポジションです。
僕らのチームは、まさにそれを実践しています。インフラとストリーミング、両方の視点から、どうすればサービスが一番良くなるかを常に考えている。だから、特定の技術のマイクロチューニングだけに留まらず、サービス全体のアーキテクチャ設計に挑戦したい人、もっと言えば、Mirrativというサービスの未来を自分たちの手で変えていきたい、デザインしたいと思ってくれる方には、最高の環境だと思います。
インフラという枠組みに囚われず、幅広い挑戦がしたい方、ぜひ一度お話ししましょう。お待ちしています！

ミラティブでは積極的に採用活動を行っています。本記事を読んで、ミラティブに興味を持ってくださった方は、ぜひお気軽にご応募ください。