この記事はBASEアドベントカレンダーの24日目の記事です。
はじめに
こんにちは！BASEプロダクト開発チームにて責任者（エンジニアリングマネージャー）をしている植田です。アドベントカレンダーも残すところあと2日ですね。
今回は エンジニア組織の「組織デザイン」 をテーマに、BASEの開発組織でこれまで実際に行ってきた組織設計と、その変遷をご紹介します。
組織論やチームトポロジーに関する書籍や記事は数多くありますが、
- 理論としては理解できるが、自分の組織にどう当てはめればいいかわからない
- 他社の開発組織が、実際にどう悩み、どう変えてきたのかを知りたい
と感じたことがある方も多いのではないでしょうか。
この記事では、「この形が正解です」という話ではなく、なぜその組織にして、どこに課題を感じ、次に何を選んだのかという意思決定の変遷をリアルに書いています。
想定読者
- エンジニアリングマネージャー、開発組織の責任者の方
- 組織設計・組織デザインに興味があるエンジニアの方
前提：BASEの全社組織と、今回扱う範囲
まず前提として、BASEの全社組織の概要を簡単に説明します。
BASEでは事業部制を採用しており、各事業部の中にプロダクト開発・マーケティング・CSなどの機能が配置されています。一方で、SREや情シスなどの全社横断の技術組織は、事業部とは別の技術本部として存在します。こうすることで各事業部の開発組織は事業・プロダクトにおける機能開発や運用といったことに集中しやすい環境が整備されています。
この記事で扱うのは、BASE事業における「Product Dev（プロダクト開発組織）」 の組織設計です。
組織設計の観点とその難しさ
具体的な組織図の話に入る前に、そもそもなぜ組織設計が難しいのかを整理しておきます。 組織設計で考慮すべき論点は非常に多岐にわたります。
- 事業戦略・プロダクト戦略との整合性
- 開発組織としてのビジョン、方向性とのアライン
- 開発PJをパフォーマンス高く推進できるか
- 開発チームへのPJアサインをスムーズにできるか
- プロダクトマネージャー、デザイナーとの協業
- 現状の開発組織の課題を解消できるか
- 開発組織における各機能をどのように持たせるか
- 1チームあたりのメンバー人数は何名が適正か
- 採用と育成との相性
- 運用体制・フローをどうするか
- メンバー同士の相性
- コードベースと組織境界の関係
- 専門領域と属人性の落とし所
ざっと挙げただけでもこのような観点が想定されます。1つずつ論点として取り上げ全体の整合性を設計する作業は多くの時間を要します。
しかも厄介なのは、組織設計は試行回数を簡単に増やせないという点です。組織を変えても、その良し悪しが見えるまでには時間がかかります。頻繁に組織を変えれば現場は疲弊しますし、一方で変えなければ歪みは蓄積していきます。
この前提を踏まえたうえで、ここから実際の組織変遷を紹介します。
フェーズ1：事業戦略ミラーリング型（2022〜2023）
1つ目は「事業戦略ミラーリング型」です。
背景と狙い
当時採用していたのは、事業戦略と開発組織をミラーリングする構成 でした。BASEは、スモールチーム向けのEC・決済という変化が激しく、事業戦略のスピードが求められる領域です。事業・プロダクトマネージャー・デザイナー・エンジニアが同じ方向を向き、同期的に動けることを重視していました。具体的には”Value Creation Sec”はテイクレート成長に責任を持つ戦略推進、”Core & Capacity Sec”はGMV成長に責任を持つ戦略推進というようにミッションが分かれていました。
得られたメリット
- 事業戦略の変更に追従しやすい
- チームごとの守備範囲が明確
- 特定領域の知見が溜まりやすい
見えてきた課題
一方で、次第に以下のような問題が顕在化しました。
- 事業戦略の変更に追従するために組織改編が頻発する
- チームの耐用年数が短く、チームビルディングが進まない
- サイロ化が進み、隣のチームへの関心が薄れる
- チームにおいて忙しさの濃淡が生まれる
実際にメンバーからは、「またすぐ組織が変わると思うと、チームを良くしようとするモチベーションが湧かない」という声も上がり、「強いチームが良いプロダクトを作る」 という前提が揺らぎ始めました。
フェーズ2：Feature Dev型（2024〜2025）
次に選んだのが、担当領域を固定しない Feature Dev チームを複数置く構成です。
- 開発領域を持たない Feature Dev チーム
- リアーキテクチャを推進する Module Development チーム
狙い
- 事業戦略変更への耐性を高める
- PJの割当柔軟性を上げる
- メンバーの経験領域を広げる
- モジュラーモノリスへの移行（リアーキテクチャ）に継続投資する
実際どうだったか
一定の成果はありました。
- 機動力の向上
- マンネリ化の軽減
- チーム間の負荷は平準化
- 広くプロダクトを知る機会の創出
しかし2年ほど運用する中で、別の歪みも見えてきました。
- 誰がどの領域を「守る」のかが曖昧
- 特定領域を守る・成長させる・身につけるという力学が働かない
- リリース後の運用責任が分散する
- パフォーマンス改善など中長期テーマに継続投資し辛い
メリットとデメリットは表裏一体ではありますが、2年程度の間にデメリットが少しずつ顕在化するようになってきました。またこの2年の間にリアーキテクチャが前進し、新たなアーキテクチャ上でスピーディに開発していくことの重要性が増してきました。
さらに、新機能開発だけでなく、事業成長とともにサービスレベルを継続的に高めていく必要性も高まり、専任チームを作る機運が高まってきました。
フェーズ3：ECコア機能領域型（2026〜）
そして2026年からは、ECのコア機能を軸にした組織設計 に踏み切ります。
- Item / Order / Checkout はECのコア機能になりリアーキテクチャ境界に近い
- Feature Dev…当該Sectionにおける開発PJを担う
- Item Scalability…商品領域のパフォーマンス改善を担う
- Architecture Design…中期的なアーキテクチャ設計を担う
- Checkout Reliability…購入に関するスケーラビリティ向上を担う（高負荷対応）
この形に込めた意思
- 耐用年数が長い領域を組織境界にする
- サービスレベル改善を「片手間」にしない
- 新たなアーキテクチャに取り組みやすい体制にする
期待するメリット
- 担当領域に詳しくなり責任を持つ文化の醸成
- 近い領域を重点的に開発することによるスピードアップ
- 機能開発以外の、サービスレベル改善の継続的な投資
もちろん、この形も完成形ではありません。サイロ化やマンネリ化のリスクは理解した上で、ローテーションや横断OKRなどで緩和する前提にしています。
まとめ
振り返って強く感じているのは、組織設計に最終解はないということです。事業・プロダクト・人が変われば、最適な組織も変わります。
大事なのは、
- 今の課題は何か
- 何を優先し、何を捨てるか
- 次に変える前提で、今をどう設計するか
を言語化し続けることだと思っています。
この記事が、どこかの開発組織で「組織を考えるきっかけ」になれば嬉しいです。
BASE では、今後のプロダクト成長を支える技術戦略や開発基盤の構築をリードしていただけるエンジニアを募集しています。 ご興味があれば、ぜひ採用情報をご覧ください。
