モノリシックな開発組織のリアーキテクチャ

＼スニダンを開発しているSODA inc.の Advent Calendar 2025 10日目の記事です!!!／

SODAでリードEMをしているmiyukiです。

今日は開発組織の話をしようと思います。
コードベースのリアーキテクチャの話はよく聞きますが、開発組織のリアーキテクチャはあまり聞くことがないと思うので、弊社において移行中の事例や設計について紹介していこうと思います。

背景と課題

組織のリアーキテクチャについて話す前に、開発組織の背景や課題について説明します。

1. AIエージェントの台頭

今年は「AIエージェント元年」としてAIによる開発に目覚ましい発展がありました。すると、どこの組織もAIを開発リソースの内数にして、少人数チームでスケールさせたいというような野望が芽生えます。

弊社も例に漏れず、CursorやClaude CodeのようなAIエージェントを利用できるツールを最大限に採用しています。

組織としては、これらAIエージェントの価値を最大化できるような組織編成を検討する必要があります。

2. コードベースのモジュラーモノリス化

弊社では昨年頃からバックエンドのコードベースで、モノリスからモジュラーモノリスへの移行が進んでいます。

コードベースをリアーキテクチャするのはよいのですが、運用面で課題も見えてきました。
具体的には、移行したモジュールの担当チームが解散し保守できる人の負荷が増大したり、そもそも移行メンバをジョブ型のチームとして公募したりして同様に運用負荷が増大したりしていました。

3. 新COOによるプロダクトロードマップ拡充に伴う採用拡大

昨年12月に入社したCPO(現COO)によって、プロダクトロードマップが大幅に整理され、開発内容も拡充されました。

すると、これまでの開発チームではリソースが足りず、採用を拡大したいという風になります。

ただ、採用はただ人を採るだけでいいわけではありません。当然、採った人の配置、オンボーディング、成長を考え、またチームを分割する上でのパワーバランスのようなものもしっかり検討しておく必要があります。

少数チーム化に向けた実験

次に、今回のリアーキテクチャに踏み切る前に行ったPoCについて触れさせてもらいます。

前項「1. AIエージェントの台頭」を解決するために、2チームを少数チームに分割し3チームにして運用するPoCを実施しました。
具体的には、SWEが4人ずついた2チームをSWE2人、3人、3人の3チームに分割しました。

しかし、結果的にはあまり上手くいきませんでした。
というのも、AIエージェントによって一人当たりの開発生産性は上がりますが、チームとしての安定性は当然少数化した分下がるのです。
プロジェクトがリリースターゲットに近づいてきた時にチームの負荷が以前より高まったり、チーム内でも生産性の高いメンバと低いメンバの負担がより顕著になったりと、チームが安定的に運営される上での課題が発生し、5ヶ月運用した上で最終的には元のチーム構成に戻しました。

最近では、少数精鋭のスタートアップやワンマンでのプロダクト開発事例が増えてきていますが、小規模でビジョナリーな組織では少数のスーパープレイヤーのハードワークによって大きな成果を獲得できそうですが、開発組織が50人以上いる中規模以上の組織でいきなり少数精鋭化するにはそれなりに課題がありそうです。
少なくともマルチプロダクト戦略や子会社化なりで、組織の構造から変えていかないとただ少数化するだけではうまくいかないケースも多いと思います。

設計

それでは、これまでの背景や実験を踏まえて、今回採用する新しいチームトポロジーとチームの設計について話します。

トポロジー設計

こちらが今回採用するトポロジーを図示したものになります。

大枠はSpotify Modelのようなマトクリス型の設計を採用しつつ、独自にアレンジを加えております。

詳細について解説していきます。

• Chapter: 本図の横軸であり、技術領域を表します。ChapterにはChapter Lead(緑色の丸)が存在し、Chapter Leadは領域の技術選定や技術的負債返済などの意思決定をリードします
• Squad Team: 本図の縦軸であり、スクラムチームを表します。スクラムチームにはTeam Lead(濃いピンク色の丸)が存在し、機能開発における設計や非機能要件の担保をリードします
• Guild: 薄紫色の背景の部分であり、任意参加のコミュニティを表します
• Module: 本図下方のDBの図の部分であり、チームがメンテナンスするモジュールおよびコード領域を表します

では、このトポロジーで上記課題にどのようにアプローチするのかを話します。

AIエージェントの台頭によって個々人の開発生産性が上がります。個々人の開発生産性が上がれば、チームが少数化されていくだけでなく他技術領域への越境が盛んになります。
ただ、単純に他技術領域のエンジニアが越境してくるとコードベースの内部品質が下がります。そのために越境する前に越境される側の受け入れ体制を万全にしたり、越境を許可した上で継続的な治安維持が必要不可欠です。

その役割を担うのがGuildとChapter Leadです。
Guildは、越境される側として受け入れ体制を万全に整備します。実際の活動についてはこちらの記事をご参考いただければと思います。
Chapter Leadは、越境されていくコードベースの品質を担保するためにコーディングルールやCIを整備したり、負債化してきたら負債解消の判断と実行を行います。

また、チームにモジュラーモノリス化されたモジュールの所有権を持たせます。
チームにモジュールを所有してもらうことによって、他チームの当該モジュール開発時にレビュアーになってもらうことで内部品質を担保したり、プロジェクトのアサインもより所有モジュールに近い機能がアサインされることが増え、チームのナレッジもより連続的なものになります。

コラム: Spotify modelは失敗した？

Spotify Modelをご存じの方は同様にそれが失敗し実際には使われていなかったことをご存じかと思います。

この記事で分析されている失敗理由は主に以下の4つです。

1. Matrix management solved the wrong problem: マトリクスマネージメントの責任の欠如
2. Spotify fixated on team autonomy: チーム間インタラクションの欠如、独自カルチャー形成によるサイロ化
3. Collaboration was an assumed competency: アジャイル知識・経験不足
4. Mythology is difficult to change: 過度の神格化による変更に対する恐れ

本設計ではこの失敗に対して以下のように考えています。

1については、Spotify ModelはTeam LeadやEngineering Managerが存在せずChapter Leadがその役割を持っていました。結果、チームのデリバリーにエンジニアとして責任を持つ人がいないという事態を招きました。
なので、本設計ではデリバリーに責任を持つロールとしてTeam Leadを、メンバーのピープルマネジメントを支援できるロールとしてEngineering Managerを設置しています。

2については、チームの自律性を重んじすぎた結果過度にサイロ化してしまったそうですが、本設計ではチームの開発手法やツールなどはあくまで組織として共通のものを使ってもらうようにしています。

3については、チーム間のインタラクションやコラボレーションの課題ですが、これは弊社でも課題のままです。チームをモジュラーモノリスのように分割していくと大きな開発ではチームがコラボレーションしないといけないケースが少なからずあります。そういった場合にはやはりアジャイルコーチがよくコラボレーションできるように介入する必要があるのですが、現状そういったロールは弊社には不在の状況です。

4については、神話化されてしまったのでその内容を容易に変更することができないという話ですが、もちろん弊社には当てはまりません。
Spotify Modelはユニコーン企業のひみつで取り上げられたことで広く認知されましたが、この記事が幸運にもランキング入りし多くの方の目に留まったとしても、神格化されることはないでしょう（まあ、神格化されればありがたいかもしれませんが）。

チーム設計

次にチームの設計になります。ここでいうチームは上記のトポロジーでいうところのSquadになります。

チームはSWE(Software Engineer), QA(Quality Engineer), EM(Engineering Manager), PdM(Product Manager)で構成されます。

上記課題「3. 新COOによるプロダクトロードマップ拡充に伴う採用拡大」を解決するために、チームにはチームサイズを設けます。チームサイズはSWEの人数を表し、3人〜5人におさまるように規定し、2人以下や6人以上になると結合や分離を進めるようにします。

あとチームには上記トポロジーのTeam Leadに該当する人を一人擁立します。チーム内にリードエンジニアのようなロールを設置することで、開発の品質を安定的に高めてもらっています。

かつてはチーム内ロールとして、Scrum Masterも設置していたのですが、AIエージェントの台頭によって従来型のスクラム開発の限界を感じるチームやプロジェクトもあったので撤廃することにしました。

参考ですが、フロントエンドリプレイスプロジェクトでは原理的なスクラムではなくAI駆動のウォーターフォール開発で劇的に開発速度を早めました。詳細について興味ある方は、こちらからお読みいただけます。

移行計画と現状

実際の移行は以下のような手順で進めていきます。

• 周知と共有
• ロール設定
• ギルドの設立
• 越境実績の可視化
• リチーミング

周知と共有について、まずEM全員でこの案について議論し、ある程度内容が固まった段階で全体に周知しました。
全体への周知は弊社の場合、プロダクト部門内で全員参加のProduct All Handsというものを毎月開催しているので、そこで実施しました。

ロール設定について、元々Chapter Leadの動きをしてくれていたメンバーに改めてロールとして付与しました。また、新たに生まれたロールでもあるので、そのロールに就きたい人を公募もしています。

ギルドの設立について、元々存在していたギルドを基礎としてギルドを体系化しました。弊社の場合、Flutter Guildが一番古参かつ勢力があって、ギルドメンバーは50人規模の開発組織で20人弱にのぼります。

越境実績の可視化について、これはまだできていないのですが、技術領域ごとにリポジトリが分かれているのでそこでの開発実績を可視化する予定です。この実績をもとに今後のチーム編成の目安にできればと思っています。

リチーミングについて、採用が進めばリチーミングする必要性が出てきます。その際はダイナミックリチーミングを参考に、基本ワンバイワンパターンとグロウアンドスプリットパターンで分割と結合を実施する予定です。

さいごに

AIの勃興によって、これから更に開発手法・開発組織の領域でもパラダイムシフトが起こるだろうと思います。
そのような時代の転換点では様々なアーキテクチャが提唱され、試されるのでしょう。

正解のない時代に正解を作っていくことがEMのやりがいのように感じます。とりわけコーディングより組織開発の方が抽象的で最適解を探索しづらいですが、開発組織を動かす人にとって何かしら考えるきっかけになれば幸いです。