こんにちは、タイミーのデータサイエンスグループでマネージャーをしている菊地です。
本記事では、タイミーのデータサイエンス組織が直面した「認知負荷」や「優先順位」の課題に対し、チームトポロジーの考え方を取り入れて、どのように体制を見直したかを紹介します。
具体的には、データサイエンティストをストリームアラインドチームから「コンプリケイティッド・サブシステムチーム」へと再配置した背景と、その後のチーム間連携を円滑にするための「プロトコル」の設計・運用についてお話しします。
はじめに
タイミーの開発組織ではチームトポロジーに基づいた組織運営を行っており、ストリームアラインドチーム、プラットフォームチーム、イネイブリングチーム、コンプリケイティッド・サブシステムチームといったチームタイプに分かれて、日々の開発業務を行っています。
チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計
データサイエンスを用いた機能開発の初期フェーズでは、その立ち上げを軌道に乗せるために、データサイエンティストがストリームアラインドチームに所属し、プロダクト開発と並走する体制をとっていました。データサイエンティストがドメイン知識を深く理解し、ビジネス課題に対して即応性の高い分析やモデル構築を行う必要があったからです。
しかし、事業が急成長し、プロダクトが大規模化・複雑化するとともに、サブシステムとして運用しうるものが一定程度できてくるにつれて、「ストリームアラインドチームにデータサイエンティストが同居する」体制の限界が見え始めてきました。
そこで、高度な専門性が求められる特定の領域（審査システムや推薦システムなど）において、データサイエンティストをストリームアラインドチームから切り出し、コンプリケイティッド・サブシステムチームとして再編成する組織リデザインを行いました。
以下では、その背景にあった具体的な課題と解決策、そして運用で定着しつつある具体的な連携プロトコルについて紹介します。
課題：ストリームアラインドチームにおけるデータサイエンティストの認知負荷と専門性のコンフリクト
以前まで特定のプロダクト領域では、データサイエンティストがストリームアラインドチームの一員として活動していました。この体制には「ドメイン知識の獲得」や「デリバリーのスピード」というメリットがあった一方で、運用を続ける中で以下のような課題が顕在化してきました。
1. 認知負荷の高まり
ストリームアラインドチームの取り組みは、ユーザーへの価値提供に集中し、高速にイテレーションを回すことが求められます。一方、高度なML/LLMシステムの開発・運用には、論文調査や実験設計、長期的な精度改善といった、通常の開発サイクルとは異なる時間軸と専門知識が必要です。
ストリームアラインドチームにおける日々のユーザーへの価値提供と高度なMLモデルの研究開発を、同時に同一チーム内で担うことは、脳のスイッチングコストが非常に高く、認知負荷の限界を超えつつありました。結果として、「機能は作れるが、モデルの精度改善やアーキテクチャの刷新に手が回らない」という状況が生まれ始めていました。
2. 優先順位の競合
ストリームアラインドチームは、その時々のプロダクトゴールに向かってバックログの優先順位を決定します。一方で、ML/LLMシステムには「一度作って終わり」ではなく、データ傾向の変化への追随や継続的な精度モニタリングといった恒常的な改善が不可欠です。しかし、こうしたタスクは直近のゴールには直接結びつかないことが多く、結果として構造的に優先順位を上げにくいという課題がありました。
例えば、MLモデルの定期的な再学習パイプラインの整備や、将来の施策に向けた技術検証（PoC）、論文調査などは、短期的にはユーザー価値に直結しにくいため、スプリントの中で後回しにされがちでした。さらには、正式なタスクとしてバックログに載せることを諦め、メンバーが個人的に時間を捻出して整備を行うといった「隠れた稼働」が発生してしまうこともありました。これにより、データサイエンティストの活動が見えにくくなったり、キャリア成長の機会が損なわれたり、技術的負債が蓄積するといった懸念がありました。
解決策：チームトポロジーに基づくコンプリケイティッド・サブシステムチームの組成
これらの課題を解決するため、チームトポロジーの概念におけるコンプリケイティッド・サブシステムチームとして、対象領域ごとに専門チームを新設しました。
コンプリケイティッド・サブシステムチームの役割は、「高度な専門知識を必要とする複雑なサブシステムの管理に責任を持ち、その複雑さを他のチームから隠蔽すること」です。
これにより、データサイエンティストはコンプリケイティッド・サブシステムチームに所属し、複雑なサブシステムの開発・運用に集中できるようになります。同時に、ストリームアラインドチームは「中身の複雑なロジック」を意識することなく、提供されたAPIを利用するだけで高度な機能をユーザーに届けることができるようになります。
Before
flowchart TB
subgraph SAT1 ["🔹 Stream-aligned Team"]
direction TB
DS1("📊 Data Scientist"):::ds
Others1("👥 Other Members<br>(PdM, Designer, Eng, Scrum Master, etc.)"):::others
end
%% Styles
classDef ds fill:#fff9c4,stroke:#fbc02d,color:black,stroke-width:2px,rx:5,ry:5
classDef others fill:#ffffff,stroke:#bdbdbd,color:black,stroke-width:1px,rx:5,ry:5
style SAT1 fill:#f8f9fa,stroke:#dee2e6,stroke-width:2px,rx:10,ry:10
After
flowchart TB
subgraph SAT2 ["🔹 Stream-aligned Team"]
direction TB
Members2("👥 Team Members<br>(PdM, Designer, Eng, Scrum Master, etc.)"):::others
end
subgraph CSub ["✨ Complicated Subsystem Team ✨"]
direction TB
DS2("📊 Data Scientist"):::ds
end
CSub == "API (X-as-a-Service)" ===> SAT2
%% Styles
classDef ds fill:#fff9c4,stroke:#fbc02d,color:black,stroke-width:4px,rx:10,ry:10
classDef others fill:#ffffff,stroke:#bdbdbd,color:black,stroke-width:1px,rx:5,ry:5
style SAT2 fill:#f8f9fa,stroke:#dee2e6,stroke-width:2px,rx:10,ry:10
style CSub fill:#fff3e0,stroke:#ef6c00,stroke-width:3px,stroke-dasharray: 5 5,rx:10,ry:10
linkStyle 0 stroke:#ef6c00,stroke-width:3px,color:#ef6c00
インタラクションモードとプロトコルの明文化
組織を分けることで最も懸念されるのが、「サイロ化」と「連携コストの増大」です。これを防ぐため、基本的にはX-as-a-Serviceモードを採用しつつ、状況に応じて コラボレーションモードを使い分ける運用としています。
基本方針：X-as-a-Service
日常的な開発・運用においては、コンプリケイティッド・サブシステムチームが提供するサービス（API、ドキュメント等）をストリームアラインドチームがセルフサービスで利用する形をとります。
ストリームアラインドチームとの連携境界における、コンプリケイティッド・サブシステムチームの主な責務は以下の通りです。
- 安定したAPIの提供と、SLA/SLOの維持。
- 専門的なロジックの隠蔽と、利用しやすいインターフェースの設計。
- ドキュメントの整備（ストリームアラインドチームが自律的に利用できるようにする）。
ストリームアラインドチームは、いちいちコンプリケイティッド・サブシステムチームに「これどうなってますか？」と確認することなく、APIドキュメントを参照して開発を進めることができ、開発スピードを維持できます。
もちろん、API仕様書だけを投げ合うのが非効率な場面（新規機能開発や大きな変更時など）では、同期的な会議や一時的なスクラムイベントへの参加などを通じて、柔軟にコラボレーションを行っています。基本は疎結合（X-as-a-Service）を保ちつつ、必要な時には密に連携できる柔軟性を持たせています。
プロトコルの明文化
「X-as-a-Service」や「コラボレーション」といったモードを定義しても、実際の現場では「このタスクはどっちの責務？」「今はどっちのモードで動くべき？」といった迷いが生じがちです。
そこで、これらの実行を補完する役割として、特に密接に関わっているストリームアラインドチームとコンプリケイティッド・サブシステムチームの間で「チーム間連携プロトコル」というドキュメントを作成し、合意形成を行いました。
このドキュメントには、主に以下のような内容を記載しています。
- 各チームのミッションと責務の定義: ストリームアラインドチームとコンプリケイティッド・サブシステムチームがそれぞれ何に責任を持つかを明記。
- 自律的に実行できる活動リスト: 連携や確認なしで進めて良いタスクを具体的にリスト化（例：公開API仕様内でのリファクタリングなど）。
- 連携が必要なケースとフロー: コミュニケーションが必要な具体的なトリガーと、その際の推奨連絡手段。
- エスカレーションパス: 解決しない場合の判断フロー。
こうした具体的な「期待値調整」をドキュメント化しておくことで、日々のコミュニケーションコストを削減し、迷いを減らすことができています。
おわりに
組織構造は、その時点でのビジネスフェーズと技術的な複雑さに応じて進化させる必要があります。かつてはデータサイエンス的な要素を含んだ機能開発を行うため、ストリームアラインドチームにデータサイエンティストが在籍する体制をとっていましたが、フェーズの変化に伴い、コンプリケイティッド・サブシステムチームとして切り出す形がより適した状態へと変わりました。
今回のリデザインにより、データサイエンティストはより専門性を発揮しやすく、ストリームアラインドチームはよりユーザー価値に向き合いやすい体制が整いつつあります。特に、データサイエンティストからは「技術的な深掘りがしやすくなった」「コンテキストスイッチが減った」という声が上がっており、組織としての健全性も向上しています。
この事例が、拡大するエンジニアリング組織におけるチーム設計の参考になれば幸いです。
We’re Hiring!
タイミーではデータサイエンティストをはじめ、一緒に働くメンバーを募集しています！
カジュアル面談も行なっておりますので、興味のある方はぜひお気軽にお申し込みください！
