これはなにか
「コピーされない競争優位の築き方」と題して2019年末に社内向けに公開した資料をベースに、コピーされない競争優位を作るために重要な3つの要素と、それが生まれるプロセスを図解したものである。
本テーマは下記のような3部構成となっており、今回のポストは前回に続く第二弾となっている。
- 競争優位の3源泉の説明とそれが生まれるプロセスについて
- 「良いオペレーション」を支える構成要素について
- 構成要素を作る上で最優先で取り組むべき点
これはなにか 「コピーされない競争優位の築き方」と題して2019年末に社内向けに公開した資料をベースに、コピーされない競争優位を作るために重要な3つの要素と、それが生まれるプロセスを図解したものである。 全体構造 プロセス全体の説明、[…]
前回のポストでは「競争優位の3源泉を生み出す優位性の輪」と題して、競争優位を築く3つの源泉と、それらの源泉が生まれていくプロセスを書き、プロセスの失敗は「良いオペレーション」が出来ないことに起因すると述べた。
今回のポストは、その「良いオペレーション」を生み出すためのフローである「データ主導のオペレーションループ(Data-driven Operational Loop)」にスポットライトを当てる。
データ主導のオペレーションループ
データ主導のオペレーションループとはなにか?
これは競争優位を生み出す分水嶺となる「良いオペレーション」を作り出すフローをまとめたものである。
このフロー全体は下記の図のようになる。
社内・外で起こるあらゆるアクティビティを対象とし、それをセンシング(感知)する、センシングした情報を適切な場所に適切な形で整理し、それらを分析する。
分析をして、課題に対する「正しいオペレーション」を発見・定義することができれば、あとはその「正しいオペレーション」が強化されるように、ワークフローを整備して仕組み化し、システムを改修して自動化する。
その「正しいオペレーション」の積み重ねの結果として、さらにアクティビティが溜まっていくという循環を描く。
この循環を通じてデータを活用した「良いオペレーション」が作られていく。
抽象的な概念になるので、ひとつずつ順を追って具体例と共に詳述していく。
1. アクティビティ
ここでいうアクティビティは社内での活動やアプリケーション上のユーザーの動き、リアルビジネスであれば店舗でのお客さんの店舗内の活動全てを含む。
例えば下記のようなものである。
カテゴリ | アクティビティ |
---|---|
社内外でのオフライン活動 | 顧客へのカスタマーサポート対応 |
採用面接の実施 | |
上長とメンバー間での1 on 1 | |
コミュニティミートアップの開催 | |
見込み顧客への電話商談 | |
チームでのミーティングの実行 | |
客先での商談 | |
アプリケーション上のアクティビティ | アプリの起動・ログイン |
商品の検索 | |
商品の閲覧 | |
商品の購入 | |
キャンペーンLPの閲覧 | |
リファラルの発生 | |
Push通知の配信 | |
リアルビジネスでの活動 | 来店・入店 |
商品を手に取る | |
店員と会話 | |
決済 | |
商品の説明 |
上記の事例を見ると分かるように全ての活動であり、1 on 1や社内ミーティングのような完全に内部向けで内部に閉じた活動であってもアクティビティに該当する。
これは発生するイベント全てを包括する概念である。データ設計や分析、Webマーケティングに明るければ聞き慣れた言葉かもしれないが、ここで言うアクティビティは日々の活動の中で「発火したイベント全て」を指している。
2. センシング
次はセンシングである。センシングとはなにか。
センシング(=sensing)とは感知することである。センサー(=sensor)をイメージするとわかりやすい。
1つめのステップ、アクティビティの発生を感知する仕組みを作ることを意味している。
このセンシングを成功させるには、下記の3つのポイントが重要になる。
まずは感知の仕組みから説明する。
2-1. 感知の仕組み
このステップが司るのは、アクティビティの発生をどう感知するか、である。
ここでは、どんな手法でもツールでも構わないので、アクティビティが発生したことを漏らさないことが重要だ。
先程の事例に沿って具体例をあげると、下記のようになる。
カテゴリ | アクティビティ | センシング |
---|---|---|
社内外でのオフライン活動 | 顧客への電話サポート | 通話ツール, CRM管理ツール |
採用面接の実施 | 管理シート, カレンダーの予定 | |
上長とメンバー間での1 on 1 | 管理シート, カレンダーの予定 | |
コミュニティミートアップの開催 | 管理シート, カレンダーの予定 | |
見込み顧客への電話商談 | 通話ツール, CRM管理ツール | |
チームでのミーティングの実行 | 管理シート, カレンダーの予定 | |
客先での商談 | CRM管理ツール, カレンダーの予定 | |
アプリケーション上のアクティビティ | アプリの起動・ログイン | 行動ログ |
商品の検索 | 行動ログ | |
商品の閲覧 | 行動ログ | |
商品の購入 | 行動ログ | |
キャンペーンLPの閲覧 | 行動ログ | |
リファラルの発生 | 行動ログ, アプリケーションDB | |
Push通知の配信 | 実行ログ | |
リアルビジネスでの活動 | 来店・入店 | 管理シート, 人感センサー?? |
商品を手に取る | ??? | |
店員と会話 | ??? | |
決済 | 帳簿 | |
商品の説明 | ??? |
当該アクティビティが発生したことがわかり、その内容が記録できればよいので、やり方は何でも良い。
メインのワークフローに沿って最も効率的で運用負荷が限りなく0に近いセンシングの方法が望ましい。
メインフローから外れて運用負荷がある行動は習慣化が難しく、人間には継続できない。
2-2. 内容の定義
上記のような仕組みでアクティビティの発生を感知したあとは、要素を記録する。
リアル店舗で「商品が購入された」というアクティビティだけがわかっても何の役にも立たない。
そこで本当にほしいのは周辺の情報である。
例えばリアル店舗の洋服屋を例に取ると、下記のような内容が考えられる。
- 買ってくれたのはどんなお客さんか(年齢, 性別, 職業, 家族構成, 年収 etc.)
- 誰向けに買ったのか(自分で使う, パートナーや知人へのプレゼント, イベントの景品 etc.)
- 購入した日時
- 購入した店舗
- どの店員から買ったのか
- 来店回数
- 購入回数
- どの商品を買ったのか
- 何点買ったのか
- あわせて購入した商品はなにか
- 誰と一緒に来店していたか
などなど
当然、これらの要素はアクティビティごとに異なるので、アクティビティごとに記録する内容を定義することが重要である。
2-3. 要素の取捨選択
次に定義した内容を精査する。
感知した内容をすべて記録するのは現実的ではない。
オンラインのアクティビティでれば、その分実装するコストが増え、取得したあとも管理コストがかさむし、オフラインのアクティビティであれば、全ての情報を記録するの不可能に近い。
この先のステップにある「分析」でなにを知り、どう行動を変えるのかを踏まえて、どの要素を取得するかを取捨選択する必要がある。
3. データの整理
次のステップはデータの整理である。
データの整理はセンシングしたアクティビティの情報を、この次のステップで行う分析に耐える適切な形に加工し、適切な場所に格納することを意味する。
このステップには、初期段階の格納場所や格納フローの設計も含まれるが、そういった初期設計のような、いわゆるデータアーキテクチャやデータパイプライン構築等の詳細についてはここでは触れない。
データの基盤を作るかという話は各社の思想がわかれるので、具体例として私が運営する会社であるドクターズプライムの例を上げる。
ドクターズプライムではELTというデータ処理の方式を採用している。
ELTとはExtract, Load, Transformのアクロニムである。データを抽出し、読み込み、整形するといった順番で処理をする方式である。
※別の方式として、抽出して整形してから読み込む、ETL(Extract, Transform, Load)がある。
ELT/ETLについては、下記の記事が2つの違いをわかりやすく説明している。
社内のデータを分析・活用する際は「ETL」、もしくは「ELT」を利用すると効率化を図れます。しかし、ETLとELTの違い…
ドクターズプライムのデータの整理・格納プロセスは、ELT方式を採用し、下記のフローを辿るように設計されている。
フロー | オフラインのアクティビティ | オンラインのアクティビティ |
---|---|---|
1. センシング後の抽出(Extract) | Google SpreadSheets | Cloud Logging |
2. 読み込み(Load) | Google BigQuery | Google BigQuery |
3. 加工・整形(Transform) | Scheduled Query | Scheduled Query |
4. 最終格納場所 | BQ内のデータマート | BQ内のデータマート |
このように、データをセンシングしたあとに、そのデータを抽出、読み込み、整形というフローを経て、最終的に分析に耐える形式でデータが格納されることを目指している。
4. 分析・モニタリング
ここまできてようやく実際の分析である。
分析については、手短に書くにはあまりに知られすぎていて、詳細に書くには紙幅が足りないので、ここでは割愛する。
モニタリングというのは、センシングしたアクティビティをダッシュボードに表示させて、主要指標の変化を監視することである。
大掛かりな分析だけでなく、このデイリーのモニタリングで変化に気づき、適切なアクションを取っていくことも多い。
5. 正しいオペレーションの発見と定義
実際に分析を行った結果、「課題を解決し、成果を最大化できるオペレーション」が定義される。
例えばそれは、「お問い合わせフォームの受信後5分以内に架電すること」や「ユーザーに送るメールにユーザーの氏名(◯◯さんなど)を含めないこと」かもしれない。
また、このモデルでは「分析」と「正しいオペレーションの発見と定義」のステップを分けているが、これは分析すれば必ず「正しいなにか」が分かるわけではないからである。
分析は魔法ではない。データを使えばなんでも分かるというわけではなく、データの質や量によっては何も分からない、確からしいことは何も言えないということは、日常茶飯事である。
6. 仕組み化・自動化
正しいオペレーションが発見され、具体的に定義されたあとは、その「正しいオペレーション」を行う回路が強化されるように固定化しなくてはならない。
オフラインのオペレーションであれば、それはマニュアルへの組み込みであったり、ワークフローからの削除であったり、仕組みを整える必要がる。
また、オンラインのオペレーションであれば、システムによる自動化などを通じて、そのオペレーションが固定されるようにする。
ここで大切なのは、個人の能力やスキルに依存させない「属人化させない」ことである。
仕組み化や自動化を通じて、どんな状況でも正しいオペレーションが完遂されるような、業務レベルの平準化が必要である。
平凡な企業はデータのセンシングと整理に失敗する
このループのどこで躓くかというと、「センシング」と「整理」のステップであると考えている。
センシングについては言えば、データの取得ができておらずデータの欠損が起きている、自由記述の形式になっており分析を想定されたデータになっていないといった問題が挙げられる。
また整理について言えば、データが適切な場所に整理された形で格納されていないため、各自が勝手にインポートした「野良データ」を使って分析がされており、データの定義が揃わず、分析者によって結論がバラバラになり、意思決定が出来ないと言った問題などが考えられる。
感知できないものは整理できない、整理できないものは理解できず、理解できないものは対応できないのである。
適切なセンシングと整理を行うには
適切なセンシングと整理を行うためには、ハード・ソフト両面の条件が揃う必要がある。
その条件とは「データ基盤の整備」と「データリテラシーの浸透」である。
データ基盤の整理については、下記のようなトピックが考えられるが、データエンジニアやデータアーキテクトといった専門職の方々の説明のほうが、正確かつ実践的であるため割愛する。
- 場所・タイミング(Where/When)
- データを取得する場所の決定
- 定義(What)
- データの定義の明確化
- 方法(How)
- データベース選定
- パイプライン設計
- ETL/ELT
- データベース内のルール設計
もう一方の「データリテラシーの浸透」とはどういったもので、なぜこれが重要なのかについては、次回、第三弾のポストとして詳述していく。
これはなにか 「コピーされない競争優位の築き方」と題して2019年末に社内向けに公開した資料をベースに、コピーされない競争優位を作るために重要な3つの要素と、それが生まれるプロセスを図解したものである。 本テーマは下記のような3部構成と[…]
まとめ
- 「良いオペレーション」を実現させるためには、正しいオペレーションの回路を強化して積み重ねることが大切
- そのためにまずはアクティビティを感知して、必要な情報を取得し、適切に整理・格納する仕組みが必要
- そういった仕組みを作るためには、データ基盤の整備とデータリテラシーの浸透が重要である
Twitterもやっています。よかったらフォローしてください!
一緒に働くメンバーを募集しています
「救急車のたらい回しをゼロにする」というビジョンの実現に向けて、病院向けのSaaSプロダクトおよび、医師/病院間の最適なマッチングを提供するマッチングプラットフォームを展開する会社を経営しており、創業期のメンバーを募集しています。採用情報はこちらから。興味を持っていただけた方はフォームからでもTwitterからでもお気軽にご連絡ください!