Looker Advent Calendar 2020 2日目の記事です。 この記事ではLookerの活用例を紹介します。
免責事項
- 正確にはLookerそのものに関する話ではなく「Lookerを含めて様々なツールを組み合わせることでビジネスを加速させようぜ!」という話です。
- 本稿は筆者個人の見解であり、所属組織を代表するものではありません。不適切・考慮不足だと感じさせてしまう点があれば、それは筆者個人の責任によるものですので、どうぞ筆者個人宛てにご指摘のコメントをいただけますと幸いです。
- ランチ返上の突貫執筆なので気が向いたときに手直しします。
誰?
はじめまして。 ゆずたそ (@yuzutas0) と申します。 『データマネジメントが30分でわかる本』 という本の著者です。
筆者が関わっているFinTechベンチャーでは「金融事業としての品質」「ベンチャーとしてのスピード」の両立が求められました。 Looker活用によるバイモーダルITを実現することで、この課題に立ち向かいました。
概要
- 想定する対象:事業責任者から相談を受けるPdM/CTO/TechLead
- 理想の状態:ビジネスの「品質」と「スピード」が両立できていると感じること
- ギャップ:ITシステムの構築が追いついていないと感じている
- この記事が提案するアプローチ:バイモーダルIT戦略
- この記事の独自価値:アーキテクチャ例の提示
この記事で学べること
「品質」「スピード」両立のためのIT戦略の事例を紹介します。 FinTech領域は顕著な例ですが、FinTech以外にも多くの分野で「品質」と「スピード」の両立に苦労しているのではないでしょうか。
アイデアを実現するには時間が掛かります。 【ビジネスの仮説を立てる】<【オペレーションを構築する】<【ITシステムを開発する】の順番で時間が掛かるように思います。 ITシステムに時間が掛かるのは、設定ファイルやソースコードを1文字間違えるだけで動かなくなる、という性質があるからです。 この構造上どうしてもITシステムがボトルネックだと感じることが(少なくとも筆者は)多いです。
先に申し上げておくと、本稿で紹介する事例は銀の弾丸ではありません。 あくまで1つの事例として「こういう観点で見たら改善できるポイントがあるかもしれない」と思ってもらえたら幸いです。
アーキテクチャ事例
このようなアーキテクチャを設計しました。 Lookerは右のほうにあります。
順を追って説明します。
- 前半は課題発見の話をします。Lookerは出てきません。
- 後半は課題解決の話をします。Lookerを活用します。
課題発見サマリー
- SoEとSoRで要素を分けて「品質」重視のポイントを絞り、残りを「スピード」に向ける。
- SoR:ソフトウェアエンジニアは金融取引のITシステムを構築。
- SoE:営業活動はSpreadsheetなどのツールを使う。
- 業務ロジックと構造化データを管理しないと最低限の品質を満たせなくなる。
アプローチの方向性
バイモーダルIT戦略を採用しました。
FinTech事業のヒト・モノ・カネ・情報の流れを分解すると
- 金融取引のような「Record重視」(バグで1円ズレたら問題になる)
- 営業活動のような「Engagement重視」(商談メモの誤字は許容される)
といった形で、期待されるサービスレベル水準が異なることが分かります。 「Record」と「Engagement」の2つのモードを使い分けることをバイモーダル戦略と呼びます。 バイモーダル戦略については多々議論があるのですが、本稿では以下の資料を参考にして話を進めます。
バイモーダルにおける役割分担
FinTechベンチャーの場合、限られたリソースで成果を挙げるには
- SoR:ソフトウェアエンジニアは金融取引システムの構築に全力投球(単体でも難易度の高い開発プロジェクト)
- SoE:ソフトウェアエンジニアの力を借りずにSpreadsheetやSalesforceで営業の仕組みを構築
という役割分担にせざるを得ませんでした。
日々状況が変わるベンチャーにおいて、業務プロセスも日々変わります。 本格的なITシステムを構築して日々アップデートできるほど、開発人員に余裕はありません。
ITシステムとしての振る舞い
見切り発車でSpreadsheetやSalesforceを使い始めると、以下のような弊害が生じます。
この弊害を抑えて営業のオペレーションを安定的に回せるようにすることが第一要件です。
第二要件として、SoEからSoRにいずれシフトすることを見越した設計であること、も添えておきます。 ビジネスの成長に伴って、営業活動(特に契約や顧客管理)でも「Record重視」のサービスレベルが求められるようになります。 データと業務ロジックが散在している場合、SoRシフトの難易度は上がります。
これらの要件を満たすために
- 「Spreadsheet」などのツールに構造化データを持たせる
- 「作業手順マニュアル」に業務ロジックを持たせる
つまりITシステムとしての振る舞いを果たすように設計することが鍵になります。
ソフトウェアエンジニアが不足しているから適当にシートを作りましょう、という話ではありません。 ソフトウェアエンジニア不在の体制でもSoE(軽量なITシステム)を構築しよう、と言っています。 意図的に2つのモードを使い分けることで、アーキテクチャと投資計画を最適化しよう、と言っています。
※最初から全てに備えるのは無理なので、シート運用の見切り発射は妥当だと思っています。 ヒヤリハットが目立ってきたタイミングで作り直すのがベストだと思います。
課題発見サマリー(再掲)
- SoEとSoRで要素を分けて「品質」重視のポイントを絞り、残りを「スピード」に向ける。
- SoR:ソフトウェアエンジニアは金融取引のITシステムを構築。
- SoE:営業活動はSpreadsheetなどのツールを使う。
- 業務ロジックと構造化データを管理しないと最低限の品質を満たせなくなる。
課題解決サマリー
このアーキテクチャ(再掲)を実現します。
課題解決1.マニュアルのトラッキング
顧客獲得の業務プロセスとして、部署ごとに役割を分担しています。
- 部署Aが集客・キャンペーン
- 部署Bが商談・契約(いわゆる営業活動)
- 部署Cがオンボーディング・問い合わせ対応
それぞれで使うツールは異なっています。 Spreadsheet, Salesforce, Kintone など。 本当は1つのツールに寄せることで真価を発揮するのですが、コンウェイの法則が効いているように思います。 担当者の心情としては「試行錯誤しながらツールに習熟したいが、設定を壊して他部署に迷惑を掛けるのは避けたい」といったところでしょうか。 今回はツール分散を与件として話を進めます。
業務ロジックと構造化データを管理するための鍵が、マニュアル(手順書)になります。 理想は 『無印良品は、仕組みが9割』 のマニュアルや 『経営計画は1冊の手帳にまとめなさい』 の手帳ですが、かなり気合を入れないといけません。 最初は大まかな手順を書き、Q&Aやトラブルが起きる度にアップデートするのが、よくある妥協ラインでしょうか。 人員増加や外部委託のタイミングで充実することが多いように思います。
マニュアルとSpreadsheetによってオペレーションを実現して、データをLookerで可視化します。 例えば、部署Aの「キャンペーン」を「対象エリア別」で可視化すると「東京 3件」「東京都 108件」が出てくる。 マニュアルでは「都・道・府・県」まで入力するように書いてあるのに、Spreadsheetへの入力方法が守られていない。 といった形で、業務ロジックと構造化データが適切に運用されていないことを確認できます。
「キャンペーン効果ダッシュボード」などに加えて「不整合ダッシュボード」を用意すると、 週のヨミ会などで定期的にチェックし、オペレーションのミスを検知することができます。 あまりにもミスが頻出するようであれば、何らかの改善策を講じようという会話に繋げます。
課題解決2.NoCodeでETL+DWH+BI構築
各部署のデータは以下のようにLookerに統合します。
SpreadsheetはBigQueryのExternalTableで読み込むように設定します。 ソフトウェアエンジニアではなくても、画面上の操作だけで設定を完結させることができます。
Spreadsheetは機械で読み込めるフォーマットでなければいけません。 1シートで1テーブルを表現し、1行目はカラムを表現し、セルの結合は避けます。 まさに↓の記事で書かれているような点です。
いわゆる「業種」などのマスターデータであれば、そのままのフォーマットで管理できます。 一部の「履歴」データはGoogleForm経由で入力してフォーマットを崩さないように工夫しています。 そこまでスマートにいかない場合(ほとんど上手くいきません)担当者が使いやすい入力用シートとは別に、BigQueryに読ませる専用のシートを作り、そこから入力シートを参照します。
SalesforceやKintoneのデータは、troccoというツールを使ってBigQueryにデータを転送しています。 troccoについては以下の記事で紹介しています。
こちらもWEB画面でETLを完結できます。 ソフトウェアエンジニアである必要はありません。 残念ながらKintone連携については、WebAPIの制約 + troccoの機能拡充待ちで、十分に満足できる状態ではないのが正直なところですが。
BigQueryのデータレイク層には、未加工のデータを集約します。 LookerはBigQueryに接続させて、データレイク層のデータを参照します。 Lookerで生成したデータはBigQueryのデータマート層に保存します。 これらのデータを使って最終的にはダッシュボードを表示します。
課題解決3.チーム別KPIと反脆弱性
各部署のKPIは、その部署自身がLookerで管理します。 営業チームであれば「初回アポの件数は目標達成」「商談での次回アポ獲得がNG」といった形で、部署内の課題検知・解決に繋げます。 なるべく指標(Data)と現場(Ops)が近いほうが良いと筆者は考えています。
ちなみに、Spreadsheetのセルを結合してしまうと、結果的にLookerの表示もエラーになります。 エラー原因を調査して「セル結合をしたから」とフィードバックを得ると「じゃあこういう体裁に直そう」といったシステム改善にも繋がります。 IT部門から依頼されてしぶしぶ直すのではなく、自分たちの業績を把握するために必要だから自主的に直す、という流れを実現できます。
本当は1つのツールに寄せることで真価を発揮するのですが、コンウェイの法則が効いているように思います。 担当者の心情としては「試行錯誤しながらツールに習熟したいが、設定を壊して他部署に迷惑を掛けるのは避けたい」といったところでしょうか。
というツール散在問題があったにも関わらず、横断でLookerを使えているのは、以下のような反脆弱性があるからだと思っています。
- ETL -> DWH -> BIツールがReadOnlyのデータの流れだから。Lookerをぶっ壊しても、影響がLookerに限定される。
- Development Mode があるから。ローカルブランチでぶっ壊しても、影響が自分に限定される。
- GitHub連携があるから。ぶっ壊してもバージョンを戻せる。
社内にLooker大臣が1人いると、この安心感がステークホルダーに伝わるので、話が早いかなと思います。
課題解決4.横断KPI
複数部署のデータを統合したことで、工程横断での指標を可視化できるようになります。 例えば、部署Aのキャンペーン1,2について
- 1:営業リード獲得100社。その後の契約完了10社。
- 2:営業リード獲得50社。その後の契約完了15社。
だった場合、部署A単体のデータでキャンペーンを評価すると 1 > 2 ですが、後工程を視野に入れると 1 < 2 になります。 次のキャンペーンは2の勝ちパターンを踏襲したほうが好ましい結果を得られるかもしれません。
さらに後工程を見ると「契約は出来たけど説明不足でサポートに時間を割かないといけない」といった事態に陥っているかもしれません。
さらに後工程(金融取引のデータ)を統合すると 「このお客様はオンボーディングまで順調に終わったけど取引量が少ない」とか 「このお客様は取引量が多いけど絶対的な金額が少ないので手数料売上を稼げない」とか、 1つの工程だけでは分からなかった全体の評価を行うことができます。
統合データを可視化することで、局所最適化に陥らずに業務を改善できるようになります。
課題解決5.横断CRMとAdminPack
横断KPIを踏まえて業務を改善する場合、マニュアル(業務ロジック)で横断データを参照する必要が生じます。
例えば、営業活動のインセンティブ設計を最適化したい、という会話が挙がります。
Before | After |
---|---|
単体データ | 横断データ |
受注有無だけしか分からない | 後工程のデータが分かる |
「契約完了でインセンティブ◯◯円を付与」にせざるを得ない | 「契約後3ヶ月で△△円以上の金融取引があったらインセンティブ□□円を付与」を実現できる |
営業スタッフは利用意欲の低いお客様に売りつけてもボーナスが貰える | 営業スタッフは良質なマッチングを促して初めてボーナスを貰える |
インセンティブの集計業務は、横断データに依存します。 業務用途の顧客データを管理するデータ・ダッシュボード(要するにCRM)をLookerで提供することになります。
念の為に捕捉すると、CRM構築のために個人情報や機密情報をBigQuery/Lookerに含める必要はありません。 あくまで独自発番idを結合キーにして、担当営業やサポート履歴といったデータを統合すれば十分だと思います。 法人顧客の公開情報など、PIIに該当しない参考データを扱うことはあります。
実際に横断CRMとしてLookerを利用した知見としては、アカウント管理の作業コストが上がりました。 アカウント一括管理には Admin Power Packを使っています。 Looker AdventCalendar 2020 1日目に hase-ryo さんが紹介記事を書いてくださっています。
部署A(キャンペーン)・部署B(営業)・部署C(サポート)は、いずれも外部委託の機会が多い領域です。 このキャンペーンのために期間限定のスタッフが必要だとか、一気にこのエリアを攻めるから営業代行会社に依頼するとか、 コールセンターを立ち上げる余力はないので専門会社にお願いするとか、そういった場面は多々あります。 また、委託期間が終わったときにはデータにアクセスできないようにクリーニングしないと情報漏洩のリスクになります。
そこでアカウント管理の問題をLooker社に相談したところ、有志に働き掛けてツールを公開してくださいました。
Lookerアカウント管理(ユーザー追加や権限編集)について、CSVリストを一括自動適用できるExtension。https://t.co/yZis5ferWo
— ゆずたそ (@yuzutas0) 2020年10月2日
最初は自分でスクリプトを書こうとしたが、公式に乗せたほうが世界中のユーザーも幸せなのでは?とLookerチームに相談したら、有志で機能追加してくださった。神対応。
課題解決6.E2Eテスト
チーム別KPI、横断KPI、横断CRMといった形で、オペレーションの課題発見・課題解決を進めていきました。 業務プロセス・業務ロジック・業務データを磨き込んでいくと(そしてビジネスが成長すると)、 一定の規模・複雑性を超えて、SoEからSoRへとシフトさせるフェーズがやってきます。
全ての業務を一気にシステム化するのではなく段階的に進化させることになるでしょう。 まずはサポート部門向けの管理画面を作るなど、マイクロサービスを生やすイメージです。
これまでKintoneやSpreadsheetで扱っていた業務を、管理画面システムに置き換えるにあたって、 Before/Afterで想定外の変化が起きていないかをテストする必要があります。 Lookerを業務・データ観点のE2Eに活用することができます。
新システムのDB -> trocco -> BigQuery -> Looker へとデータを統合します。 Lookerで本番用のダッシュボードとは別に、Staging用のダッシュボードを作成します。
- 手順書(マニュアル)と新システムとLookerでオペレーションが回るかテストすることができます。
- データのマイグレーションを行う場合は、Before/Afterで指標が一致するかを確認できます。
- データのマイグレーションを行わない場合は、Before/Afterのデータを統合することで
(仮に新システムのDBが空であっても)Lookerでは連続して指標をトラッキングすることができます。
- 明らかにBefore/Afterでデータの欠損がある場合などはグラフで検知することができます。
現実的な問題として、きちんと業務テストできない&マイグレーションできない場面は多いので、最後の用途が一番役に立っている印象です。
課題解決サマリー(再掲)
といった感じで、このアーキテクチャは課題解決に貢献します。
【再掲】
まとめ
- 理想の状態:ビジネスの「品質」と「スピード」が両立できていると感じること。
- ギャップ:ITシステムの構築が追いついていないと感じている。
- 【ビジネスの仮説を立てる】<【オペレーションを構築する】<【ITシステムを開発する】の順番で時間が掛かる
- この記事が提案するアプローチ:バイモーダルIT戦略。
- SoEとSoRで要素を分けて「品質」重視のポイントを絞り、残りを「スピード」に向ける。
- SoR:ソフトウェアエンジニアは金融取引のITシステムを構築。
- SoE:営業活動はSpreadsheetなどのツールを使う。
- 業務ロジックと構造化データを管理しないと最低限の品質を満たせなくなる。
- この記事の独自価値:アーキテクチャ例の提示。
- ↓こうすると業務ロジックと構造化データを管理できるようになる。
【再掲】
NextAction
「品質」「スピード」両立のためのIT戦略の事例を紹介しました。
経産省が「2025年の崖」を発表したように、新しいマーケット機会に対してシステム開発が追いついていない、というのが多くの現場の実情ではないでしょうか。 だからこそNoCodeやLowCodeといったキーワードが流行しているのだと思います。
残念ながら本稿で紹介した事例は銀の弾丸ではありません。 まだ十分に成果を出せておらず、少々表現を盛っている箇所もあります。 あくまで1つの事例として「こういう観点で見たら改善できるポイントがあるかもしれない」と思ってもらえたら幸いです。 具体的には
- SoEとSoRを適切に分けているか? → もしNOならIT投資のポートフォリオを見直そう!
- SoEで業務ロジックと構造化データを管理できているか? → もしNOならアーキテクチャを見直そう!(Lookerは強力な武器になりうるよ!)
ご自身の担当現場について、この2つのクエスチョンを考えてみてはいかがでしょうか。
宣伝
Looker Advent Calendar 2020 1日目 担当のhase-ryoさんと一緒に書籍を執筆しました! 良かったらぜひ読んでください!
『データマネジメントが30分でわかる本』をKindleで販売開始しました!データ活用に関わる方々はぜひお買い求めいただければと思います!https://t.co/aRRYIsJeqR
— ゆずたそ (@yuzutas0) 2020年3月13日