Header image

クラッソーネの開発者がエンジニアリングに関することもそうでないことも綴っています!

『チームトポロジー』から学んだ組織設計 #ちいとぽ

『チームトポロジー』から学んだ組織設計 #ちいとぽ

こんにちは。プロダクトマネージャーの田原です。
社内のSlackに社員の誕生日と入社記念日を通知する仕組みを作ったところ、各方面から割と好評なようで嬉しいです。
https://twitter.com/shogocat/status/1485925356070924288

この度、話題の『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』を読みました。

https://www.amazon.co.jp/dp/4820729632/

(アトラクタ様のプレゼント企画にて御本をいただきました。ありがとうございます!)

『チームトポロジー』の紹介

チームトポロジーについては本書訳者の吉羽さんの【資料公開】30分で分かった気になるチームトポロジーその講演の様子を見ていただくと概要をすぐに掴めるのでおすすめです。変化が激しく正解の見えないソフトウェア開発において、チームが適切に機能するためのモデルを示しています。

本書で語られている4つのチームタイプと3つのインタラクションモードは、今後組織設計を語る上での共通言語として覚えておくとよいでしょう。

4つのチームタイプと3つのインタラクションモード

4つのチームタイプ

ソフトウェアシステムの開発と運用に必要なのは次の4つのチームタイプのみ。

  • ストリームアラインドチーム:ビジネスの主な変更フローに沿って配置されるチーム。
  • プラットフォームチーム:下位のプラットフォームを扱うチームで、ストリームアラインドチームのデリバリーを助ける。
  • イネイブリングチーム:転換期や学習期に、他のチームがソフトウェアを導入したり変更したりするのを助ける。
  • コンプリケイテッド・サブシステムチーム:ストリームアラインドチームやプラットフォームチームが扱うには複雑すぎるサブシステムを扱うためのチーム。

これらに該当しないチームタイプは不要である、と述べられています。

3つのインタラクションモード

チーム間のインタラクションモードは以下の3種類のみ。

  • コラボレーションモード:特に新しい技術やアプローチを探索している間、2つのチームがゴールを共有して一緒に働く。
  • X-as-a-Serviceモード:あるチームが、別のチームが提供する何かを利用する(API、ツール、ソフトウェア製品全体など)。コラボレーションは最小限。
  • ファシリテーションモード:あるチーム(通常はイネイブリングチーム)が、新しいアプローチの学習と適用を促すため、他のチームをファシリテーションする。

インタラクションモードもまた、上記に該当しない場合は無駄であり、チームの責任境界や目的が適切に割り当てられていないことを意味すると述べられています。

クラッソーネのソフトウェア開発組織体制の可視化

チームトポロジーの用語を使ってクラッソーネのソフトウェア開発組織体制を可視化してみました。

2021年1月時点の組織体制
2021年1月時点ではストリームアラインドチーム1チームとコンプリケイテッド・サブシステムチーム1チームの構成でした。

機械学習を使ったAI予想金額について別チームに切り出して動いていて、かつX-as-a-Serviceモードの関係性になっていたおかげで認知負荷の軽減に寄与していました。
ただ、人手不足もありWebアプリケーション開発もインフラ周りもすべて1チームでこなしていたのはかなり負担になっていました。

2022年1月時点の組織体制
その1年後の様子は上の図の通りです。
新たにSREチームが発足しました。発足当初はコラボレーションモードで密に連携しながら協働していましたが、その後は徐々に仕組みが整うにつれてX-as-a-Serviceモードへと移行していきました。おかげでWebアプリケーション開発を担当するメンバーの認知負荷が大幅に軽減されました。

現状の課題から考えた理想の組織体制イメージ

チームトポロジーを読む中で、現状の組織体制には大きく2つの課題があるのではと感じました。

1つ目の課題は、まだまだ認知負荷が高い点です。
ストリームアラインドチームにおいて、申し込み完了時点を節理面として2つに分けるとさらにチームが動きやすくなりそうです。
また、マッチングロジックは位置情報や希望条件など複雑な仕様となっているため、コンプリケイテッド・サブシステムチームとして1チーム作った方が良さそうです。

図に反映すると次のとおりです。
組織体制の理想型

2つ目の課題は、ストリームアラインドチームとプラットフォームチームの線引きが曖昧な点です。
組織が成果を出すために、どのチームがどこまで責任を持って動くかは明確にすべきです。
線引きが決まるまではコラボレーションモードで連携する必要があるのかもしれないと思いました。

今後に向けて

まずはチームトポロジーの内容をチーム内でシェアし、組織の形について議論していくべきだと感じました。
現状はコンパクトな組織体制でなんとか回っている部分も、今後プロダクトや組織がスケールしたときを見据えてチームファーストで考えるべきですね。

そして、チームの認知負荷を下げる取り組みとして、コードもアーキテクチャも整理していく必要があると感じました。
リファクタリングはどうしても後回しになりがちですが、チームとして安心して手を加えていくために必要だと再認識しました。

最後に

組織論についてもっと学んでいきたいと考えさせられる一冊でした。
組織設計に興味がある方、ぜひクラッソーネで一緒に働きませんか。

https://www.crassone.co.jp/recruit/engineer/


起業、エンジニア職、マーケティング職、新規事業立ち上げを経て、現在はクラッソーネでプロダクトマネージャーをしています。ねことスプラトゥーンとNotionが好き。