1. はじめに
こんにちは。株式会社タイミーのデータサイエンスグループ（以下、DSG）でグループマネージャーを務めている菊地です。
タイミーでは「『はたらく』を通じて人生の可能性を広げるインフラをつくる」というミッションを掲げ、日々膨大なマッチングデータや行動データを活用して、プロダクトの価値向上や意思決定の高度化に取り組んでいます。
ありがたいことに、最近は採用活動を通じて多くの方とカジュアル面談でお話しする機会が増えています。その中で、非常によくいただくのが「DSGはどのような組織体制で、どのようにコミュニケーションを取りながら組織運営しているんですか？」というご質問です。
これまでは面談の場で個別にお伝えしてきましたが、私たちの組織も拡大し、フェーズに合わせて柔軟に形を変えてきました。そこで今回、改めてタイミーDSGの現在の「組織のカタチ」を言語化し、候補者の皆さんに私たちのチームの現在地を詳しくお伝えしたいと思い、この記事を書くことにしました。
私たちの組織運営のキーワードは、「認知負荷の低減」と「自律性の最大化」です。
かつては全員で一つのスクラムを組んでいましたが、現在は「仮想チーム」という形態をとり、各チームが自律的に開発サイクルを回しています。本記事では、チームトポロジーの考え方を取り入れた組織構造から、具体的な開発フロー、そしてグループ内の文化までご紹介します。
2. 組織の変遷：なぜ「仮想チーム」へと移行したのか
全員ですべてを把握していた「単一スクラム」時代
以前、まだグループの人数が少なかった頃は、DSG全体で一つのスクラムチームとして活動していました。当時は全員がすべての取り組みの状況を把握し、毎日のデイリースクラムで情報を共有し、全員でリファインメント（バックログの精査）を行っていました。このスタイルは、情報の透明性が高く、誰が何をやっているかが一目でわかるという大きなメリットがありました。
急成長に伴う「認知負荷」の限界
しかし、タイミーというプロダクトの成長に合わせ、DSGが解決すべき課題は急速に増え、かつ多様化していきました。
- 担当するドメインの拡大
- MLOps基盤の高度化と、それに伴う専門知識の深化
- ステークホルダーの増加
こうした状況下で、一つの大きなスクラムを維持しようとすると、メンバー一人ひとりが追わなければならない情報量が爆発的に増えていきました。例えば、あるデータサイエンティストにとっては、自分が担当していない領域の細かい仕様検討を延々と聞き続けなければならず、逆にMLOpsエンジニアにとっては、すべてのモデルの数理的な背景まで深く理解し続けなければならない…といった具合です。
これが、本記事のキーワードである「認知負荷」が限界に達した瞬間でした。
「仮想チーム」とチームトポロジーの導入
この課題を解決するために私たちが取り入れたのが、実組織の中をいくつかの「仮想チーム」に分割する運用です。
「実組織」としては一つのDSGですが、日々の活動（スクラム）は各仮想チーム（Squad）単位で行います。この体制を設計する際、書籍「」の考え方を参考にしました。
チームトポロジーとは、チームの「認知負荷」を考慮して組織とシステム構造を整合させ、高速な価値提供を目指す組織論です。私たちはこれに基づき、チームの性質を以下のように定義しました。
MLOpsエンジニア主体のチーム：プラットフォームチーム
DSを中心とした多様な利用者が、ML/LLMを用いた価値提供に集中できるように、機械学習基盤やLLM基盤、CI/CD、MLミドルウェアなどの「専門性を最大化するための共通基盤」を提供する役割。
データサイエンティスト主体のチーム：コンプリケイティッド・サブシステム・チーム
推薦・マッチングやモデレーションといった特定のドメインに責任を持ち、高度なサブシステムの開発やビジネス上の複雑な課題解決を担う役割。
このように役割とチームを明確に切り分けることで、メンバーは「今自分が注力すべき領域」に認知的リソースを集中することができるようになりました。
DSG内の仮想チーム関係図
%%{init: {'theme': 'base', 'themeVariables': {
'fontFamily': 'arial',
'primaryColor': '#ffffff',
'edgeLabelBackground':'#ffffff',
'tertiaryColor': '#f8fafc'
}}}%%
graph BT
%% --- スタイル定義 ---
classDef platform fill:#2563eb,stroke:#1e40af,stroke-width:2px,color:#ffffff,rx:10,ry:10,font-size:15px,font-weight:bold;
classDef css fill:#f97316,stroke:#c2410c,stroke-width:2px,color:#ffffff,rx:10,ry:10,font-size:15px,font-weight:bold;
classDef dsgContainer fill:#f1f5f9,stroke:#3b82f6,stroke-width:3px,stroke-dasharray: 6 4,color:#1e40af,font-weight:bold,font-size:16px;
%% --- DSG内部の組織構造 ---
subgraph DSG ["DSG (Virtual Organization Structure)"]
direction BT
%% 上層：価値創出の主体
CSS["コンプリケイティッド<br/>サブシステムチーム<br/>(Squads)"]:::css
%% 下層：強固な基盤
MLP["ML基盤チーム<br/>(Platform Team)"]:::platform
%% 供給フロー（強力な支援）
MLP ====>|専門性を最大化するための共通基盤を提供| CSS
end
%% スタイルの適用
class DSG dsgContainer
linkStyle 0 stroke:#3b82f6,stroke-width:4px;
関連記事として、データサイエンティストのストリームアラインドチームからコンプリケイティッド・サブシステムチームへの配置変更の変遷は、以下の記事をご参照いただければと思います。
3. 現場の意思決定を加速させる「Squad Lead」
仮想チーム（Squad）は、特定のプロジェクトを遂行するためだけのタスクフォースではなく、担当ドメインの成果に対して中長期的に責任を持つ半永久的な組織として機能しています。
このSquadにおいて、現場の自律性を支えているのがDSG独自の役割である「Squad Lead（SL）」です。SLは、データサイエンティストやMLOpsエンジニアが本来の業務と兼務する形で担う「内部的なロール」です。
GMとSLの役割分担
私（グループマネージャー：GM）とSLは、「組織の土台作り」と「ドメインの戦略実行」という軸で役割を分担しています。
- GM：採用・配置・評価・キャリア成長など、「ヒト・モノ・カネ」といった組織基盤の最適化。
- SL：担当ドメインにおける「コト（プロダクト・課題）」の解決。ロードマップ策定、短期〜中期の成果創出、ステークホルダーとの合意形成に責任を持つ。
現場のコンテキストを一番理解しているメンバーがSLとして意思決定を主導し、私はそれを組織的な側面から全力でサポートする。この補完関係を築くことで、マネージャーがボトルネックにならないスピーディな開発体制を実現しています。また、あえて「仮想」という柔軟な形にしていることで、メンバーがリーダーシップを経験する機会を広げ、事業状況に合わせた機動的なチーム編成を可能にしています。
4. 専門性を最大化するプラットフォームと開発フロー
では、具体的にどのようにプロダクト開発が進められているのでしょうか。ここからは、MLOpsエンジニアとデータサイエンティストの連携に焦点を当ててご紹介します。
MLOpsエンジニアが整える、専門性に集中するための共通基盤
MLOpsエンジニアは、いわゆるプラットフォームチームとして、利用者が本来の役割に集中できるよう、共通の開発環境やデプロイフローを整えています。
利用者の中心はDSですが、領域によってはデータアナリストやプロダクトエンジニアも想定ユーザーに含まれます。Google Cloudをメイン基盤とし、モノリポ構成でのディレクトリ設計やTerraformによる構成管理、CI/CDスクリプトの整備、さらにLLM基盤の構築やMLミドルウェアの導入・運用までを幅広く担当します。これにより、インフラやデプロイの複雑さを意識せずとも、安全かつ高速に価値を送り出せる仕組みが整っています。
大まかな機械学習基盤の構成は下記ページの「Architecture」セクションをご覧いただければと思います。
データサイエンティストによる一気通貫の価値創出
データサイエンティストはこの基盤を使い倒し、ビジネス課題の発見から解決までを一気通貫で担います。
- 上流工程：課題設定、問題発見、ステークホルダーとの期待値調整。
- 開発・実装：分析、PoC（LLM活用含む）、本番環境へのエンジニアリング。
- 検証・改善：デプロイ後のABテスト、効果検証、それに基づく改善サイクルの実行。
整備されたプラットフォーム上で、Dev / Stg / Prod の各環境を使い分けながら高速にサイクルを回しています。このように、基盤を支えるスペシャリストと、事業価値を創出するスペシャリストが背中を預け合える関係性が、タイミーDSGの強みです。
5. チーム運営とシナジーを生む仕組み
仮想チームとして分かれて活動しつつも、グループ全体としての知見の共有や、職種を越えた連携を支えるための「場」や「仕組み」を大切にしています。
MLOpsとDSを繋ぐフィードバックループ
MLOpsエンジニア主体のプラットフォームチームは、2週間のスプリントで動いています。スプリントの終わりには、基盤の利用者（主にDS）に向けた「ML基盤アップデート共有会」を実施しています。
ここでは新機能の周知だけでなく、利用者からの改善リクエストや困りごとを直接受け付けるスプリントレビューのような役割も果たしています。「作って終わり」ではなく、常に利用者の声を聞きながら基盤をブラッシュアップしていく。この対話の仕組みこそが、DSG内での高い開発体験を支えています。
AIも駆使して刺激を与え合う「学び」の習慣
私たちは技術的な研鑽も欠かしませんが、その「継続しやすさ」にもこだわっています。DSG内では定期的に勉強会を開催していますが、現在は隔週1時間で「毎回3,4名が10〜15分ずつ発表する」というスタイルをとっています。
意識しているポイントとしては、発表のハードルを極限まで下げていることです。発表時間を短くすることで、トピックの論点を端的にまとめやすくし、発表のハードルも下げています。発表資料の作成にはNotion AIやNotebookLMといったツールを積極的に活用し、準備の省力化を推奨しています。これにより「資料作りに追われてアウトプットが億劫になる」のを防ぎ、ハイスピードで知見を循環させることに挑戦しています。
また、グループ内に閉じず、他部署のエンジニアを交えた合同輪読会を行っているチームもあり、組織を越えて互いに高め合う文化が根付いています。
制度を活用した「チームビルディング」
仕事以外での繋がりも、心理的安全性を高める重要な要素です。タイミーにはチームビルディング費用の補助が出る全社的な福利厚生制度があり、これを活用して毎月、部署内外のメンバーと交流（飲み会や親睦会）を行っています。
部署内の結束を深める月もあれば、他部署のメンバーと交流する月もあり、こうした定期的な交流の場が「困った時にいつでも相談できる」関係性の土台になっています。
6. おわりに
今回は、タイミーのデータサイエンスグループ（DSG）がどのような組織構造で、どのような思想を持って日々開発・運用を行っているのかをご紹介しました。
私たちが「仮想チーム」や「Squad Lead（SL）」という運用に行き着いたのは、単に組織を管理するためではなく、「メンバー一人ひとりが認知負荷に振り回されず、本来の専門性を最大限に発揮して、プロダクトに価値を届けられる環境」を作りたかったからです。
組織の形は、プロダクトのフェーズや課題に合わせて柔軟に変わっていくべきものです。今回ご紹介した体制も現在の「最適解」ではありますが、今後さらに組織が拡大していく中で、私たちはまた新しい壁にぶつかり、形を変え続けていくはずです。そうした変化を楽しみながら、仕組みそのものをアップデートしていけることも、今のタイミーDSGの面白さだと感じています。
この記事を通じて、私たちの組織運営やチームの雰囲気が少しでも伝わっていれば幸いです。
We’re Hiring!
タイミーではデータサイエンティスト・MLOps Engineerをはじめ、一緒に働くメンバーを募集しています！
カジュアル面談も行なっておりますので、興味のある方はぜひお気軽にお申し込みください！
