エンジニアが「組織のボトルネック」を解消する。CTOに頼らない意思決定の分散システム

組織が拡大していく中で、どうしてもぶつかってしまう壁。それが意思決定のボトルネックです。

開発現場のタスクは回っていても、予算、採用、評価制度、オンボーディング……といった組織経営に関わる意思決定は、CTOなどマネジメント層に集中し、承認待ちが発生しがちです。

私たちユーザベースのSpeeda事業プロダクトチーム（以下、プロダクトチーム）も同様に、組織が大きくなるにつれて、この課題が表面化してきました。

こうした課題に対応するために、2020年ごろに導入したのが「経営チーム」という仕組みです。経営タスクに興味のあるエンジニアメンバーを集め、そのチームに権限を委譲し、意思決定を行うようにしました。

今回はこの取り組みについて、実際に経営チームに参加している中嶋・炭谷の視点から、組織のテーマでもある「自己組織化」と絡めて紹介します。

• ユーザベースに迫っていた「組織のボトルネック」
• なぜ経営チームという「解」が生まれたのか
• CTOからの権限委譲はどのように行われたか
• 実務は担わない──意思決定に特化した13の分散チーム
• なぜ専任ではなくエンジニアが兼任するのか
• 経営チームへの参加がエンジニア個人にもたらす変化
  • より「小さく始める」トレーニングになる
  • 組織全体を考えて振る舞えるようになる
• 【Case1：採用チーム】採用基準をエンジニア視点で「設計」する
  • 採用基準のブレをなくすためにドラフトコーチを導入
• 【Case2：構造化面接チーム】面接評価の均一化を目指す
  • スピード重視で、正社員面接へ「小さく」導入する
• 3カ月の「CTO不在期間」で実証された組織の強度
• まとめ：なぜ「自己組織化」を追求するのか
• 権限に頼らない「強いチーム」の育て方を知る

ユーザベースに迫っていた「組織のボトルネック」

2019年ごろ、プロダクトチームは組織拡大のフェーズにあり、エンジニアの人数も増え続けていました。

人数が増えれば、組織として判断すべきことの総量も増えていきます。しかし、それら全ての決定権はCTO一人が持っている状況でした。

そのような状況が今後の組織運営のボトルネックになると判断し、手を打つ必要がありました。

なぜ経営チームという「解」が生まれたのか

そこで、この組織のボトルネックを解消するために生まれたのが「経営チーム」という仕組みです。

従来CTOが一人で担っていた責務を分割し、複数のチームが分担する形にしました。意思決定に必要な裁量もそれぞれのチームへ委譲することで、特定の誰かの承認待ちで止まることなく、物事を素早く進められるようにしました。

例えば、承認チームは予算執行の裁量を持っていますし、ブランディングチームでは「開発組織のテックブランディングの戦略をどうするか」といった判断を自分たちで行います。

こうして各チームが与えられた責務を自律的に果たしていくことで、CTOが一人のときに比べて変化に素早く対応し、結果として、組織全体としてアジリティが高まる状態を目指したのです。

このような仕組みにした背景には、ボトルネック解消以外にも狙いがあります。リーダーやマネージャーというポジションと、それらのレイヤーのメンバーが通常行う経営タスクを分離したかったのです。

例えば採用に興味があるものの、それをやるにはリーダーにならなければいけない。でもリーダーになることによって、他の経営タスクもやる必要が出てくるし、いざやってみて合わなかった場合にリーダーを降りるということはすぐには難しい。

経営チームという採用・評価などの各ドメインに対応する形にすることで、リーダーという役職に就かなくても経営タスクに参加できます。また、合わなければ柔軟に抜けられる構造にすることで、個人の状況に応じた関わり方ができるようにしました。

CTOからの権限委譲はどのように行われたか

CTOからどのように権限が委譲されたのかを見ていきます。

小さく始めるという意味でも、段階を踏んで権限委譲をするかと思われそうですが、経営チームでは、「そのチームが担当する経営領域全て」を権限委譲することにしました。

採用チームであればエンジニア採用の領域全て。コンピテンシーチームであればエンジニアの評価基準（コンピテンシークライテリア）に関わるもの全て、という形になります。

ただいきなり全部丸投げするのではなく、最初はその領域を知っている人（CTOなど）と一緒にやったり、迷ったときにはすぐ相談できるようにとサポートメンバーとして入るようにしています。

段階的に権限委譲をするのではなく、あえて全てを担当してもらうことには意図があります。部分的な委譲だと全体感を知るのも難しいですし、結局もともとの課題である特定の一人がボトルネックになることを解消できないからです。

しばらくサポートメンバーが伴走した後、ある程度一緒に経営判断ができるようになってからはチームに任せるようにしていきます。もちろん判断に迷ったときは、いつでも相談できるようにしています。

実務は担わない──意思決定に特化した13の分散チーム

こうしたルールのもとで、意思決定はドメインごとの小さなチームに分散させています。

重要なのは、経営チームが担うのはあくまで「何をやるか」の設計・意思決定（経営）であり、日々の実務オペレーション（運営）ではないという点です。

例えば、採用チームなら「プロダクトチームのValueにマッチするエンジニアを効率的かつ持続的に採用し続けるために組織が何をするのかを決める」ことが責務であり、エージェントへの連絡や日程調整といった実務までは担いません。

ここを「何かをする」と捉えて、実務まで抱え込んでしまうと、本業である開発の手が止まってしまうため、明確に「経営」と「運営」を分離しています。

状況に合わせてチームの新設や統廃合を行っており、現在は13チームあります。

また、経営と開発は違ったドメインになるので、それを理解しながらやっていくという意味では普段の開発チームほどメンバーの入れ替わりが激しいわけではないのですが、6〜12カ月に平均1〜2回、それぞれのチームでシャッフルがあります*1。

例えば、以下のようないろいろなパターンがあります。

• 別の経営チームに参加してもいい
• 開発に集中したいときは経営チームをやめてもいい
• 気になる別の経営チームと掛け持ちをしてもいい
• 参加している経営チームが大変なので、力を貸してもらうためにスカウトをする

経営チームの掛け持ちに関しては、自分自身がメインで担当する開発チームとの調整がつけば自由にやっても問題ないことになっています。

ただし、経営チームの活動に過度に注力してしまい、本質であるエンジニアリングの仕事を損なわないように、目安として「経営チーム関連の活動は週に2時間まで」に収めるようにしています。

なぜ専任ではなくエンジニアが兼任するのか

ここまで仕組みを紹介してきましたが、もう一つの特徴は「誰がそれを担うのか」です。

経営チームは普段の開発チームと同じように2〜4人のメンバーで構成されたチームとなっています。

この経営チームを構成するメンバーは、普段開発を行っているエンジニアが兼任をしており、「経営チームに携わりたい」というメンバーが手を挙げることでジョインすることになります。

「なぜそれぞれ専任のチームを作らないのか。なぜエンジニアが兼任するのか」という疑問が湧いてくるかもしれません。これにはちゃんとした理由があります。

私たちユーザベースには、会社のValueを日々の行動レベルに落とし込んだ指針として「34の約束」というものがあります。その中の一つが「自己規律を大事にすること」です。

つまり誰かに管理されるのではなく、自分たちで考え、判断し、行動することを良しとする文化があります。

また、開発組織ではXP（eXtreme Programming）の価値観も大切にしています。現場に近い人間が意思決定し、小さく試し、フィードバックを素早く回す──そうした考え方です。

実際に現場で開発しているメンバーが兼任することで、エンジニアの実情や開発現場のコンテキストを深く理解した上での判断が可能になり、実態に即した無理のない意思決定につながります。

これらを踏まえると、経営に関するタスクだけをマネジメント層に集約するのではなく、現場のエンジニア自身が関わり、設計し、改善していく方が、私たちの価値観にも合っていると考えています。

経営チームへの参加がエンジニア個人にもたらす変化

エンジニアが経営チームとして組織運営に関わることは、単にマネジメント層のタスクをやってみるという経験値を積めるだけにとどまりません。

実際に参加してみて感じている、エンジニア個人にとってのメリットについてお話しします。

より「小さく始める」トレーニングになる

経営チームでは、それぞれが担う組織課題を解決することが一つの役割となっています。抽象的な課題も多く、正解が分からない中での意思決定力が求められます。

コンテキストが不十分な中での「経営や組織に関する判断」はハードルが高く見えるかもしれません。しかし、私が参加して感じたのは「基本的な考え方はエンジニアリングと変わらない」ということです。

正解が分からないからこそ、小さく始めて、フィードバック（FB）を得ながら前に進む。この「FBサイクルをいかに速く回すか」が大切だという点は、開発も経営も同じです。

ただ、経営チームが扱う課題は不確実性が高いことが多いため、より意識的に「小さく始めること」「サイクルを回すこと」が求められます。このプロセス自体が、不確実な状況下で判断を下すための最良のトレーニングになっています。

組織全体を考えて振る舞えるようになる

経営チームに参加することで「視座が高まった」と言うと大げさに聞こえるかもしれませんが、私自身は、日々の仕事の中での「解像度」や「意識」が少しずつ変化した感覚があります。

これまでは「まぁ、そこまで大きなことじゃないし、このままでいいか」とスルーしていた違和感に対し、「もう一段階踏み込んで話すべきでは？」「組織のために遠慮せずに伝えた方が良くないか？」と立ち止まって考え、行動に移すようになりました。

経営チームとして「組織全体のことを考える時間を持つ」ことで、自分のことだけでなく、チームや組織全体にとってプラスになる振る舞いをしようという意識が、自然と芽生えてきたのだと思います。

では、実際に私たちがどのように「小さく始め」、どんな「サイクル」を回したのか。その具体的なプロセスを、採用チームと構造化面接チームの事例を通じてご紹介します。

【Case1：採用チーム】採用基準をエンジニア視点で「設計」する

私・炭谷が担当している「採用チーム」は、組織の採用活動をより良くするために改善することが役割の一つです。

ユーザベースのSpeedaのエンジニア組織では、「自分たちが一緒に働く人は自分たち自身で決める」という考えのもと、基本的にエンジニア自身が採用活動をしています。そのため、応募のあったレジュメを見て合否の判断をしたり、面接に参加し面接官として判断したりということは、エンジニア組織全体で担います。

その中で、採用チームは、採用活動がより良いものになるために改善策を考えたり、円滑に進むようにリソースを調整したりすることがメインの役割となります。もちろん採用チームメンバーも採用活動をするエンジニアの一人であるため、書類選考や面接などの日々の採用活動にも参加しています。

採用基準のブレをなくすためにドラフトコーチを導入

この採用チームでは、「指名受託率（スカウト／指名に対して、候補者が辞退せず選考に進んだ割合）」が低下しているという課題を抱えていました。なぜ低下しているのかを深掘りし、CTOや採用に携わるメンバーにも意見を聞いていく中で、「採用基準がメンバー間で微妙にブレているのではないか」という一つの仮説が上がりました。

候補者のレジュメを見て「指名を出すべきか」を判断する際、個人の感覚に頼ってしまう部分があり、組織として一貫した基準で向き合えていない可能性があると考えたのです。

この課題に対する解決策として、ドラフトコーチを導入することにしました。組織理解が深く、採用経験も豊富なメンバーが「ドラフトコーチ」となり、指名を出す最終判断の前に、必ずコーチへ相談するプロセスを追加しました。

実際に運用を始めてみると、メンバーからは「ドラフトコーチの視点を知ることで、判断基準の学びになった」や「コーチに説明するために『なぜ指名を出すべきか』を言語化するプロセス自体が、情報の整理に繋がり、判断の迷いがなくなった」などのポジティブな声が上がりました。

いきなり全社の採用ルールを厳格化するのではなく、「まずは相談役を置く」という小さな変更で様子を見た結果、メンバーの心理的負担が減り、質が向上するという手応え（フィードバック）が得られたのです。

指名受託率自体は、さまざまな要因により変動するため今回の施策だけで全て解決したわけではありませんが、質の高い採用活動にしていくための施策としては良い結果で終えることができました。

私は採用チームに参画しながら、採用担当として書類選考や面接にも参加しています。課題を持っている当事者であるからこそ、「自ら課題を見つけ、自ら改善を試せる」楽しさがあると感じています。

経営チームの一員として採用に携わりながら、現場の違和感をそのままにせず、仕組みとして解決していく。自分たちが抱える課題が解決に向かうことは純粋にうれしいと感じると同時に、やりがいでもあります。

【Case2：構造化面接チーム】面接評価の均一化を目指す

私・中嶋が所属する「構造化面接チーム」は、面接評価のブレを減らすため、構造化面接というアプローチに注目しました。 構造化面接とはGoogleの記事にあるように、どの候補者に対してもあらかじめ決まった質問をして評価する面接方式です。

rework.withgoogle.com

この構造化面接の導入は元々は採用チームで検討していましたが、導入スピードを上げるために、タスクフォース的に独立したチームとして切り出しました。

スピード重視で、正社員面接へ「小さく」導入する

当初は業務委託面談で試験導入していたのですが、そこで集まるフィードバックへの対応にとどまり、正社員面接での導入に踏み切れていませんでした。

このままだとプロダクトチーム全体へ展開するリードタイムが延びることになってしまうので、私を含めた3名のメンバーで、

• 正社員面接にも導入する
• ただし導入は一次面接のみ
• ひとつの設問だけにとどめる

と決めました。慣れない面接で時間が延びないように、少しでも早く小さくリリースすることにしたのです。

その意思決定に至った背景については、プロダクトチームのメンバーが集まる定例ミーティングの場で伝え、質問があればその場で答えるという感じでスピードを重視したのを覚えています。

意思決定することは大切ですが、同時にどういう背景でこの意思決定になったかを共有することも大切です。

自分が説明される立場だったときに、「明日からこれやって、以上」だけだと納得感は生まれにくいものです。このように共有することで、「むしろこっちの方が良くないか」という建設的な提案をもらえたりします。

3カ月の「CTO不在期間」で実証された組織の強度

経営チームだけの効果ではありませんが、「組織の強度」を実感した出来事があります。

実は2025年1〜3月の期間、立ち上げたばかりのプロジェクトに集中するべく、CTOの林がCTO業務から一時的に離れていました（カオスWeekの取り組みから取って、社内ではこの状態を「カオスCTO」と呼んでいました）。

具体的な取り組みとしては、以下のような形です。

• 林はCTOの業務を原則行わず、別の誰かに任せる
• どうしても林にしかできない業務（予算承認や最終面接など）は行う
• いつもどおり「エンジニアの林」に相談や質問をするのはウェルカム
• 「カオスCTO」中に困ったことは付箋に書いておき、ふりかえれるようにする

CTOが3カ月も経営的な業務をやらないと言われると普通は不安になるのではないかと思います。

プロダクトチーム全体への周知は2024年12月でしたが、メンバーの反応は意外なほど落ち着いていました。

実際、「カオスCTO」期間中も大きな問題もなく、採用活動や評価基準の改定、オンボーディングなど経営チームの方も活動できていました。

過去にもCTOが出張などを理由にカオスWeekを実施したことはありましたが、3カ月という長期間でも大きなトラブルなく進めることができたのは、経営チームという仕組みで経営タスクをほかのメンバーが自律的に進められていたからこそだと思っています。

結果的に、これは「組織としてどこがボトルネックになっているか」を可視化する良い負荷テストにもなりました。

▼ カオスWeekの取り組みについてはこちらをご参照ください

agilejourney.uzabase.com

まとめ：なぜ「自己組織化」を追求するのか

最後に、私たちエンジニア自身が経営チームを実施する理由とそれが自己組織化にどのようにつながるかをお伝えします。

なぜエンジニア自身が経営チームを担うのか。その根底には、私たちが大切にしている「自由と責任」という考えがあります。

プロダクトチームでは、技術選定やプロジェクトの進め方、タスクの優先順位付けなど、エンジニア個人やチームに大きな裁量（自由）が与えられています。

しかし、この自由は「成果を出し続けること」そして「組織を健全に保つこと」という「責任」とセットで初めて成立するものです。

つまり「経営チーム」への参加は、誰かにやらされる仕事ではなく、自分たちの「自由」を守り続けるために必要で、エンジニアとしての「責任」を果たすための重要な活動の一つだと捉えています。

自らの手で組織のボトルネックを解消し、最高のパフォーマンスを発揮できる環境を作り上げる。このプロセスこそが、私たちが目指す「自己組織化」の姿です。

編集・制作：はてな編集部