データ組織のトポロジー
この記事について
最近発売された『チームトポロジー』（以後、本書）を読んだのですが、チーム体制やコミュニケーションの設計について汎用的にまとめられていてとても良い読書体験でした。私自身、データ組織をどのように設計していくか日頃考えており、本書を読み進めながら、考えが構造化され、課題の解像度が高まった気がします。
現在、私は株式会社エウレカで、BIチーム（分析チーム）、AIチーム、Data Managementチーム（データ基盤チーム）、の3チームのマネジメントをしています。日々生まれるデータを価値に転換し、同時にプライバシーやセキュリティなどのガバナンスを徹底するために、全社的なデータ戦略を推進していく立場です。大雑把に「データ活用」と括ってしまいましたが、意思決定をサポートするのための活動（BI）、ユーザー向けの機能開発を伴う活動（AI）、それらの活動を効率よく進めるための活動（Data Management）はそれぞれ異なるスキルが要求され、チームのあり方やコミュニケーションも多様です。
『エウレカのデータ組織運営の1年間』（奥村 純, 2020）より
この記事では、『チームトポロジー』で紹介された「４つのチームタイプと３つのインタラクションモード」を敷衍しながら、データ組織のあるべきトポロジーについて考察したいと思います。対象読者は、① データ組織のマネジメントに関わっている方、② 1年後の自分、です。
Disclaimer
● BtoCのモバイルアプリを運営する3桁人規模の会社でのデータ組織を想定しています。組織の規模やドメインの複雑度によってもあるべき姿は変わるため、本記事が当てはまらない場合もあるでしょう。
● 本書では開発文脈で様々な整理がされていますが、そこで紹介された用語をデータ組織文脈で独自解釈しているため、著者の意図と異なる使い方をしてしまっているかもしれません。誤読がある場合はぜひお知らせいただけると嬉しいです。
● 本書では原著の用語がそのままカタカナ表記されていますが、意味が取りづらいと感じたので英語表記しているものもあります（４つのチームタイプなど）
前提となる考え方
まず、本書で提示されている「４つのチームタイプと３つのインタラクションモード」を簡単に紹介した後に、この考えをデータ組織に当てはめるにあたって考慮するべき点を整理します。
４つのチームタイプ
チームには様々な形態がありますが、最も基礎的な単位となるのがStream Aligned Teamです。End to Endで成果物をデリバリーする能力を持ち、分析チームに例えれば「意思決定ニーズを受けて、データを処理した後に、レポートとしてステークホルダーに届けるチーム」のイメージです。チーム内の工程は、要件の整理から、データの抽出や加工、レポーティングなどの一連のフローとして定義されています。
このチームは、社内の様々な分析依頼に対応していくため、分析の質を向上させ活動を効率化すること、を目標としています。チームの自助努力で行う改善もあれば、他チームからのサポートが必要な場合もあるでしょう。
他チームのサポートには様々なパターンがありますが、いずれもStream Aligned Teamだけでは対応できない高度な役割を提供し、結果として分析の質とスピードの向上に寄与します。分析チームを例に噛み砕いてみましょう。
Platform Teamは、データ基盤の提供に相当します。Platformの助けがなければ、アナリストが分析の度にデータ品質のチェックに工数を使い、ワークフローエンジンのエラーに悩まされ、バックエンドチームにログフォーマットの確認をしなければならないでしょう（過去のエウレカではこのような状況が実際に発生していました）。これはオーバーヘッドを増やして分析のスピードを大きく停滞させてしまうため、別チームが引き受けてデータ基盤として整え続ける必要があります。
Enabling Teamは、Stream Aligned Teamがまだ持っていない知識や技術の導入をサポートするチームです。『LeanとDevOpsの科学』でも継続的な能力向上の重要性が述べられていますが、その活動をチームとして切り出しているイメージです。本書は開発組織について書かれたものなのでCI/CDツールの導入サポートなどが想定されていますが、分析の例に解釈を広げると、クエリ構文チェックツールを導入したり、統計や財務の知識をレクチャーしたり、プロセスを標準化するワークショップを開いたりする活動に近いかもしれません。これらの活動によって、Stream Aligned Teamに新しい能力が付与され、成果物の品質とスピードが向上します。
Complicated Subsystem Teamは、Stream Aligned Teamだけでは解決困難な専門的な課題を引き受けるチームです。実験計画や因果推論、数値シミュレーションが該当するかもしれません。例えばA/Bテストは、バリアントの割当や様々なバイアスを考慮した解釈法など、高い専門性が必要となる実験方法です。全アナリストがハマりどころを抑えておくことが難しい場合には、専門知識を持つメンバーが実験計画や解釈のレビューを担当した方がいいかもしれません。
ここで注意したいのは、それぞれの要素は習熟度やチーム状況によって変化することです。「分析チームが正しくA/Bテストを行えるようにする」というケースを考えると、ワークショップのような知識の導入であればEnabling Team、実験レビューのようにフローの中で任せる形態になればComplicated Subsystem Team、サービスとして利用可能な統合的なA/Bテスト基盤を開発していればPlatform Team、といった具合です。
続いて、これらのチームがどのように関わり合うのかを整理します。
３つのインタラクションモード
コラボレーションモードは、並走・協業、です。2つの切り離されたチームが連携するので当然オーバーヘッドは重くなりますが、Stream Aligned Teamの能力が底上げされ、専門知識が必要なコンポーネントに悩まされなくて済むようになります。主にComplicated Subsystem Teamや一部のEnabling Teamが該当するでしょう。
X-as-a-Serviceモードは、Platform Teamとのインタラクションに相当します。アナリストはデータ基盤の詳細には関与せず、あくまでもAPIやサービスとして使い倒していくイメージです。余分な認知負荷を作らないためにも、コミュニケーションは最小限で済むようにします。
ファシリテーションモードは、チームの学習を助けるためのファシリテーションに徹している状況です。Enabling Teamの一部が該当しそうです。
組織のあり方を考える切り口
「４つのチームタイプと３つのインタラクションモード」を紹介したところで、私がデータ組織のチーム体制やコミュニケーション設計を考える上で、大事にしたいと思う観点をまとめます。
1. 逆コンウェイ戦略
「組織が生み出すアウトプットは組織のコミュニケーション構造を模倣したものになる」というコンウェイの法則を逆手に取って、望ましいアウトプットが得られるよう組織構造の方を作り変える、という考え方を「逆コンウェイ戦略」といいます。チームの体制やコミュニケーションは、理想とするアウトプットからの逆算で設計するべきです。
2. 認知負荷と帯域幅
メンバーの認知負荷が適切な範囲に収まっているかに気を配るべきです。責任範囲が広かったりステークホルダーが多いと、すぐに個人が抱えられるマインドシェアやコミュニケーションの帯域幅を超えてしまいます。また、たくさんの制約によって自律性を抑えられ、得意領域以外でのパフォーマンスを求められてスキル開発も停滞し、目的も分散してアウトプットの質は下がるでしょう。『モチベーション3.0』では内発的動機づけを構成する要素として「自律性・マスタリー（熟達）・目的」が登場しますが、前述の状態はこれらを阻害し、メンバーのモチベーションを低下させる原因になります。
3. チームを分割する境界面
メンバーやチームの役割をどの軸で分離しているのか自覚的であるべきです。本書では、ビジネスドメイン、規律、システムの変更頻度、チームの地理的配置、考慮するリスク、パフォーマンス、利用する技術、ユーザーペルソナ、といった様々な観点での境界決定について述べられています。
4. マネジメント
該当チームを誰がどのようにマネジメントするかについても考慮が必要です。例えば、データ分析チームでは、様々なドメイン領域に手を伸ばしていくほど、コミュニケーションが複雑になったりカバーするべきスキルが膨らんでマネジメントコストは肥大化します。チームの形態によっても求められるマネジメントスキルは異なるでしょう。
5. 組織的なセンシングと進化
事業状況やメンバーの能力、扱うドメインの複雑さによって、組織のあるべき姿は刻々と変化していきます。今の構造が本当に正しく働いているのか、チームを再編しないといけないのか、どのようなシグナルをもとに判断するか、を定義しておかないといけません。シグナルには、JIRAチケットの未消化率が増えているといった定量的な観測もあれば、他部門からのフィードバックやメンバーの余裕といった定性的な観察もありそうです。
6. トポロジーの階層構造
分析チームを「データで課題解決を行うStream Aligned Team」と捉えたとして、PMチームからは「データを専門的に解釈してくれるComplicated Subsystem Team」として見えているかもしれません。また、小さなStream Aligned Teamが集まって一つの大きなStream Aligned Teamを構成することもあるかもしれません。このようにチームトポロジーは相対的だったり階層的だったりするため、自分のチームだけでなく、周辺チームにとっての見え方も意識するべきでしょう。
データ組織のトポロジー
ここからは、以上6つの観点を織り交ぜながら、現在所属しているエウレカでのデータ組織を振り返ってみたいと思います。
1. データ分析チームについて考える
分析チームは課題解決に特化したチーム
エウレカの分析チームは、BI（Business Intelligence）という名前の通り、社内の様々な意思決定をサポートするチームです。データを主な武器にはしますが、ダブルダイヤモンド・モデルの上流から下流まで並走しながら、課題の言語化と整理を助け、課題解決全般に向き合うチームです。
帯域幅はステークホルダーに集中させる
このようなサポートを実現するためには、分析メンバーは当該ドメインについて深い知識を持つ必要がありますし、コミュニケーションの帯域幅はステークホルダーとの境界（入口の要件定義と出口のレポーティング）に多くを振り分けることになります。
逆に、ドメインに縛られずに、分析依頼を機械的に対応していくパターンもあります。その場合には広い帯域幅は必要なく、依頼通りの分析結果をどれだけ早く提供できるか、を目指すコミュニケーション設計になります。依頼内容の齟齬が起こらないようなチケットテンプレートを作成し、アナリストは単純にそれらを処理していきます。以下の項目に当てはまる現場ではこのパターンを取ることもあるでしょう。
● 対応しきれないくらいの分析ニーズがある
● アナリストが少なく、深いコミットメントが難しい
● 単純な集計データしか扱わない
● 依頼側のデータリテラシーが育っている
一方で、数字を使った意思決定、というのはそれだけで専門職ができるほど難易度の高いことだと思っています。「そもそもそれは課題なのか」「課題を検証する方法は適切なのか」「グラフや数値がいいように解釈されて独り歩きしないか」といったことを念頭に、解くべき課題の解像度を上げないといけません。特に難しいと感じているのはA/Bテストで、バリアントの割当、条件設定、指標の定義、バイアスの考慮、など少しでも間違えると誤った意思決定につながります。参考になる書籍もたくさん出ていますが、必要な知識量は多く、アナリストだけでなくComplicated Subsystem Teamとしての実験設計チームのサポートも必要になるでしょう。
専任制を採用する
現場と並走しながらのサポートを目指すと、要求されるコミュニケーション量は多くなり、コンテキストは深くなるため、なるべく少数体制でフローを処理していくのが最適になります。エウレカでは、プロジェクトの粒度でアナリストを専任しています。コンテキストスイッチを少なくしながら依頼者の課題に集中することで、これまでのところ高い成果を出せていると感じています。
組織横断の活動を意識する
専任制によって質の高い課題解決はしやすくなるのですが、同時に様々なデメリットを生み出していることにも自覚的であるべきです。
専任制を採用するデメリット
● プロジェクトごとに属人化が進み、他のメンバーが代替できなくなる
● メンバーのアサインに制約が増える
● 閉じた暗黙知が増えてチームとしての学習が進みづらくなる
● メンバーごとに専門領域が異なるためマネジメントコストが増える
● 案件に対してスケールしない（人を増やし続けるしかない）
● 分析依頼に最適化してチームを作ることになるため、R&D活動など横断的にリソースが割かれない
これらのデメリットを解決するための仕組みの導入がマネジメントの役割になります。エウレカでも試行錯誤が続いていますが、アプローチの仕方はたくさんありそうです。
ナレッジマネジメント
● 分析クエリのレビューを徹底することで知識が個人に偏らないようにする
● JIRAチケットの対応を分散させることで知識を転移する
● 分析共有会などの会議体設計
ピープルマネジメント
● アサインのローテーション（メンバーのキャリア志向に合わせる、短期的なサイクルには注意する）
● 評価のためのステークホルダーへの定期的なヒアリング
チームマネジメント
● 冗長化していたり、パフォーマンスのばらつきがあるプロセスをEnabling Teamとして解決する（データマートやUDFの整理・統合、プロセス改善のワークショップ開催、など）
● 専門性が高く、多くのプロジェクトで利用するコンポーネントはComplicated Subsystem Teamとして切り出す（A/Bテストの標準化、など）
● 投資としてのR&Dプロジェクトの立ち上げ
分析活動の民主化
● アナリストと同等のデータリテラシーを他部門に広げる
● （民主化の最終形として）分析チームをPlatform TeamやComplicated Subsystem Teamとして位置づけていく
専任制でしっかりと価値を出しつつ、横断的な活動によってスケールを実現する、という考え方は『実践的データ基盤への処方箋』3章で述べられていた分析組織の発展フェーズ「集権型→分権型→ハイブリッド型」のハイブリッド型にも符合するものです。
2. データ基盤チームについて考える
利用者の認知負荷を最小限に減らす
上述のように、Stream Aligned Teamとしてのアナリストはステークホルダーとの並走にマインドシェアを奪われるので、それ以外の工程では認知負荷がかからないように他チームに協力してもらいます。
特に重要となるのはデータマネジメントの切り離しです。データ品質の管理、プライバシーポリシーに基づいたデータのライフサイクル管理、ワークフローエンジンのトラブルシューティング、BIツールのサーバー運用、データ基盤のSLA運用、などはPlatform Teamとしてのデータ基盤チームが管理します。
エウレカでは、データ基盤を構築する過程でBIチームが立ち上がった経緯から、データ基盤運用とアナリスト業務の結合度が高い状態が続いていました。そのため、2021年からData Managementチームを新設し、Metisと呼ばれる新しいデータ基盤を構築しています。
もちろん、データ基盤管理を分離したからといってアナリストの関与がなくなる訳ではなく、引き続きビジネスメタデータの管理やDWH・DMの管理には責任を持ちます。この領域は、近年データスチュアードという役割として注目が集まっている部分で、アナリストとの役割分担が進んでいる組織も増えてきている印象です。
AIとBIの境界面
ここまでは主にデータ分析に焦点をあてていましたが、データ活用の出口としては、AIというとても重要な役割もあります。新しいデータ基盤では、チームに関わらず適切なデータを提供できるような環境構築を進めていますが、AIとBIはなるべく相互に干渉しないよう気をつけています。これは以下の理由からくるものです。
● AIは実際にユーザーに届く機能を開発・管理するため動き方やリスクの種類が異なる
● データ処理のためのライブラリやコンピューティング環境が異なる
● システムの変更頻度が異なる（AIでは高頻度のEDAやモデル実験によってパイプラインを組み直すことが多い）
● スキルセットが異なる
● コミュニケーションを取る相手が異なる
● データ品質に対する要求が異なる（AIはバッチ処理だけでなくストリーミング処理のSLAも必要）
これだけの差異がある中で、共通コンポーネントを作ってしまうと逆に調整コストや管理コストが肥大化するリスクがあります。もちろん中には共通化した方がいいものもありますが、（多少冗長なデータの持ち方をしていたとしても）切り離した方がいいものもあります。
Data Meshという考え方
近年は、中央集権的なデータマネジメントに対する懸念も取り上げられるようになりました。データソースが時間とともに拡大・分散していき（多様なデータベースの利用、マイクロサービス化に伴うデータの分散的な発生）、データ品質の管理主体が不明瞭になりやすい、といった背景から、巨大なモノリスとしてのデータ基盤ではアジリティへの要求や明確なデータガバナンスに対応しきれなくなるという文脈です。
対処方法として、Data Meshという考え方が登場しています。これはデータの発生から利用までを一つのプロダクト開発に見立てて、ドメインごとにデータパイプラインを効率的に作っていくという発想です。以下の記事が有名で分かりやすいですが、このテーマで本が一冊書けるくらい内容が多いのでここでは割愛します。
エウレカではまだData Meshに踏み込んでいくためのニーズや課題がはっきりしていない状況ですが、勉強を続けながら業界の動向をチェックしていきたいです。この辺りの整理は、また来年に振り返っていきたいなと思っています。
3. AIチームについて考える
各工程に必要とされる専門性が高い
AIチームをStream Aligned Teamとして捉えると「AIで解決したい課題がインプットされると、それを解決するための機能を一気通貫で開発・運用するチーム」となるかもしれません。
AI機能の開発で注意するべきなのは、どの工程も高度な専門性が要求されることと、各工程を行ったり来たりしながらプロジェクトが進行していく点にあります。そのため、一人で全フローを担当するのではなく、各工程の職責に応じた専門家が複数人連携する必要が出てきます。
同時に、Platform Teamのサポートが不可欠です。AIプロダクトは運用する中で変更頻度が高くなりがちで、その度に複雑なプロセスを何度もやり直すのでは安定的な運用は不可能です。「AI機能をプロダクションに載せる」というフェーズを超えたら、複雑な工程を少しでも楽にするために機械学習基盤への投資を最優先にするべきでしょう。エウレカでもこの1年間で様々な試行錯誤と進捗があった領域です。
プロダクトチームとのインターフェース
上述のように「要件通りにAI機能を提供して運用する」ということの技術的難易度は非常に高いのですが、同じく難易度が高いのが「プロダクト課題を機械学習が解ける問題に落とし込む」というプロセスです。
やってみないと分からない要素が強いため、期待値コントロールをしながら、クイックに仮説検証をしていく必要があります。AI施策が定着していない状況では、この期待値コントロールのコミュニケーションコストはとても高く付くでしょう。後工程に関わっているメンバーはその部分だけで帯域幅を大きく消費しているため、
1. 両者をブリッジする人材を入れてインターフェースとする
2. 目的となる指標（Overall Evaluation Criteria；OEC）だけ合意してその後の詳細な企画プロセスはAIチーム内で持つ
などのパターンで解消しなければいけません。企画との接合点に関する課題感は以前本を執筆した時からずっとあるものですが、最終的には期待値形成と合意形成の問題になります。また別の機会に文章をまとめるかもしれません。
マネジメントの難易度
一般論として、AIチームをどのようにマネジメントするかは難しい問題です。分析チームの場合は、一人で全フローを経験することが基本となる設計だったため、複数のドメインで実績を残していたり、引き出しの幅があれば技術的なマネジメントはできるようになります。一方でAIチームの場合には、一つ一つのコンポーネントが非常に重いため、全ての工程で実績のあるような人材を見つけることは難しいでしょう。どれか一つの工程で実績のあるメンバーがプラスアルファで別工程を担当できるように促したり、サブチームに分割してマネジメントを効率化するような動きが必要です。
エウレカでは幸い、企画からデリバリーまでの経験を持つメンバーが多く、スキルのカバー範囲も広いため、マネジメントコストが抑えられている側面もあります。ただ、来年はもっと仕組み化を進めていきたいと思っている領域です。
他チームとの連携
AI施策は専門性の高いコンポーネントがつながっているため、AIチームは他チームからはComplicated Subsystem Teamとして見えているかもしれません。一方で、「AI機能を実装するエンジニアはバックエンドチームにいるのか」「AI機能のSLIをモニタリングしているのはSREチームなのか」といった開発の境界面での責務は曖昧になりがちです。
現時点では、データに関する施策を扱うメンバーはなるべく既存の開発チームではなくデータ組織内に集約していきたいと考えています。データを処理していくには独特のコンテキストを必要とするので、ステークホルダーの認知負荷を下げることを期待しています。ただ、これはあくまでも一時的な理想型で、将来的には全社的にデータを扱える人を増やしていって、より適切なトポロジーに進化させないといけないな、とも感じています。
まとめ
書評を書くつもりがすごく長くなってしまいました。年末ということもあり、この1年の活動を振り返りながら、頭の中であれこれ考えていることを吐き出せたのではないかなと思います。今回はデータガバナンスや全社的なデータ戦略の作り方、みたいな話題は（分量が多くなりすぎるので）踏み込めませんでしたが、いずれまとめていきたいなと思っています。
本記事は1年後の自分への手紙みたいなものです。2021年末にはこういう考えだけれども、次の1年でどれだけ解像度を上げられたのか、方針転換したのか、振り返るチェックポイントにしていきたいです。そんな個人的なまとめ記事ですが、似たような悩みを抱えている方に何か持ち帰ってもらえる何かがあればすごく嬉しいです。コメントや意見も歓迎しています。何かあれば @pacocat もしくはMeetyでお話しましょう！みなさま、良いお年を。
この記事が気に入ったらサポートをしてみませんか？