1. はじめに
この記事はアソビュー！ Advent Calendar 2025 の25日目です🎅🎄！
アソビューCTOの兼平(disc99)🐼です！
今年も多くのメンバーが記事を執筆してくれました。
それぞれの現場で起きているチャレンジや工夫が詰まった記事を、ぜひご覧いただければと思います！
この記事では、CTOという立場からプロダクト組織全体の2025年を振り返ります。
個別の技術トピックだけではなく、組織としてどのような意思決定を行い、何を目指してきたのかをお伝えします。
2025年のテーマを一言で表すなら「アウトカム志向への転換と基盤投資」です。
私たちは現在、20以上のサービス、1,800万人以上の会員、10,000以上の契約施設を抱える規模に成長しています。
また5年後には利用者数1億人という目標を掲げています。
この成長を支えるために、2025年は様々な改革を実施しました。
2. 組織構造の進化
2-1. ストリームアラインドチーム比率の見直し
私たちはTeam Topologiesの考え方を組織設計に取り入れています。
元々は、プロダクト開発組織の約90%がストリームアラインドチームで構成されていました。
2025年、この比率の75%へのシフトを進めています。
事業を成長させるための開発は、理想的なシステム構成や適切な運用状態と同時に進められるとは限りません。
顧客に価値を届け、事業をグロースさせるためには、一時的な対応を選択することもあります。
アソビューは事業開始から12年以上プロダクトを開発し続けており、プロダクト組織も100名規模に成長しました。
このフェーズでは、単純に目の前の課題を解決するだけでは長期的な成長に寄与するとは限りません。
基盤への投資を意図的に行うタイミングだと判断しました。
「Headcount benchmarks for DevProd teams」によると、現在のアソビューの組織規模において、統計的に開発生産性(非事業施策人員の一部)に20%程度を割くのが一般的です。
これはDevProdチームのみの数値であり、プラットフォーム、イネーブリング、コンプリケイテッド・サブシステムチームを含めると、今後事業を持続的に成長させて行くうえで、この比率を変化させることが重要だと判断しました。
getdx.com
2-2. プロダクトマネジメントの強化
エンジニアリング組織だけでなく、プロダクトマネジメント機能の強化も進めています。
2024年、私たちはプロダクトマネジメント体制の抜本的な見直しに着手しました。
その背景には、単一プロダクトからマルチプロダクトへの戦略転換があります。
アソビューはこれまで、主力サービスを中心とした事業運営を行ってきましたが、市場環境の変化と顧客ニーズの多様化に伴い、複数のプロダクトを有機的に連携させる「コンパウンド戦略」への移行が不可欠となりました。
SaaS業界全体でもこの潮流は加速しており、単なる機能追加ではなく、プロダクト群全体でより大きな顧客価値を創出するアプローチが求められています。
この体制見直しで重視したのは「アウトプットからアウトカムへ」の意識転換です。
機能をリリースすることがゴールではなく、それによって顧客満足度が向上したか、売上が伸びたかという成果を問う姿勢への切り替えです。
従来はプロジェクト推進に労力が偏り、「何を作れば最も価値を生むか」を探索する活動が不足していました。
2025年は、プロダクトマネージャーの役割としてディスカバリー（仮説検証・効果測定）やロードマップ策定を明確に位置づけたことで、開発前にポテンシャルを具体化し、リリース後は振り返りを徹底する体制が整いました。
この変化により「作ったものがどれだけ顧客に価値貢献できたか」という付加価値生産性を追求し、アウトカムにこだわる開発へとシフトしています。
詳細はCPO横峯のnoteでも触れていますので、ご覧ください。
note.com
2-3. エンジニアマネジメント体制の確立
2024年まで、CTOやCPOを除くエンジニアのマネジメント体制は曖昧な状態でした。
会社上の役割としてマネージャーが存在し、プロダクトマネージャーと部長を兼務するケースもありましたが、役割定義が明確でなく人数も4名に留まっていました。
2025年は、プロダクト組織に適したマネジメント体制と役割の見直しを行いました。
マネージャー2名からEM（エンジニアリングマネージャー）5名へ、プロダクトマネージャーは3名から7名へと拡充しています。
EMはエンジニアの成長支援やチームのパフォーマンス向上に注力し、プロダクトマネージャーは前述のディスカバリーやロードマップ策定に集中できる体制となりました。
役割の明確化により、それぞれが本来注力すべき領域に時間を割けるようになっています。
2-4. SET（Software Engineer in Test）の配置
品質への投資として、SET（Software Engineer in Test）の役割を担う人材を組織横断で配置しました。
事業拡大に伴い開発スピードを重視した結果、技術的負債と本番バグが増加していました。
テスト自動化の仕組みや品質保証プロセスが不十分で、QAが後工程中心となりコストが高い状態でした。
また、単体テストで検知できる不具合も本番で発覚するケースも存在していました。
私たちが定義するSETは、テスト自動化のみに限定されず、プロダクト品質全体に向き合うエンジニアです。
開発チームが品質とスピードを両立できる状態の実現、テスト・品質保証のシフトレフトを目指しています。
品質を「後工程で担保する」から「開発プロセス全体で作り込む」へシフトしています。
具体的な成果として、手動で数時間かかっていたリグレッションテストをPlaywright導入により数分で完了できるようになりました。
また、開発チームメンバーとも細かくコミュニケーションを取り、テストコード実装をPR単位でモニタリングし、SonarQubeでカバレッジを可視化することで、テスト実装率を40%以下から80%に改善しました。
今後はAI活用による機械的チェックの導入や、テスト自動化の文化定着を進めていきます。
詳細はテックブログでも紹介しています。
tech.asoview.co.jp
3. AIへの全面投資
このテーマは現在各社積極的に取り組んでいる領域だと思います。
私自身もAIを使い業務やツール開発など毎日時間を忘れて触り続けています。
3-1. AIイネーブリングチームの立ち上げ
2025年4月、CTO直下でAIイネーブリングチームを立ち上げました。
組織には3つの課題がありました。
- 個人採用のサイロ化: 開発者が個々にAIを採用した結果、チーム間で知識格差が発生
- プロダクション品質のギャップ: AIは驚異的なスピードでコードを生成するが、本番品質に達するには課題が残る（いわゆる「70%問題」）
- 意思決定の遅れ: AIツール導入の判断が遅れ、競争機会を逃すリスク
これらを解決するには、組織横断で推進する専任チームが必要でした。
AIチームは、急速に進化するAI技術の組織適合性を評価し、最適なツールの導入を推進しています。
社内ガイドラインやプラクティスを整備してナレッジを蓄積するとともに、トレーニングやワークショップ、ピアラーニングを通じて支援しています。
また、イネーブルメントにとどまらず、AIを活用したプロダクト企画から技術実装も担当し、部門横断の連携を担う接続点として全社的なAI活用を後押ししています。
詳細はテックブログでも紹介しています。
tech.asoview.co.jp
3-2. AI FIRST宣言
今期プロダクト組織のテーマを「AI FIRST」としています。 このテーマは、あらゆる業務において「まずAIで何ができるか」を考えることを習慣にする思考と行動の規範としています。
私たちは日々の業務の中で、AI活用の重要性を認識しながらも、実際には以下のような状況に直面していました。
- 目の前の業務に追われ、慣れたやり方で作業してしまう
- AI活用を「試す時間」が取れず、結局従来の手法に戻ってしまう
- 新しいAIツールが次々登場するが、試行錯誤する優先度が下がってしまう
- AIツールを使っていても自分の使い方が正しいか自信がない
生成AIの進化により、ソフトウェア開発のスタイルは大きく変化しています。
これらに適応するためには、意識的にAIを活用する文化が必要不可欠です。
逆にこの変化に適応できなければ、個人としても組織としても競争力を失いかねません。
感覚的には必要性は理解できていますが、改めて「AI FIRST」を掲げることで、組織全体での明確な意識統一と行動変革を促進しています。
4. 開発プロセス・品質の強化
4-1. アジャイル・スクラムの全社推進
全チームでスクラム・アジャイルの推進を目標に掲げました。
2024年、私たちはFour Keys（デプロイ頻度、変更リードタイム、変更失敗率、サービス復旧時間）の測定に取り組みました。
これはGoogle CloudのDORAチームが提唱する開発パフォーマンス指標であり、開発チームの健全性を測る上で有効な指標です。
しかし、振り返ってみると、私たちの生産性への取り組みは「レベル1」に偏りすぎていたことに気づきました。
広木大地氏の「開発生産性について議論する前に知っておきたいこと」では、生産性を3つの階層で捉えています。
- レベル1：仕事量の生産性 - タスク完了数やコード行数など、どれだけの作業をこなせたか
- レベル2：期待付加価値の生産性 - 個々の施策がプロダクトにとってどの程度価値があるか
- レベル3：実現付加価値の生産性 - 売上やKPIなど、実際のサービス貢献
Four Keysはレベル1の「開発環境の成熟度」を示す指標であり、レベル2・3との統計的相関は必ずしも強くありません。
デプロイ頻度が高くても、リリースした機能がビジネス成果に結びつかなければ、本当の意味での生産性向上とは言えません。
2025年は、レベル3の「実現付加価値」に向き合う年としました。
アジャイル・スクラムの本質は「短いサイクルでのフィードバックループ」です。
小さな単位でリリースして実際のユーザー反応を観測し、仮説検証を高速に回すことで価値のある施策に集中できます。
価値を生まない作業を早期に発見し方向修正することで、「たくさん作ったが成果が出ない」状態から「少なく作って大きな成果を出す」状態へシフトできます。
この推進を支えるため、組織開発・学習文化・コーチングを担当するアジャイルコーチを配置し、チームを「内側から強くする」取り組みを進めています。
テックブログでも現場での実践知が発信されています。
私たちが追求するのは単なる効率化ではなく、変化への適応力、チームの自律性、持続可能な開発ペース、そして何より事業成果への貢献とその先にある顧客への価値提供を目指しています。
4-2. SLO目標の強化
以前のSLO運用には改善の余地がありました。
機能の構成単位別にSLO目標値を設定していましたが、ユーザー体験との関連性が見えにくく、「何を守るべきか」という優先順位付けが難しい状態でした。
システム視点の監視からユーザー視点の監視へ進化させる必要がありました。
2025年、CUJ（Critical User Journey：クリティカルユーザージャーニー）ベースでSLOを見直しました。
CUJとは重要度と頻度が高いユーザージャーニーのことで、ユーザーが目標を達成できない場合は深刻な本番不具合となります。
Google SREのベストプラクティスでも「プロダクト、開発、SREチームを集めて、クリティカルユーザージャーニーについての共通理解を得ることが重要な最初のステップ」とされています。
cloud.google.com
具体的には、プロダクトマネージャーと協力して主要なCUJを特定し、CUJ単位でのSLO設定とアラート整理を行いました。
重要度の低いノイズアラートを削減し、エラーバジェット枯渇ゼロを目標に運用しています。
私たちも「機能監視から体験（アウトカム）監視へ」のシフトを進めています。
5. 技術基盤の刷新
5-1. データ基盤の進化
2025年、データ基盤の大きな転換点を迎えました。
Google Cloud主催 Data & AI Summit '25 Fallにて、私たちのデータ基盤戦略について発表する機会もいただきました。
cloudonair.withgoogle.com
従来、BigQueryとSnowflakeの2つのDWH（データウェアハウス）を運用していましたが、システム構成の複雑化、データサイロの発生、二重管理による運用コスト増加が課題となっていました。
シングルソース、マルチワークロード、データコラボレーション、セーフティ、アジリティなど多数の観点で検証を実施した結果、BigQueryへの一本化を決定しました。
tech.asoview.co.jp
データ基盤のアーキテクチャ選定では、事業価値のあるデータを、できる限り低コストで運用・利用できる状態で、素早く提供することを重視しています。
データを移動させること自体にコストが発生し、データは見られて初めて価値が出るためです。
これからの時代は、ここに加えてAI活用が肝になると考えています。
Google Cloudのデータエコシステムを選択した理由として、BigQuery Editionsの採用により比較検討したDWHとの価格差が許容範囲に収まったこと、ワークロードの分離やオンデマンドとの併用で運用に柔軟性が生まれたことが挙げられます。
また、BigQueryにデータが存在することで、Vertex AI、Gemini Enterprise、Conversational Analytics Agentなど、Google Cloudのエコシステム利用が容易になります。
BigQueryだけでなくLookerとLookMLの存在が大きなポイントでした。
LookMLはビジネス指標やデータの関係性を定義できるセマンティックレイヤーとして機能し、BI活用だけでなく生成AIにデータの意味を与えることで、データを一気に「AI Ready」な状態に変えます。
BIツールもTableauに加えてLookerを新たに導入し、Google Cloudのデータエコシステム全体での最適化を進めています。
目指す姿として、データドリブンな意思決定を組織文化として根付かせ、パートナーのトランザクション推移やゲストのLTV状況などを自然言語で誰でも出せる状態を実現します。
また、Lookerを通じて事業者さんへ直接データ価値を届けることで、アソビューは遊びのプラットフォームとしてだけではなく、遊びの「データ」プラットフォームとしても成長していきます。
5-2. インフラ・アーキテクチャの改善
2025年、技術基盤の改善に幅広く取り組みました。詳細はSREチームの2025年の取り組みをご覧ください。 tech.asoview.co.jp
コンテナ基盤の最適化
EKS on Fargateを廃止し、オンデマンドノードへ移行しました。FargateではDaemonSetが利用できない制約があったためです。
移行にあたっては「ノード：ポッド＝1：1」の設定を採用し、ノイジーネイバー問題を回避しながら高可用性を維持しています。
また、サービスメッシュにはIstio Ambient Meshモードを導入しました。
従来のSidecarモードと異なり、L4レイヤーのProxy（Ztunnel）とL7のProxy（Waypoint）を組み合わせたアーキテクチャを採用しています。
これによりSidecarのオーバーヘッドを削減し、より効率的なリソース利用を実現しています。
アプリケーションの効率化
モジュラーモノリスアーキテクチャにおけるマイクロサービス化も実現しました。
モジュラモノリスのメリットでもあり、デメリットでもあるのが全てのモジュールが1つのデプロイメントに集約されることです。
複数のモジュールが同一のランタイムで動作する構成上、負荷分散や可用性分離が難しくなります。
アソビューではこのデメリットに対し、アプリケーションを環境変数で読み込みモジュールを制限する仕組みを導入し、必要なモジュールのみで起動を可能にするマイクロサービスモードを導入しました。
モノリス内部の論理的な境界を活用し、必要なモジュールのみを読み込むことで、デプロイメント単位ごとのリソース効率を高めています。
また、リソースを最適化することでJVM NonHeap領域を約100MB削減することに成功しました。
インフラコード管理とデプロイの進化
KustomizeからHelmfileへの移行により、開発環境のマニフェスト定義を80%削減しました。
また、Serverless FrameworkからLambrollへの移行を進め、責務の明確な分離を実現しています。
さらに、Progressive Deliveryの実装にも着手しています。IstioとArgo Rolloutsを組み合わせることで、自動化されたカナリアリリースの構築を進めています。
Datadogによるモニタリングと連携し、早期の障害検出と自動ロールバック機能を実現することで、リリースの安全性と速度の両立を目指しています。
5-3. 技術的負債への投資
プロダクトは成長し続ける一方で、単純な拡張を繰り返せば技術的負債が蓄積していくのは避けられません。 2025年は、技術的負債の返済に対しても明確な投資判断を行いました。
ストリームアラインドチームが90%を占めていたという時点でお気づきの方もいると思いますが、アソビューではこれまでこういった領域に十分な投資ができていませんでした。
2025年は今まで手をつけられていなかった大きな負債に対しても投資を開始しています。
現在進行中の部分なので今回は具体的な内容は割愛しますが、機会があればまた公開させてもらえればと思います。
いずれにしても持続的な事業成長を続ける上で、CTOとして今後もこの領域への計画を進めていく予定です。
6. 振り返りと2026年への展望
まだ道半ばのものもありますが2025年を振り返ると、アウトカム志向への転換と基盤投資という大きな意思決定を実行に移せた年でした。
達成できたこと
- ストリームアラインドチーム比率の見直し（75%へシフト）
- プロダクトマネジメント・EM体制の強化
- SET配置と品質プロセスのシフトレフト
- AIイネーブリングチームの立ち上げとAI FIRST宣言
- アジャイル・スクラムの全社推進とCUJベースSLO
- データ基盤のBigQuery一本化とインフラ改善
- 技術的負債への計画的な投資
2026年に向けて
2026年も様々な領域でプロダクト組織を進化させていく予定です。
やりたいことは沢山ありますが、テーマとしては以下のような内容を考えています。
- アウトカムを起点とした開発文化の定着
- AIを「意識して行う」から「無意識に行う」へ
- プラットフォーム基盤の拡充による開発効率化の加速
- データドリブンな意思決定の組織への浸透
- 持続可能な開発基盤への投資継続
- セキュリティ体制の継続的強化
最後に
大きく変化し続けた2025年でしたが、ここまでの内容は、到底私一人では実現できるものではありません。
日頃多くの議論を繰り返し、一緒に協力してくれた仲間、日々プロダクトと向き合い、挑戦を続けてくれているメンバー全員の力によるものです。
この場を借りて深く感謝を伝えたいと思います！
私たちはまだ道半ばです。しかし、「生きるに、遊びを。」というミッションの実現に向けて、テクノロジーの力で挑戦を続けていきます。
この記事をご覧いただきありがとうございました！来年もよろしくお願いします！
