トラストバンクが抱えていた課題の1つ目は、データアナリストしかデータを抽出できないことだ。同社では、限られたアナリストが全社的なデータ抽出依頼を一手に担っており、対応が集中する状況だった。数人で年間600件の依頼に対応しており、データの提供にラグが生じていた。

　2つ目の課題は自由に利用できるデータ分析環境がないことだ。各事業部門にはデータ分析ツールの高度な権限を付与しておらず、アナリストが作成した編集不可能なダッシュボードを使うことになっていた。新たな分析がしたいときはアナリストへの依頼が必要だったという。

　3つ目の課題は指標の定義のブレだ。売り上げという指標一つをとっても、部門ごとに見たいデータの条件が異なり、それに合わせた個別のデータマートを立ち上げていた。トラストバンクの場合は「自治体ごとの申し込みベースの売り上げ」「新規ユーザー×自治体ごとの決済ベースの売り上げ」「自治体ごとの月別の売り上げ」などだ。

「売り上げ」の定義が複数存在していた（「Google Cloud Next Tokyo」での投影資料、筆者撮影）

　4つ目の課題はダッシュボードの乱立だ。チーム別に似たような内容のダッシュボードがあり、全体最適ができない状態だった。データ分析基盤移行前は200個以上のダッシュボードがあり、移行後には3分の1まで減ったという。

LookerとLooker Studioでデータのハブを作る

　トラストバンクはLookerとLooker Studioへの移行を進めた。2024年3月にPoCを始め、2024年9月には既存のダッシュボードの棚卸と削除、10～11月には共通マートの要件定義、そして、2025年3月までにLookerとLooker Studioの適用を進めた。

　トラストバンクのデータ分析基盤の移行において中心的な要素になったのはSSoTという思想だった。これは指標の定義を一元管理することでデータの信頼性を担保するという考え方だ。これがトラストバンクの課題と重なった。

　データの利用者とデータの間に共通マートを作り、それを信頼できる唯一のデータソースとした。それまでは利用者が個別のデータにアクセスしていたが、必ず共通マートを通すようになった。指標の定義も統一され正しいデータ分析が可能になったという。

SSoTを意識した仕組み作り

　汎用（はんよう）的なデータをある程度自由に使えるようにしたことで、自由なデータ分析ができない課題とアナリストへの負担集中を解消した。

　LookerとLooker Studioを両方使っているのはコスト削減のためだ。有料のLookerの利用は役職者などに限定し、各部門では無料で使えるLooker Studioを広く適用した。

Looker移行後のアーキテクチャ

　Lookerへの移行で、それまで2000万行を超えるデータは動作が重くなって見れなかった状態から、1億行超えのデータも扱えるようにもなった。

　データのビジュアライズは、移行前の方が凝ったものを作れたが、移行後でも一通りの可視化はできて困らない程度で済んでいるという。

　今後はGoogleの生成AI「Gemini」を使って、ユーザーが自然言語でほしい情報を指示するとAIがある程度自動的にデータを分析できるようにするとしている。