Data Engineering Study第1回では「DWHとBIツールの選び方」というタイトルで、データ分析基盤に必須の2つのツールについて概要を学んできました。
今回はBIツールにフォーカスし、さまざまあるOSS・商用ツールを網羅的にキャッチアップし、より具体的なツールの事例を学べる勉強会にしていきます。
基調講演には「BIツール研究所」のSho Maekawa（HN: ウィル）氏をお呼びし、OSS・商用のBIツールを幅広くご紹介いただきつつ、OSSと商用の上手い使い分けについて学んでいきます。
事例講演ではOSSと商用ツールそれぞれに詳しいデータエンジニアをお呼びし、3つのツールを紹介しております。
なお当日の配信内容はこちらからご覧いただけます。
基調講演「BIツール大全｜もうBIツールで迷わない「超カタログ」」
出典：Sho maekawa/ウィル、「BIツール大全 BIツールの歴史」、https://speakerdeck.comより
Sho Maekawa 氏
RedshiftやBigQueryなど自社に合うモダンなDWHを導入する企業は増えておりますが、BIツールを自社のDWHや事業に合う形で活用しきれていないというお悩みをよく伺います。 本資料ではBIツール大全「超カタログ」ということで、BIツール研究所で調査した結果を整理して、各社の環境に合うBIツールをご紹介します。
株式会社オープンエイト/データストラテジスト
Twitterのアカウントはこちら
BIツール研究所について
Sho Maekawa氏：「BIツール研究所では、BIツールの情報をオープンにして誰もが意思決定につなげられるように支援する活動を行っています。 有志のデータアナリスト5名で立ち上げたコミュニティになっています。BIツールの情報を中立的な立場で発信していくことを目的としており、 Twitter・YouTubeでも活動しているので興味があればご覧ください。」
BIツール選定の前に、データ基盤の全体図について触れていただきました。
基本的なデータ基盤の流れ
Sho Maekawa氏：「データ基盤の略図は上のようになっていて、企業でデータベースを扱う場合にはオーソドックスなパターンだと思います。 様々なデータを、ETL処理を行うtrocco®に渡し、BigQueryデータを貯めてから意思決定するために可視化するツールがBIツールになります。
BIツールの役割は、データを判断しやすいように可視化してビジネスの意思決定に使うことです。可視化できるツールは100種類にも及ぶため、可視化できればどのツールでも一緒だという疑問が出るかと思います。」
BIツールを選定する上での課題点
Sho Maekawa氏：「留意すべき点として、データを扱える人が会社に少ないケースが多いです。データ分析者の方が自分の分析をしたくても、別のBIツールのレポーティングに時間を割かれたり、データエンジニアの方が他の人のレポート作業を肩代わりして作業工数を削られる事があります。
最近だと、メンテナンスに工数を取られる事が増えています。 経営の速度が上がったことで一ヶ月で今までの定義が通用せず、BIツールで作ったアウトプットが使い物にならなくなることも増えています。」
BIツールを選定する上で考えるべきこと
Sho Maekawa氏：「DWHをBigQuery・Redshift・Snowflakeの中から自社に合う形で選択できるのが一番いいと考えています。
そういった選択の一助になるように、今日はBIツールの特徴をたくさん紹介していきます。」
まずはBIツールの歴史を解説していただきました。
第1世代のBIツール
Sho Maekawa氏：「誕生した時代背景別に、第1世代、第2世代、第3世代と分けて紹介していきます。 第1世代のBIツールは1990年ぐらいに誕生したBIツールを指します。 90年代の初めは1人1台PCを持つような状況ではなく、基幹システムにデータが貯まっていて、そこからデータをもってくるツールとしてBIツールが誕生しました。」
バブル崩壊による投資抑制
Sho Maekawa氏：「時代背景としてバブル崩壊と被るところがあり、この時代のBIツールは高額だったため、一般まで浸透することはありませんでした。そのため、データの民主化という考えは広がっておらず、”データ分析は ITリテラシーが高い人がやるもの”と思われていた時代です。」
比較的安価なBIツールが誕生
Sho Maekawa氏：「2010年代から流行ったツール群を第2世代と名付けています。この時代の背景は、効率的にメモリを活用してなるべく安価に集計をできるようにるなど、独自の集計技術の研究を通して誕生したツールです。
ノートPCのビット数が32ビットか64ビットになってメモリが安価になった背景があり、インメモリー技術などが流行った時代です。」
セルフサービスBIツールとは
Sho Maekawa氏：「セルフサービスBIツールとは第1世代と比較した言い方です。第1世代の時は、システムのリテラシーがないようなビジネス部門の方やマーケッターの方がBIツールを使うときに、データのシステムを多段階で構築する必要がありました。1人ではできないため専門の技術者を雇う必要があったり、そもそも構築に半年以上かかったりするのが一般的でした。
それと比較して第2世代のBIツールはBIツールから好きなデータを自由に取得できて、ビジネス部門の方でも自分自身でセルフサービスで扱えるという意味で、セルフサービスBIツールと呼ばれています。」
ここで、BIツールの活用フェーズについてお話ししていただきました。
Sho Maekawa氏：「BIツールの活用フェーズは4つに分けることができて、最初はBIツールを使い始める導入フェーズで、第2フェーズは利用が促進されて、BIツール上にグラフが上がっていく段階です。さらに第3フェーズでは高度化・ヨコ展開化と呼ばれるもので、全社の重要指標をまとめたダッシュボード・グラフ群ができたり、様々な部門のデータを統合したアウトプットができたりする段階です。そして第4フェーズには高度化・効率化が該当します。たとえば、KPIの変更対応を1・2日で対応完了できるようになるなど、一箇所定義を変更すればBIツール上にあるすべての関連する定義を変更できる事が第4フェーズに当たります。」
この考えをもとに、先ほどのセルフBIツールについて考えていきます。
セルフサービスBIツールの限界点
Sho Maekawa氏：「セルフサービスBIツールは第3フェーズまでは到達可能ですが、第4フェーズの高速化・効率化までは到達できないと考えています。 理由として、セルフサービスBIツールは現場の方々が自由に扱えることに重きを置いているため、ガバナンス全体で値を統一するところを考えていなかったためです。
今後はアプリケーションのようにBIツールを扱うことが求められているのではないかなと考えています。」
クラウドを活用したBIツールの登場
Sho Maekawa氏：「今後出てくるのが第3世代BIツールで、時代背景のひとつとしてDWH依存型になったことが挙げられます。2010年代まではメモリを活用していくことが主流でしたが、莫大なデータを扱う際は処理時間が掛かってしまうところを、クラウドの自動で分散化してくれるデータベースに処理を任せればメタバイト級のデータも1分以内に（処理が終わり、可視化した結果が）返ってきます。
データの計算処理はデータベースに依存させることが後発の製品では当たり前になり、これからのトレンドはアプリケーションのようにBIツールを使うことが考えられます。」
今後BIツールに求められるもの
Sho Maekawa氏：「アプリケーションのようにBIツールを扱うことのひとつとして、メタデータの一元管理があります。たとえば、スマホアプリで定義に欠陥があると大問題ですが、BIツールでは各々が自由に集計を行うので全体管理ができていません。そのため定義にミスがある可能性が高く、加えて大企業であればアウトプットにミスが生じたり、メンテナンスし切れてない状態になってしまいます。 今後は、この辺の定義を管理する機能やアプリケーションのようにプログラミング言語で扱うことが求められています。
2つ目が埋め込み分析です。今まではBIツール上に様々なグラフ群やダッシュボードを貯めていましたが、BIツールは意思決定に使うもので、職種や業務ごとに意思決定と判断する場所が異なってくるので、意思決定する一番近い場所にBIツールのグラフを置いていくことがどんどん求められてきます。今後は埋め込み分析の機能をレベルアップして行くことがトレンドになってきます。
さらにアプリのデザインなどのABテストを実施する際に、社内利用のBIツールで作ったアウトプットが意思決定に寄与されているかを図っているケースって少ないと思います。そういった効果検証が実行されるようになったり、効果検証するためのモニタリング系の機能が今後出てくると考えています。」
自社に合うBIツールの選択
Sho Maekawa氏：「ツールの特徴をチャートに落とすと図のようになります。自分はどれが当てはまるかを考えていただけると嬉しいです。」
ここからは、各BIツールの特徴をお話ししていただきました。
BIツール①：Tableau
Sho Maekawa氏：「Tableauは一番有名なBIツールの絶対王者だと考えています。 迷ったらTableauの導入をお勧めできる理由として、事例と機能の豊富さがあり、製品が安定していて開発も進んでいる点があります。
ライセンスがユーザーごとにかかるため、お金をかけられる方でしたらまずTableauで間違いないと思います。転職の時の実績にもなるツールなのでおすすめです。」
BIツール②：Qlik Sense
Sho Maekawa氏：「Qlik Senseはセルフサービス系のデータ探索最強BIツールで、商品分析や顧客分析をする際はQlik Senseが最適です。
取り込んだ複数のテーブル間のデータを同じキーで紐づけしておけば、勝手にデータが連動してフィルターがかかります。マーケターの方などは商品分析をするときに、高速にいろんな条件を見る必要があるので、いちいち設定をせずに条件を自由に当てはめることができるQlik Senseが最適です。」
BIツール③：PowerBI
Sho Maekawa氏：「PowerBIは世界でもっとも利用されているBIツールで、マイクロソフトのoffice 365についてくるツールなので、無償ユーザーなどを含めると一番利用者が多いです。MicrosoftのOfficeを使っている会社さんだったら、こちらから試すのがいいではないかと思います。」
BIツール④：DOMO
Sho Maekawa氏：「DOMOは高機能オールインワンBIツールで他のツールより単価が高いですが、その分機能が十分に備わっています。
通常の可視化機能に加えて、BIツール内でのチャット機能や、利用度合いに応じて学習スコアをつけてくれたり、Twitter用のアナリティクステンプレートがあったりと、機能が豊富なのでお金に余裕のある企業さんは導入しても良いかと思います。」
BIツール⑤：Motion Board
Sho Maekawa氏：「続いてMotion Boardという国産のBIツールです。こちらは尖ったツールで、日本でよくあるExcelのクロス集計表でセルが結合されているデータに対して帳票を作るような機能があります。」
最後に、同氏が所属しているオープンエイトでのBIツールの使い分けについて紹介していただきました。
RedashとTableauの使い分け
Sho Maekawa氏：「OSSで使えるRedashとTableauを使っています。 使い分けとしては、Redashは自由な分析を行うときに使って、Tableauは全社向けに綺麗にレポーティングする形で使い分けてます。」
Redash事例講演「Redashで踏み出すBI導入はじめの一歩」
出典：有田拓哉氏（Takuya Arita）、「Redashが踏み出すBI導入はじめの一歩」、https://speakerdeck.com より
有田 拓哉 氏
低コストではじめられる OSS BI ツール Redash の強みや、導入によって得られるメリット、導入パターンなどを紹介します。
株式会社オープンエイト
Redash Meetup 主催
Twitterのアカウントはこちら
Redashの紹介
有田 拓哉氏：「Redashは仮想的に始まったOSSのBIツールです。最大の特徴がオープンソースであることで、 同じような並びのBIツールとしてはデータベースとかApache Supersetがあります。機能としては、データを抽出するクエリエディターやチャートなどを書く可視化の機能であったり、チャートを一元管理し、俯瞰して情報を見ることができるようなダッシュボードなど主要な機能はサポートしています。
また有償にはなりますが、サーバーを管理しなくても利用できるのがRedashの良いところだと思います。」
Redashの1番の魅力
有田 拓哉氏：「Redashの1番の魅力は低コストで利用できるところです。小さな組織でデータ活用の第一歩として、まずRedashを導入しているところが非常に多いと感じています。また、導入環境としてクラウドやオンプレどちらでも導入できるので、幅広さも良いところだと思っています。
今の時点で最新版を出して60種類ぐらいのデータソースをサポートしているので、一般的なRDBMSやDWHには対応しています。
RedashはSQLを書いてデータ抽出を行うので、SQLが使えればRedash自体の使い方を覚えなくても使い始めることができます。また、SQLに不慣れでも一部の条件を変えてクエリを発行できるのがRedashの良いところだと思います。」
Redashの苦手なところ
有田 拓哉氏：「一方で、Redashの導入・運用については公式のサポートはないので、ドキュメントを見たり、コミュニティ・フォーラムを見たりあるいはRedashを利用されている方のブログも見て情報収集したりする必要があります。
また、UIなどのドキュメントは基本的にすべて英語で書かれているので、慣れていない方は選びにくいのも特徴としてあります。
Redashを導入してデータアクセス環境が整えられた一方で、クエリやダッシュボードの乱立が目立ち、正しいデータがどれか分からなくなることがよく起きます。Redash自体に乱立を防ぐ機能がないので、運用でルールを作成したり定期的なチェックが必要になります。
さらに、細やかな権限管理は苦手なところがあるので、Redashの仕様と実際使われる方の要件に合わせて選択する必要があります。 」
ここで、Redashの導入事例でよくあることについて紹介していただきました。
Redashの導入前
有田 拓哉氏：「Redashを導入する前は、データベース等にデータは蓄積されているがSQLをかけるのがエンジニアだけで、データを活用したい人はエンジニアに依頼してCSVやExcelで受け取ることが恒常的に発生していました。
データ抽出はデータ更新や抽出条件の変更をする必要があるため1回では終わらないため、エンジニアの稼働を制限したり、抽出までのリードタイムが課題としてありました。」
Redashを導入したことによって起こった変化
有田 拓哉氏：「こういった背景からRedashを導入しましたが、様々な利点がありました。
データ活用したい人がSQLを直接かけなくても、エンジニアに書いてもらったSQLを利用できるので、誰でもデータ抽出ができるようになりました。
また、一部の条件を変えて再抽出したい事例でも、SQLを直接編集する必要はなくパラメーターを利用することで、期間やキーワードを変えてデータを抽出できます。Redash上でデータを管理・抽出できる環境が整うと、データを可視化したり、閾値を超えたらslackで通知できるので、よりデータの活用を進められることができます。
さらに、応用編として社内でSQL勉強会を実施してSQLをかける人を増やしたり、かけなくてもデータベースの構造を理解するメンバーを増やすことで、データ活用を推進して行く事例もあります。」
ここからは、今後Redashの導入を検討している方に向けての内容となります。
Redashの導入前に確認したいこと
有田 拓哉氏：「まず、データがないところにBIツールを導入しても効果がないので、分析したいデータがDWHやデータベースにあるかを改めて確認する必要があります。ない場合は、データ基盤をを作るところから始めていただく必要があります。
次は接続先のデータソースがどこにあるかを調べる必要があります。DWHにあるのか、オンプレ中のデータベースのレプリカなのかは、Self-hostingする際の接続方法の選択に影響を与えるので、改めて確認しておいた方がいいです。
Redashはオンプレのデータベースに直接つないで分析するのは簡単にできますが、そのデータのデータベースにはどんな情報が入ってますかを改めて確認する必要があります。なぜなら、Redashは多くの人に使ってもらうのが活用のポイントですが、アクセスする対象のデータに個人情報が入ってしまうと、Redash自体が個人情報の漏洩リスクを持ってしまうので、接続先のデータベースの理解と接続できる条件等をクリアにしてから導入するのがいいと考えています。」
Redashの導入パターンは大きく3つある
有田 拓哉氏：「Redashの公式イメージを使用するのが一番お勧めのパターンになります。AWSやGCPを利用している場合はRedashの公式で公開しているイメージを利用すれば、簡単にRedashを立ち上げることができます。
2つ目の導入のパターンは、公式のセットアップスクリプトを利用する方法です。AWSやGCP以外のクラウドを利用していたり、オンプレで使用する際に利用するもので、OSがUbuntu前提になっていますが、性能要件は公式イメージとほぼ同様です。
3つ目はSaaSを利用するというパターンで、クラウド上のDWHを利用している場合は選択肢に入ってくるもので、自分たちでサーバーの面倒を見なくて済むので運用コストは削減できますが、最低価格が１ヶ月で49ドルになっています。」
Redashは無料では利用できない
有田 拓哉氏：「Redashを無料で利用できると思われている方もいますが、正確には無料ではありません。RedashをOSSでSelf-hostingするなら少なくともコストがかかります。 たとえばサーバーのコストや、初期構築であったり、実際に運用することになった時にかかるエンジニアの稼働負担があるので無料とは言えません。ただ他のBIツールに比べたら、安価に構築運用できます。
Self-hostingする事例が本当に多く、国内の利用者様はOSS版を利用していますが、エンジニア組織がないのにhostingするのは相当難しいです。そういった場合はSaaS版のRedashではないものを検討する必要があります。」
Redashの利用方法について、デモを活用しながら解説していただきました。
※こちらからデモの様子を動画で見ることができます。
クエリエディターを使う
有田 拓哉氏：「Redashで利用できるデータソースは60以上あり、その中からデータソース接続の設定をして表示されるのが、図のクエリエディターです。サンプルデータの社員のデータベースでクエリを実行すると、職種に対して何人ぐらいいるかが出力されます。」
Redashには「Fork」という特徴的な機能があって、もとのクエリをコピーするだけですが、これによってSQLにあまり詳しくない人でも、コピーして改修することで自分の欲しいとやりたいことができます。条件を変えたい場合はパラメーターという機能を使うことで、SQLの存在をほとんど意識しなくてもデータ抽出が行えます。」
可視化を行う
有田 拓哉氏：「可視化を行う際は、Edit Visualizationのタブを開きます。ダッシュボードでは複数のチャートを一緒に置くことができるのでよく見る情報をまとめる際に有効です。」
Pythonのコードを使う
有田 拓哉氏：「Redashの特徴として、クエリにPythonのコードを直接書くことができます。 PythonでできることはRedashでもできるので、いろんなデータ持ってきたりExcelで何か変換してデータを取得などできます。使いすぎると管理が複雑になりますが、面白い機能のひとつです。
さらに、この結果にSQLを投げられるので、csvに対してをSQLを投げたりGoogleスプレッドシートの結果に対してSQLを投げたりすることができます。使いどころが難しいものもありますが、Redashで出来る面白いもので紹介させていただきました。」
まとめ
有田 拓哉氏：「Redashは低コストで高機能に加えて、様々な環境に適応しているのでスモールスタートにぜひ使っていただきたいです。データ抽出にSQLを利用するのは少し難しいところもありますが、Redash自体の使い方を学び直す必要はないので、SQLが書ければ気軽に使って欲しいと考えています。
また、コスト面と環境面のメリットは非常に大きいですが、”導入前にデータが整備されるか”や”運用どのように行うか”を調整した上で導入してほしいです。」
Exploratory事例講演「誰でもデータサイエンティスト！Exploratoryの紹介」
内之八重 氏
「データサイエンスの民主化」を掲げ、誰でもデータ探索ができることを強みにしているExploratory。 プログラミング未経験のユーザーとして、普段の分析業務で使用していて感じたExploratoryの特徴や強みをご紹介します。
株式会社truestar シニアコンサルタント
はじめに、Exploratoryというサービスについて解説していただきました。
Exploratoryのプロダクト紹介
内之八重氏：「Exploratory社はシリコンバレーに本社を置く企業で、データサイエンスの民主化を掲げ、Exploratoryというデータ探索ツールを開発・提供されています。創業・運営はすべて日本人の方々でされているので、導入に関する質問や普段のやり取りはすべて日本語でご対応いただいております。
Exploratoryデスクトップはデータ探索ツールで、Exploratoryコラボレーション・サーバーはデータや分析結果の社内共有やデータ更新の自動化などを行うことができるサーバーのサービスです。そしてExploratory Publicはデスクトップのオンライン版で、データや作業内容がオンラインに公開される仕組みになっていて、無料でトライアルとしても使うことができます。」
本日メインで扱うExploratoryデスクトップの詳細についてお話ししていただきました。
内之八重氏：「Exploratoryデスクトップはノーコードで・素早く・一気通貫でデータ探索サイクルを回すことができ、特徴を3点に絞ると、1つ目に統計分析・機械学習メニューが豊富であること、2つ目がわかりやすいUIを備えていること、3つ目にユーザーサポートが手厚いことが挙げられます。」
具体的な事例紹介を踏まえて、ツールの説明をしていただきました。
ExploratoryのUI
内之八重氏：「事例紹介のtruestarでは年に2回行う顧客満足度調査の結果をもとに、顧客満足度を向上させるにはどんな要因がをあるのかを分析しました。分析手法は相関分析とランダムフォレストを使用しています。
取り込めるデータはローカルのファイル以外にも、クラウドのアプリケーションデータやデータベースサービスから直接取り込むことができます。データを取り込むとサマリー画面が開き、読み込んだデータにどんなフィールドが含まれているのかや各フィールドのデータ分布を一覧して概観することができます。また Exploratoryはデータの加工も行うことができ、ステップ画面でデータ化を行っていきます。」
簡単に相関分析が可能
内之八重氏：「顧客満足度などの相関分析を行う際は、データの項目を選ぶだけで自動で計算してくれます。データを利用する場合、相関を見てデータ間の関係を見るところから始めることが多いので、サマリー画面でデータの概要を見ていきなり相関分析に入れるのは非常に便利です。
ソート機能を用いると、満足度に対して影響が強い関連が強い項目順に並べることができます。ここからは結果を見ながら議論に入って行くことができます 。」
ランダムフォレストの活用
内之八重氏：「ランダムフォレストを利用する際は、関連性のある目的変数を選択することで簡単に実行できます。クライアントのデータを使いながら分析する時も画面を見ながら分析実行できるので、クライアントの方からも人気があります。様々なタブからランダムフォレストの精度やデータの傾向などの結果を見ることができます。
変数重要度のタブを見ると、顧客満足度に対する相対的な影響度の強さ順に並んでいて、重要度の強さをもとに議論を深めていくことができます。
このようにデータの観察・分析・結果の可視化までを自動的にスピーディーにやってくれるので、普段truestarの分析業務でも結果の解釈や、どんな課題が発見できるかといった議論のところに多くの時間を割くことができています。」
サポートも手軽に受けられる
内之八重氏：「ツールの質問ボタンを利用して質問を投げると約1時間で回答いただけます。 こみいった内容になると、ビデオ通話して画面を見ながら教えてくだることもあるので本当にいつも手厚くサポートいただきながら使用しています。」
最後に、どういった方にとくにメリットが大きいのかをお話ししていただきました。
内之八重氏：「”様々な分析手法を試してデータからインサイド（気づき）が得られるか探索したい”と思っている方や、”プログラミングはできるが分析までの作業時間を短縮して考察を深めたい”と思っている方、そして”プログラミングはできないけれど分析をしたいと思っている方”にとっては便利なツールだと考えています。」
Looker事例講演「運用してわかったLookerの本質的メリット」
阿部 昌利 氏
BIツールの運用コストは「データアーキテクチャのシンプルさ」と「アウトプットの多様さ」の掛け合わせで決まると考えています。その2つをマネジメントしやすいBIツールとして、弊社のLooker事例をご紹介します。Lookerは「強くてニューゲーム」ができる素敵なツールだと思います。
株式会社ヤプリ プロダクト開発本部
データサイエンティスト
Twitterのアカウントはこちら
はじめに、株式会社ヤプリについて紹介していただきました。
株式会社ヤプリの紹介
阿部 昌利氏：「”mobile tech for all”と言うミッションを掲げており、誰でもアプリを作れるノーコードのプラットフォームを展開しております。主にマーケティング向けで社内報や営業資料などのBtoB向けのアプリも提供しています。導入実績として450社の会社さんに活用いただいてます。」
ここからは、BIツールをどのように活用しているのかをお話ししていただきました。
Lookerの利用状況
阿部 昌利氏：「大きく社内と社外の2つの用途でBIツールのLookerを活用しています。社内向けはSalesforceやスプレッドシートなどのデータをtrocco®を経由してBigQueryに入れて、Lookerで可視化して社員が見てるような形です。アプリのログの方はGoolge Cloudのプロダクトを使ってBigQueryにログを貯めて可視化して、クライアントに見ていただくような形です。
定量的な数を示すと、社内向けは約30あり、自分を含めた2人のビジネスユーザーでETLやMLを対応しています。社員約15人が先週の実績だと平均1週間で100近く使ってもらってるような形です。青い部分に関しましてはGoogle Cloud Dayのイベントで発表し、事例の記事も出ています。」
BIツールの運用コスト
阿部 昌利氏：「BIツール運用コストが測る要因は大きく2つあり、「テーブルの構造の複雑さ」と「アウトプットの多様さ」の掛け合わせで決まってくると考えています。
たとえば、どんな集計でも「GROUP BY」一発で出力されるならアウトプットの種類が増えてもコストをあまりかけずに済みます。一方、事前のデータハンドリングが何百行も必要ならアウトプットは少なくても大変になります。」
運用コストへの様々な対応策
阿部 昌利氏：「これまでも、BIツール界隈では、運用ツールに関するノウハウについて議論されてきていて、このコストに関わる議論が多いと感じています。
たとえば、テーブル構造の複雑さに対してはクエリ作成労力を軽減する取り組みがあったり、 最小限のアウトプットで満たしているような取り組みもあります。あるいはコストを削減するのではなく、対応キャパシティ増やして行く取り組みをしたり、同コストでビジネスの成果を最大にする取り組みなどがあります。 ニーズをしっかり聞いてコンサルティングして、BIツールの状況をモニタリングして改善していく流れもあります。」
Lookerの本質的メリット
阿部 昌利氏：「概念図を簡単に解釈すると、様々なデータがあってアウトプットしたいものが多岐にわたる状況で、それらをLookerでモデリング層で多様性への対処を可能にする特徴的なツールがLookerです。」
Lookerの特徴がBIツール運用コストにどう関わるのか
阿部 昌利氏：「実際運用していると運用コストは長方形ではなく、利用するにつれてアウトプットの種類が増えて、段階的にテーブルの構造が複雑になっていきやすいです。その点Lookerはモデリング層で一元的に対応できるので、継続的に使っていてもコストを抑えやすいと考えてます。そのため、BIツールの活用を進めても最小限の変更で済むのが特徴です。
Looker以外のBIツールだと、データ活用するにつれてウォーターフォール的に運用しないと破綻しやすいですが、Lookerなら気軽に変更が継続的にしやすいので、アジャイル的に運用しやすいツールだと思っています。」
モデリング層の得手不得手
阿部 昌利氏：「得意なこととしては一元管理が挙げられ、たとえば使いたいフィールドがあったときにシステムのエラーがあっても、修正することができます。2点目は機能適用で、単純なデータの定義だけじゃなく、ドリルダウン機能やリンク機能が設定でき、全てのダッシュボードに対して一括でアップデートできます。3つ目として、LookMLの中で定義として条件がダッシュボードとしてフィルターに入力されたら、それに合わせて出し分けをしていく事が可能です。 そのため、データソースをひとつに留めたまま用途を拡張できます。
不得意なところは、計算に時間を要する処理です。 モデリング層で生ログからwindow関数をかけて計算し直すと時間がかかるので、その場合はデータマート化を検討する必要があります。もう一つはモデリング層の設計する難易度が高いことです。設計によっては一元管理できない状況に簡単になるんで設計が大切になってきます。 」
最後に、本日のお話をまとめていただきました。
Lookerは使い込んでこそ真価を発揮する
阿部 昌利氏：「Lookerを一言で表すと、強くてニューゲームしやすいツールです。BIツールの運用あるいはデータ基盤を始めると、もう一回やり直したいポイントが絶対出てくると思います。そういった時に基盤側のワークフローを変えずに、モデリング層で擬似的に実現できます。
もうひとつは、何周もするほど強くなるというところです。LookMLの構築は何度も作っていく中で別の機能を理解し、日が経つにつれて構築が強くなっていきます。 3点目はやり込み要素が満載で多いので、根気強くやらないとLookerの力を引き出せないまま高いライセンスフィー（利用料）を持っていかれることになります。専用のチームがあって、何周もLookeMLの構築を作れるのを前提にした上で、導入すると真価が発揮されると考えています。」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございますので、ぜひご覧ください。
https://www.youtube.com/@dataengineeringstudy6866/featured
