データ基盤におけるチームトポロジーの実例

2026年7月29日(水)に実施された「データマネジメント戦略Night - 5社のリアルを語る会」での発表資料です。
イベントページ：https://teratail.connpass.com/event/398181/
登壇者：株式会社kubell 飯島知之

Transcript

1. データ基盤における チームトポロジーの実例 株式会社kubell プロダクトディビジョン データエンジニアリンググループ 飯島知之 2026年07月29日 データマネジメント戦略Night - 5社のリアルを語る会
2. 01 | 会社&自己紹介 02 | チームトポロジーとは 03 | kubellにおける実例 CONTENTS 目次
3. 01 | 会社&自己紹介
4. 会社概要 会社名 株式会社kubell 代表取締役CEO 山本 正喜 グループ従業員数 735名（2026年3月時点） 所在地 東京 設立 2004年11月11日
5. MISSION 働くをもっと 楽しく、創造的に ⼈⽣の⼤半を過ごすことになる 「働く」という時間において、 ただ⽣活の糧を得るためだけではなく、 1⼈でも多くの⼈がより楽しく、 ⾃由な創造性を存分に発揮できる社会を実現する
6. VISION すべての⼈に、 ⼀歩先の働き⽅を ⼀部の先進的な⼈だけではなく、 世界中で働くあらゆる⼈が、 ⾃分⾃⾝の働き⽅を常に「⼀歩先」へと 進めていけるプラットフォームを提供する
7. 自己紹介 飯島知之（いいじま ともゆき） ざっくりエンジニア遍歴 • Oracleデータベース管理者 • データ基盤導入案件のアーキテクト • データエンジニア（現在） DBやAWSが得意なデータエンジニアです！ 最近は子育てしつつ、Netflixを観てます 7
8. 02 | チームトポロジーとは
9. チームトポロジーとは 高速なデリバリーを実現することを目的とした4つ の基本的なチームタイプと3つのインタラクション パターンに基づく組織設計とチームインタラクショ ンのための実践的な適応モデルを紹介した本です。 バリューストリームを最適化するためにどういう チーム構成でどういう役割で動くべきなのかについ ての型がまとまっています。 データ基盤におけるチームトポロジーの実例を共有 するのが今日のテーマです。 https://www.amazon.co.jp/dp/4820729632?tag=ryuzeecom-22&linkCode=ogi&th=1&psc=1 https://www.ryuzee.com/contents/blog/14566 9
10. チームトポロジーの話をすると それだけでLTが終わるのでエッセンスだけ抽出します 後日、資料を公開するのでそちらをご覧ください
11. 最低限押さえておきたい用語たち 起点となる法則 DevOps（組織の話の方）などもコンウェイの法則が土台 • コンウェイの法則：システムを設計する組織は、そのコミュニケーション構造をそっくり真似た構 造の設計を生み出してしまう 認知負荷の種類 フローを効率化するためにチームの認知負荷の低減に向き合う • • • 課題内在性負荷：仕事そのものが持っている基本の難しさ ◦ プログラミング言語の文法や担当する業務（ドメイン）のルールや仕様など ◦ 研修や適切な言語・ライブラリの採用などで低減 課題外在性負荷：環境やプロセスのせいで発生する、無駄な手間 ◦ 環境構築やデプロイが複雑など ◦ CI/CDやスクリプトなどの自動化で削減 学習関連負荷：成長や改善のための、価値ある良い負担 ◦ 新アーキテクチャやパターンの学習やよりよい機能を考えることなど ◦ ここに時間を使えるようにする 11
12. 4つチームタイプ • • • • ストリームアラインドチーム ◦ ビジネスの主な変更フロー（ストリーム）に沿って配置するチーム ◦ 他のチームを待たずにデリバリーができる ◦ 職能横断型で要求探索から運用まで能力一式を持っている ◦ データ基盤においてはデータパイプラインを想像するといい イネイブリングチーム ◦ 他のチームが新しい技術やスキルを身につけるのを支援するチーム ◦ 永続的に支援するのではなく、短期的な支援をする プラットフォームチーム ◦ インフラやツール・共通サービスなどの内部サービス（プラットフォーム）を提供するチーム ◦ ストリームアラインドチームの認知負荷を下げる ◦ Thinnest Viable Platform (TVP) からフィードバックを元に改善していく コンプリケイテッド・サブシステムチーム ◦ 複雑なサブシステムやコンポーネントを担う専門チーム ◦ スペシャリストじゃないと扱えないようなものを担当する ◦ データ基盤においては機械学習とか（MLOpsとか含めて作るといまだに大変） 12
13. 3つのチームインタラクション • • • コラボレーションモード ◦ 2つのチームが探索を目的として協力する形（長く続けるものではない） ◦ ❌責任境界が不明確で、オーバーヘッド（コンテキストの共有）があり生産性が低い ◦ ❌高カロリーでそんなに並列できない ◦ ✅学習がスピーディーに進む X-as-a-Serviceモード ◦ 別のチームが提供するものをサービスとして利用する形 ▪ コンプリケイテッド・サブシステムが提供 ▪ プラットフォームチームが提供 ◦ ✅責任境界が明確であり、オーバーヘッド（コンテキストの共有）が少ない ◦ ❌イノベーションが遅くなりがち ◦ ❌効果的じゃないAPIや境界だとフロー全体に悪影響が出る ファシリテーションモード ◦ 新しい技術を身につけたり学習するためにファシリテーションをする ▪ イネブリングチームが提供 ◦ ✅ストリームアラインドチームのフローが向上 ◦ ❌シンプルに効果を出すのが難しいの経験値が必要 13
14. フロー最大化の障害になるものを組織の設計で解きにいく （認知負荷とインタラクションが特に重要） また、トポロジーは動的に変化させる必要があります …それでは kubellのデータ組織の実例を見ていきましょう
15. 03 | kubellにおける実例
16. トポロジーの変化でみるデータパイプラインの変遷 ① ② ③ ④ 立ち上がり期 並列体制への移行期 並列体制の安定期 次なる進化 データエンジニアチー ムでSnowflakeでの新 データ基盤を立ち上げ アナリストがdbtパイ プラインへの開発に参 加して並列体制へ dbt開発のプラット フォームの整備が進 み、並列体制が安定化 AI向けのプラット フォームに進化させ、 フローを向上 機能追加 80 件/年 200 件/年 280 件/年 (推定) 500〜600 件/年 (エンジニア 2〜3人月) (エンジニア 2〜3人月) (アナリスト 4〜5人月) (エンジニア 2〜3人月) (アナリスト 4〜5人月) (エンジニア 2〜3人月) (アナリスト 4〜5人月) (利用者with AI 数名 随時) データパイプライン データ ソース データ マート ソース ：データエンジニア ：アナリスト（アナリティクスエンジニア） ：AI Agent マート ソース （一部） マート ソース マート ファシリ XaaS XaaS XaaS XaaS イネイブリ ング プラットフォーム プラットフォーム XaaS XaaS XaaS ソース 重要な ところ 重要な ところ 16
17. ②並列体制への移行期 データエンジニアがパイプラインをメンテするのが限界 →特にデータマートのための加工の仕様（課題内在性負荷）の把握が大変 その辺り詳しいのはアナリストなので、ストリームアラインドチームとしてデー タマート構築の部分に入ってもらう 主にファシリテーション的な形で協力（イネイブリングチームの帽子） 一方でデータソース部分はコラボレーション的な形で分業したままにした（シス テム関連系はエンジニアのバックグラウンドが必要） （参考スライド: https://speakerdeck.com/kubell_hr/250924-mitsuhashi?slide=9 ） 17
18. ③並列体制の安定期 アナリストがdbt開発をするのを効率的にするためにプラットフォームを整備 →dbt buildを安全に本番データを利用して安全に動作確認にできるようにする環 境を整備 CI/CDも順次テコ入れしていき、dbtモデルのテストを差分で回るようにしたり、 その時その時でレバレッジが効くように薄いプラットフォーム（TVP）を継続し て改善して生産性を向上 データエンジニア向け（自分たち）にもTerraformのモジュールを整備して安全に ガバナンスが効いた環境を増やせるようなプラットフォームを整備 主に「課題外在性負荷」を削っていき、自律できるようにしていった（X-as-aService的なインタラクションが増えていった） （この辺りはnoteにまとめてます https://note.com/kubell_dsu/n/nd5737381d4ca ） 18
19. ④次なる進化 AI Agentがより安全に確実な品質で開発ができるようにハーネス（プラット フォーム機能の一つとしてとらえる）を整備中 安全に接続できるようなツールやskill、CIなどを充実させて正しいアウトプット をAIだけで出力できるようにして、エンジニア・アナリストが本来集中するべき 「学習関連負荷」に向き合えるようにしたい AI Agentも一つのチームとして扱えるようになるとさらに強くなれる （AIにより課題内在性負荷を一定レベルでスキップしてくれるので、XaaSを介し てビジネスサイドやプロダクトのエンジニアも参画できる） 19
20. kubellのデータ組織は このように進化してきたのですが、 皆さんの組織はどうやって進化してきましたか？ （チームトポロジーの本を片手に振り返ってみると面白いと思います）
21. 働くをもっと楽しく、創造的に