本記事は、 Timee Advent Calendar 2024 の 12/22 公開分の記事になります。
はじめに
株式会社タイミーでVPoEをつとめております、赤澤 a.k.a chango（@go0517go）です！
2024年2月に私がタイミーにジョインして以来、タイミーのプロダクト開発組織全体で適用・実践している「チームトポロジー」について、開発生産性Conference 2024をはじめ、様々な場で関連するトピックをお話しする機会がありました。
そういった場でいただく反応やご相談の中に、「タイミーはチームトポロジーを適用できる組織規模で羨ましい」「うちは開発組織を立ち上げてこれから組織をグロースしていくタイミングなので、まだチームトポロジーは取り入れていない」といったお声がいくつかいただきました。
確かに、チームトポロジーは認知負荷への対処方法などを例にとっても、一定以上の規模や複雑性を持つプロダクト開発組織で効果が顕著に現れやすいフレームワークです。しかし、「チームトポロジーを取り入れる＝定義された全てのチームタイプを組織内に揃えなければならない」というわけでは決してありません。また、前職のユーザベース、そして現職のタイミーでの経験を通じて、チームトポロジーは今後の事業・組織の成長期に生じる混乱や生産性低下を軽減するための“備え”として非常に有益な概念であると実感しています。
このアドベントカレンダーの記事では、そうしたプロダクト開発組織の立ち上げ期や成長期におけるチームトポロジーに対する誤解を解き、組織の初期段階からチームトポロジーを活用するためのTIPSについて書きたいと思います。
前提：チームトポロジーとは？
この記事の前提となるチームトポロジー自体の説明は省略させていただきますが、当該書籍自体はもちろんのこと、本書の共訳者である吉羽 龍太郎（@ryuzee）さんの記事や、弊社CTOの山口（@ZIGOROu）や私の開発生産性Conferenceでの登壇資料などもご参照ください。
- 【資料公開】30分で分かった気になるチームトポロジー（吉羽龍太郎@ryuzee）
- 組織をスケールさせるための Four Keys とチームトポロジー（山口徹@ZIGOROu）
- 実践チームトポロジー：プラットフォーム性とイネーブリング性の戦略（赤澤剛@chango）
組織規模とフェーズにおけるチームトポロジーへの誤解
前述のような場でいただいたご質問やご相談を、規模やフェーズに関する誤解として整理すると、概ね以下の点に集約されると考えています。
- エンジニアリング組織が立ち上げ期で小規模なため、チームトポロジーを適用できない（と考えている）。
- ストリームアラインドチーム以外のチームタイプ、特にイネーブリングチームやプラットフォームチームを検討できるほどの規模や余裕がない（と考えている）。
冒頭でも記載した通り、チームトポロジーは一定の規模や複雑性を有するプロダクト開発組織で、その効果がより顕著に現れるフレームワークです。しかし、「一定の組織規模がなければチームトポロジーを取り入れられない」と解釈することは本質的ではありません。また、4つのチームタイプ（ストリームアラインド、プラットフォーム、イネーブリング、コンプリケイティッド・サブシステム）を全て明確に揃えることが、チームトポロジーの適用を意味するわけでもありません。
むしろ、組織がまだ小規模な段階から、将来的に必要となるチームの性質を内包しつつ、ストリームアラインドチームを中心に据えた思考で価値創出に集中することこそが、チームトポロジーの有用性を最大限に活かす鍵だと考えています。
参考：チームトポロジーで表現したタイミーのプロダクト開発組織
備えとしてのチームトポロジー
「チームトポロジーが適切に実施できる組織規模で羨ましい！」と言っていただいたことがあり、非常にありがたくも恐縮なのですが、実際のところ私の認識では、一定の規模になったからチームトポロジーが実践できるようになったのではなく、一定の規模と複雑性でも顧客への価値提供を継続強化するために、チームトポロジーなどを取り込む必要性が生じた結果、実践せざるを得なくなったというのが正しい表現かと考えています（私自身は前職・現職を通じてチームトポロジーが好きで、決して否定的な意図はないことをお伝えしておきます）。
顧客価値とプロダクトに向き合い、主に機能開発をリードするストリームアラインドチームのみでビジネス要求に十分応えられるうちは、わざわざ複雑なチーム構造や追加の支援チームを設ける必要はありません。組織がまだ比較的シンプルな状態で、エンジニアリングやオペレーション、デリバリープロセスに関わる領域が一つのチームで把握できる範囲に収まっているのであれば、そのまま突き進んで問題はないでしょう。むしろ、その段階で「チームトポロジーを取り入れなければ」「無理に他チームを設置しなければ」と考えてしまうと、まだ不要な段階で組織構造の複雑化や権限移譲のコストが増大し、スピードや柔軟性を損ねる可能性があります。
問題は、プロダクトや組織が成長し、技術的・ビジネス的な複雑性が増大したときに表面化します。たとえば、以下のようなケースが想定されます。
ストリームアラインドチームの責務や負荷が増大
当初は1つ、あるいは少数のストリームアラインドチームでエンドツーエンドの開発・運用が可能だったが、新機能の追加や顧客数の増加、利用技術の多様化によって、本来集中すべき領域以外への対応（インフラ構築、技術調査、セキュリティ対応など）が増え、コア業務に影響が出始める。
領域の専門性が著しく向上
ストリームアラインドチームが扱う技術スタックやドメインが増え、メンバー全員がすべてを理解し追従することが難しくなっている。高度な機械学習アルゴリズムや極めて複雑なインフラ設定、厳格な法規制対応が求められるセキュリティ領域など、専門性を強く求められる分野が増え、従来の体制では対応しきれなくなる。
新技術・新手法の導入が困難
担当範囲の拡大に伴い、各ストリームアラインドチームが自前で新技術を調査・学習・導入することが難しくなり、新たなスキルやプラクティスの普及が停滞する。
共通基盤整備の必要性
アプリケーションやサービス群が増え、それぞれがインフラやCI/CDパイプラインを独自に整える状況が続くと、重複した作業や不整合が発生し、共通基盤・共通サービスを整備するチームの必要性が高まってくる。
重要なのは、これらのチームタイプの追加や新たなトポロジーは、これまで維持できていた単純性が崩れつつある状態を補完するために必要となるもので、組織規模が大きくなったからといって自動的に投入されるべきものではないという点です。あくまでも顧客への価値提供を止めない、もしくは加速させるための“備え”として、チームトポロジーを「引き出し」に用意しておくという発想が求められます。
言い換えれば、今はまだモノリシックなチーム構造で回せているのなら、それは望ましい状態です。同時に、将来的な成長過程で複雑性が増し、上記のような課題に直面する可能性を見越して「いざ必要になったとき、どう変化できるか」「どのようなチーム間関係を設計すれば、スケール時にも価値提供を継続できるか」といったシナリオを事前に想定しておくことが、長期的な競争力や組織の持続可能性を高める鍵となるのです。
グロース期の組織への段階的なチームトポロジーの適用
ここまでのパートで、発生しうる技術的・組織的な「備え」としてチームトポロジーを活用する方針について記載しましたが、後半ではエンジニアリング組織の立ち上げから拡大していくフェーズにおいてどう段階的に適用してきたか、そしてその際の留意事項や反省点についても書きたいと思います。
チーム組成のトリガーを見極める
これは前職でエンジニアリング組織を立ち上げ、人数がおおよそ30名を超えた段階までの話ですが、チームトポロジーの適用、特にイネーブリングチームやプラットフォームチームをどのタイミングで組成するかについては、あらかじめトリガー（条件）を設けていました。
わかりやすい例として、イネーブリング的支援とプラットフォーム基盤整備の両方を担うSREチームを挙げてみます。以下は、覚えている範囲で抽出した定性的な条件例です。
- 複数のバリューストリームが生まれ、共通的な信頼性向上施策（CI/CDパイプラインの標準化、モニタリング基盤の強化、インシデントレスポンス手順の標準化）が求められる段階になっている。
- 利用ユーザ数やトランザクション量が増加し、現行体制下でSLO/SLAを維持するための継続的改善・強化が不可欠になっている。結果として、ストリームアラインドチームが本来の機能開発領域以外のシステム運用、トラブルシューティング、パフォーマンス改善などに多くの時間を割く状態が生じている。
- 組織内に、信頼性向上やオペレーション自動化に強い関心を持つエンジニアが育ちつつあり、共通基盤整備やシステム品質改善に特化して注力できる人材が揃ってきた。
- SREチーム組成後、仮にSREチームメンバーが一時的に不在であっても、ストリームアラインドチームのメンバーのみでプロダクトの継続的デリバリーが（1や2のような課題を抱えつつも）自走可能な状態である。
事業やプロダクト面では1や2が特に重要な判断軸となりますが、私自身がSREチーム組成の可否を見極める上で“ノックアウトファクター”と捉えていたのは、4の条件でした。過去に別の組織で、CI/CDやOps領域においてSREチームへの依存が過度に高まり、ストリームアラインドチームが自前で運用しきれない状況に直面した経験がありました。その反省から、「顧客への価値提供をストリームアラインドチームが自走完結できること」を前提とし、その状態を強化・加速するために「Center of Practice」としてSREチームが存在する、という関係性を実現できることが、SREチームを組成する上での重要な前提条件、すなわちトリガーだったのです。
組成に備えてチームメンバーの志向を理解しておく
開発生産性Conference 2024の発表では、
- イネイブリングやプラットフォームを「性質」として捉える。
- タイミーにおいては、イネイブリングチームやプラットフォームチームを定義しつつも、内部ではQA領域、SREおよびプラットフォームエンジニアリング領域を中心に、イネイブリング性とプラットフォーム性の両面を兼ね備えたチームが存在している（メインの性質がそのチームタイプとなる）。
といった点に触れました。セッションの際には言及しませんでしたが、こうした性質や振る舞いは、当然ながら各メンバーにも志向や特性として内在しています。そして、ここでは「イネイブリング志向」や「プラットフォーム志向」と呼べる個々人の志向は、キャリア開発の観点も含め、チーム組成において重要な判断材料としています。
エンジニアにとって、「仕組みや方法によって再現性を高める」「自分以外の人でも運用可能にする」といった点は、共通して大切にされる価値観だと私自身も考えています。ただ、その中でも特に、インフラやプラットフォーム領域に強みと志向を持ち、複数のプロダクトに対して共通基盤の整備や最適化を行うことに喜びを感じるエンジニアもいます。
チームトポロジーで提唱される「タイプ」や「モード」はあくまでフレームワークであり、最終的には「誰が、どのような価値創出に楽しさや挑戦を感じるのか」という個々の志向やキャリアパスと、組織が目指すチーム構造を結びつけることで、中長期的に継続的な顧客価値提供が可能な組織を形作ることができると考えています。
また、私の過去の経験からの反省点として、イネイブリングチームやプラットフォームチームを立ち上げる際には、ストリームアラインドチームでの所属経験を一定割合以上持つ人材をアサインすることが重要だと強く感じています。そうすることで、ドメイン知識や現場課題の理解度が高まり、表層的なアドバイスではなく、実質的なサポートが可能になります。
具体的な防止策として、タイミーでは次のような点に留意して取り組んでいます。
- イネイブリングチームは、ファシリテーションモードでの支援だけでなく、コラボレーションモードを意図的に発生させ、ストリームアラインドチーム内で密に課題解決を行う。
- 転職入社のエンジニアにイネイブリングやプラットフォーム領域への強い志向がある場合でも、まずはストリームアラインドチームで経験を積んでもらい、現場への理解を深めた上で、本人のキャリア意向と合意を得た上でイネイブリングまたはプラットフォーム領域へシフトしていく。
これらのトピックについては、開発生産性Conference 2024の中でも各領域の事例を交えて言及しています。ご興味がありましたら、ぜひ以下の資料をご覧ください。
開発生産性Conference 2024：組織全体の成長や成熟の過程でインタラクションモードを変化させている事例
最後に
本記事で述べた立ち上げ期でのチームトポロジーの適用は、択一的な正解を示唆するものでは全くありません。その上で私自身の経験として、チームトポロジーを組織の立ち上げ期から理解し、今後発生しうる課題と共に適用パターンを思考し始めることが非常に有用だと感じています。
ストリームアラインドチーム以外のチームタイプが組成されていることが重要なのではなく、自組織が携わる事業やプロダクトの特性を踏まえた上で、今後の課題と組織的な対応策をチームトポロジーに従って想定しておくことがチームトポロジーの組織適用の第一歩だと考えています。
これを読んでくださった皆様に、事例の1つとして参考になる部分があれば幸いでございます。
