なぜピクシブはデータ利活用の中心に“ドメインチーム”を置くのか　データの生成・連携・加工・分析のすべてを任せる理由

登壇者の自己紹介とアジェンダの紹介

kashira氏：初めまして、kashiraと申します。本日は、ピクシブのデータインフラと組織構造について発表いたします。

自己紹介です。CTO室プラットフォーム開発部でエンジニアをしています、kashiraと申します。ふだんは、全社のデータインフラの整備や、データマネジメントの整備といった業務を行っています。

本日は、データインフラとデータ利活用の組織構造について、データ基盤チームの観点からお話できればと思っています。

今日のプレゼンで話すことは、大きく3つです。ピクシブでは、プロダクトのデータがすべて集約された全社共通のデータインフラを整備しています。この全社共通のデータインフラについて、まずお話しします。

次に、なぜピクシブが全社共通のデータインフラを整備しているのか、データ利活用をどう進めているのかについて理解してもらうために、データ利活用の組織構造について、併せてお話しします。

そして最後に、全社共通のデータインフラの将来の展望についてお話できればと思っています。

1つの基盤にプロダクトやドメインのデータを集約するかたちでデータインフラを構築

まず、データインフラです。唐突な会社紹介になってしまうのですが、ピクシブは社員の数に対してプロダクトの数が多いという事情があります。正社員約330名で16プロダクトを運営しています。

実際には、全員がプロダクト開発に関わっているわけではないのですが、関わっていると仮定すると、1プロダクトあたり約20人で運営されていることになります。

そしてピクシブは、（スライドを示して）このように1つの基盤にプロダクトやドメインのデータを集約するかたちで、データインフラを構築しています。すべてのプロダクトのデータを1つに集約している関係で、データ量がすごいことになっています。これについて話します。

まず「BigQuery」です。プロダクトのデータを入れているので、データ量がとても大きいです。BigQuery単体でペビバイト（PiB）という数字は、なかなか見られないものだと思っています。

また、全体のデータ量だけだと大きすぎてパッとわかりにくいのですが、1日のデータアップロード量に着目すると6.9TiB（テビバイト）と、ものすごく大きな数のデータがアップロードされていることも確認できると思います。

次に「Looker」です。Lookerに対して個人的にすごいなと思っているところは、アクティブ率です。このアクティブ率には、スケジュール実行を含みません。つまり、全社員の7割が、月に1度はLookerのインスタンスにアクセスしてデータを探索しているということになります。これはすごいなと感じています。

また、モデル数やダッシュボード数も1,000個を超えているので、すべてを把握している人はいない状況です。

データ基盤チームがデータインフラを整備している

ここからは、全社のデータインフラについてお話しします。ピクシブのデータインフラは、（スライドを示して）こんな感じになっています。といっても画像が小さく文字が読めないと思うので、これは後日、スライドを配布した際にご確認ください。

かなり簡略化して、すべてのプロダクトが使う部分だけを抜き出しました。実際には、機械学習チームがMLプラットフォームを持っていたり、リアルタイムで特殊な要件に対応するために別な基盤があったりもします。データ基盤チームでは、このメインとなるデータインフラを整備しています。

データ基盤チームの仕事内容

ここからは、データ基盤チームがデータインフラの何を管理しているか、どのように管理しているかについてお話しします。

まず、BigQueryです。データ基盤チームではBigQueryに対して、ストレージの管理・モニタリング、スロット周りの管理・モニタリング、機密情報周りの管理・モニタリングや、権限ポリシーの設計、コスト管理といった作業を行っています。

次にLookerです。Lookerでは、コスト管理、CI/CDの管理、インスタンスとBigQueryの接続周りの管理といった作業を担当しています。

そして最後に、「Airflow」と「Embulk」が合わさった「bq-batch」というリポジトリについてお話しします。bq-batchでは、Airflowの管理、テンプレートの作成、使い方ドキュメントの整備、CI/CDの管理、ライブラリの更新といった作業を行っています。

データ組織が中心となる組織体制は、ピクシブには合わない

仕事内容を見てわかったと思いますが、データ基盤チームは、データの集合体としての基盤を整備していません。データインフラのみを管理しています。ややこしいですが、ピクシブのデータ基盤チームは、データ整備に必要なインフラのみを管理しています。

「では、データ本体は、誰が管理しているのか？」と疑問に思う方がいると思います。その疑問を解消するために、ピクシブにおけるデータ利活用の組織構造についてお話しします。

よくある構成として、ドメインチームがあって、横断組織があって、基盤があるという組織構造を持っている会社さんは多いと思います。

補足ですが、ドメインチームとはプロダクトチームのことをメインに指しています。ただし、プロダクトを直接持たず、間接的にプロダクトに関わっているマーケティングやコーポレート、インフラチームといったチームもデータ利活用はしていますし、利活用していくことを推奨しています。

こういった事情から、プロダクトチームと限定せずに間接的にプロダクトに関わっているチームを含めて、ドメインチームといった呼び方をしています。

このように、横断組織が一括でデータ利活用やデータ整備を進める組織構造の場合、データ利活用の主役は、横断組織になりがちです。

データ組織が主役の場合、アプリケーションを管理するドメインチームと分析を行う分析チーム、場合によっては、データを整備するデータ整備チームというようにチームが分散されているケースが想定されます。

こういった場合、ドメインチームは分析チームに分析が欲しいと依頼をかけ、分析チームはデータ整備チームにデータの仕様について問い合わせ、データ整備チームはドメインチームにデータ連携についての問い合わせを行います。

しかし、このようなデータ組織が中心となる組織体制はピクシブには合わないことが想定されました。

それはなぜか。前半にも少し出ましたが、一番大きい理由は社員数に対してプロダクト数が非常に多いからです。

データ分析においてはドメイン知識が、なにより重要です。ドメイン知識なしでの分析は、誤った分析結果を引き起こし、事業の成長を阻害します。そういった事情から、ドメインに詳しくない人が分析するのはとても時間がかかります。

そしてピクシブではコミュニケーションサービスの「pixiv」、ECサイトの「BOOTH」、3D事業の「VRoid」、BtoBの「pixiv Ads」など、ドメイン知識が大きく異なることが想定されます。中央の分析者のみですべての分析を行うのは非常に難しいという判断になりました。

もしピクシブのデータ利活用の主役が、中央のデータ組織だったとすると、利用者は、簡単に分析結果を得ることができるでしょう。一方で、データ分析に時間がかかるので、分析依頼が多くなると返信が遅くなり、利用者体験が悪化します。解決には、データ人材がたくさん必要です。でも、そんなに人は取れません。これは困った、ということになることが想定されました。

（スライドを示して）こんな感じで、外部のチームとの調整部分に時間がかかってデータ利活用が進みにくいと考えました。

ドメインチームを主役にデータ利活用が進む体制を構築

ではどうしたのかというと、ドメインチームを主役にデータ利活用が進む体制を構築しました。

（スライドを示して）こんな感じで、ドメインチームが主役で、横断組織やデータ基盤が黒子となるような体制です。データ利活用する際には、データを生成して、データを連携して、データを加工して、データを分析するという作業を踏みます。

ドメインチームが主役というのは、ドメインチームがデータ連携、データ加工、データ分析の一連のプロセスをすべて担当することを意味しています。

ドメインチームを主役にすることで、伝言ゲームが少なく分析にかかる時間が短い、スケールしやすい組織体制を進めてきました。

ドメインチームに存分に活躍してもらうためにサポート体制を整えている

ただし課題もたくさんあります。

データ利活用をするための認知負荷が高い、データ利活用の環境構築まで手が回らない、作業者がデータの専門家でない場合も多い、データガバナンスの統制が難しい、など課題は盛りだくさんです。

つまりドメインチームに丸投げすればいいという話ではありません。ドメインチームをサポートする体制が非常に重要になります。

ピクシブでは、ドメインチームに存分に活躍してもらうために、ノウハウの共有や共通ルールを決めるための定例、データ利活用の推進・コンサル、そして全社プラットフォームを用意しています。

データに詳しい方なら少し聞いたことがあるかもしれませんが、データメッシュやチームトポロジーといった組織体制に似ています。

ここからは、ドメインチームのサポート体制についてお話しします。

データエンジニアリング互助会、データ駆動推進室、データ基盤チームといったチームがドメインチームを全力でサポートしています。

役割を一覧にするとこんな感じです。こちらも図が見にくいので、後ほどスライドを配布した際にご覧ください。

まず、データエンジニアリング互助会の役割です。データエンジニアリング互助会は、社内でデータ利活用に携わる仲間と知見を交換・集約できる場です。データに興味がある人たちで運営されているため、体制図上のチームではありません。ベストプラクティスを共有して、分析環境を健全に保つという目的で運営されています。

互助会の具体的な内容は、（スライドを示して）こんな感じです。出席は、任意かつ飛び入り参加OKなので、参加人数は曜日によって大きく変わりますが、9部署15人がよく参加するメンバーです。

具体的な議題としては、更新されたドキュメントの確認や、他部署や全社的なルールに関する討論、現在進行中の案件の共有といったことを行っています。

先ほど述べた課題でいうところの、（スライドを示して）このあたりが対象です。作業者がデータ専門家ではない場合の支援や、データガバナンスの統制といったところの対策として行っています。

次に、データ駆動推進室です。データ駆動推進室では、データドリブンの意思決定による実務の効率化を推進しています。具体的には、ドメインチームが実装してデータ利活用を行うためのサポートを行います。データインフラやデータは、ただ整備しても使われません。データ品質やセキュリティなど、安全にデータを使える環境の整備やツールの使い方の整備、社内教育といったことが必要になってきます。

先ほどの課題だと、（スライドを示して）このあたりの対策になります。データ利活用をするための認知負荷を抑えたり、作業者がデータの専門家ではない場合の支援を行っています。

そして最後に、データ基盤チームです。前半に話したようにデータ基盤チームでは、ドメインチームがデータ利活用を自己完結できるためのインフラを提供しています。よくあるETLのテンプレートやドキュメントの整備、ライブラリのアップデート、コスト管理などのデータ利活用を行うためのハードルをインフラ方面からできるだけ下げます。

データ基盤チームは、全社のデータインフラを提供していると言いましたが、これは、ドメインチームがデータ利活用を自己完結できるために構築していたというわけです。

先ほど述べた課題でいうと、（スライドを示して）このあたりの対策になります。

実際に運用してみて感じたメリット

では、実際に運用してみてどうだったかについてお話ししていこうと思います。

まずうまくいった点です。何度も言っていますが、データのつなぎ込み、データの分析がチーム内で素早く完結できることになったのはとても良いことだと感じています。中央のチームで依頼を処理しないのでスケールがしやすいと感じています。

また、データの生成からデータの利活用までドメインチームが一気通貫で行うので、エンジニアの分析への関心度が非常に高いとも感じています。そして最後に、インフラを全社共通にしたことで、コストの最適化やインフラのナレッジが溜まりやすいというところがメリットだと感じています。

残っている課題とその対策

逆に、まだ対策が不十分だなと感じている点についてはこのあたりです。データ品質の管理が難しい。ナレッジの共有が難しい。ビジネス職にはハードルが高い。データ基盤チームがボトルネックになりやすいと感じています。

まず、データ品質管理が難しい点についてです。そもそもデータ品質は、非常に重要です。低品質のデータは誤った結果を出力します。ですが、データ品質を保つのはそもそも大変です。ピクシブのデータ利活用をする人がデータ専門家でないことが相まって、データ品質の管理が非常に難しいと感じています。啓蒙やベストプラクティスや工数、すべてが足りない状況です。

ピクシブでは、こういった事象に対応するため、データオーナーを立てて責任者を明確にしたり、全社的なデータ品質のチェックを行っています。ですが、まだまだ不十分であると感じているので、データカタログのテンプレート整備やdbtでのテストの追加、強制といった検討を考えています。

次に、ナレッジ共有が難しい点です。ピクシブでは、ドメインチームごとにデータ分析をする人が分散している関係で、ナレッジの共有が起きにくいです。特に基礎的な部分に対してデータ専門家ではないため、知識が足りていないなと感じるところがあります。

こういったナレッジ共有の対策として、データ基盤チームが旗振り役となって、さまざまな部署を巻き込んで読書会を実行するといった対策をしています。現在は『Fundamentals of Data Engineering』や『Lean Analytics』といった本の読書会を行っています。

次に、ビジネス職にはハードルが高い点です。ピクシブでは、エンジニアであれば誰でもデータ利活用ができるインフラを提供しています。一方で、ビジネス職に求めるスキルは、SQL、Git、Pythonと比較的高いものとなっています。そのため、エンジニアの採用などが解決の糸口になりそうですが、採用で人を増やすことは難しいです。

現在考えている対策として、トレーニングの強化や、GUIでデータ連携が完結できる画面の提供を検討しています。

そして最後に、データ基盤チームがボトルネックになりやすいという点についてお話しします。データツールは進化が早いです。ツールの導入の遅れは、データ利活用の遅れに直結します。しかし、全社共通インフラですぐにデータツールを導入、移行することはできません。それなりに時間がかかります。

こういったボトルネックへの対策として、まずは、データ基盤チームの責務を無闇に増やさないことが重要だと考えています。特にデータに関する責任は、ドメインチームに持ってもらうことを重点的に意識しています。データ基盤チームは、データに関する責任を持つのではなく、データインフラに責任を持つことが重要です。

よくあるケースとして、特定のチームのみが使うデータパイプラインを作ってほしいと言われることがあります。データ基盤チームがそれを作るのはよいのですが、その管理をきちんとドメインチームに持ってもらうことが大事だと思っています。

また、全社共通のルール・処理といったことを無闇に増やさないことも大事だと考えています。共通ルールは、ドメインチームの枷になったり、変更するのに時間がかかりがちです。重大な事故防止策としてのルールや、運用上強く必要な場合にのみ追加することを意識しています。

そして最後に、移行作業はドメインチームにも手伝ってもらうということです。パイプラインの管理者のメインはやはりドメインチームで、データの管理者はドメインチームです。

つまりデータ基盤チームでは把握していないところも多く、データ基盤チームですべてをやりきろうとすると時間がかかりすぎることが想定されます。素直にドメインチームにも作業を手伝ってもらいます。

データ基盤チームにおける将来の展望3つ

最後に、データ基盤チームとしての将来の展望についてお話しします。

データ基盤チームとして重要だと考えているのは、以下の3つです。データ整備のサイクルタイムを短くする。全社のデータ品質・メタデータの強化。データインフラのProduct化。こういった対応を進めていきたいと考えています。

「データ整備のサイクルタイムを短く」について。まずは、Modern Data Stackの導入です。データ整備にかける時間を短縮して、データ品質の向上にも着手したいと考えています。

次にデータ品質・メタデータの強化です。dbtの移行に合わせたテスト・メタデータの強化や、データカタログのテンプレートポリシーの策定、全社的なデータ品質チェックのさらなる追加を検討しています。

そして最後に、データインフラのProduct化です。データインフラは全社員から使われる関係上、Platform as a ProductとしてのProductと考えることが重要だと考えています。そのため、定常的に社内からフィードバックを受け取る仕組みの整備や、社内向けマーケティングに力を入れたいと考えています。