ROXXに入社して「Spotifyモデル」に出会ったら、開発スピードの次元が違った話〜AI駆動型開発チームの挑戦〜

こんにちは、ROXXでEM（エンジニアリングマネージャー）を務めている窪内です。

私はこれまで、キャリアの多くの期間を「スクラム」によるプロダクト開発に費やしてきました。前職でも、スクラムマスターと共にベロシティの安定化やプロセス改善に取り組み、組織のアウトカム最大化に注力してきました。「型」を適切に回し、継続的に改善することこそが、開発組織の最適解だと考えていました。

しかし昨年ROXXに入社し、その考え方は良い意味で裏切られることになりました。 ROXXが採用している「Spotifyモデル」由来の組織構造と、そこで徹底されている「スピードへの執着」。そして現在取り組んでいる「AI駆動開発」。

本記事では、スクラムに慣れ親しんだ私が直面したギャップと、AIを前提とした開発チームの現在地について、少し解像度を上げてお話しできればと思います。

1. はじめに：スクラムが主流だった私が見た「ROXXの景色」

ROXXに入社して最初に感じたのは、意思決定から実行までのリードタイムの短さです。

一般的なスクラム開発では、スプリントプランニングやレビューといったセレモニーを通じて、チームのリズムを作ります。しかし、ROXXの組織構造は全員がBiz視点を持つために「Spotifyモデル」をベースにしており、各チームは「スクワッド（Squad）」と呼ばれる自律的な単位で活動しています。

ここで私が感じた最大の違いは、「プロセスの遵守」よりも「ミッションへのコミットメント」が強烈に優先されている点です。

各スクワッドには「解決すべき課題（ミッション）」が設定されています。そこにはBizとDevの境界線がほとんど存在しません。「次のスプリントで検討しましょう」という会話は少なく、「今この瞬間、顧客に価値を届けるために何が最短か？」という議論が、職能を跨いで常に行われています。

AI技術が日々進化する現在において、この機動力こそが最大の武器であると、改めて実感させられる日々です。

引用元: Spotify Scaling Agile Model

2. ROXXの「スクワッド」：BizとDevが協働する開発スタイル

「Spotifyモデル」という言葉は有名ですが、ROXXにおける運用の実態は、私が知るスクラムとは明確な差分がありました。

決定的な「差分」はプロセスの自由度

スクラムのアプローチ： フレームワーク（型）があり、それに沿ってイベントを実施し、透明性と検査・適応を担保する。
ROXXのスクワッド： プロセスに関する全社的な規定は極めて薄い。チームビルディング、会議体、開発フローに至るまで、「ミッション達成に最適なら何でも良い」としてチームに一任されている。

エンジニアがBizの現場に溶け込む

私が所属するスクワッドでは、BizとDevが定例ミーティングで顔を合わせるだけでなく、実務レベルで深く連携しています。

現在、私たちは「AIロープレによる社内キャリアアドバイザー（CA）の業務効率化」というプロジェクトを進めています。ここでは、エンジニアが仕様書を待つことはありません。実際にCA（キャリアアドバイザー）の業務フローに入り込み、現場のオペレーションを観察し、その場でヒアリングを行います。

「ここが使いにくい」「こういうAIの返しだと業務に合わない」といった生の声をエンジニアが直接拾い上げ、その日のうちに修正し、翌日には現場で試してもらう。この超短サイクルのフィードバックループは、BizとDevが分離している組織では決して真似できないスピード感です。

3. 社内CA業務効率化に向けた「AI駆動開発」へのシフト

現在、私たちのチームではAI駆動開発へのシフトを強力に推進しています。これは単にコーディング補助ツールを使うという意味ではなく、ワークフローそのものをAI前提に書き換える試みです。

「偶有的複雑性」をAIで排除する

ソフトウェア開発には、本質的な課題解決（本質的複雑性）と、それを実現するための付随作業（偶有的複雑性）が存在します。私たちの戦略はシンプルです。

人間： 「ユーザーにとっての理想の体験は何か？」「解決すべき真の課題は何か？」という本質的複雑性に向き合う。
AIエージェント： 単純なコード生成、テストケースの列挙、議事録の構造化など、偶有的複雑性を徹底的に処理させる。

朝会での「デイリーゴール」設定

毎朝のスタンドアップでは、タスクの進捗確認以上に「今日達成すべき最重要項目」の合意に時間を割きます。「今日、確実にユーザーに届ける価値は何か？」を定義し、それ以外をいかにAIにオフロードするかを考えます。

EMである私自身のAI活用（"AI部下"との並列稼働）

私自身、EMとしてマネジメント業務を行いながら、社内向けツールの運用・保守も担当しています。常に依頼が絶えず、カレンダーはMTGで埋まる日々。普通にやれば時間がいくらあっても足りません。そこで私は、自分自身の業務フロー自体をAIエージェントで「非同期処理」化しています。

具体的には、1on1や定例MTGを行っている「裏」で、AIエージェントを走らせています。

ドキュメント作成（要約・整形）： 散らばったメモを渡して要約し、即座に状況把握できるように。
タスク分解： 抽象度の高い依頼が来たら、「これを開発チケット化するためのタスク分解案を作って」とプロンプトを投げておく。
技術的な壁打ちの並列化： 実装方針に迷うポイントを投げておき、複数のアプローチ案を出力させておく。
実装のドラフト依頼：実装方針が明確になったものは実装をどんどん依頼。MTG後にまとめてレビュー。

MTGが終わってPCに戻ると、AIという「優秀な部下」がドラフトを用意して待っている状態です。私はレビューと意思決定に集中し、すぐに次のMTGへ向かうことができます。これにより、MTGが多くても業務がスタックすることが減りました。今ではAIなしの業務には戻れません。

4. AI駆動開発の「光と影」：直面している新たな壁

コードレビューがボトルネックになる

AIによって実装（コーディング）のスピードは飛躍的に上がりましたが、それを人間が確認する「レビュー」のスピードは変わりません。結果として、作成されたPull Request（PR）の消化が追いつかず、レビュー待ちでスタックしてしまう現象が起き始めています。生産性が上がったがゆえの贅沢な悩みではありますが、チーム全体のフロー効率をどう維持するかは課題です。直近ではPR上がったら即座に検知しレビューできるようSlack上でのメンションを自動化しつつ試行錯誤して進めています。

並列稼働による「コンテキストスイッチ」の疲弊

先ほど、AIエージェントによる「並列稼働」について触れましたが、これは人間の脳にも相応の負荷をかけます。会議中に裏でAIを走らせ、戻ってきたらアウトプットを即座に判断し、また別のタスクへ……という動きは、頻繁な頭の切り替え（コンテキストスイッチ）を要求します。夕方には脳のメモリを使い果たしたような感覚に陥ることもあり、「AIを使いこなすための体力・集中力」のマネジメントも必要だと痛感しています。

「オーケストレーター」としての観点の醸成

現在、AIの活用度合いはまだメンバーによってバラつきがあり、チームとして標準化されているとは言えません。 AIからの回答精度はこちらの「問い（プロンプト）」の質に依存します。そのため、今後は単にツールを使うだけでなく、AIというリソースを指揮する「オーケストレーター」としての観点を養う必要があります。そのためには、メンバー一人ひとりが担当領域に対してより強いオーナーシップを持ち、「何を解決すべきか」を明確に定義する力が、これまで以上に求められるフェーズに来ています。