SRE強化・可用性向上・モジュラモノリス化。アソビューの事例から開発組織拡大の知見を学ぶ

「生きるに、遊びを。」をミッションとし、日本最大級の遊び予約サイト「アソビュー！」やレジャー業界のDXを推進するSaaS「ウラカタ」シリーズなどを提供するアソビュー株式会社。同社の開発組織の人数は、1年半前と比較して1.5倍の約100人となっています。また「アソビュー！」の累計会員数は1,000万人を突破し、サービスの規模も大きくなっているのです。開発組織やサービスを成長させるうえで、アソビューではどのような工夫をしているのでしょうか。VPoT 技術本部副本部長 技術戦略部部長の兼平大資さんに聞きました。

全員が「フルサイクルエンジニア」であるために

――兼平さんは2023年までVPoEの役割を担われていましたが、2024年からはその役割を服部毅保さんにバトンタッチされ、ご自身はVPoTになりました。この経緯からまずはご説明ください。

もともと、私がVPoEをしていたのはCTOの江部さんからの依頼がきっかけでした。開発組織がだんだんと大きくなっていくなかで、江部さんから「開発組織の全体を見てもらえないか」と声をかけられたんです。それを受けて、VPoEとテックリードを兼任しつつ働いていました。

そこから数年が経ってアソビューの開発組織は100名規模になり、このまま私が兼務でVPoEを担当するよりも、他の誰かに専任で任せたいと思うようになりました。服部さんは人や組織を見ることに長けているので、彼にVPoEを任せて私はVPoTとして技術面を見ることに注力すると決めました。

――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的・組織的な意思決定のなかで印象に残るものや、そこから得た学びを話していただきます。

前提としてアソビューが重視していることをお伝えすると「顧客の課題を解決すること」「ユーザーの方々に喜んでいただけること」が大切だとみなが思っていて、私たちマネジメント層は「エンジニアに、その思いをいかにして仕事で実現してもらうか」を考えています。

しかし、開発組織の規模が大きくなるとタスクが徐々に細分化されていき、「目の前の仕事をやっていけばいい」と個別最適化が起こってしまいます。そうではなく、エンジニア個人が事業やユーザーのことを俯瞰して捉えて、全体最適の動きができることが重要です。

そこで、CTOやエンジニアリングマネージャーたちと話し合って決めたのが「アソビューのエンジニアには、フルサイクルエンジニア*になってもらいたい」というビジョンでした。

*…設計や開発だけでなく顧客への価値提供が仕事であると捉え、運用とサポートを含めたサービスライフサイクルの一連のタスクすべてを担うエンジニアのこと。

――フルサイクルにするために、どのような制度や仕組みを構築していますか？

具体的な施策についてはこれから整備していくところですが、いまはエンジニアリングマネージャーには各メンバーに「フルサイクルエンジニアを目指す意義」について伝えてもらい、意識付けをしています。

この先の目標としては、メンバーの何割かに定期的なジョブローテーションをお願いして、開発組織のなかでいろいろなポジションを経験してもらおうと考えています。そうした施策が最終的には、事業やユーザーのことを考えられるエンジニアを増やし、組織が継続して成長することにつながります。

3種類のSREがサービスを支える

――他の事例についても教えてください。

私たちの開発組織にはService SREとPlatform SRE、Embedded SREという3種類のSREが存在しているのですが、その経緯や意図をお話しします。私たちが事業を開始してシステムの開発を始めたばかりのタイミングでは、エンジニアは細かな役割に分かれておらず、全員がどんなタスクでも担当していました。

そして、だんだんと事業が成長してエンジニアが20～30名ほどになり、「アソビュー！」や「ウラカタ」などのユーザーや契約施設も増え、「サービスの信頼性を高めよう」という流れになったんです。そこで、約6年前に独立した専門のSREチームを設立しました。

これによりサービスを安定して運用できる体制にはなったものの、一方でDevとOpsが分離しているという、ありがちな問題が生じてきました。SREがプロダクトの課題を理解して最適解を見つけることが難しいとか、逆に開発チームから見るとインフラやCI/CDがブラックボックスになりやすいという傾向にあったんです。

そのため開発チームから有志を募り、業務時間を10%程度使って開発チームとSREチームの橋渡しを行ってもらうEmbedded SREを設置し、SREチーム+Embedded SRE体制に移行しました。こうして、開発チームとSREチームとの間の情報連携やシステムの全体最適化の促進ができるようになったんです。

その後、さらに運用体制を強化するためService SRE+Platform SRE+Embedded SREという体制に変化しました。これにも理由があり、事業やシステム、開発組織が成長していくにつれ、可用性・セキュリティ向上、開発生産性の改善、アーキテクチャ最適化などの多種多様なタスクをすべてSREチームが抱えて、負担が大きくなっていたんです。

そこで、開発生産性や長期的な課題を解決することをミッションとしたPlatform SREチームと、システムの信頼性を高めることにフォーカスしたService SREチームとに、チームを分離することにしました。

――アソビューはかなり柔軟にSREの体制を変化させていますが、どのような考え方をすればこうした体制変更を実現できるでしょうか？

課題をどのように捉えるかと、将来像をどう考えるかが重要だと思っています。ここで言う“課題”には顧客の課題や社内のメンバーが抱える課題など、複数の種類があります。それらのフィードバックを常に得ながら、「どのような状態になれば解決し得るのか」を考え続けていくことです。

そして、社内だけではなくて社外からのインプットを増やし続けることも大切です。たとえば、今回のインタビューで出てきたようなフルサイクルエンジニアやプラットフォームエンジニアリングなどの概念も、もとは他社が提唱し始めた概念です。それを、自分たちの開発組織に適用するためにはどうするかを考えたうえで、現在のような仕組みにしています。

＜参考記事＞

アソビューを支える3つのSRE。それぞれの専門性を活かすための組織体制

守りの施策に振り切った可用性向上プロジェクト

――他にはどのようなエピソードがあるでしょうか？

2021年から2022年5月にかけて取り組んだ、可用性向上プロジェクトの話をさせてください。2021年は、サービスが高い成長率を維持しており、契約している事業者の数も商品数もアクセス数も順調に伸びているタイミングでした。しかし、それに伴ってシステムの障害が多発するようになり、利用者にご迷惑をおかけする事態になっていたんです。

それまで私たちの会社は、事業成長していくための「攻めの施策」が中心でした。しかし、この事態を重く捉えて、事業推進関連の施策をいったん止めて開発チーム全体で半年かけて可用性向上に総力を上げることにしたんです。サーキットブレーカーの設置やCDNの利用拡大、SQLの性能劣化の検知、システムのデプロイ速度を向上させることによるリカバリ速度向上など、複数の施策を同時に推進しました。

――記事を読まれる方々のなかにも、システムの可用性向上のために何らかの対策を講じなければならない立場の人もいるはずです。この事例を踏まえて、伝えたいことはありますか？

費用対効果を考えるということを挙げたいです。このプロジェクトは「半年間でやりましょう」という期限が決まっていたので、開発チーム全体で取り組むとはいっても実施できることは限られていました。そこで、手当たり次第にいろいろな施策に手を付けるのではなく、システムの可用性を維持するうえで問題になりやすい箇所と、それに対応するための選択肢があるかを初期フェーズで洗い出したんです。それらにかかる工数や、実現した場合にどれくらい可用性が上がるかを鑑みて、費用対効果の高いものからやっていくという進め方をしましたね。

その結果、対応してから現在まではかなり安定してサービスを運営し続けられています。サービスのトラフィックは毎年1.5倍のペースで増加していますが、それでも障害は発生しにくくなりました。それから副次的な効果として、開発チーム全体で取り組んだプロジェクトだったことから、エンジニア一人ひとりにサービスの可用性や信頼性を大切にする意識が根付いたのも大きかったです。

＜参考記事＞

分間約50,000リクエストに耐えられるように、可用性向上に全集中した話。開発チーム全体で半年かけて挑んだ改善

集約と分散をコントロールする

――他にはどのような事例がありますか？

モジュラモノリス化やMonorepo化についてお話しします。アソビューのシステムはモノリスなアーキテクチャから始まって、会社が成長するに伴って新規事業を立ち上げる際には、システムも新規に構築してきました。そして、さらに事業や組織が拡大するにつれて、よりアジリティを向上させるためにマイクロサービス化を推進したんです。

これは短期的には成長に効果的だったものの、サイロ化の促進や全体最適化の難易度の上昇など、複数の問題が発生するようになりました。また、マイクロサービス化に伴っていくつもリポジトリが作られ、最も多い時期には120個ほどにまで増えていました。それだけたくさんあると、メンバーがシステムの全容を把握するのも困難になってしまいます。私たちがモノリスとマイクロサービスの運用を経験して学んだのは「集約と分散をうまくコントロールするのが重要」ということでした。 そこで私たちは、モジュラモノリスへのアーキテクチャ変更を進めました。

モジュラモノリスは、デプロイするアプリケーションは1つであるものの、システム内部は複数のモジュールに分割されています。マイクロサービスの抱えていた課題の多くを回避しつつも、システムの集約・分散を適切に管理しやすいという利点があります。また、これに伴って山ほど存在していたリポジトリも1つに集約し、Monorepo化も進めました。

＜参考記事＞

マイクロサービスによって起こったサイロ化に対する取り組み

3ヶ月で120のリポジトリを1つのMonorepo(モノレポ/モノリポ)に移行した話

「顧客の課題を解決する」意識が強い会社

――今回のインタビューの内容を踏まえて、「アソビューの開発組織の良さ」はどのような点にあると思われますか？

私は個人的に、「顧客の課題を解決しよう」という意識を、エンジニア一人ひとりが非常に高いレベルで持っているのが良さだと思っています。採用するうえでも、そこを重視しているんですよね。だからこそ、何かの方針を考える際にメンバー同士の目的意識が揃いやすいですし、共通認識を持ったうえで「どのような方法を取ろう」とか「どのような技術を使おう」と話し合えるのが強みだと思います。

――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的・組織的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

そうした事例は、成功した内容だけではなく背景にあった課題や失敗なども含めて公開されていることが多いです。私たちのシステムや開発組織は、もちろん独自の部分もあるんですが、他社のシステムや開発組織と似ている部分もたくさんあります。

だからこそ、他の人々がどのような課題を抱えていたか、どう解決したかを知るのは、自分たちの事業をより成長させていくうえで非常に役立つと思っています。そうした知識を得ておくことで、自分たちが同じような課題に直面した際、解決するためのひとつの選択肢になります。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul