チームトポロジーを取り入れ、スケールフェーズに合った組織構造に移行した話
これはUbie Engineers & Designers Advent Calendar 2022 11日目の記事です
こんにちは、Ubie(ユビー)株式会社のUbie Discoveryという組織で、ソフトウェアエンジニアとして働いている八木(@sys1yagi)です。
組織における50人、100人の壁の問題は、もはやありふれた話ですが、当然Ubieにおいてもこれらの問題に直面し、都度皆で奮闘して乗り越えていったり、現在進行系だったりします。
本エントリでは、私が所属する医療機関事業の組織において、チームトポロジーを導入し、スケールフェーズに向けたチーム構成に移行した話を紹介します。
1. チームトポロジーとは何か
チームトポロジーは、ソフトウェア開発において、高速なデリバリーを実現することを目的とした、組織設計とチームインタラクションのモデルを紹介する書籍で、2021年12月1日に日本語版が発売されました。
コンウェイの法則、逆コンウェイ戦略、コンテキスト境界、チームファースト思考などの基本的な考え方から始まり、4つのチームタイプと3つのインタラクションパターンを導入し、組織設計を動的に進化させていく方法を解説しています。
チームトポロジーを学ぶことで、現況の組織課題を言語化でき、次にどのようなステップを踏むべきかのヒントを得られます。
2. チームトポロジーを導入する動機
チームの状況
チームトポロジーを導入しようという話は、2022年の7月ごろに出始めました。当時は従業員が200人を超え、主要な事業領域が4つとなり、それぞれの領域で組織を形成して、「高速に仮説検証する」ということ以外にやるべきことのボリュームが加速度的に増加していました。
しかしその時点ではまだ「高速に仮説検証する」ことに特化した組織設計で、様々な問題が顕在化し始めていました。
顕在化した問題点
ここでは医療機関事業の組織において顕在化した問題をいくつか紹介します。
関係するシステムの数の増加し、変更容易性が低下した
1年前の2021年7月に比べるとプロダクトに関連するシステムの数が8個から16個と倍になっていました。施策や改善を行う場合に考えるべき変更や影響の範囲が広がり、認知負荷が増加していました。構造的に「高速に仮説検証する」ことが難しくなりつつありました。
チームの改廃が激しく、プロダクトに対する責務を網羅できなくなっていた
チームの組成は、3ヶ月ごとに立案するOKRに沿ってフォーカスチームを結成するスタイルを取っていました。スピーディに目標に向かって走ることができる一方で、フォーカスから外れた領域については手薄になってしまいます。事業の状況変化に合わせて様々な開発や検証をしていく中で、たくさんの機能が積み上がっていました。すでに検証できたことに関する機能群はフォーカスから外れることが多く、不具合があった際やユーザサポートが必要な際に、誰が責務を持っているかでボールが浮いてしまうことが増えていました。
運用観点での取り組みが薄く、上述の問題に歯止めが効かなくなってきていた
上述の問題は、ある程度根性でなんとかなります。実際に課題感を持つ個人が、システムの複雑性への対処や浮いた責務を拾うといった行動を起こし、これまではなんとかやりくりしてきました。しかし問題の解決速度より増加速度が上回り、限界が近づいていました。組織的に運用の観点を取り入れ、日々の営みに落とし込まないと、解決には難しい状況でした。
「高速に仮説検証する」ことに特化していた結果、グロースフェーズに向けて整えておくべき組織の構築が遅れており、結果的に高速な検証も、安定的な運用も難しい状態になっていたのでした。
チームトポロジーは、こうした問題の解決案として魅力的でした。特に書籍のP73「チームのアンチパターン」の項は多くのソフトウェアエンジニアが首肯する内容で、社内でチームトポロジーについて語りあう機会が増え始めました。
3. チームトポロジーを導入する
チームトポロジーを学ぶ
まずはソフトウェアエンジニアやデータエンジニア、機械学習エンジニア、SREなどが横断的に集まって読書感想会を開きました。書籍を購入して読むほかに、すでにいくつかの解りやすいまとめや事例などがあり、そういったものを参照したりしました。
読書感想会では、現状の組織全体における課題感やチームトポロジーの解釈、どういったものを取り入れられそうかなどを議論しました。各々が学びを得て、それぞれの領域でどういった活用ができそうか検討が始まりました。
チームトポロジーは「ちいとぽ」と略され、社内の用語集にも追加されています。
チームトポロジーを取り入る準備をする
医療機関事業の組織では、ソフトウェアエンジニアに続き、カスタマーサクセスや各チームのPO（プロダクトオーナー）や、BizDevの面々などもチームトポロジーについて学び始め、組織設計の課題について議論を始めました。
サポート、サクセス、セールス、検証のための開発などが、チームトポロジーによってどのような影響を受けるか、どのような組織構造だと良いのかなどについて原案を持ち込み合いながら、行ったり来たりしました。
ある程度解像度が上がったところで、新たな組織設計を推進するプロジェクトチームを結成しました。6~7名の小さなチームで、様々な職種のメンバーが集まりました。
ストリームアラインドチームを洗い出す
まずはじめに行ったのは、プロダクトが取り扱うストリームの特定でした。
チームトポロジーでは中心的なチームとしてストリームアラインドチームというものを定義しています。ストリームアラインドチームの定義は以下の通りです。
ストリームアラインドチームとは、価値のある単一の仕事のストリームに沿って働くチームのことだ。ストリームとは、仕事やサービスの場合もあるし、機能一式のこともあり、ユーザージャーニーやユーザーペルソナの1つのような場合もあるだろう。さらに、なるべくそのチームだけですばやく安全に顧客やユーザーに価値を届けられるように、チームに権限が委譲されている。他のチームへの仕事の引き継ぎは必要ないということだ。
パッと読むとなんとなくわかるようでいて、実際に定義をしてみようとすると抽象度の高さに手が止まります。私達もこのストリームの解釈を巡ってたくさんの議論をしました。既存のチームが持っている責務の範囲や、機能の多さや、その機能が実装してあるシステムの場所などがバイアスとなって思考を妨げていたのでした。
まずはそういった現状をすべて忘れて、業務フローやカスタマージャーニーを改めて整頓し、フローの境界はどこかなどを洗い出すところから始めました。結果的に7つのストリームを定義しました。その時点ではOKRにフォーカスしたチームが4つだったので、各ストリームでチームを結成するとおよそ175%の増加になります。
プラットフォームチーム、イネイブリングチーム、コンプリケイテッドサブシステムチームもある
医療機関事業にはストリームアラインドチームが7つありそうだとわかりました。しかしチームトポロジーでは4種類のチームを定義しています。残る3つのチームの定義は次の通りです。
プラットフォームチーム
プラットフォームチームの目的は、ストリームアラインドチームが自律的に仕事を届けられるようにすることである。内部サービスを提供することで、ストリームアラインドチームが下位のサービスを開発する必要性をなくし、認知負荷を下げる
イネイブリングチーム
特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フレームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案を行う
コンプリケイテッドサブシステムチーム
システムのなかでスペシャリストの知識が必要となるパーツを開発、保守する責任を持つ。ほとんどのチームメンバーがその分野のスペシャリストでなければ、理解や変更が難しいようなサブシステムを担当する
この定義に基づいて改めて洗い出すと次のようになりました。
全部で13チームとなりました。これは流石に現状からの乖離が激しいですが、理想形として認識を揃えられたのは良かったかなと思います。
現実に落とし込む
現状が4チームのところを、13チームにするというのは全く現実的ではないので、なんとか実運用が可能な形に落とし込む必要があります。
まずコンプリケイテッドサブシステムチームは実はすでに専門チームとして独立できていたので、全体からは除外しました。次にイネーブリングチームを、チームからロールに変えることにしました。チームを結成する余裕はないが、責務自体は持っておく必要があるので、人の単位でアサインし、必要に応じて活動するという形としました。これでまずは8チームまで減りました。
次にストリームアラインドチームの活動の濃淡について議論し、リソースをどこに寄せるかを話しました。理想としては全チームが2pizzaチームくらいのサイズで活動できると良いですが、無理やり結成しても兼任に次ぐ兼任となり、まともな活動は難しいです。その時点でのOKRや中期的な事業戦略を鑑みて優先度をつけることにしました。
これにより「休眠チーム」という概念が生まれ、それぞれの負担が爆発しないようにアサインを調整しました。2チームを「休眠チーム」とし、6チームがアクティブという形に落ち着きました。
目的と責務の範囲を明示する
概ね現実的なチーム構成が見えてきたところで、各チームの目的と責務の範囲の明示を行いました。
Ubie Discoveryでは、ホラクラシーを使って組織を構成しています。ホラクラシーではロールを作る際に、目的と責務などを定義して公開します。各ストリームアラインドチームをロールとして定義し、チームの目的と責務を明示しました。
責務は、ストリームに沿って価値をデリバリーする上で必要なすべてを織り込む形にしています。新規の開発の他に、システムの運用や、サポート、カスタマーサクセスに関連することなどもそれぞれのチームが持つことになります。
こうして、休眠チームを含む8つのチームを結成し、実際の活動を始めました。最初にチームトポロジーを学び始めた2022年7月からおよそ一ヶ月後の8月半ばに、それぞれのチームが動き出しました。
4. チームトポロジーの導入後
チームトポロジーを取り入れてから4ヶ月程度経過しました。解決できた課題、新たに出てきた課題と対応、まだ解決できていないことなどを紹介します。
導入後に解決できたこと
目的と責務を網羅し、ボールが落ちることがなくなった
業務フローやカスタマージャーニーを中心にストリームを定義したことで、プロダクト全体が覆われ、今まででは個人に頼っていたようなケースが、チームに落ちるようになりました。
もちろん最初から全ての範囲を網羅できていたわけではありません。責務を決定するフローチャートを作成し、どのチームが対応すべきか分からないケースが出てきたときは、チャートに沿って必ずどこかのストリームアラインドチームにたどり着けるようにしました。これによりボールが浮いてしまうことはなくなりました。
チーム構造が安定し、ナレッジを蓄積できるようになった
今までは四半期を跨ぐ際に、事業のOKRを定義し、それに沿ってチームの改廃を行っていました。このため以前存在していたチームのナレッジが雲散霧消し、後で苦労するといったことが起こっていました。ストリームアラインドチームを半永続的な存在として定義し、ドキュメントを置く場所を決め、ナレッジを貯めることで、中長期的に残しておくべきコンテキストを保存できるようになりました。これにより「特定の誰かしか知らない仕様」や「背景のよくわからない機能」などを減らし、属人性を下げられるようになりました。
中長期の目線でのタスクも開発に組み込めるようになった
チーム構造が安定したことで、ストリームにおけるシステムの中長期的な課題がクリアになりました。重要度や緊急度をレビューし、具体的な開発の日程に落とし込むことができるようになりました。今までは特定の領域に解像度の高い個人が「うわああ、これは大変だ早くなんとかしないとやばい！」と孤軍奮闘することが多かったですが、チームの課題として捕捉できるようになり、レビューをして優先度を決めることで、計画的な動きができるようになりました。
導入後に出てきた問題点と対策
運用タスクが激増し、開発リソースを圧迫。SLI/SLOを導入してバランスを取れるようにした
チームがサポートやシステム運用の面も持つようになったことで、最初はかなり運用タスクに忙殺される形となりました。もちろん重要な領域なのでリソースを充てるのは当然なのですが、しかしどれくらい充てるべきかをどう判断したらいいのか？という話になります。
そこで、それぞれのストリームでSLIを定義して計測・可視化し、SLOを定めてエラーバジェットを設けることで、開発と運用のリソースのバランスを取ることにしました。まだ定義して日が浅いので、かなり甘めの設定になっています。徐々にバジェット消費のバランスが良くなるように調整していく予定です。
事業観点でのチーム横断的な意思決定は範疇外だったので、別途横断的な意思決定をするロールを作った
チームトポロジーでは、開発チームに関する話が中心で、その外側との関わりについては軽く触れられている程度でした。ストリームアラインドチームは、事業全体を眺める視点は持っていないため、事業全体のマイルストーンを考え、それによってストリームの重要度の濃淡の変化を誰が考えるか、という点が浮いていました。
一般的には管掌役員だとか事業部長だとか執行役員だとかいった役職が存在するかと思いますが、Ubie Discoveryにはそういった役職は存在しません。そこでこの領域の責務を持つロールを作成し、チームを運用するサークルの上位に配置することにしました。また、チームトポロジーをベースとした開発運用組織の運用そのものを司るロールも設けました。
まだ解決できていないこと
システムのリアーキテクチャ
ストリームアラインドチームによって、独立してデリバリーできるべき領域はある程度分かってきましたが、具体的にアーキテクチャをそれに寄せるところまでは至っていません。リアーキテクチャは時間がかかるので、まずは理想像を模索して徐々に進めて行く予定です。
チーム数に対して人が足りていない
休眠などの概念を設けてなんとかやりくりできる体制はできましたが、とはいえ人数が不足しています。現在は大抵の人がチームを兼任していて多忙となっています。こちらは事業計画と人員計画に依存するので少しずつ改善できればと考えています。
インタラクションのパターンはまだ使いこなせていない
チームトポロジーが定義する4つのチームについては、取り入れることができたかなと思うのですが、3つのインタラクションパターンについてはまだ明確には使いこなせていません。基本的に全員が近い位置に居るので、密に連携するというのが基本的な動き方となっています。ゆくゆくはX as a Serviceなどの疎な連携ができるようになっていきたいと考えています。
チーム構造の更新の方針はまだできていない
最初に定義したストリームが未来永劫同じだとは考えていません。しかし、ではどのようにストリームの形を見直すべきか？についてはまだ明確な方針が見い出せていません。とりあえずコンテキストマップを書いて、定期的に更新することで歪が見えたりしないか、ということで図を書いたりしてみていますが、まだチームの改廃は一度も行っていません。この辺りは動きがゆっくりだと思うので、3ヶ月単位で見直すなどしながら忘れないようにしよう、というのが現在の方針となっています。
5. おわりに
Ubie Discoveryでチームトポロジーを取り入れ、スケールフェーズに合った組織構造に移行した話を紹介しました。似たような課題を抱えていたり、組織が大きくなってきて今後どのような構造にしていくといいか迷っている、といった場合に、ひとつの事例としてお役に立てれば幸いです。
Ubie Discoveryではソフトウェアエンジニアをはじめ、様々な職種を募集しています。
まだまだカオスな状況で、幾多の困難を乗り越えなければならないですが、そんなエキサイティングな環境に興味がある方はぜひお声がけください。