アーカイブ動画

PayPayデータ基盤チーム立ち上げと役割・運営について

PayPay株式会社　コーポレート統括本部
システム本部データマネジメント部　部長　三重野 嵩之氏

まず、登壇したのはデータマネジメント部 部長の三重野嵩之氏。三重野氏は建設コンサルタントを1年半、北海道・札幌でSESを1年半、SIでソフトウェアエンジニアを約6年経験。このSIで小売企業向けのデータ分析基盤を構築した。その経験を活かして、2021年6月にPayPayに入社した。入社当初は、GCP周りの運用チーム立ち上げを担当。現在はデータ基盤チームの方針やロードマップ策定に携わっている。

データマネジメント部が設立されたのは、2018年のPayPayローンチから2年後となる2020年10月。それ以前は、全社横断でデータをマネジメントするチームは存在していなかった。 設立の背景にあったのは、DWH（Data Ware House）とGCP周りに課題があったからだと三重野氏は語る。

一つ目はDWH周りの課題。PayPayアプリのデータはBigQueryで全量数時間おきに更新する処理になっており、SQLやBIツール「Googleデータポータル」を利用して業務側のユーザーが自由にクエリを作成していた。個人で作ったクエリがいつの間にか全社展開されていることもあった。

この場合、データの有識者が辞めてしまったあとの保守の問題がある。SQLを書ける人がスケジュールドクエリを組み合わせて使いやすいマートを作成していても、対応できる人材が作成元の部署にいなくなってしまうケースがある。現在は、そうした対応はデータマネジメント部が保守業務を引き取っている。 ２つ目は、GCP周りの課題である。DWHの状態に加え、一つのプロジェクトを全ユーザーが利用するため、リソースや権限管理が難しくなったことである。

これらの課題を解決するため、チームを設立後にまず取り組んだのは、全社へのヒアリングだ。BigQueryをどのように使っているかわからなかったため、主にデータを活用している約15チームにアンケートフォームを配付し、一部のユーザーに対しては1時間程度のヒアリングを実施した。続いて行ったのは、データマネジメント部の認知度向上である。

「社内報に出たり、BigQueryのクエリでつまづいたユーザーに直接メールしてフォローしたり、事例をSlackなどで共有したりしました」（三重野氏）

社内への働きかけと同時に、カスタム開発の知識があり、データ周りをやりたいというエンジニアも積極的に外部から採用を始めた。 また、社内のデータマネジメントに関わる組織のネットワークも強化した。

例えば、三重野氏が率いるデータマネジメント部のほか、プロダクト本部のdaasチーム（アプリのデータをBigQueryに連携する）やproduct ops（プロダクトマネジャーへレポーティングなどをする）チーム、データガバナンスのルールを作るCDO室だ。

「このようなデータ関連の部署が既にある場合は、全社的に協力して進めていく必要があります」（三重野氏）

これらの他のチームとのコミュニケーションは、自由にミーティングに誘う社風が功を奏した。そのほか、SlackチャンネルやGoogle Formも活用。Slackチャンネルでは、BigQuery用のチャンネルや、クエリの書き方などを質問できるチャンネル、個別プロジェクト用のチャンネルなどを設けた。またGoogle Formでは分析依頼フォームを設け、分析依頼の問い合わせができるようにした。

「データマネジメント部のタスクは明確な期限がないものも少なくなく、同時並行で大量のプロジェクトが進むことや差し込みの作業や小さな協力依頼が非常に多い。そのギャップに最初はとまどった」と、三重野氏は明かす。

そこで課題を洗い出し、簡単なロードマップを策定。工数をどのプロジェクトに割り振るかについて、月に一度認識合わせを行ったり、自分の予定は常に3、4割は空けておくようにしたりなど、柔軟に対応している。

データ活用を支えるパイプライン環境や全社共通テーブルを整備

PayPay株式会社　コーポレート統括本部
システム本部データマネジメント部　小芝 涼太氏

続いて登壇した小芝氏は、動画配信サービスのWebエンジニア、ゲーム・ライブ配信アプリのデータエンジニアを経て、21年8月にPayPayに入社。現在はデータマネジメント部でDWH回りを担当している。

小芝氏は、まずPayPayのデータ基盤について解説。PayPayのデータ基盤は次のような構成になっている。プロダクト本部のDaaSチームから流れてきたデータがBigQueryに入り、加工される。それをBIツールでデータを参照するのである。

「データレイクとしてBigQueryを活用しているが、この中にはさまざまなテーブルが入っています」（小芝氏）

例えば、BigQueryの利用者全員に使えるように整備された全社マートや、それを部署で参照するための部署作成マートもあった。全社マートは20から30のテーブルで構成されており、元々は別部署で管理されていた。

「担当者が退職することでデータマネジメント部に管理が移管されました。スケジュールドクエリで依存管理された簡易のマートだが処理は複雑でした」（小芝氏）

そのほかにも外部データソースの連携などは、データマネジメント部で担当。GCPのCloud Composer上で動く、Apache Airflowベースのワークフローを作成している。

直近、取り組んで来た課題は大きく3つある。1つはBigQuery利用の改善である。データマネジメント部で対応したこととしては、フォルダ・プロジェクトの構成を設計したことだ。

「PayPayのBigQueryはオンデマンド課金ではなく、リザベーションを選択。確実に処理したいクエリは別プロジェクトに移行して、流れるようにフォルダやプロジェクトを構成しました」（小芝氏）

また、BigQueryで流れているジョブを可視化することで、コストの大きいクエリを特定し、作成者に同意を取ってクエリの改善を行ってきた。データマネジメント部の対応だけでは、数カ月すると元に戻ったりするので、ユーザー側での対応も促している。

クエリの実行状況をデータポータルで可視化し、ユーザーがslotsを意識できるようにした。さらにクエリのポイントをwikiに記載したり、Slackにクエリの質問できる場所を用意している。

2つ目の課題は、全社マートの再設計である。進め方としては既存のテーブル構造は維持しつつ、自分たちが運用しやすい形に中間テーブルを作成することで管理しやすくした。

テーブル設計・生成の流れは、既存の全社マートと同じ構造のものをマートとして3層目に分類。前段の2層目はユーザーや加盟店、クーポンなどドメイン知識に沿って整理。スタースキーマ風になっている。1層目はJSON形式で入ってくるものを取り出して使うことがあるので、BigQueryのパフォーマンスに影響しないよう、JSONのフラット化を行っている。

「現在は1層目のみリリース。2層目、3層目も10月中にリリースを予定しています。完全な状態というよりは自分たちが運用しやすいものを作っているため、フィードバックをもらいながら改良していきたいと思っています」（小芝氏）

3つ目の課題はパイプライン関連だ。Airflowの導入やCI/CDなども整備したが、今回はデータカタログの整備に絞って紹介された。

もともとはGoogle Data Catalogや自作のリネージツールを利用していたが、より便利にするため、dbtを検証することにした。dbtはテンプレート化されたSQLやあらかじめ設定したconfigをもとに、依存関係通りにクエリを実行する。

データカタログの自動生成も可能なため、社内向けに公開できるか、セキュリティを担当しているチームと相談して検証を進めている。

取り組む課題において、各領域で専門性が高まってきたため、2つのユニット体制とし、各ユニットがそれぞれに合ったチームと連携を深めていく体制へと改善を行った。

データアーキテクトは、全社共通テーブルの整備を担当し、BIチームやデータアナリスト関連のチームとの連携を図っている。

もう一つのユニット、データパイプラインはパイプライン環境のCI/CD整備、dbtなどツールの検証を行う。CAPチームやプロダクト本部DaaSチームと連携し、取り組みを強化している。

またユニットリーダーをチームリーダーとは別に立て、ユニット単位でリソースを拡大しやすいように改善している。「今後もデータマネジメント系の施策に注力していきたい」と、小芝氏は抱負を語り、セッションをまとめた。

BIプラットフォームとしてLookerを導入。ユーザー展開の課題と解決策とは

PayPay株式会社　コーポレート統括本部
システム本部データマネジメント部　Kil Dongseok氏

最後に登壇したのは、Kil Dongseok氏。Kil氏は自動車メーカーでBIやデータ分析を経験した後、IoT系やメーカー向けのコンサルタントとして、主にディープラーニングや機械学習のシステム構築、データ分析サポートに従事。2021年7月にPayPayに転職。現在は、BI回りを主に担当している。

PayPayでは設立当初からGoogle Workspaceが導入されていたため、自然とデータポータル（Google Data Studio）が使われてきた。会社ができて3年で、数百から数千のダッシュボードが作成されていた。

データポータルが使われた理由は、大きく3つある。1つはGoogleアカウントさえあれば、誰でも使えること。次にBigQueryに接続しやすく、インフラのメンテナンスが不要であること。3つ目は直感的なUIで開発しやすいことだ。

だがデータポータルを使うにつれ、「いくつか課題が出てきた」とKil氏。誰がどんなダッシュボード、データソースを作っているか把握できず、管理統制ができなかったり、BigQueryの権限がないと社内データが利用できなかったりなどである。

パフォーマンスが不安定という業務上の課題はもちろん、「データポータルはGoogle Workspaceからのサポートがないことも大きかった」とKil氏は語る。これらの課題を解決するため、エンタープライズ向けのBIプラットフォームの導入を検討することとなった。

その結果、導入することになったのがLookerである。Lookerは次のような特徴を持つサービスである。

1. Webサービスでインストールが不要。可視化もサクサクできる
2. LookMLというYAMLのようなスクリプトでデータソースを定義して、Git管理ができる
3. Looker内部でデータを保存・抽出しない

「3番目の特徴は、異なるDBを結合するときにはデメリットになるが、PayPayはBigQueryだけだったので、デメリットにはなりませんでした」（Kil氏）

そしてLooker導入で、データの民主化とガバナンスが強化されることを期待したという。例えばサービスアカウントでBigQueryに接続するコネクターを構成して、エンジニアとアナリスト双方に使いやすい環境を構築することもその一つである。

こうすることでDB側に対して個人の権限を付与することなく、Lookerで権限をコントロールできる。エンジニアはDB側のメンテナンスに集中でき、アナリストはDBの権限がなくてもデータが見られるようになるからだ。

また、LookMLでデータガバナンスの確保とサイロ化の解決や、監査ログと配信制御でセキュリティの強化もできる。エンタープライズサポートが提供されるので、ユーザーも安定して使うことができるようになる。

もちろん導入にあたって課題になったこともある。一つはデータポータルが根付いており、BigQueryの中でパイプラインが構築されているケースだと、LookMLへの移行コストがかかってしまうこと。またこれまではGUIでできていたことが、スクリプトを書くことになるので「抵抗感を感じる人も多かった」とKil氏は明かす。

可視化にこだわるケースも「これはLookerの弱点で課題だと感じた」と続ける。例えばグラフを他のグラフと被せて配置したり、凡例や説明の書式にこだわったり、いろんなグラフを描きたいユーザーには不評だった。UI/UXが独特なので、Tableauを使っていた人からは「使いにくい」という声が上がった。

そこでデータポータルとLookerの使い分ける方針を採用。ライトユーザーやアドホックな分析をしたい、ビジュアライゼーションにこだわりのある人はデータポータル、チームで分析したい、社内で共通の値を加工する必要がある、ビジュアライゼーションにこだわらない人にはLookerという方針を定めた。

Looker導入にあたり、特に取り組んだことは大きく3つある。1つは各部署にデータを理解してLookerを利用できるユーザーの育成である。自ら必要なダッシュボードを作成できる人を増やすことで、横展開を図った。

2つ目は部署ごとに区切ってプロジェクトを作成し、全社的なデータはデータマネジメント部で提供しながら各部署で必要なデータを自由に作成できるようにしたこと。

「部署単位のマートの利便性を生かしながら、重要なデータはしっかり管理するようにしました」（Kil氏）

3つ目はLookerに慣れていないユーザーが多いため、社内サポートの充実を図ったこと。データ相談会の実施やLookerユーザーSlackチャンネルの設定、社内Wikiなどを作成した。

すでにLookerはプロダクト開発進捗分析やカスタマサポート状況の分析などのプロジェクトで活用が進んでおり、「1年でユーザー数も200人となっており、日々増加している」とKil氏は語る。

Looker導入によるメリットも得られている。まずはLookMLでデータソースを管理することで、データ定義の一元化が図られたこと。次にGitによるバージョン管理、チーム管理が実現し、引き継ぎ工数が激減したこと。さらにLookerだけでデータの利活用が完結したり、派生テーブルによるデータリソースの節約、ダッシュボード配信安定化が図られた。

その他にも、System Activityによるセキュリティ強化、データ利用率分析でデータの活用を推進。メールやSlackなどAPIによる配信を制御し、セキュリティ強化にも繋がっている。

「Looker環境を改善し、個人的には社内でデータポータルが使われなくなるまで、頑張りたいと思います」（Kil氏）

参加者からの質問で盛り上がったQ＆Aタイム

3人のセッションが終わった後、Q&Aタイムが設けられた。

Q．Lookerは費用が高いと思うが、どのように社内承認を取ったのか

三重野：Looker導入時、まだPayPayにはいなかったので、詳細はわかりませんが、おそらく事業が拡大するフェーズだったので、社内の承認が通りやすかったのだと思います。

Kil：Amazon QuickSightやTableauなど、エンタープライズ向けのBIプラットフォームは他にもありますが、Lookerとの価格差はそれほどなかったと思います。

Q．BIツールはどのように使い分けしているか

Kil：データポータルは数千人とまだ圧倒的にユーザー数は多いですが、KPIレポートなどは巻き取って、Lookerで配信できるようにしたいと考えています。

Q．BigQueryの使い方を社内でヒアリングしたときの具体的な内容について

三重野：クエリ開発に充てている人数や工数、私たちが作っているマートが要求しているSQLなど、BigQuery上の課題や要望、教育プログラムの必要性、データ更新の頻度、データ共有の方法、チーム編成などの項目を挙げました。

Q．データマートは社内の誰でも作れるものなのか

三重野：エンジニアではなくライトなSQLユーザがデータマートを運用したい場合はBigQueryやCloud Data Fusionを使えば可能です。リカバリーが難しいので、運用の工数がかかるかもしれませんが、小さいものなら作れると思います。

Q．lookerのトレーニングを行う上で、ユーザーの方の理解を深めるために、最も重要視しているポイントは？

Kil：1つはハンズオンを実施すること。もう1つは業務のデータを使って実践的な分析をすることです。この2つの方法でLookerが使えるようになると、その人がエバンジェリストとなり、所属部署の他メンバーに広げてくれるからです。

PayPay株式会社
https://about.paypay.ne.jp/

PayPay株式会社の採用情報
https://about.paypay.ne.jp/career/