AIで個人が速くなるほど、組織は静かにバラバラになっていく——この半年でそれを目の当たりにして、私は「1つのチームのEM」をやめました。
こんにちは、ROXXでEM（エンジニアリングマネージャー）を務めている窪内です。
以前、ROXXに入社して「Spotifyモデル」に出会い、開発スピードの次元が違ったという話を書きました。
ありがたいことに多くの方に読んでいただいたのですが、あの記事を書いてから、私自身の役割が大きく変わりました。「1つのスクワッドのEM」をやめて、開発組織全体を横断する"横断EM" という役割を、いま設計しながら進めています。
先日、CTOの松本がROXXのFDE（フォワードデプロイ）事業についての記事を公開しました。
あちらは「火は、家の竈で熾す」という"事業"の話でした。本記事はその竈の中 —— つまり、火を熾している開発組織そのものの話です。なぜ1チームのEMをやめたのか、スピードに全振りした組織の「その後」に何が起きたのか、少し解像度を上げてお話しできればと思います。
1. スピードの代償 — AI駆動開発は、サイロ化を加速させる
前回書いたとおり、ROXXのスクワッドは「ミッション達成に最適なら何でも良い」という自由度の高さで、意思決定から実行までのリードタイムが圧倒的に短い組織です。この強みは今も変わっていません。
ただ、半年以上この体制を走らせてきて、光の裏にある影も見えてきました。
- 各スクワッドが自己完結し、横の情報流通が減る。 ミッションに没頭するほど、隣のスクワッドで何が起きているかを知る機会がなくなる
- 同じ試行錯誤が並行して起きる。 あるスクワッドが苦労して確立したAIワークフローと、ほぼ同じものを別のスクワッドがゼロから作っていたことがありました
- 「1人でやってる感」が強まる。 プロジェクトを1人で推進する場面が増えるほど、チームで働いている実感が薄れていく
そして、これが今回一番お伝えしたいことなのですが、AI駆動開発はこのサイロ化を加速させます。
AIエージェントを"部下"として使いこなせるようになると、1人でできることが劇的に増えます。それ自体は素晴らしいことです。ただ、裏を返せば「人に聞く必然」「人を頼る必然」が減るということでもあります。個人の生産性が上がれば上がるほど、組織は静かにバラバラになっていく。スピードに全振りした組織の、これが代償でした。
2. 「何をAIに任せ、どこを人に残すか」を、組織にも問う
前回の記事で、私は自分の業務をAIエージェントで「非同期処理」化している話を書きました。MTGの裏でAIを走らせ、戻ったらレビューと意思決定に集中する。この働き方は今も続けていますし、むしろ依存度は上がっています。
プロダクト開発では、私たちは「偶有的複雑性はAIへ、本質的複雑性は人へ」という整理をしています。あるとき、この問いは組織運営にもそのまま立てられることに気づきました。
組織運営において、AIに任せられないものは何か。
考えた末に残ったのは、メンバーのコンディションに気づくこと、スクワッドを越えた信頼関係をつくること、キャリアに伴走すること。つまり「横の繋がり」と「人への向き合い」でした。ドキュメント整理やタスク分解はAIが肩代わりしてくれます。でも、隣のチームの誰かが静かに疲弊していることには、AIは気づいてくれません。
実は、1チームのEMをやめようと考えたきっかけは2つあります。1つは、ここまで書いてきたサイロ化。もう1つは、「1チームに1人のEM」という体制そのものの脆さに気づいたことです。
「1つのチームに1人のEM」という体制では、その1人が抜けた瞬間に、担当チームのメンバーケアがまるごと空白になります。実際、私自身が複数のチームを兼務でカバーする場面も前職で多々ありました。その中で気づいたのは、「1チームに1人のEM」という構造である限り、誰かが欠ければマネジメントの空白がまた生まれる、ということでした。誰かのせいではなく、空白が生まれやすい構造の問題です。だから、組織として横をつなぐ構造そのものをつくる必要がある。この気づきが、「1チームのEM」という枠組み自体を見直す、大きなきっかけになりました。
であれば、EMという役割はどこに張るべきか。サイロ化と、マネジメントの空白 — この2つを同時に解消していくには、1つのスクワッドの中で深くやるのではなく、スクワッドを横断して「組織の横糸」を担う存在が必要なのではないか。そう考えて、1チームのEMをやめることにしました。
3. 横断EMとして、いまやっていること
とはいえ「横断EM」という役割の定義はどこにもありません。現時点でやっていることを、試行錯誤の途中経過として書いてみます。
- スクワッドを横断した1on1とコンディションの可視化。 現在は2つのスクワッド・8名のメンバーを横断して見ています。特定チームの定例に閉じず、組織全体のメンバーの稼働・状態・成長を見る。サイロ化の兆候を早めに拾う。
- AIワークフローの知見を越境させる場づくり。 前回の記事で「AIの活用度合いはメンバーによってバラつきがある」という課題を書きましたが、これはスクワッド間でも同じでした。ROXXには職能や関心領域ごとの横断コミュニティ「Chapter」（Spotifyモデル由来の呼び名）があり、私自身もその1つのチャプターリードを務めています。各チームの試行錯誤をChapter経由で吸い上げて共通化し、オーケストレーターとしての観点を組織の標準にしていく（Chapter活動の実態は、今後シリーズ記事として各リードから紹介していく予定です）。
- 事業サイドとの並走。 ROXXのエンジニアリングは「作って終わり」ではなく、顧客の成果にコミットするスタイルです。「何をAIに任せ、どこを人に残すか」の責務分解など、技術と事業をまたいだ意思決定を現場と一緒にやっています。
- 採用・ブランディングのリードと、組織運営の推進。 組織の課題を一番よく知る人間が採用の入り口に立つべきだと考え、EM採用のスカウトや選考設計、このテックブログを含む発信の設計も私が担っています。あわせて、組織運営の推進にも関わっています。
- 経営・CTOとの接続。 定期的に開発組織のコンディションを経営レイヤーに共有する場を設計し、組織の状態を経営に接続。CTOが不確実性の高い挑戦に向かえるように、組織運営を引き取っていく。「エンジニアリングが事業の主役」であり続けるための、土台をつくる役割です。
4. まだまだ設計の途中です
良いことばかり書いても仕方ないので、いま直面している壁についても触れておきます。
- 横断すると、深さが薄まる。 1チームのEMだった頃に比べて、1人あたりに割ける時間は確実に減りました。どこまでを自分が持ち、どこからをスクワッド内のリードに任せるか。この責務分解はまだ手探りです。
- コンディションの可視化は難しい。 稼働時間は数字で見えても、「疲弊」や「孤独感」は数字に出にくい。仕組みで拾うのか、対話で拾うのか、試行錯誤しています。
- 役割の正解がない。 Spotifyモデルに「こうすれば正解」というものがないのと同じで、横断EMという役割も、自分で定義し続けるしかありません。
ただ、前回も書いたとおり、この「正解のない問い」こそがROXXの面白さだと思っています。AIによって開発の在り方が変わるなら、EMの在り方も変わって当然です。それを教科書に沿って運用するのではなく、設計する側に回れる環境は、そう多くないはずです。
あなたの組織ではどうでしょうか。AIで個人が速くなったあと、横の繋がりはどうなっていますか。
5. この組織設計を、一緒に推進する仲間を探しています
松本の記事は、「竈そのもの——この事業と組織をどう設計し、どう大きくしていくか——を一緒に考えてくれる人は、外に探している」と結ばれていました。それが、このポジションです。探しているのは、抜けた穴の"補充"ではありません。横をつなぐ構造を、一緒に設計してくれるEMです。
- 既存チームの運用ではなく、組織の形から設計できる白紙の裁量があります
- 商談同席や技術的意思決定など、技術から離れずにマネジメントできます
- OpenAI / Gemini / Claudeを前提とした開発プロセスが既に稼働しており、AIを"使う"段階ではなく"設計する"側に立てます
「1人でやってる感」を「チームでやってる感」に変えていく仕事です。この問いを面白いと感じた方は、ぜひ一度カジュアルにお話ししましょう。
一緒に時代の転換点を創っていきましょう！
エントリーはこちらから👇
その他の求人はこちらから👇
ROXXってどんな会社？気になった方はこちらから👇
