こちらはバイセルテクノロジーズ Advent Calendar 2022 の 14 日目の記事です。前日の記事は菅原さん「iOSアプリを誰でも簡単にビルドできるようにする」でした。

こんにちは！株式会社バイセルテクノロジーズのテクノロジー戦略本部データサイエンス部の高谷です。データアナリストチームで、主にBizメンバーのデータ活用促進をサポートしています。

バイセルでは部署に関わらずデータを基とした意思決定や、新規施策の議論など熱量高くデータ活用が行われていますが、また一歩先のデータ活用のために「BizメンバーもSQLを書ける環境」を構築する機会がありました。

この環境を構築するために権限設計やデータソースの在り方など調べても「これ！」となるものが少なく悩んだため

BizメンバーがSQLを書くために用意した環境
環境を用意する上で実際にやったこと

の2点をバイセルアドベントカレンダーの記事としてお伝えしたいと思います。

2日分に分けて公開予定で、今回は前編となります。

前編（今回の記事）：概要、全体像説明
後編（後日公開予定）：BQの設定を中心とした詳細

はじめに
- バイセルの組織について
- バイセルのデータ基盤について
データ活用の流れ
なぜSQLを書ける環境を用意するのか
- データが集まるのも参照できるのも1か所からのみだった
- Bizメンバーが参照するために必要な環境を整えるための知見&時間がなかった
実際にやったこと
- 誰が何を出来るのか整理
- GCPプロジェクト再設計
まとめ

はじめに

バイセルの組織について

バイセルグループはバイセルとリユース事業の他グループ会社の数社で構成されており、データ基盤としてもバイセル本体だけでなくグループ全体で構築しています。

また、本記事で登場するBizメンバーはバイセル本体の組織を対象としたとき下図の青い部門のメンバーを指しています。

バイセルのデータ基盤について

サービスはBigQuery（Google Cloud Platform）を利用しており、

バイセルグループ全体のデータ基盤
クレンジング層（※）
会社ごと

でプロジェクトを分けているイメージです。

※クレンジング層はデータウェアハウスとデータマートの中間のようなイメージで、個人情報の除外やBizメンバーが利用しやすい形に加工された層となっています

データ活用の流れ

現在のバイセルのデータ活用の一連の流れのイメージで、ポイントとしては以下3つです。

Bizメンバーが自由にアクセス可能な基盤があること
データの可視化＆分析に繋げる手段として、Viewを自由に作成できる環境があること
グループ（会社）単位でプロジェクトを切ることで構造がシンプルであること

ある程度自由がありかつシンプルな構造とすることでデータ活用の意欲を妨げず、必要なデータの抽出～可視化＆分析まで一気通貫で実施できるようになりました。

一気通貫となったことで意思決定のスピード感が上がりよりデータ活用が促進されています。

また結果的に「手動集計業務の自動化促進」や「権限管理コスト削減」の派生効果も生まれていますが、データ活用において必要なデータを自分で参照できる環境というのはバイセルにとって重要なこととなっています。

なぜSQLを書ける環境を用意するのか

今まで社内プロダクトのデータ（主にRDB）をデータ基盤に集めBIツールを通してデータを提供→Bizメンバーが活用という流れでしたが、データサイエンス部から提供したデータしか見えず「もっとデータ活用したい！！けど限られたデータしか見れない」という状態でした。また、新しい施策が始まりそのデータを蓄積したとしても都度データサイエンス部への依頼が発生していました。

つまり、データ活用の意思はあるのに環境がそれを邪魔するという問題が発生していたのです。

この状態になっていたのは以下2つの理由です。

データが集まるのも参照できるのも1か所からのみだった

SSOTの観点からデータが集約されるのは1か所でよいですが、バイセルのデータの性質上個人情報を含むのでそこを安易に参照できてしまうとリスクが高く簡単に開放できませんでした。

Bizメンバーが参照するために必要な環境を整えるための知見&時間がなかった

1つ目と重なる部分もありますが、プロジェクト設計や権限設計などデータ基盤の参照がデータサイエンス部のみが参照する前提でした。またデータサイエンス部の人数も少なかったこともあり、ここの検討に時間が割けないという状況でした。

これらを改善するためにバイセル内の必要なデータを必要なタイミングで自由に参照できる世界の実現が必要で、具体的な要素の1つとして誰でもSQLが書ける環境がありました。

具体的な3要素

個人情報を参照してしまうリスクがない
Bizメンバーでも自分でSQLを書いて簡単に可視化できる
データの流れや権限をシンプルにして構造を複雑化させない

実際にやったこと

実際にやったのは7つで、本編では2までご紹介します。

誰が何を出来るのか整理
GCPプロジェクト再設計
権限調査
データセット設計＆権限設計
Googleグループの作成
必要な権限付与
動作検証

誰が何を出来るのか整理

大方針「バイセルの人であれば誰でもデータが参照できる（個人情報除く）」ではあったものの、具体的に誰がどんなことができるのかを落とし込む必要がありました。

ざっくり↓のイメージが落とし込んだ結果です。

	アンバサダー	Bizメンバー	テクノロジー部門	データサイエンス部
データ見る	●	●	●	●
可視化する	●		●	●
運用する				●

バイセルは全国各地にセンターなどもあり、データサイエンス部だけでデータ関連業務の全てのフォローやSQL教育を実施するのが難しい状況です。

そのため、Bizメンバーの部署に自部署のデータ関連に詳しいアンバサダー（代表者）を選出してもらいました。

そのアンバサダーを「データも見れて可視化もする人」に設定しています。

GCPプロジェクト再設計

最初に説明したイメージで

グループ（会社）ごとのプロジェクト
個人情報を抜きBizメンバー利用しやすい形で加工されたデータをもつプロジェクト（クレンジング層）

を作成することになりました。

設計時のポイントは3つです。

必要なデータ範囲にのみアクセスできる構造であること

個人情報へアクセスできない状態になることはもちろん、グループ会社→本社データへのアクセスはNG、本社→グループ会社データへのアクセスはOKなど細かにデータ閲覧を制御する必要がありました。

Bizメンバーも自由に使える環境があること

データ閲覧のみならず、構築したSQLからViewを作成し可視化に利用してもらうという前提があったためデータサイエンス部以外の部署が自由にViewを作成できる環境が必要でした

運用をシンプルに

会社ごとのコスト管理や、権限管理などできるだけシンプルに分かりやすくと心がけました。

この部分が複雑になると1つ目に挙げた内容がオペレーションミスにより問題発生してしまうと考えられるからです。

これらを踏まえてグループ（会社）ごとのプロジェクトの検討時に利用した表のイメージです。

検討案	メリット	デメリット	デメリット解消案
プロジェクトを分けない ※ バイセルグループ全体のデータ基盤内にデータセット作る	PJを新規に作成する作業がない	データセットごとに権限を設定しなければならずオペミスの可能性あり →オペミスると個人情報や生データが閲覧できてしまうリスクが高い（グループ会社→バイセルのデータは基本参照させたくない）	権限管理頑張る
部ごとのプロジェクトを作成する	コスト案分が容易	分けた単位の組織変更があったときにプロジェクトの作成など変更が必要	なし
★会社ごとにBizメンバーが利用できるプロジェクトを作成	権限管理が容易（プロジェクトごとに権限を設定するのでデータセットで分ける必要なし）	データセット単位での権限管理を行わないので別の部のデータセットにViewを作成できてしまう（へたしたら荒らされる）	運用ルールを整備し、荒らしが発生した場合に対応できる仕組みを用意しておく