株式会社MonotaRO データ基盤グループの小谷です。データ基盤グループでは、データに基づく意思決定や業務改善を通したビジネスの拡大を支援するため社内のデータ利活用サイクルを加速させるような取り組みを行っています。
この度は、当社での未来のデータ管理体制について、チームトポロジーの考え方を用いて整理してみましたので紹介したいと思います。
この記事は先日開催されたdatatech-jp Casual Talksで登壇した内容についてまとめ紹介したものとなります。登壇の際に使用した資料の方も以下に記載いたしますのでよろしければご覧ください。
www.slideshare.net
データ活用とデータウェアハウス
モノタロウは商品採用、サプライヤ等からの商品調達、在庫、物流、マーケティング、コールセンター、データサイエンス、IT など多くの業務とシステムを自社開発、自社運用をしております。そのため、1000を超えるテーブルがシステムによって管理・運用しており、それらのシステムデータ、ログデータやGoogle Analytics等の分析用のデータの多くをBigQuery上に集約したデータ基盤を構築しております。（具体的な取り組み等は以下の資料に記載しておりますので、ご興味があればご参照ください。）
モノタロウは商品採用、発注、受注、在庫、物流を自社で行っている特性上、データ分析においても複数のシステムで管理されているデータを突き合わせて行うことが多くあります。例えば商品カテゴリ毎の売上を分析するためには,商品情報と受注情報を管理しているそれぞれのシステムのデータを突き合わせて分析する必要があります。その様な分析ではそれぞれのシステム側の変更が分析に影響を与えるためシステムの変更を把握する必要や、正しい集計を行うためにはデータの入り方や更新等のシステムの仕様の理解が必要となります。
しかし、そのようなナレッジは部署や個人単位でが局在化しやすく各人によって分析や集計が異なるといったことがありました。その課題を解決するため『システム等のデータを正しく、より集計・分析しやすいように加工したテーブル』を弊社におけるデータウェアハウス（以下、DWH）として構築し、全社展開することとしました。
(部署や個人毎に複数のアプリケーションからデータを集約した分析のための独自テーブルを構築していた。正しい集計を行うにはシステムの変更や仕様の把握を行わなければならず、それぞれの集計が微妙に異なっていた（上図左）。
システム等のデータを正しく、より集計・分析しやすいように構築したDWHを分析者が利用することで、分析者はシステムの仕様等を意識せず分析に集中できる。（上図右）)
目標とするデータ活用・管理体制
DWHを構築するには、その特性上分析面とシステム面でのドメイン知識が必要になってきます。例えばキャンセルされた注文についての分析をしやすいように注文のキャンセルフラグの様なものをDWHに格納しようとした場合、分析上でのキャンセルの定義とその条件で抽出するためのシステムの仕様の把握が必要となります。しかし、我々データエンジニアはそのようなドメイン知識を持っていないため、構築を分析者や基幹のシステムエンジニアにヒアリングとレビューを受けながら進める必要がありました。構築を進める中でそれらのコミュニケーションコストが想定以上に高く、予定していたリリースより大幅に遅れたリリースとなってしまいました（この経緯は下記資料に詳しく記載しておりますので、ご興味がありましたらご参照ください。）
データに基づく意思決定や業務改善を通したビジネスの拡大を支援するためには多くの業務や分析でDWHが利用できるよう更新や構築を進めていく必要がありますが、我々の様なデータエンジニアが構築する体制ではその都度ドメイン知識がある方へのヒアリング等を行わなければならず、うまくスケールしないことに気づきました。そのため、データ管理を特定の部署が行うのではなく、データ活用を行う業務側のメンバーと、データ生成を行うシステム側のメンバーが共同でドメイン毎に分散したデータの管理を行えるような体制を『データ基盤の分散管理』と名付け、目指すことにしました。データのドメイン知識を持ったメンバーで必要なデータの取得・管理を行うことで、分析にかかるリードタイムの減少や、全社的なデータ利用にスケールする管理体制を実現することができます。
データ管理に重要なことは事業と組織の理解だった（Data Engineering Study #11 発表資料
(現状のDWH構築体制、ドメイン知識獲得のためシステムエンジニアや分析者とのヒアリングを繰り返しながら構築を進める必要がある。コミュニケーションコストが高くリリースや要望反映までのリードタイムが長い。)
(目標とする『データ基盤の分散管理』。ドメイン知識を持った利用者自身で自律的にデータの管理・改善を行い、データ基盤グループはそれを支えるプラットフォームを構築する。)
目標とするデータ活用・管理体制を実現する上で生じた課題
『データ基盤の分散管理』を実現するための具体的なアクションをグループ内で議論するにあたって、分散管理を行う上でのデータ利用者とのデータ基盤の責務の境界が曖昧であることが分かりました。そこが曖昧な事によって、メンバー間、特に新しいメンバーの参画時に、目標とするデータ管理体制の中でグループとして取り組むこととしなくてよいことの境界の認識が合わせづらく議論をすることが難しい状況となったり、グループ外の方に我々の活動について説明することが難しくなってしまいました。そのため、『データ基盤の分散管理』におけるデータ基盤の立ち位置について一度整理を行い、言語化する必要を感じはじめました。
チームトポロジーの考え方の導入
目標とするデータ管理体制の中でのデータ基盤の立ち位置について整理するにあたりチームトポロジーを活用することにしました。チームトポロジーについてこの後の内容に関わる部分だけ触れさせていただきますと、チームトポロジーは「システムを設計する時、そのシステムは組織の構造を模倣したアーキテクチャになる」とするコンウェイの法則を逆手にとり、作りたいシステムに合った組織構造を設計することを提唱し、システムに合う組織を設計するための４つのチームと３つのインタラクションの類型を提案しています。（チームトポロジーは『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』で紹介されたものです。詳しく知りたい方は書籍等で確認いただければと思います）
４つのチームタイプと３つのインタラクションモードについて、今後の内容に関係してまいりますので概略いたします。
４つのチームタイプ
| チームタイプ | 概要 |
|---|---|
| ストリームアラインドチーム | チームトポロジーではチームの基本系で顧客に価値を届けるチーム |
| イネイブリングチーム | 新しいスキルを学習しストリームアラインドチームに還元し支援するチーム |
| コンプリケイテッド・サブシステムチーム | スペシャリストの知識が必要な部分の開発・保守を担当するチーム |
| プラットフォームチーム | ストリームアラインドチームが自律的に動けるようなサービスを提供するチーム |
３つのインタラクションモード
| インタラクションモード | 概要 |
|---|---|
| コラボレーション | チーム間で密に協力してコミュニケーションをとる方法。 素早いコミュニケーションが可能だが、コミュニケーションコストが高い |
| X-as-a-Service | あらかじめ用意したサービスとして機能を提供する方法。 限定的ではあるが、オーナーシップが明確でコミュニケーションの負荷が少なく、プラットフォームチームに適している。 |
| ファシリテーション | 一方のチームが主導して他方のチームを支援する方法。イネイブリングチームに適している。 |
我々には『データ基盤の分散管理』という目指すシステムはありましたが、それを実現するためのチームとしての立ち位置と利用者との関係性が曖昧でありました。そのため、作りたいシステムに合った組織構造を設計するといったチームトポロジーの上記のような考え方を用いて上手く整理できると考えました。
データ基盤の分散管理について現状と理想を整理してみた
チームトポロジーの考え方を用いて目指すデータ基盤の分散管理とそれを実現するために望ましいチームと他チームとの関係性を整理する事にしました。データ基盤の分散管理の目的である『利用者が自律的にデータ利活用業務を行えるようにする』、『組織の拡大にスケールする』ことをふまえるとデータ基盤グループはストリームアラインドチームである他のデータを利活用するチームが自律的に活動できことを支援するプラットフォームチームであることが望ましいことになります。また、プラットフォームチームに適している他チームとのインタラクションモードはX-as-a-Serviceであるとされています。
そこから現状と目標の状態について整理してみますと、現状はプラットフォームとしての体制が整っていないためDWH構築のヒアリングなどで、コミュニケーションコストが高いインタラクションが他チームとの間で発生していると考えられます。現状コミュニケーションコストが高くなっているインタラクションをX-as-a-Serviceへ移行することを目指します。そうすることで、データ利用者による自律的なデータ利活用の促進や、全社的なデータ利活用の増加と管理体制のスケールが実現できると考えられます。よって、多くのインタラクションがX-as-a-Serviceで完結できるようプラットフォームとしての体制を整えることを目指すことにしました。
(現状は、DWHの構築等でデータを利活用するチームとコラボレーションなどのコミュニケーションコストの高いインタラクションが生じている。データを利活用するチームの増加に上手くスケールできていない。)
(目標では、現在コラボレーションなどのコミュニケーションコストの高いインタラクションをX-as-a-Serviceで完結できるようにする。利用者がデータ基盤グループを介さずに、データの管理・活用を行える様になることで、データ活用業務のリードタイムの低減が期待できる。)
整理から見えてきたこれから注力すること
以上の議論から、ドメイン毎のデータ利活用者が自律的に必要なデータを取得・管理を行えるようなプラットフォームを構築することが目標のデータ管理体制を実現するためには必要であることが分かりました。プラットフォームとしての整備を進めるため、以下の取り組みを進める事にしました。
エンジニア的な専門知識がなくともDWHを構築、更新可能な体制の実現
- SQLでデータパイプラインの構築を可能とするパッケージを導入し、エンジニア的な専門知識がなくともDWHを構築、更新可能な体制の実現
利用者自身で自律的に探索的な分析やダッシュボードの作成を可能とする環境の実現
- Lookerの展開によるデータ品質の担保、ロジックの共有の容易化
ポータルサイトの充実による利用者の自律的な問題解決の促進
- 利用者自身でデータ活用・管理を可能とするナレッジの集約
まとめ
グループの目標である『データ基盤の分散管理』を実現するための体制について、チームトポロジーを用いて整理を行いました。結果として、メンバー間の認識を揃えた議論を行うことができ、具体的なアクションに落としこむことができました。
今回の学びとして、チームトポロジーに限らず、一つの観点をメンバー間で共有し整理を行うことが重要であることがわかりました。メンバー間で目線を揃えて議論を行うことで、目標とする状態の解像度を上げることができ、その後の具体的な取り組みの決定につなげることができました。
最後に
データ基盤グループは今後も社内のデータ利活用サイクルを加速するための取り組みを行っていきます。こういったデータ管理の仕事に一緒に取り組んでいただけるメンバーを募集しています。ご興味がある方は是非下記からカジュアル面談等にご応募ください。
