atama plusにおけるチームトポロジーとは？（読書会の感想＆考察）
こんにちは。atama plusでスクラムマスターをしている河口です。みなさん、2021年12月1日に日本語版が発売されたチームトポロジーはもう読まれましたか？
先日、社内でチームトポロジー読書会を実施しました。atama plusの未来に向けた組織課題にもふれつつ、感想と考察をnoteに書いてみます。
チームトポロジーってなに？
チームトポロジーはコンウェイの法則で言われている認知負荷の観点から組織の分割方法、モデルについて書かれている本です。今回は本の内容についてはあまり触れないので、ご興味ある方は、他のまとめ記事を御覧ください。
・新刊『チームトポロジー』発売のお知らせ | Ryuzee.com
・「ちいとぽ」こと『Team Topologies』の翻訳（12月1日発売）を読んだ - こまぶろ
・Team Topologies(by Manuel Pais)のキーポイント
チームトポロジー読書会のきっかけ
atama plusも組織が急成長し、エンジニアも50人近くになりました。プロダクトアーキテクチャと開発チームをどういう構造にするのかを検討するフェーズに来ており、そんな折にアーキテクチャチームが読書会を企画しているのを見つけて相乗りしました。
読書会の進め方
atama plusではよく読書会をしており、社外の人に「どうやって読書会しているの？」と聞かれることも多いので今回の読書会の進め方を簡単にご紹介します。
今回は参加者が10人いたので、議論しやすいように2回に分けて実施しました。事前に各自がチームトポロジーを読んでmiro上に「学び」「疑問点」「チャレンジ」「つぶやき」を付箋で書き出しておきます。
読書会当日は2時間で特に触れたい付箋をきっかけに意見交換を行いました。
読書会当日に出た話題
読書会で議論したテーマの一部をご紹介します。
atama plusにおいて認知負荷が高いと感じた経験は？
前職との比較や、ソースコードレベルでの認知負荷が高い部分や、SREチームなど横断的なプラットフォームを見ているチームの認知負荷の高さの話などいろいろな観点でのatama plusにおける認知負荷の話題が出ました。
LeSS Hugeでのコミュニケーション負荷
現状のLeSS Huge体制ではAreaのPOが密にコミュニケーションをとっているので開発レベルで、Area間のコミュニケーション負荷はかかっていませんが、もしかすると実はプロダクトの全体感がどんどん見えなくなっている状況で、共同保有のコードに対するオーナーシップを持ちづらい状態になりつつあるのかもしれないという話になりました。
各スクラムチームの分類
atama plusには現在複数のスクラムチームが存在します。それぞれのチームがチームトポロジーのどの分類に当たるのかも意見交換しました。次にその考察を記載します。
atama plusの開発チーム体制の現状
atama plusの開発チーム体制を今回のチームトポロジーで紹介されているモデルを中心に僕なりに整理してみました。
①アプリチーム
現在、Areaを2つに分けて5つのチームのLeSS Huge体制で開発しています。ユーザー価値をDiscover〜Deliverまで一気通貫して開発しているストリームアラインドチームになります。
②模試チーム
atama＋事業とは別の新規プロダクトを作っているチームです。インフラ部分はSREチームと協力していますが、Discover〜Deliverまで実施するストリームアラインドチームです。
③アルゴリズムチーム
atama＋のAI部分を開発しており、ストリームアラインドチームの側面と、アプリチームにAPIを提供しているコンプリケイテッドサブシステムチームの側面がありそうです。
④SREチーム
インフラ部分、開発環境部分はプラットフォームチームの側面を持っており、一方でユーザーに対する信頼性を提供しているという観点でストリームアラインドチームの側面も持っています。
⑤アーキテクチャチーム
現在兼任者のみでアーキテクチャについて検討しているチームです。今回のチームトポロジーの分類だとシステム全体に対するエネイブリングチームになるのかなと思います。
⑥開発基盤チーム（※図に記載なし）
『開発者体験の向上』を目指して最近できたスクラムチームです。議論の余地はあると思いますが、チームトポロジーでいうとエネイブリングチームを目指していくチームになっていきそうです。
チームトポロジーでは、4つのチーム分類で書かれていますが、実際の組織においては、各チームがいろいろな役割を持っているので、単純に分類するのは難しいなと感じました。しかし、今後の組織拡大を見据えたときに、今の6チームがどのように分かれていくのかの示唆にはなったと思います。
チームトポロジー読書会を経て、atama plusの開発体制に対する示唆
開発組織を設計する上で、「事業戦略≒プロダクト戦略」という側面からのアプローチと、コンウェイの法則の「認知負荷≒チーム分割≒アーキテクチャ」という側面からの組織設計の両方が必要であると改めて感じました。
今までのatama plusは事業戦略の不確実性が高く、その中で開発組織をスケールさせるために、「LeSS」というフレームワークを活用して一定程度どういう課題でも対応できる組織設計をしてきました。
一方で、この1年間でメンバーが増えると同時に事業の解像度がだいぶ上がりました。またプロダクトもどんどん大きくなってきています。
その中で既存の体制を良い部分を活かしながら、場合によっては痛みを伴う変化を許容して、未来を考えることが大事になるフェーズだと思います。
今までの向こう3ヶ月、半年を見据えた組織変化への適応から、今後は向こう2年ぐらいを見据えたアーキテクチャ設計、組織設計を考えていくタイミングになってきたのだと思います。
atama plusにおけるチームトポロジーの進化過程のロードマップをひきつつ、小さく実験しながら、アーキテクチャ、組織を変えていく必要がありそうです。
チームトポロジー読書会に参加した個人的な感想
今回のチームトポロジー読書会によって、組織検討、アーキテクチャ検討の共通言語ができたので、その点で非常に有用だったと思います。
一方で、チームトポロジーは分業によって認知負荷軽減する前提にたって書かれていますが、技術プラクティス、良いアーキテクチャ、オンボーディング、社内コミュニティなどの活用によっても認知負荷を下げることもできそうだと感じました。
分業をあえてしない、LeSSなどのフレームワークは、様々なガイドを活用しながら、時間をかけて認知負荷を下げていくフレームワークだと思います。
時間軸を考慮して、『LeSSのようにあえて分業しない方法』と『チームトポロジーによる分業の方法』の両方の組み合わせが大切になりそうです。
まとめ
いかがだったでしょうか？
改めてatama plusの開発組織も次のフェーズに入ってきています。事業・組織の両面で成長していくためには今までのやり方にとらわれず、検証しながら新しいやり方も取り入れていくことが重要になってきます。
ミッション実現のためにまだまだお困りごとがたくさんあるのでぜひ力を貸してください！ご連絡お待ちしております。
また、atama plusでは各職種仲間を募集しておりますので、ご興味があればぜひお話しましょう！
最後までお読みいただきありがとうございました！
Twitterでの情報発信も始めました！atama plusの開発に関する発信を取りまとめてお届けします。フォローいただけたら幸いです。
いいなと思ったら応援しよう！
