チームトポロジーを用いたRettyプロダクト開発体制の解説 #ちいとぽ

マネージャーの常松です。 2021年12月1日にTeam Topologiesの翻訳 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (愛称 #ちいとぽ) が発売になりましたが、皆さんもう読まれましたか? この書籍には事前レビューから参加させていただいていたのですが、「出版されたら自社の開発体制を図にして話せると良いな」とずっと考えていました。ただタイミングを逸してしまい・・・ようやく筆をとったのが本記事です。

チームトポロジーとは

翻訳者の一人であるryuzeeさん始め、多くの方が既にまとめてくださっているのでそちらを参照ください。

チームトポロジーは、このコンウェイの法則を踏まえたチームファーストのアプローチです。 「チーム構造と組織構造を進化させて、望ましいアーキテクチャーを実現する」という逆コンウェイ戦略を実現するために、4つのチームタイプと3つのインタラクションモードを定めています。 それをもとにフローを最適化する組織を設計しようというのが肝です。

書籍は読めてないけど短く概要を知りたいという方は角谷さん(@kakutani)が翻訳されたQuick Reference Cardもおすすめです。

scrapbox.io

描いてみた & 解説

f:id:tune:20220228111331p:plain
2022年2月時点のRettyプロダクト開発 チームトポロジー

ということで描いてみたのが上図です。 TeamTopologies / Team-Shape-Templatesにいろいろなツール用のテンプレートが用意されており、今回はGoogleスライドのテンプレートを使いました。

Rettyでは2019年10月から大規模スクラム(LeSS : Large Scale Scrum)を取り入れており、バックログの優先順位に基づいて短く価値提供を行なっています。数ヶ月かかるようなプロジェクトも基本的にはなく、チームが集められたり解散させられたりということはありません。

チーム構成が変わる時は「新しく何かを始める(新規事業、SREの立ち上げなど)」か「チームメンバーの増減により分割・統合・入れ替えを行う方が開発しやすい状態となった」のいずれかかと思います。チームメンバーを入れ替える際も元のメンバーが過半数以上を占めるよう気を付けており、それぞれのチームがそれぞれの文化を育みながら長期間存続しています。

f:id:tune:20220212141233p:plain

基本はストリームアラインドチーム

大規模スクラムに含まれる機能開発チームは toC Web / toB Web / スマホアプリ の領域で5チームです。 2021年にサービス提供を始めたRettyOrderとアドテク(広告事業)チームは大規模スクラムの外で開発を行っています。

基本は5つのチームが単独で開発を完遂できるようになっていますが、アプリバックエンドをtoC Webチームが、RettyOrderの店舗向けAndoridアプリをスマホアプリチームが開発することがあるため、チーム間にXaaSの関係があります。

toB Web開発はセールスや代理店に事前周知が必要な大きめの開発物が多く、2チームが密に連携をとりながら開発に取り組んでいます。両者はコラボレーションの関係です。

インフラチームはストリームアラインドチームからの依頼ベースでインフラ設定を行ったり、サポートに入っており、XaaSの関係性となっています。デプロイはストリームアラインドチームの開発チームが主体です。また開発チームとインフラチームで協力してサービス・インフラ構成を見直したり、オンコール・障害対応にあたったりします。

プラットフォームよりの横串チームとしては他に「データ分析・データ基盤」「QA」もありますが、前者はセールスや企画部門との連携、後者はアプリなど特定チームのサポートが主となるため、今回の図からは簡略化のため除外しました。

SREチームを立ち上げ中

攻めのインフラ改善が継続的に行えるよう、2021年後半からSREチームを立ち上げようとしています。

SREチームが取り組む課題は長く残る技術課題や歴史的経緯がないと扱いが難しいものが多いため、技術部(イネーブリングチーム)が技術支援(ファシリテーション)に入ったり、開発を推し進める原動力となるようtoC Webチーム・インフラチームと密に連携(コラボレーション)して開発にあたっています。

トポロジー図を元に角谷さんと話したこと

トポロジー図を描いてはみたものの・・・

  • どう扱うと次の良いアクションにつなげられるんだっけ?
  • 普段から大きな問題や課題もそれほど感じてないんだけど、自分達の思い違いなのだろうか??

と疑問が浮かびました。

そこで先のQuick Reference Cardの翻訳を行なわれチームトポロジーに造詣が深い角谷さんにお声がけし、Retty VPoEの小迫含め3名でトポロジー図を元に1時間程度話してみました。 角谷さんとは実は組織面のアドバイザー(開発・企画・セールス含めたアジャイルな在り方の模索)を2021年秋からお願いしている関係があります。

XaaSはセルフサービスを目指す

インフラチームは複数のストリームアラインドチームとXaaSの関係がありますが、書籍で解説しているXaaSの関係性と比べると、今のSlack依頼ベースのコミュニケーションは受発注感があります。双方で問題に感じていることはないですが、XaaSの関係性は「自動で対応する仕組みを整える」などを念頭に置いており、インフラ周りの権限変更などはSlackコマンドなどの仕組みを構築し解決できるようにできると、省力化できて良いのかもしれません。

スマホアプリとWebで開発順序の依存関係がたまにある

toC Webチームとスマホアプリチームの間にバックエンドサーバーを開発してもらうXaaSの関係がありますが、バックエンドを待ってスマホアプリチームが開発に着手できないことが時々あります。いまは発生頻度も低く許容できる範疇だと考えていますが、スマホアプリ開発が加速し発生頻度が増えるとWeb/アプリを合わせた形のストリームアラインドチームとして見直すのが良いのかもしれません。

開発部門外とのコミュニケーションをどう扱うか

チームトポロジーは「開発チーム向け」と書籍でも明記されていますが、実際のプロダクト開発は企画やセールスなど関係者が複数いるのが当たり前かと思います。それ抜きにチームトポロジーで整理・改善を行なっても「開発だけの自己満足」の域を出ません。

  1. 開発の流れの起点に置く (図の一番左にいて見切れている状態と考える。)
  2. ストリームアラインドチームの中に含める (開発チームの一員としてコミュニケーションを取ると考える。)

といった案が上がりましたが、どちらも正直スッキリはしていません。 チームタイプとコミュニケーションパターンを類型化し、図にまとめて議論・整理するというパターンは有用そうなのですが、アレンジ案を思いついた方ぜひ教えてください。

ストリームアラインドチームに専門の役目を持たせるか

今のRettyではtoC Web / toB Web / スマホアプリとチームの持ち場が大まかに分かれていますが、チームごとの強み・得意領域は残しつつ、特定のチームしか触れない持ち場を作ることは減らそうとしています。チームトポロジーの書籍でも顧客提供価値に沿った形(フロー)に基づき、ストリームアラインドチームを作ることを提唱しています。つまり専門の役目を持たせる組織づくりといえます。

開発組織がもっと大きくなるとなんらかの分割は必要かも知れませんが、現時点では皆がプロダクト全体を気にかけるメリットの方が大きいと感じているため、このままでいこうと思います。

オンコール対応をフローとして描いておくと良いかも?

これは角谷さんからいただいたアドバイスです。 チームトポロジー図を描こうとすると普段の開発プロセスだけを対象に考えてしまいがちですが、オンコール対応(障害発生時)のような本来やるべきことをフローで図示すると新たに気がつくこともあるそうです。

こんなきれいなトポロジー図通りに本当に開発できているの?

と思いのあなた、ぜひMeetyでお話ししましょう!

meety.net

ストリームアラインドチームを中心に据えたデリバリーを意識したプロダクト開発に興味がある方、SRE/インフラチームで全社的な開発に取り組んでいきたい方、多くの採用ポジションを空けておりますのでぜひ一緒に働きましょう!!