究極はチームをなくしても回る仕組みづくり─FANSHIPを360°から見るエンジニアチームが考えていること

こんにちは。PRチームのnonaskです。

ファン育成プラットフォーム・FANSHIPの中の人を知ってもらうためのインタビューシリーズ、今回は大規模サービスをがっちり支えるFANSHIP運用チームのみなさんにお話を聞きました。

「運用」と聞いて想像したのとはちょっと違う、チャレンジングで未知数だらけのめちゃくちゃ格好いい仕事ぶり、ぜひご一読ください。

左上から時計回りに、川口さん、井口さん、植木さん、城山さん。植木さんは記事内には登場しませんが、運用チームのスクラムにおけるプロダクトオーナーとしてインタビューにご協力いただきました。

──ではまずリーダーの川口さんから、運用チームのお仕事内容について教えてください。

運用チームリーダー 川口：
分け方次第ですが、大きく５つに分けると以下のような担当範囲となっています。

１．FANSHIPのサービスレベルの維持
社内で事前に決めたお客さまへのサービス提供レベルを出せるように活動する。
「観測→検知→計画→実行」という流れを主導し、必要に応じて他チームの力を借りて解決に導いていく。

２．カスタマーリレーション（CR）グループとの連携
FANSHIPのカスタマーサポート/サクセスを担当しているCRグループからエスカレーションされてきた技術的な問い合わせへの一次対応を行い、他のエンジニアチームとの連携が必要な場合は集約して技術側の窓口となる。
その他、ログ調査やシステム状態の確認方法など、技術的知識の共有・連携も密に実施。

３．開発環境の管理
開発メインのエンジニアチームがそれぞれ開発環境を使っていく中で、環境が被って上手く使えなかったり環境が荒れたりするなどの支障が出ないよう、責任を持って全体を管理する。

４．コスト（サーバ費用）の観測
FANSHIPのサービスを運用していく中での費用を毎日確認して、突然増えたり想定外のコストが発生していないか観測する。

５．トラブルが起きた時に素早く対応できるチームづくり
開発チームの中でリソースが足りなかった時のヘルプや差し込みタスクを柔軟に受けられるようにするなど、FANSHIP全体の技術的業務に入れるチームづくりを行う。

いま私を含め3名のチームですが、あえて担当分けせず全員が同じことをできるチームを目指しています。
FANSHIPは24時間365日提供しているサービスなので、特定の人しか対応できないタスクがあると、何かあった時にその人が24時間稼働することになってしまいます。
そうならないためにも、属人化を防ぐことは重視しています。

私自身のチームリーダーとしての仕事は、スクラムマスターとしてチームの業務を上手く回すことです。
運用チームは、アジャイル開発の手法の一つであるスクラムという開発手法を取り入れ、計画から実施、振り返りというスプリント（業務のサイクル）を1週間単位で回すことでなるべく差し込みに強い体制を作っています。
スクラムマスターはこのサイクルが適切に回るように各メンバーを補助する人のイメージです。

いまのチームになる前の写真ですが、今年の初めにスプリントレトロスペクティブ（振り返り）を行う川口さんと当時の運用チームの様子

──「運用」という言葉から想像していたよりかなり広い守備範囲、かつイレギュラーな業務が多そうで驚きました。仕事をする中で大変なところってどんなところなんでしょうか。

城山：
日々多く寄せられるCRグループからの問い合わせにしても障害対応にしても、すぐに回答できない難しいタスクが多く、調査や調べ物に費やす時間は多いです。知識が足りない時は人の力を借りることも必要です。
障害対応であれば適切な対処とスピード感の両方が求められるので、技術情報やサービスの知識について、とにかく知らない部分を調べて潰すという、日々勉強の連続ですね。
自分は昨年度まで開発側の機能強化チームにいたんですが、学ぶ機会が多いのは運用としてのやりがいとも感じています。

井口：
僕は先月入社したばかりで、まず全体の流れを掴むところから取り組んでいます。
前職ではウォーターフォール型の開発に携わっていたので、かっちり決まったものを順序立ててやってきましたが、いまは突発の業務が多く、かつ解決方法も原因もわからない状態から始まることがほとんどです。
システムの問題なのかお客さまの利用方法の問題なのかなど、毎回特定から始める必要があります。

城山：
FANSHIPは規模も大きいので、1ヶ月だとシステムの理解から始めなくてはいけないのが大変だと思います。

──しかも入社以来ずっとリモートワークですよね。質問したりするのにも余計大変なんじゃないですか？

井口：
入社日当日のオリエン以外はずっとリモートで一切出社していないですが、さまざまなツールを駆使して普段会っているのと変わらないくらいのコミュニケーションは取れていると感じています。
いつでもいいよというオープンな雰囲気も作っていただいているので、ちょっと聞きたいことがある時も、DiscordやSlackを使って、席の後ろから話しかける感覚で話せていますね。

運用チームリーダー 川口：
Discordは常時ログインしていて会話部屋に入ればすぐに話せる点で通話に至るまでのステップやハードルが低いので、一部チームで使っています。

大変さの話に戻ると、お二人が話してくれたとおりですが、運用チームはシステムのカバー範囲が広く、FANSHIP全体を見なくてはなりません。
FANSHIPは複数のシステムで構成されているのですが、そのシステムごとに使っている技術が違っているので、業務の知識に加え技術的な知識が幅広く求められます。
さらに属人化排除というチームの方針もあるので覚えることは多いですね。

また、FANSHIPはいろいろなお客さまがサーバやシステムを共有するマルチテナントサービスで、トラフィックやリクエストが多くシステム負荷が高い部類に入ります。
その分運用の難易度は高いですし、当初想定したよりも高度な使い方をされるお客さまもいますので、観測が欠かせません。
原因特定のためには、日頃からお客さまごとの使い方を把握して計測できるようにしておくことも重要です。

──聞けば聞くほど覚えることが多い・・！大変さと面白さはセットだったりもしますが、やりがいやモチベーションとなることってどんなことですか？

井口：
自分自身運用業務は初めてで、これまでやってきた開発とは違う業務として楽しみでした。
運用を通してシステム全体のことを知れるのが楽しいですし、ピンポイントで何かを作っていたら把握できないところも多いと思います。
あとは誰もが知っている大企業のお客さまに多数採用されていて2億人近い延べユーザーがいるような大規模サービスに携われるのは、ミスをしたら大事故に繋がるという緊張感はもちろんありますが、やはりやりがいがあります。

城山：
先ほどもお話しましたが学びが多いところです。
中でも、一般に知られていない細かい技術とか、調べても調べても出てこないようなニッチな技術を体得することは自分自身の市場価値を上げることにも繋がるんじゃないかなと。
例えばAWSなど多くの企業が使っているサービスでも、それをどう使うかはビジネスによって違ってくるし、それによって問題も違ってきます。
さまざまな事例に立ち会え知識が得られるのは面白いところだと思います。

運用チームリーダー 川口：
運用・保守と言うと、以前は専任の人材が与えられた範囲の中で業務を行い開発ともサービス全体ともビジネスとも関わらないイメージが一般的でしたが、最近のグローバルIT企業やそれに追従する国内企業ではDevOpsやSREと呼ばれる文化を取り入れて運用業務をより理想形に近づけていこうという流れが出てきました。
ざっくり言うと、ソフトウェアエンジニア自身が運用を担当しサービス全体の信頼に貢献していこうというような流れです。
運用という分野自体の環境や意識が変わろうとしている時で、勉強会も盛り上がってきています。
そういったタイミングで日々新しい情報に触れ自分自身も新しい取り組みにチャレンジできる環境にいるのはモチベーションになっていますね。
FANSHIPというサービスに関して言えば、難易度が高いので学ぶところが多いのはやりがいがあります。

──なるほど。私が想像していた「運用」とのギャップが大きかったのも、まさにいま変革期にいるからなんですね。今後はどんなことに取り組んでいくのか教えてください。

城山：
自分が運用チームに入る前からの「これ改善したい」というタスクが結構溜まっているので、まずそれを消化し切りたいです。
消化する中でまた自分自身が気づいた改善点が出てくると思うので、それを挙げては解消してブラッシュアップしていきたいと思っています。

井口：
先ほど城山さんのお話にもありましたが、業務の中でネットで調べても出てこない情報が多々あるので、これらを社内に限らず社外の人も使えるようなクオリティでドキュメント化して残していけたらと思っています。
足元の具体的な話で言うと、ロードバランサのログを自動で取得しそれを監視ツールに転送する仕組みを現在作っているので、これをコードベースで実現するスマートな方法をまとめ、アイリッジの技術ブログでも公開する予定です。

運用チームリーダー 川口：
ドキュメントについては保守という視点で以前から課題があったのですが、最近はNotionに運用チームとして内容を保証するドキュメントグループというのを整備してそこをきちんとメンテナンスすることで担保しています。

私個人としては、いろんなエンジニアが関わることで運用業務がいいものになっていくと考えているので、エンジニアなら誰でも運用チームにアサインできるくらい運用業務の自動化や効率化、知識の共有を進めていきたいです。
あらゆる人が関われるようにすることで、ゆくゆくは運用チームをなくして担当レベルでローテーションできるくらい負荷が低い状態に持っていけたらより良いと思っています。

──運用チームのインタビューなのに運用チームをなくしたいという驚きの締めに（笑）。でもさらに広い範囲のチーム力を上げる、すごく面白い視点ですね。
今日はみなさんありがとうございました！