「生きるに、遊びを。」をミッションとし、日本最大級の遊び予約サイト「アソビュー！」やレジャー業界のDXを推進するSaaS「ウラカタ」シリーズなどを提供するアソビュー株式会社。同社の開発組織の人数は、1年半前と比較して1.5倍の約100人となっています。また「アソビュー！」の累計会員数は1,000万人を突破し、サービスの規模も大きくなっているのです。開発組織やサービスを成長させるうえで、アソビューではどのような工夫をしているのでしょうか。VPoT 技術本部副本部長 技術戦略部部長の兼平大資さんに聞きました。<h2 id="h61de5f0b86">全員が「フルサイクルエンジニア」であるために</h2>――兼平さんは2023年までVPoEの役割を担われていましたが、2024年からはその役割を服部毅保さんにバトンタッチされ、ご自身はVPoTになりました。この経緯からまずはご説明ください。もともと、私がVPoEをしていたのはCTOの江部さんからの依頼がきっかけでした。開発組織がだんだんと大きくなっていくなかで、江部さんから「開発組織の全体を見てもらえないか」と声をかけられたんです。それを受けて、VPoEとテックリードを兼任しつつ働いていました。そこから数年が経ってアソビューの開発組織は100名規模になり、このまま私が兼務でVPoEを担当するよりも、他の誰かに専任で任せたいと思うようになりました。服部さんは人や組織を見ることに長けているので、彼にVPoEを任せて私はVPoTとして技術面を見ることに注力すると決めました。――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的・組織的な意思決定のなかで印象に残るものや、そこから得た学びを話していただきます。前提としてアソビューが重視していることをお伝えすると「顧客の課題を解決すること」「ユーザーの方々に喜んでいただけること」が大切だとみなが思っていて、私たちマネジメント層は「エンジニアに、その思いをいかにして仕事で実現してもらうか」を考えています。しかし、開発組織の規模が大きくなるとタスクが徐々に細分化されていき、「目の前の仕事をやっていけばいい」と個別最適化が起こってしまいます。そうではなく、エンジニア個人が事業やユーザーのことを俯瞰して捉えて、全体最適の動きができることが重要です。そこで、CTOやエンジニアリングマネージャーたちと話し合って決めたのが「アソビューのエンジニアには、フルサイクルエンジニア*になってもらいたい」というビジョンでした。*…設計や開発だけでなく顧客への価値提供が仕事であると捉え、運用とサポートを含めたサービスライフサイクルの一連のタスクすべてを担うエンジニアのこと。――フルサイクルにするために、どのような制度や仕組みを構築していますか？具体的な施策についてはこれから整備していくところですが、いまはエンジニアリングマネージャーには各メンバーに「フルサイクルエンジニアを目指す意義」について伝えてもらい、意識付けをしています。この先の目標としては、メンバーの何割かに定期的なジョブローテーションをお願いして、開発組織のなかでいろいろなポジションを経験してもらおうと考えています。そうした施策が最終的には、事業やユーザーのことを考えられるエンジニアを増やし、組織が継続して成長することにつながります。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/846369e60d874a5ab29e4126b5ceab9b/image2.jpg" alt="" width="1999" height="1334"></figure><h2 id="h02d5dfb346">3種類のSREがサービスを支える</h2>――他の事例についても教えてください。私たちの開発組織には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の体制を変化させていますが、どのような考え方をすればこうした体制変更を実現できるでしょうか？課題をどのように捉えるかと、将来像をどう考えるかが重要だと思っています。ここで言う“課題”には顧客の課題や社内のメンバーが抱える課題など、複数の種類があります。それらのフィードバックを常に得ながら、「どのような状態になれば解決し得るのか」を考え続けていくことです。そして、社内だけではなくて社外からのインプットを増やし続けることも大切です。たとえば、今回のインタビューで出てきたようなフルサイクルエンジニアやプラットフォームエンジニアリングなどの概念も、もとは他社が提唱し始めた概念です。それを、自分たちの開発組織に適用するためにはどうするかを考えたうえで、現在のような仕組みにしています。＜参考記事＞<a href="https://tech.asoview.co.jp/entry/2024/04/12/090000">アソビューを支える3つのSRE。それぞれの専門性を活かすための組織体制</a><h2 id="h3c439f51b9">守りの施策に振り切った可用性向上プロジェクト</h2>――他にはどのようなエピソードがあるでしょうか？2021年から2022年5月にかけて取り組んだ、可用性向上プロジェクトの話をさせてください。2021年は、サービスが高い成長率を維持しており、契約している事業者の数も商品数もアクセス数も順調に伸びているタイミングでした。しかし、それに伴ってシステムの障害が多発するようになり、利用者にご迷惑をおかけする事態になっていたんです。それまで私たちの会社は、事業成長していくための「攻めの施策」が中心でした。しかし、この事態を重く捉えて、事業推進関連の施策をいったん止めて開発チーム全体で半年かけて可用性向上に総力を上げることにしたんです。サーキットブレーカーの設置やCDNの利用拡大、SQLの性能劣化の検知、システムのデプロイ速度を向上させることによるリカバリ速度向上など、複数の施策を同時に推進しました。――記事を読まれる方々のなかにも、システムの可用性向上のために何らかの対策を講じなければならない立場の人もいるはずです。この事例を踏まえて、伝えたいことはありますか？費用対効果を考えるということを挙げたいです。このプロジェクトは「半年間でやりましょう」という期限が決まっていたので、開発チーム全体で取り組むとはいっても実施できることは限られていました。そこで、手当たり次第にいろいろな施策に手を付けるのではなく、システムの可用性を維持するうえで問題になりやすい箇所と、それに対応するための選択肢があるかを初期フェーズで洗い出したんです。それらにかかる工数や、実現した場合にどれくらい可用性が上がるかを鑑みて、費用対効果の高いものからやっていくという進め方をしましたね。その結果、対応してから現在まではかなり安定してサービスを運営し続けられています。サービスのトラフィックは毎年1.5倍のペースで増加していますが、それでも障害は発生しにくくなりました。それから副次的な効果として、開発チーム全体で取り組んだプロジェクトだったことから、エンジニア一人ひとりにサービスの可用性や信頼性を大切にする意識が根付いたのも大きかったです。＜参考記事＞<a href="https://tech.asoview.co.jp/entry/2022/12/25/092015" target="_blank" rel="noopener noreferrer nofollow">分間約50,000リクエストに耐えられるように、可用性向上に全集中した話。開発チーム全体で半年かけて挑んだ改善</a><figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/fd76197d815f42a5addf1bda75de7089/image1.jpg" alt="" width="1999" height="1334"></figure><h2 id="h2ad04e6c4c">集約と分散をコントロールする</h2>――他にはどのような事例がありますか？モジュラモノリス化やMonorepo化についてお話しします。アソビューのシステムはモノリスなアーキテクチャから始まって、会社が成長するに伴って新規事業を立ち上げる際には、システムも新規に構築してきました。そして、さらに事業や組織が拡大するにつれて、よりアジリティを向上させるためにマイクロサービス化を推進したんです。これは短期的には成長に効果的だったものの、サイロ化の促進や全体最適化の難易度の上昇など、複数の問題が発生するようになりました。また、マイクロサービス化に伴っていくつもリポジトリが作られ、最も多い時期には120個ほどにまで増えていました。それだけたくさんあると、メンバーがシステムの全容を把握するのも困難になってしまいます。私たちがモノリスとマイクロサービスの運用を経験して学んだのは「集約と分散をうまくコントロールするのが重要」ということでした。 そこで私たちは、モジュラモノリスへのアーキテクチャ変更を進めました。モジュラモノリスは、デプロイするアプリケーションは1つであるものの、システム内部は複数のモジュールに分割されています。マイクロサービスの抱えていた課題の多くを回避しつつも、システムの集約・分散を適切に管理しやすいという利点があります。また、これに伴って山ほど存在していたリポジトリも1つに集約し、Monorepo化も進めました。＜参考記事＞<a href="https://tech.asoview.co.jp/entry/2021/12/05/000000">マイクロサービスによって起こったサイロ化に対する取り組み</a><a href="https://tech.asoview.co.jp/entry/2022/12/23/095914">3ヶ月で120のリポジトリを1つのMonorepo(モノレポ/モノリポ)に移行した話</a><h2 id="hcba1773ce2">「顧客の課題を解決する」意識が強い会社</h2>――今回のインタビューの内容を踏まえて、「アソビューの開発組織の良さ」はどのような点にあると思われますか？私は個人的に、「顧客の課題を解決しよう」という意識を、エンジニア一人ひとりが非常に高いレベルで持っているのが良さだと思っています。採用するうえでも、そこを重視しているんですよね。だからこそ、何かの方針を考える際にメンバー同士の目的意識が揃いやすいですし、共通認識を持ったうえで「どのような方法を取ろう」とか「どのような技術を使おう」と話し合えるのが強みだと思います。――最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的・組織的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？そうした事例は、成功した内容だけではなく背景にあった課題や失敗なども含めて公開されていることが多いです。私たちのシステムや開発組織は、もちろん独自の部分もあるんですが、他社のシステムや開発組織と似ている部分もたくさんあります。だからこそ、他の人々がどのような課題を抱えていたか、どう解決したかを知るのは、自分たちの事業をより成長させていくうえで非常に役立つと思っています。そうした知識を得ておくことで、自分たちが同じような課題に直面した際、解決するためのひとつの選択肢になります。取材・執筆：中薗昴撮影：山辺恵美子提供：<a href="https://haulinc.jp/">株式会社Haul</a>

開発組織やサービスを成長させるうえで、アソビューではどのような工夫をしているのでしょうか。VPoT 技術本部副本部長 技術戦略部部長の兼平大資さんに聞きました。

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

はじめまして、<a href="https://www.asoview.co.jp/">アソビュー</a>でデータ基盤チームに所属している霧生です。近年、モダンデータスタックの登場などによりデータ分析基盤は一層盛り上がりを見せています。選択肢も増えてできることが多くなった反面、どう構築していくか迷う場面も多いのではないでしょうか。今回はアソビューのデータ分析基盤の構成と現状の課題、将来的な改善をどう考えているのかなどを解説しますので、ご参考になれば幸いです。<h2 id="h551033d7c6">現在のアソビューのデータ分析基盤</h2>アソビューは創業10周年を超えており、当然ながら今までもデータを分析して事業やサービスに役立ててきました。しかし、コードやインフラの継ぎ足しを重ねたことにより秘伝のタレのような状態と化してしまい、多くの課題が生まれています。そこで、アソビューではこの問題を解消するために、昨年から<a href="https://datale.co.jp/">株式会社DATALE</a>さんとともにデータ分析基盤の再構築を行いました。データ分析基盤を構築するにあたり、「使われる」データ分析基盤にすることを大切に設計・実装していきました。というのもそもそも「データ分析基盤は使われなければ意味がない」からです。ただデータを収集しているだけ、データ分析基盤を作ることだけが目的になってしまっている場合、どれだけ優れたアーキテクチャを組んでも、データからインサイトを得てビジネスに役立てるデータ活用のプロセスが進みません。では、どうすればデータの活用が進むのでしょうか。その答えのひとつが弊社も利用しているBIツール、<a href="https://www.tableau.com/ja-jp" target="_blank" rel="noopener noreferrer nofollow">Tableau</a>が提唱しているビジュアル分析のサイクルにあると考えています。<figure><a href="https://help.tableau.com/current/blueprint/ja-jp/bp_cycle_of_visual_analysis.htm" target="_blank" rel="noopener noreferrer nofollow"><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/5a80e285e9884c8894dbfeb628a3f26e/image1.png" alt="" width="489" height="425"></a><figcaption>ビジュアル分析のサイクル。画像は https://help.tableau.com/current/blueprint/ja-jp/bp_cycle_of_visual_analysis.htm より引用。</figcaption></figure>「どこからデータを分析していけばいいかわからない」「分析結果を見てもよくわからない」というユーザーからのフィードバックは「タスク」がないことに起因していることが多いです。簡単な例ですが、「売り上げを上げたい」「コストを下げたい」といったタスクに対して、どんなデータを見ればいいか、さらにそのデータをどう見ればいいかなどを考えて、必要十分なデータを取捨選択していくことが重要です。こうして適切なデータを適切に扱うことで、より価値のある活用につながります。また、ビジュアル分析のサイクルはただのプロセスサイクルではないため、分析を行う中でさらに必要なデータが出てくることもあります。柔軟かつ高速にビジュアル分析のサイクルを回すことで、データ分析基盤は使われる・価値のあるものに進化していきます。分析者と同じ視点に立ち、高速に新しいデータを連携して分析のプロセスを回す。これがデータ分析基盤を新規に作り上げていく段階では特に重要な観点だと考えています。そこで私たちが導入したのが<a href="https://trocco.io/lp/index.html">trocco</a>です。troccoとはETL/データ転送機能を提供する分析基盤構築・運用支援のSaaSです。troccoを提供している<a href="https://primenumber.co.jp/">株式会社primeNumber</a>が日本企業ということもあり、日本語での手厚いサポートや日本でよく使われるSaaSからのデータ連携にも多く対応しています。troccoは主にGUIで設定を作成するため、初期の学習コストや設定作業のコストを大幅に削減でき、いち早くデータを提供できます。また、データウェアハウスには<a href="https://cloud.google.com/bigquery?hl=ja">BigQuery</a>を採用しました。これも構築・提供スピードを重視した技術選定です。GAなどの他のGoogleサービスとの親和性や、よく使われるSaaSとの連携に対応していることを考えて選択しました。最終的なアーキテクチャは下記のようになりました。<figure><img src="https://images.microcms-assets.io/assets/a305d34415d64c7cb069450481b6130c/8ed3924aac5846ada4dbc3991266cc67/image2.png" alt="" width="1537" height="865"></figure>troccoにはデータマート生成という機能があり、これを利用して収集したデータを最終的に分析可能な状態に変換してデータマートを構築しています。BIツールは先にも出てきたTableauを利用しており、直近では社内のアクティブユーザー数が全社員の4分の1に迫る40人前後、Tableau Cloud上での分析結果のView数は約600view/日と、広く使われる状態を実現できていると感じています。今ではマーケティング施策やモニタリングだけではなく、アプリケーションへのデータの利活用や広告の最適化など、さまざまな用途でデータ分析基盤が使われています。これは株式会社DATALEさんのご協力はもちろんですが、分析しているアソビュー社員のデータに対しての感度の高さや意欲など、さまざまな立場とスキルを持ったメンバーが揃い尽力した結果だと思います。データ分析基盤は使われなければ意味がないと冒頭で書きましたが、それはつまりエンジニアだけで作り上げるものではなく、使っている人や状況に応じてアーキテクチャも変わっていくべきということです。現状は前述の構成を使っていますが、運用している中での課題も出てきており、その解決のためには小手先の対応ではなくアーキテクチャレベルの改修が必要になっています。<h2 id="h7070e90391">将来的なデータ分析基盤の構想と導入したい技術</h2>先に挙げた現状抱えている課題ですが、大きく分けて下記の2つがあります。<ul><li>データマートに対してのSQLの実行速度とデータ基盤全体の料金</li><li>データ分析基盤の堅牢性</li></ul><h3 id="h4312134b13">データマートに対してのSQLの実行速度とデータ基盤全体の料金</h3>ビジュアル分析のサイクルを高速に回していくには、さまざまなデータについて異なる角度から何度もビジュアル分析を試すデータ探索によって、BIツールから素早く結果を取得できることが重要になります。アソビューではデータ分析基盤の利用が拡大し分析可能なデータが加速度的に増えていった結果、いくつかのテーブルで速度劣化が起きるようになりました。また、うれしい悲鳴ではありますが、データ分析基盤の利用が拡大し利用者が増えたことにより料金も大きく増加しています。テーブルの構造変更やBigQueryの機能の利用など、現状のアーキテクチャでも改善できる部分は当然あると考えています。しかし投げるクエリやテーブルの性質、利用しているBIツールとの相性などを鑑みて、アソビューの場合は同時並行で検証を行っていた<a href="https://www.snowflake.com/ja/">Snowflake</a>を利用することでこれらの課題に対して一定の効果が期待できると判断しています。速度面では、データ探索中にTableauが類似したクエリを多く投げる点や、ライブ接続でViz*を見た場合に同じクエリが投げられる点などから、Snowflakeの強力なキャッシュ機能の恩恵を受けやすいこと。料金面では従量課金の方式がBigQueryではデータのスキャン料であるのに対して、Snowflakeはデータウェアハウスというコンピュートリソースの起動時間であるため、予測が立てやすく利用者が爆発的に増えた場合でも対応しやすい料金体系になっていることが理由です。*…Tableauで作成した、ビジュアライズされたグラフや表。また、管理側の目線ではクラウドサービスプロバイダーであるGCPのひとつの機能であるBigQueryよりも、データクラウドとしての機能に特化しているSnowflakeのほうがアクセスコントロールが優れている点もあり、管理と利用の両面でSnowflakeへの移行はメリットが大きいです。一部ではすでにSnowflakeの実験利用が始まっています。GAなどBigQueryに依存したデータがあるので、Snowflakeだけでデータ分析基盤を構築することはできないですし、クエリの細かな違い、データの移行やどう活用するかのステップなど多くの課題がありますが、一歩一歩移行を進めていく予定です。<h3 id="h11f5f4f8cc">データ分析基盤の堅牢性</h3>データ分析基盤の利用者が増えて、データ分析基盤自体の業務への依存度が高まっています。それに伴い、データの鮮度や状態といったデータ分析基盤の可用性や変更に対しての強さ、堅牢性の重要度が日々増しています。troccoはGUIからの設定が主であるため導入コストの低さが特徴です。しかし、分析できるデータが増えて規模が大きくなるにつれて、データマートを構築するためのクエリやそれらを取りまとめるワークフローは複雑になっており、管理が煩雑で属人化が激しくなってきています。これをきっかけに、より使われるようになったからこそ堅牢性を上げていきたいと考えています。しかし、堅牢性は構築スピードとトレードオフになってしまうため、バランスをどう取るかに頭を悩ませています。現状この問題に対してはdbtを導入することが良いのではないかと考えています。troccoにもdbt連携という機能があるため、どこでどう実行するか、Snowflakeへの移行も含め今後検討していく予定です。<h2 id="hcbec2bf0d9">終わりに</h2>アソビューにおけるデータ分析基盤のアーキテクチャと、その設計意図に関しての紹介でした。技術の更新が激しい界隈ですし、ここには書けていない課題も多くある状況です。お察しの通りアソビューのデータ分析基盤はまだまだ道半ば、なんなら走り始めた段階だと思っています。しかし、データ分析基盤の利用者は日々増えており、データドリブンな文化も浸透してきています。ここを走り切ってデータの利活用が進むことが大きく事業を成長させる重要な要素であることは間違いありません。これからも、より「使われる」データ分析基盤になるように改善を続けていきます。1年後には別の姿になっているかもしれません。その時はまたどこかで共有できればと思います。本記事が皆さまの一助になれば幸いです。編集：中薗昴提供：<a href="https://haulinc.jp/" target="_blank" rel="noopener noreferrer nofollow">株式会社Haul</a>

アソビューでデータ基盤チームに所属している霧生さんによる寄稿。アソビューのデータ分析基盤の構成と現状の課題、将来的な改善をどう考えているのかなどを解説します。

「アソビュー株式会社」の記事一覧