こんにちは！株式会社COMPASSのエンジニアリングマネージャーの千葉です。普段はエンジニアリングマネージャーとして開発組織のマネジメントに従事しているということで、前回はテックブログ開始のご挨拶をさせていただきましたが、今回はCOMPASSのプロダクト開発体制の変遷についてお話ししようと思います。
COMPASSの大事にしているValueの一つにBeyond the Best（常に現状に満足しないこと）というものがあります。事業や組織が拡大していく中で、組織の形についても常に最適な形を模索し、柔軟に体制を変えていこうという考えのもと、会社のフェーズに応じて組織体制を変更してきました。本記事ではその中でも直近のプロダクト開発体制の変遷についてどういった意図でどういう取り組みを行ってきたかについてご紹介させてもらえればと思います。
この記事はこんな方におすすめ
- 株式会社COMPASSのプロダクト開発体制について知りたい方
- これから開発組織を作っていこうと考えている方
- チームトポロジーを参考にした開発体制構築の事例を知りたい方
COMPASSのValueについて知りたい方は併せてこちらの記事もご覧ください。
社員一人ひとりの想いから紡いだCOMPASSの「価値観」。バリューができるまで、そしてこれからのこと。 バリューと連動し、組織体制の変化に強い人事評価制度を苦労の末に設計した話 COMPASSという会社がわかるオススメ記事3選〜MVVと組織風土〜
背景
COMPASSのプロダクト開発に携わるメンバーは、事業の拡大とともに年々増えてきました。これまでもプロダクト開発体制について最適な形を模索すべく試行錯誤を繰り返してきましたが、2022年頃に今のベースとなる体制が出来上がりました。2022年までの組織体制の変遷については本記事では割愛しますが、ベースとなる体制はチームトポロジーの考えに基づいて設計したものでした。しかし、チーム構成については一定セオリーに基づいて作れているものの、各チームにおける各メンバーの役割の定義の仕方によってはうまくワークしないことなどもあり、実際の現場で運用をするにあたっては細かくチューニングをしていく必要がありました。そこで、実際に運用してみた時に出てきた課題と、それらにどう向き合ったかというところについて具体的にお話ししていきたいと思います。
チームトポロジーとは
まず、ベースとなるプロダクト開発体制を作る際に参考にしたチームトポロジーについて簡単に説明させていただきます。といっても、チームトポロジーの全容について説明しようとすると本記事内で取り扱うには膨大な量になってしまうので、かいつまんで説明させていただければと思います。
プロダクト開発の組織に求められることは、ビジネスの変化のスピードが加速する中で、価値を素早く生み出して提供することです。事業が大きくなり、システムが大規模化、複雑化していく中で、素早い価値提供を実現するためにどのような体制を作っていくのが望ましいか、の一つの指針となるパターンがチームトポロジーです。素早い価値提供を行うにあたって、具体的にはDORAが提唱するFour Keys（変更のリードタイム、デプロイ頻度、変更失敗率、平均修復時間）を高い水準に保つことが重要とされており、それを実現するためには方法論だけではなく体制としても実現しやすい形を取る必要があるという考え方になります。
そのために、プロダクト開発現場で従来より採用されている職能別の組織体制ではなく、適切な水準（人数、コミュニケーション手法など）に則った「チーム」を組成し、各チームの役割を明確にし、そのチームとして成果を出せるように運営していこうというのが概要になります。
※詳細は書籍に記載されておりますが、本記事では割愛します。気になる方はぜひ書籍を読んでみてください
上記概要の中でも特に体制を作る上で重要になってくるのが各チームの役割、責任範囲をどうするかという部分になってきます。チームトポロジーでは下記の4つの種類のチームで体制を構築することが望ましいと記載されています。
ストリームアラインドチーム
ビジネスに最も影響力のある1つのストリームを取り扱うチームです。そして、そのチーム単独で開発のライフサイクル、つまり要件を決めるところから実際の運用まで回せるようになっている状態のチームがストリームアラインドチームです。このストリームアラインドチームがプロダクト開発における中心となるチームであり、そのほかのチームはストリームアラインドチームの認知負荷を減らすために存在する形になります。また、ストリームアラインドチームはストリームの数によって増減します。（複数チーム存在していてもいい）書籍やあらゆるところで難しい書き方がされていますが、要するに価値提供をする上で本質的に時間を割くべきところに専念するチームを作りましょうという話だと理解しています。そしてこのチームが本質的に時間を割くべきではない具体的な項目についてはほかのチームの役割の説明で見ていきましょう。
プラットフォームチーム
プラットフォームチームは、インフラやネットワーク、各種外部ツールなどのサービスを内部サービスとして提供するチームです。そして、ストリームアラインドチームが顧客に価値を届ける上でそれらを容易に利用できるようにすることがこのチームの役割となります。例えば、ストリームアラインドチームが開発から運用までできるようにするためには、インフラの取り扱いができる必要があります。しかしストリームアラインドチームがインフラを提供するサービスを深く理解する必要があるかというとそんなことはありません。プラットフォームチームはストリームアラインドチームが目的を達成するために必要な内部サービス（この場合はインフラの取り扱いに関するサービス）を提供することで、ストリームアラインドチームは価値提供にフォーカスをすることができるようになります。
イネイブリングチーム
イネイブリングチームはストリームアラインドチームで起こる専門性の高い重要なトピックについてストリームアラインドチームの認知負荷を減らす役割を持ったチームで、適切なツールやフレームワークなどの調査、新しい技術の取り入れなどを支援します。また、イネイブリングチームは複数のストリームアラインドチームを横断的に支援することを想定しています。例えば、ある機能を開発するとなったときに、セキュリティを担保するための検討を行わなければならないという状況を想定します。セキュリティに関しては専門性の高く非常に重要な領域ですので、実際に調査をしたり事例をもとに解決策を検討するだけでもかなりの労力が必要となる作業になります。こういった専門性が高く難易度の高いトピックについてイネイブリングチームが受け持つことによって、ストリームアラインドチームの認知負荷を下げることができます。
コンプリケイテッド・サブシステムチーム
コンプリケイテッド・サブシステムチームはチームの名前の通りではあるのですが、システムの中でも複雑なサブシステムを受け持つチームとなります。このチームの役割は理解しやすいかなとは思うのですが、システムの中で数理モデルや機械学習、統計などを取り扱う部分がある場合には、コンプリケイテッド・サブシステムチームが受け持ちます。これにより、ストリームアラインドチームが複雑なサブシステムの中身を深く理解しなくとも、価値提供ができるようになります。
このように、役割の異なる4つのチームを組成し、それぞれのチームが適切な形でのコミュニケーション（インタラクションモード）をとっていくことで、素早い価値提供を行えるようにするというのが大枠での考え方となります。
※チーム構成に加えて各チーム間のコミュニケーション方法を定義したインタラクションモードについてもチームトポロジーを考える上では非常に重要な要素ではありますが、本記事では各チームの設立趣旨とチーム内のメンバーの役割にフォーカスを当ててお話ししようと思いますので、インタラクションモードについての説明は割愛します。
COMPASSでのチーム構成
それでは具体的にCOMPASSではどのようにチームを構成していったかというところについて説明していきます。チームトポロジーの考え方は非常に理にかなっているものの、既存の体制に対してチームトポロジーの考え方を綺麗に当てはめるにはややギャップが大きいと考えました。従って、まずは必要なストリームアラインドチームを洗い出し、そのストリームアラインドチームの認知負荷を下げることを目的としたチーム構成を考えることにしました。そこでベースとなった体制がこちらになります。
COMPASSのチーム構成 Ver.1
まずCOMPASSのプロダクト開発においてビジネスに最も影響力のあるストリームとしてはやはりプロダクトがそれに該当すると考えています。キュビナのサービスは大きく4つのプロダクトから構成されており、生徒が利用するプロダクト（QS）、先生が学習管理をするプロダクト（QM）、先生や教育委員会がアカウント管理をするプロダクト（AM）、社内でコンテンツを制作するためのプロダクト（CUEB）に分かれています。従ってこの4つをストリームアラインドチームとして定義しました。
そして、それらの4つのストリームアラインドチームの認知負荷を下げるために、まずはプラットフォームチームを定義しました。こちらはプロダクト横断的に利用している基盤部分について取り扱うチームとなっており、ストリームアラインドチームの基盤部分に対する認知負荷を減らすことを目的として作られています。
ここまではチームトポロジーの考え方に沿ってはいますが、図に記載の通り各ストリームアラインドチーム、プラットフォームチームの他にSREチームとQAチームを作ることとしました。いずれもストリームアラインドチームを横断してチームを支援する目的で作られてはいますが、SREチームはチームトポロジーでいうところのプラットフォームチームとイネイブリングチームの間のような立ち位置、QAチームはイネイブリングチームのような立ち位置で存在しているという形にしました。
このように最初から綺麗にチームトポロジーの考え方を適用するというよりは、まずはストリームアラインドチームを定義した上で現状から移行可能な形でストリームアラインドチームの負荷を下げるためのチーム構成を作ったという形になります。
ここまででチームという箱は出来上がりました。そこで各チームにメンバーをアサインし、最初の体制ではリーダー中心としたチーム運営を始めることにしました。
チームリーダー制を採用した人員配置
しかし実際に運用を始めてみたところ、チーム構成というよりは、各チーム内でのメンバーの役割分担というところで課題が浮き彫りになってきました。チームそのものの設計自体は一定チームトポロジーというテンプレートに沿って行ったものの、チーム内部の設計が上手にできていなかった、そしてそれが非常にこのチーム体制を作っていく中で難しいポイントであるということを認識することとなりました。それでは運用してみた結果見えてきた課題とどのようにその課題に向き合ってきたかというところについてご紹介していきます。
チームリーダー制からの脱却
運用を始めるにあたり、前述の通り、各チームにリーダーを置き、リーダーを中心に各チームを運営していく方式をとりました。しかし、実際にチームリーダーが負うべき役割はプロダクトの開発そのものに対する責任だけではなく、各チームの技術のマネジメント、各チームに所属するメンバーのマネジメント（開発におけるメンバーのタスクマネジメントだけではなくメンバーの評価やフィードバック、リソース確保と配分、採用、オンボーディングなども含む）など多岐にわたるものでした。その結果、チームリーダーに負荷が集中し、本来注力すべき箇所に注力ができなくなったり、さらにそれが続くことでリーダーの役割というものが曖昧になってしまうという状況に陥りました。そこで、リーダーが負うべき役割というものを棚卸しし、それらを二つに分類し、テックリード（TL）とエンジニアリングマネージャー（EM）というポジションを設け、それぞれが負うべき役割を明確に定義することにしました。
TLに期待する役割
-
技術的な意思決定:
- TLは新しい技術を採用するか、既存の技術を使うべきか、またそれに関連する最善の手法や実装戦略を選択する役割を持ちます。また、チームが優先順位を決定できるようにするための技術的な視点を提供します。
-
専門領域における品質の担保:
- TLは専門領域におけるベストプラクティスとチームの品質基準を維持します。（コードやインフラなど）
-
チームのエンジニアリングスキル向上:
- TLはチームメンバーのエンジニアリングスキルを向上させるための手助けをします。ジュニアレベルのメンバーにはメンターシップを提供し（自分以外でも可）、新しい技術や手法を学び、習得するのを助けます。
-
技術的なロードマップ:
- TLはチームの技術的なロードマップを作成し、それをチームとステークホルダーに共有します。
EMに期待する役割
-
ピープルマネジメント:
- EMはチームの人々を管理し、キャリアの進行をサポートします。パフォーマンスの評価、フィードバックの提供、TLと協業したプロフェッショナルな成長の機会の提供、目標と期待の管理などが含まれます。
-
チームビルディングとカルチャー醸成:
- EMはメンバーがよく働くことができ、お互いに信頼と尊重を持つ環境を作る役割を持ちます。横断的なチームビルディングの活動を企画し、ポジティブなカルチャーを強化します。また、チーム内のチームビルディングにおいてTLをサポートします。
-
リソースの確保と配分:
- EMはプロジェクトが計画通りに進行するために必要なリソースを確保し、適切に配分します。
-
エスカレーションの管理:
- EMはエスカレーションポイントとして機能し、問題が発生した場合には対処します。対人関係の問題やプロジェクトの問題、オペレーションの問題まで広範にわたり対処します。
-
採用とオンボーディング:
- EMはチームの人員を増やすために新しいエンジニアを採用し、新しいメンバーの成功を保証するためのオンボーディングプロセスを管理します。
この時、ピープルマネジメント、チームビルディングをする上で、それぞれの職能の専門領域の人たちがEMを担うのが良いだろうということで、EMに関してはフロントエンド（FE）、バックエンド（BE）に分け、さらにリソースの確保と配分、採用などにも責任を持つため、チーム横断でマネジメントをする体制にしました（SREとQA以外）。一方TLについては各チームに専任で配置し、チーム内の技術マネジメントに特化する形をとりました。これによりリーダーの役割を複数人で分担し、領域ごとに人をアサインすることで、負荷の集中による役割の曖昧化を防ぐことを目指しました。
TL、EM制を採用した人員配置
チームリーダー制Ver.2
リーダー制を採用して運用した後、発生している課題を見極め、きっちりと役割を明確化して運用したTL、EM制ではありましたが、運用して半年ほどして、それでもやはり運用上の課題が出てきました。とはいえ、冒頭にBeyond the Bestのお話をさせていただきましたが、実際に試してみて課題が見えたところで試行錯誤を繰り返し、より良い状態に持っていくという中では早めに課題を見つけアクションに落とせるというところはCOMPASSの良いところだと考えています。
実際に発生していた課題としては、TLとEMをおいたものの、チームごとにアサインされているTLが結局はリーダー制の時にやっていた業務を任されている状況になってしまっていて、実質前の状況を引きずってしまっている状況（うまく移行できていない状況）になってしまっていたことが挙げられます。きっちりと定義を固められたことは良かったのですが、やはり旧体制から新体制に移行する際にギャップが大きいとなかなかうまく移行できないものだなと感じました。また、TL、EMという形でレポーティングが行われる役割の人を増やした結果、現場ではレポートラインが曖昧になっていたり、EMがチーム横断で役割を全うするにあたって、横断であるが故に実態を把握しにくいという状況も発生していました。
そこで下記の方針に基づいて役割とアサインを再整理することにしました。
-
リーダーの役割を復活
- リーダーを廃止しようとしても結局リーダーとしての動きは残ってしまうので、リーダーという役割を復活させる
- その代わり、リーダーに求められる役割というものを再定義し、上手くTL、EMと分業できるようにする
-
TLのストリームアラインドチーム内設置を廃止
- 技術領域での牽引というメインミッションを達成するために横断的にストリームアラインドチームをサポートするチームに配置
- ストリームアラインドチームの技術に関する認知負荷を横断的に下げる役割とする
-
EMの全体横断設置を廃止し、横断範囲の縮小
- 当初職能が異なるメンバーの特に育成面で上手くいくかを懸念していたが、一定の技術レベルを持っていれば対応が可能であるとし、基本的にチーム内におく事とする
- 一方で、一定の技術レベルを持っていることが要件となるので、移行段階では全てのチームに一人づつ専任を置くのではなく、段階的に専任化していく
そうした上で、改めて各ポジションに期待される役割を整理しました。
TLに期待する役割
-
技術的な意思決定:
- TLは新しい技術を採用するか、既存の技術を使うべきか、またそれに関連する最善の手法や実装戦略を選択する役割を持ちます。また、各チームが優先順位を決定できるようにするための技術的な視点を提供します。
-
専門領域における品質の担保:
- TLは専門領域におけるベストプラクティスと各チームの品質基準を維持できるよう推進します（コードやインフラなど）
-
エンジニアリングスキル向上:
- TLはメンバーの技術領域におけるエンジニアリングスキルを向上させるための手助けをします。ジュニアレベルのメンバーにはメンターシップを提供し（自分以外でも可）、新しい技術や手法を学び、習得するのを助けます。
-
技術的なロードマップ:
- TLは担当領域における技術的なロードマップを作成し、それをチームとステークホルダーに共有します。
EMに期待する役割
-
ピープルマネジメント:
- EMはチームの人々を管理し、キャリアの進行をサポートします。パフォーマンスの評価、フィードバックの提供、リーダーと協業したプロフェッショナルな成長の機会の提供、目標と期待の管理などが含まれます。
-
横断的なチームビルディングとカルチャー醸成:
- EMはメンバーがよく働くことができ、お互いに信頼と尊重を持つ環境を作る役割を持ちます。横断的なチームビルディングの活動を企画し、ポジティブなカルチャーを強化します。客観的にみた横断的な運営の評価、改善。
-
リソースの確保と配分:
- EMはプロジェクトが計画通りに進行するために必要なリソースを確保し、適切に配分します。
-
エスカレーションの管理:
- EMはエスカレーションポイントとして機能し、問題が発生した場合に対処します。客観的にみたチームの課題の発見とリーダーと共同した解決をします。客観的にみたチーム運営の評価、改善のサポート。
-
採用とオンボーディング:
- EMはチームの人員を増やすために新しいエンジニアを採用し、新しいメンバーの成功を保証するためのオンボーディングプロセスを管理します。エンジニア組織全体における共通部分でのオンボーディング。
- 個人（共通オンボーディング、キャリア形成）、チーム（リーダーのサポート）、チーム横断（主体として活動、リソース配分）、採用
リーダーに期待する役割
-
チームにおける開発マイルストーン策定:
- リーダーはビジネスマイルストーン・技術負債や技術戦略などの開発主体のマイルストーンを加味したロードマップの策定・推進をします。
-
コラボレーションの促進:
- リーダーはチーム間の横断的なコミニュケーションと協力を促進します。
-
イノベーションの促進:
- リーダーは新しい技術やプロセスの探求を奨励し、イノベーションをチームに取り入れます
-
チームビルディング:
- チーム内のチームビルディングを推進します。
このように、リーダーを復活させつつ、TLとEMの役割を変えていくことにより、現在発生している課題を解決しようと考えました。やはり開発を進める上で考慮しなければならないことが多く、それをどの範囲でどのように分担していくかというところが非常に重要な観点だと考えています。
また、このタイミングでプラットフォームが担うべき役割を変更する事としました。現状のチーム構成の課題として、ストリームアラインドチームの認知負荷がまだまだ高い状態であると考え、持続可能なシステムに向けての課題を発見し、解消するための推進をするという目的のもと、イネイブリングチームとしての役割へと変更する事としました。これにより、以前よりもストリームアラインドチームを強くサポートするという形の構成になることを目指しました。また、イネイブリングの領域としてもバックエンド、フロントエンドそれぞれのイネイブリングチームを作ることで、各領域に特化したストリームアラインドチームのサポートができることを目指しました。結果的にこのような組織体制となりました。
チームリーダー制Verl.2
EMに関しては引き続き横断的に組織を見る部分もありますが、全体を見ていた時に比べ、見る範囲が狭くなっています。また、QAについては各ストリームアラインドチームの開発マイルストーンを意識する必要があるので、リーダーを配置するという形になりました。
現在の課題
実際にこの体制で運用してみたところ、リーダーを設置したことにより、TL、EMがそれぞれの役割を全うしやすくなったということは事実としてあると考えています。一方で、本来EMについては各チームに一人ずつ置く想定ではあるのですが、現状ではチーム横断で見ているEMもまだまだいる状況で、EMに期待される役割の最低限の動きしかできていないという課題はあります。
TLは本来であればチームに一人置きたいとは考えていますが、システムがモジュラモノリスを採用しているとはいえ、いまだに結合度合いは高い状態なので、それが難しい状態になっています。モジュール分割への取り組みは進めているので、システムと二人三脚でモジュール化できるところはモジュール化していき、チームごとに動きやすくなるような形にしていきたいとは考えています。
こうした時に、システム面は改善していくとして、やはりEMの兼務の解消が大きな課題となっています。社内としては人材の抜擢については積極的に行なっており、EMとなれる人材を育成していきたいと考えていますが、兼務の範囲が現状では大きく、やはり一定採用に頼らざるを得ないというところも考えています。現在EM職については積極的に募集を行っておりますので、ご興味のある方は下記リンクより要件を覗いてみてもらえると嬉しいです。
まとめ
今回は直近のCOMPASSのプロダクト開発体制の変遷についてご紹介してきました。プロダクト開発体制の作り方には色々な方法論がありますが、各会社におけるビジネスに直結するストリームの種類や、構成されている人員なども考慮すると、どんな会社にも適応できる絶対的な正解はなく、やはり会社ごとに最適な形を模索していく必要があると考えています。試行錯誤を繰り返していく中で、もちろん失敗したり、課題に直面することは多々ありますが、それでも常に現状に満足せず、改善を繰り返していくことで理想の開発体制を構築していけるものと考えています。今後もより良いプロダクト開発、素早い価値提供を実現するために、試行錯誤を繰り返していきたいと考えています。
最後に、ここまでお読みいただいてありがとうございました。本記事が皆様の課題解決の一助になれば幸いです。
Discussion