クイックのエンジニアリングマネージャー桃原（とうばる）です。
今回は、4月の新体制を機に横断組織を再編する話と、これから推進していくことを話します。
AI時代のエンジニア組織を、考えつづける
「今まで同期的に行っていたイベントは、本当に必要なのだろうか？」
そんなことを考え続けています。
人が集まる意味とは何か。エンジニアが組織的に動く意味とは何か。AIが多くの作業を担えるようになった今、私たちが集まって行うべきことは何か。こういったことを問い直す時代になってきたと感じています。
目の前の課題を解決するためにPRを作る。それ自体はもちろん大切なことです。でも、それだけでよいのだろうかとも思っています。中長期を見据えた課題把握・課題設定、そして既存の枠組みにとらわれない形でチームを組み、解決・推進していく土台。そういったものを自ら設計していく力が、エンジニアにもエンジニア組織にも求められてきていると感じています。
「上長が課題解決のためにチームをつくる」——それはAI時代以前の動き方かもしれません。
これからは、課題に対して自律的に動ける枠組みを、私たち自身が設計していく必要があると思っています。虫の目（現場の解像度）と鳥の目（全体の俯瞰）を行き来しながら、そのための機会を日常に置いておきたい。それが、組織設計・組織開発という営みにつながっていくのではないかと考えています。
そんな思いから、エンジニア組織を改めてつくっていきたいと動き始めました。
この記事は、同じような問いを持つ方・これから社内で横断組織を進めていきたい方・同じフェーズにいるEMの方に向けて、私たちの取り組みを記録しておくものです。まだ実践段階ではありませんが、どのように考え、進めているかのプロセスを共有します。そして社内のメンバーには「そういう想いでつくっていくよ」という共有ドキュメントでもあります。
解決しようとしていること
正直に書くとこちらです。
「誰がボールを持つか」の全体図が、なかった。
4月から組織体制が変わり、事業軸が強化されました。それ自体はとてもよい変化です。ただ、その結果としてエンジニア一人ひとりが「誰が何を進められるか」「どこが宙に浮いているか」「自分がどこを埋めに行けばよいか」を判断できる全体図が、見えにくくなりました。
全体が見えないと、動けない。動けないから、後回しになる。
さらに、横断で動くエンジニア組織が「何を担うか」も言語化されていませんでした。組織としての戦略が不明確なまま進むと、事業成長への影響が少しずつ広がっていきます。そしてこれは、新体制になって急に生まれた問題ではありません。以前からできていなかったことも、正直多くあります。
体制が変わったからといって、自然に解決するとは思っていません。
だからこそ、権限を明確にし、それぞれが「やる・やらない」を自分で判断できる全体俯瞰の仕組みが必要だと考えました。そして、その仕組みを一度作るだけでなく継続して運用するための体制、つまり「横断で動き続ける組織」が必要だという結論に至り、動き始めました。
なぜ今、先手を打とうとしているのか
4月の新体制は、上記の課題が顕在化するタイミングでもありました。
事業をより深く推進するために、事業軸を強化した設計になっています。これ自体はとてもよい変化だと思っています。事業に近いところでエンジニアが動ける環境は、プロダクトの成長速度につながります。
ただ、こういう変化のときに意識しておかないと、技術の横串がじわじわ薄くなっていきます。
技術の横串が薄くなる、ということです。
事業ごとにチームが動き始めると、ナレッジが分断されやすくなります。インフラの判断、AIツールの選定、セキュリティ対応、データ基盤の設計。こういった技術の共通課題は、事業軸では決めにくいことが多いです。決める場所がないと、どうしても後回しになってしまいます。
問題が起きてから対処するのではなく、組織が拡張するフェーズに合わせて体制を先回りして設計しておきたい。 それが今回の再編の出発点になっています。
以前、EMトライアングルを使ってチームを可視化した記事を書きました。そのとき「ピープル-技術の軸を意識的に強化していく必要があるな」と感じたことが、今につながっています。まず可視化してみることで、次の打ち手が見えてくる感覚は、今でもそうだなと思っています。
エンジニア横断の組織が必要だと考える4つの理由
上記の課題を解決するための手段として、横断組織が有効だと考える理由を整理しました。
① 重複投資を未然に防ぐために
チームが増えるほど、同じ問題を並行で解くコストが積み上がっていきます。
「あのチームも認証まわりを作っていたらしい」「同じツールやライブラリを別々に評価していた」。今すぐ深刻な問題ではないかもしれませんが、組織が大きくなるにつれて無視しにくくなっていきます。横断の視点で共有できる仕組みを最初から持っておくことで、後からのコストを減らしていけると考えています。
② 技術の賞味期限は、思っているより短いかもしれない
エンジニアは、全職種の中でも特に技術の変化スピードが速い領域にいます。半年前の知識が役にたたない、むしろ邪魔になることもありますよね。
事業チームの中だけで仕事をしていると、「自チームで使う技術スタック以外が見えにくい」状態になりやすいです。意識的に横の連携を持てる場がないと、市場全体の変化から少しずつ取り残されていく感覚が生まれやすくなると思っています。
エンジニアの行き先 という記事でも書きましたが、AI時代のエンジニアにとって「何を解決するか」を判断する力はますます重要になっていくと感じています。横断組織は、そのための刺激と情報が集まる場にできると思っています。
③ 横断施策には、レバレッジがある
共通基盤を1つ作ると、全社の開発速度が上がっていきます。
AI活用の推進、セキュリティポリシーの統一、ライセンス管理の一元化。こういった施策は、1チームが動くだけではなく、横断で動くことで効果が何倍にもなりやすいです。「自分たちだけ」ではなく「全体が動く」という感覚は、エンジニアとして得られる手ごたえの質が変わってくると思っています。
④ 多層の技術課題に、先回りしておきたい
インフラ、セキュリティ、AI、データ、ツール。
領域が広がるほど、個別のチームが個別に判断していくのは難しくなります。領域が広がる前に「誰が何を判断するか」を整理しておくことで、いざというとき動きやすくなると考えています。
これまでに整理してきたこと
6月に入ってから、少しずつ整理を進めてきました。
意思決定ラインを明確にする
最初に向き合ったのは「誰が何を決めるのか」という問いでした。
横断でやるべき判断と、事業の中で決めてよい判断を分けること。これがないと、横断組織は「とりあえず集まる場」になりやすいです。全社や事業をまたぐ最終決裁は本部長、事業内は各事業内で決める体制案を今進めています。
役割を切り分ける
技術戦略（戦略・ガバナンス・アーキテクチャ）とエンジニア組織（人・文化・コミュニティ・育成）の2つを分けて設計しています。
どちらも「横断」ですが、主語が少し違います。前者は「技術の意思決定を支える」、後者は「エンジニアが成長できる環境をつくる」。この役割の切り分けを明確にすることで、どちらも中途半端にならないようにしたいと考えています。
RACIマトリクスで可視化する
60の施策・11のカテゴリについて、A（最終責任者）/ R（実行責任者）/ C（協働者）/ I（報告対象）を整理しました。
やってみて気づいたのは、「誰も決めていない領域」と「複数が担っていて曖昧な領域」が見えてくる、ということでした。決める前にまず可視化してみること。それが先手を打つための一歩になると感じています。
組織は人が育つ場所 という記事でも書きましたが、組織は意図的に設計していくものだと私は思っています。自然に育つのを待つだけでなく、育つための構造を少しずつ整えていく。そういうアプローチが大切だと感じています。
これから、一緒に決めていくこと
途中過程ではありますが、正直にお伝えしておきます。
- エンジニア組織のミッション・バリューの言語化
- 運営チームの具体的な活動内容と工数の詰め
- 各事業の意思決定者の確定
これらはまだ決まっていません。ただ、私はこれを「遅れ」とは捉えていません。
私は全体の責任者として場を設計する役割を担いますが、ミッションや優先度、運営の方針は、これから一緒に動くメンバー自身が決める機会として提供したいと思っています。
組織をゼロから立ち上げる経験は、そう頻繁にあるものではありません。何を大事にするか、どんな組織にしたいか、どの課題から手をつけるか。そういった問いに向き合うプロセスそのものが、EMとしての力を育てる貴重な時間になると感じています。
「決まっていないから動けない」のではなく、「決めていくプロセスに一緒に参加できる」。それがこの立ち上げの面白さだと思っています。
この経験が、なぜ貴重だと感じているか
私はこれまで、組織やプロジェクトの立ち上げをいくつか経験してきました。
そのたびに感じてきたのは、人を率いる経験の質が、日常のエンジニアリングとは少し異なる、ということです。
コードを書く経験は、問題に対する答えが（だいたいの場合）あります。でも組織を動かすときに向き合う問いには、決まった答えがないことが多いです。視点の異なる方に意図を伝える、利害が違う立場で合意を作る、決断と責任を引き受ける。こういった経験は、技術の深さとは別のベクトルで、自分自身を育ててくれると感じています。
エンジニアの行き先 でも触れましたが、AIが自動化できる仕事が増えるほど、人が判断・調整・責任を担う部分の価値は上がっていくのではないかと思っています。横断組織の立ち上げに関わることは、そういう力を育てるひとつの機会になると感じています。
これから一緒にやるメンバーへ
組織の名前も、ミッションも、まだありません。
でも、それを一緒に決めることが最初の仕事だと思っています。なぜ横断で動くことが必要で、どういう組織でありたいか。それを自分たちの言葉で語れるようにしていきたいです。
「リブート」というのは、過去を否定することではありません。新しい体制に合わせて、最適な形に再設計することです。ゼロから作るよりも難しいこともありますが、既存のものを引き継ぎながら変えていく、そのプロセス自体が大きな学びになると感じています。
将来、事業を技術でリードするエンジニアにとって、「組織をどう設計するか」「人をどう動かすか」という経験は、きっと役に立つ場面が来ると思います。
組織は人が育つ場所 というのは、私が本当にそう思っているから書いたタイトルです。横断組織も、そういう場所にしていけたらと思っています。
横断組織を立ち上げるステップ（まとめ）
ここまで書いてきた内容を、立ち上げのプロセスとして整理しておきます。同じように横断組織を立ち上げようとしている方の参考になれば嬉しいです。
STEP 1｜施策をまとめる
まず「何をやるか」を洗い出します。横断でやるべき施策をリストアップし、全体像を見えるようにすることが最初の一歩です。
STEP 2｜権限と責任範囲をわける
「誰が何を決めるか」を明確にします。RACIマトリクスなどを使って、最終責任者・実行責任者・関与者を整理すると、後の意思決定がスムーズになります。
STEP 3｜レビュープロセスを決める
施策をどう承認・確認するかの流れを決めます。承認フローが曖昧なまま進めると、あとでやり直しが発生しやすいです。
STEP 4｜運営者を公募する
運営を担うメンバーを集めます。トップダウンで指名するより、手を挙げてもらう形のほうが、主体性のある運営につながりやすいと感じています。
STEP 5｜動ける役割範囲を決める
メンバーが決まったら、それぞれの役割と権限をはっきりさせます。「何を自分で決めてよいか」がわかると、動き出しが早くなります。
STEP 6｜それぞれの課題認識を揃える
メンバー間で「何が困っているか」の認識を共有します。課題の認識がバラバラなまま進めると、施策の優先度がかみ合わなくなりやすいです。
STEP 7｜どの順番で課題を解決するか認識を揃える
課題を洗い出したら、「どれから手をつけるか」の優先順位を揃えます。全員が同じ方向を向いていることが、横断組織では特に大切です。
STEP 8｜課題解決の手段を考える（ここが一番楽しい）
優先順位が決まったら、どうやって解決するかを考えます。勉強会なのか、共通基盤を作るのか、ミニプロジェクトを立ち上げるのか。ここは創造性を発揮できる場面です。
STEP 9｜運営を進める
実際に動き始めます。最初は小さく始めて、うまくいったことを積み重ねていくのがおすすめです。
STEP 10｜全体・施策のリードを決める
横断組織全体のリードと、各施策のリードを明確にします。「誰がオーナーか」がはっきりすると、物事が前に進みやすくなります。
これからやっていくこと
組織が立ち上がったら、取り組んでいきたいことがいくつかあります。
- AI開発の運用ノウハウ共有・勉強会：各チームが個別に試行錯誤しているAI活用の知見を、横断で共有できる場をつくっていきます
- 事業をまたいだ横断施策の共有・学びの場づくり：LTやワークショップなど、エンジニアが刺激し合える機会を定期的に設けていきたいです
- データによる開発プロセスの定量可視化：開発速度や品質の指標を横断で見えるようにして、改善のサイクルを回していきます
- ミニプロジェクトの立ち上げ：可視化や共通基盤づくりを、小さなプロジェクト単位で動かしていく予定です
これらの取り組みについては、実際に動き出したタイミングで次の記事にまとめたいと思っています。
次回の記事をお楽しみに。
おわりに
この記事は、完成報告ではなく途中経過の共有です。
半年後、「あのときこんなこと書いてたな」と笑えるくらい、良いものができていたらいいなと思っています。
つくる事を楽しみながら、一緒にサービス・事業・組織を盛り上げていきましょう！