こんにちは。ROXXのプロダクト開発部でテックリードをしながら、AEC（Application Engineering Chapter）のChapter Leadを務めている夕暮おこはです。
この記事は、EPC編に続く「Chapter活動の実態」シリーズの2本目です。
前提として、ROXXはSpotifyモデルをベースにした組織になっており、プロダクトを開発する縦のチームをスクワッド（Squad）、職能や関心領域で横に束ねるコミュニティをチャプター（Chapter）と呼んでいます。Squadが自律して動くには、互いの責任の境界がはっきりしている必要があります。ROXXではそれを戦略的DDDとマイクロサービスで支えてきました（経緯は2024年の記事に書きました）。
EPC編では「横糸は勝手には張られない」と書かれていましたが、AECもそうして意図的に張られた横糸の一本です。2025年10月、Spotifyモデルの本運用を始めるにあたって、技術の標準を担うChapterが必要だと判断し、必要なChapterの一つとしてAECを定義しました。プロダクト開発部の全体MTGで、全メンバーに所属したいChapterを選んでもらっています。
この記事では、AIで各Squadの開発が速くなっていくなかで、AECが技術の知見をどうSquadの外へ流しているかを書きます。
1. AECとは何をするChapterなのか
ミッションは、アプリケーション開発におけるアーキテクチャとデータ連携の標準を確立し、すべてのサービスが一貫性と拡張性を保ったまま進化できる基盤を提供することです。扱う範囲は主に次のとおりです。
- サービス間連携プロトコル（API設計、イベントの規約、契約テスト）
- データモデリングとドメイン分割の指針
- Clean Architecture、DDD、CQRS+ESの適用指針
- 品質基準を実装に落とし込む方法
- それらの教育と浸透
メンバーは各Squadのエンジニアやテックリード、約10名です。開発組織の運用を担うEPCに対して、AECは現場でコードを書いている人たちが、技術の標準を担います。
他のChapterとの関係では、EPCとの線引きが一番大事です。事業コンテキストの戦略（どこにコンテキストの境界を引くか）はAECが作り、トライブリードが承認します。トライブリードはEPCに所属しているので、管理はEPCが担う関係です。チーム組成などの組織面もEPCが主導し、AECは技術面に特化しています。
Squadとの関係はシンプルで、標準はAECが作り、採用するかどうかは各Squadが決めます。 ROXXはもともと「全体で足並みをそろえることよりも、各々が全力で突っ走ることで前に進んでいく」文化です（2023年の記事）。その強みを壊さないための線引きです。
標準の拠り所として、『Clean Architecture』『実践ドメイン駆動設計』『マイクロサービスアーキテクチャ 第2版』の3冊を「正典（Chapter Canon）」と定めています。自分たちで再発明せず、正典に従うという方針です。
2. 運営の実態：知見が流れる経路
回し方はEPC編とほぼ同じで、月1回、1時間の定例でスプリントレビュー・レトロスペクティブ・プランニングを行っています。活動時間は各自がマネージャーと相談して決め、個人目標に組み込んでいます。立ち上げ当初は実質週1〜2時間でしたが、今はほとんどのメンバーが週4時間ほどです。
ここからは、AECならではの「知見の流れ方」を書きます。
AECメンバーは各Squadに散らばって所属していて、Squadから技術的な相談があれば、まずそのSquadにいるAECメンバーが応じます。知見を届けたい先は、このメンバーと、その周りのチームです。そこへ知見を流す経路は2つあります。
共通の言葉
2026年1月から7月にかけて、正典の3冊を題材に勉強会を26回開きました。
最初は担当者の負担を考えて、準備の軽い輪読にしました。ただ、読むだけではいまいちピンと来ない。そこで2回目から、担当者が予習してかみ砕いた説明資料を作る形に切り替えました。かみ砕き方の一つとして、ROXXでの実例も入れます。ただし準備に時間を使いすぎないよう、準備は3時間くらいまでというラインを決めました。第14回では、実際に自社のSquad間のコンテキストマップを描いています。
AI
もう一つの経路がAIです。AECの標準は、各SquadのAIが読める形で配っています。仕組みは3章で詳しく書きます。
この2つの経路で、AECメンバーのいるチームでは、メンバー以外のエンジニアも同じやり方で開発するようになっています。先日の社外の勉強会で「仕様は全部ドキュメントにまとめてAIに理解させている」と話していたのも、AECではないエンジニアでした。
3. 直近の取り組み：一つのSquadの実践を、Chapterの標準にする
AIで各Squadの開発は速くなりました。一方で、Squadごとにやり方がバラバラになり、Squad間のパフォーマンス格差が大きくなっていました。AIレビューのプロンプトも、Squadごとに作り直している状態でした。
もともと私のSquadでは、ドメインモデルをドキュメントの構造に落とし込み、AIに読ませる仕組みを作っていました（2026年1月の記事）。それをChapterの標準として各Squadに広げたのが、この1年の取り組みです。
標準をどう配っているか
標準は、全サービス共通のAPI契約とガイドラインを置く「契約リポジトリ」に集め、LLMが読める形で各リポジトリに配っています。テストガイドラインやコーディング規約もここにあります。共通の部分は契約リポジトリに、Squad固有の部分は各Squadのリポジトリに置きます。仕様はOpenSpecで書き、確定した仕様は共通リポジトリにアーカイブされるので、他のチームもそのサービスがどんな仕様を持っているかを知ることができます。
問題が起きたら、個人の工夫で済ませず、ガイドラインを更新して直します。失敗を個人の記憶ではなく、共有された標準に戻すという考え方です。
採用は任意なのに、なぜ標準が効くのか
横断組織の標準は、「作ったけれど読まれない」で終わりがちです。AECでも採用はSquadの任意ですが、実際には標準に沿った開発が広がっています。効いているのは、教育よりもハーネスの配布です。
気づけば、「リポジトリをクローンしてClaude Codeに頼めば、ガイドラインどおりにやってくれる」のが当たり前になっていました。一人ひとりに教え込むのではなく、ハーネスとガイドラインを配って、それに沿って進めてもらう。教育とは別のアプローチですが、これで属人化がかなり解消できました。
一番効いたと感じるのは、チーム外の人が、特に何の案内もない状態からPRを出してくるようになったことです。それでもガイドラインが色々チェックしてくれるので、受け入れるかどうかは、ビジネス的に要るか要らないかだけで判断できます。社内からも、FDEを進めているチームから「コンテキストマップのおかげで、ドメインから逸脱したコードを洗い出しやすかった」、上長から「各SquadのAECメンバーがバリューを発揮している」という声をもらっています。いずれも意見ベースで、定量的な計測は今まさに進めているところです。
4. 仮説を立てて、外れたら組み替える
AECの取り組みは、最初から正解が分かっていたわけではありません。仮説を立てて進め、外れたら組み替えてきました。ここでは2つ紹介します。
AIレビュー：プロンプトをそろえるから、ルールを前に出すへ
最初の仮説は「共通のレビュー用プロンプトを作れば、Squad間でレビューの質がそろう」でした。AEC立ち上げ当初にメンバーから出た提案です。ところが3月の定例で振り返ると、取り組みは動いておらず、共通のプロンプトがなくても誰も困っていませんでした。
そこで4月に、最適なプロンプトを決めるのではなく、プロンプトを育てる仕組み（共通とSquad固有の置き場所、更新のきっかけ）を標準にする方向に組み替えました。今の仮説はもう一歩進んでいて、「レビューは最後のゲートであって、早い段階からルールに従っているほうが開発効率は高い」です。9月に、push前に自動レビューを回すフックの提案があったときも、再発防止はレビューではなくガイドラインに戻す、と判断しました。
勉強会：負担を嫌がると思ったら、乗り気だった
「みんな仕事が忙しいので、予習して資料を作るほどの時間を割くのは負担が重すぎる」と考えて、輪読で始めました。でも輪読ではピンと来ない。負担が増えてもいけるかメンバーに聞いてみると、意外とみんな乗り気でした。今は担当者が資料を作り、準備は3時間くらいまでという形で続けています。
まだ解けていないこと
今も解けていないことが3つあります。
1つ目は、AIのアテンションが向かない問題です。モデルの更新で改善しつつありますが、致命的な指示違反もまだ起きます。自分の過去のセッションログを統計処理してみると、セッションが長くても短くても指示違反は起きていました。コンテキストの大きさに関係なく、ガイドラインにアテンションが向かないことがある。必読ドキュメントを読んだと宣言させることで軽減はできていそうですが、宣言したのにそこに書かれた指示を無視する例は後を絶ちません。
2つ目は、新しく入ったメンバーのキャッチアップです。AECには後から加わったメンバーもいますが、受け入れの仕組みが足りていませんでした。今は受け入れの流れを決めるところから取り組んでいます。
3つ目は、効果の定量的な計測です。今まさに進めているところですが、まだ答えは出ていません。
5. さいごに
Spotifyモデルでは、「Chapterで専門技術をどう高めていくか」が課題になりがちです。全員が本業のSquadを持ったうえでの兼務なので、専門性を深める時間を取り、それを全員にそろえるのは簡単ではありません。
ただ、コーディングエージェントが登場して、この課題はハーネスの共有で克服しやすくなったのではないかと考えています。少なくともテストガイドラインやコーディング規約のような定石が確立した領域は、ベストプラクティスに沿ったガイドラインを配れば、議論や技術検討に時間をかけずに済みます。AECがいまの稼働時間で開発生産性に直結する成果を出せているのは、こうした定石の部分に時間をかけずに済んでいるからです。
AECの取り組みは、AI時代の新しい組織論として少しずつ形になってきましたが、4章で書いたように、まだまだ「解けていない課題」も山積みです。ROXXの開発組織は、決して完成された美しい組織ではありません。仮説を立て、時に外し、泥臭く軌道修正しながら前に進んでいます。だからこそ、こうした組織課題に対して「それ、面白そうじゃん」と一緒に飛び込んでくれる仲間を強く求めています。現在ROXXでは、Squadを横断して組織の成長を牽引する「横断EM（エンジニアリングマネージャー）」を募集中です。（役割の背景と選考で何を見ているかは、横断EMの記事をご覧ください。）「うちでも似た課題がある」「AIを使った開発標準化について議論したい」など、きっかけは何でも大歓迎です。まずは選考ではなく、カジュアルにお話ししてみませんか？
エントリーはこちらから👇
ROXXってどんな会社？気になった方はこちらから👇
