More Related Content
Similar to 事業の進展とデータマネジメント体制の進歩(+プレトタイプの話) (20)
More from Tokoroten Nakayama (20)
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
- 2. 自己紹介
• 中山心太(ところてん)
• @tokoroten
• 株式会社NextInt 代表
• 著書
• 仕事ではじめる機械学習
• データサイエンティスト養成読本ビジネス活用編
• お仕事
• 機械学習システム構築に関する技術顧問
• 各種スポットデータ分析業、ビジュアライズ
• 業務改善コンサルティング、DX支援
• 新規事業コンサルティング、PoC構築
• ゲームディレクター
2
- 8. マクドナルド サラダ問題
• マクドナルドは2006年に「サラダマック」を販売、大失敗
• https://www.itmedia.co.jp/business/articles/2007/25/news010.html
• 顧客アンケートを実施
• マクドナルドにヘルシーなサラダがあったら買いますか?
• 人はアンケートでは「ありたい姿」を想像して答える
• アンケートの回答は「実際の行動」とは異なる
• 市場調査による回答には「嘘」が含まれる
• 人間は合理的ではない、人はマックにジャンク・背徳感を求める
• だからこそ顧客が自分の意思で財布を開く「痛み」を伴う市場調査が必要
• アンケートの回答者は「観客」、身銭を切らない限り「顧客」ではない
8
- 13. ファサード型(素晴らしい玄関型)
• ファサードとは、都市景観における玄関の重要性に関すること
• 機能する入口を作り、機能はするが裏側には何もないこと
• 「ニセの玄関」との違いは、購入ボタンが機能するかどうか
• 「ニセの玄関」の場合「売り切れです」と表示される
• カーズダイレクト
• 実際にクレジットカードで車が購入できるサイトを作ってみる(1999年の話)
• 一晩で4件の注文があり、サイトを即閉鎖
• 自動車をディーラーから4台仕入れて顧客に届けた(輸送費で赤字)
• 「ディーラーで車の実物を見なくとも購入する顧客がいること」を確認
• 一台も車を仕入れることなく、オンライン自動車販売事業が有望であることを確認
• グルーポンのMVP
• Wordpressでブログを作り「購入希望の方は電子メールをください」と書く
• 人数が集まったら、メールで割引クーポンを送付、これで市場があることを確認
13
- 14. 潜入者型
• Upwell DesignのWalhub
• フックが付いた利便性の高いスイッチカバーを
発明
• 実際にIKEAに「勝手に」置いてみて、顧客の
反応をテスト、実際にレジに持ち込まれること
で、顧客に購入意思があることを確認
• 実際にIKEAに置いてみて実証実験を行った際
のビデオも存在
• https://vimeo.com/79313674
• 合法的に行うには?
• 個人経営のホームセンターや、書店、ネット
ショップなどに謝金付きでテストマーケティン
グの協力を依頼する
14
https://www.core77.com/posts/25912/upwell-
designs-ikea-hack-is-as-well-designed-as-the-
product-theyre-promoting-with-it-25912 より引用
- 22. グロース期
• 月商1000万~5000万円くらい
• サービスを落とすことが許されなくなる
• 「分析クエリを流したら、DBが死にました」は許されない
• 負荷対策でフロントサーバが分散するようになる
• 開発者・デザイナ10~20人、データ分析者1人くらい
• データインフラに強いインフラエンジニアが1人
• 本番環境から分析環境への隔離が行われる
• 本番DBのリードレプリカの利用
• 本番DBのデイリースナップショットの利用
• ロードバランサが入り、サーバのアクセスログがログ専用DBへ
• AmazonのAthenaやRedshift、GCPのBigQuery等の利用
22
- 23. グロース期の環境
• データ分析屋の仕事
• BIツールを利用したダッシュボードの作成、モニタリング
• ユーザの離脱ポイントの分析、離脱予測から離脱原因の分析
• サービスのリアルタイム分析
• 他社レコメンドツールの導入や、マーケティングタグの導入
• 経路別LTVの計算、キャンペーンの効果測定
• 分析システム
• 本番DBのリードレプリカを利用したり、スナップショットDBを利用して、
本番環境に影響が出にくい分析環境を構築
• 本番DBへのSQL単体で収まらない複雑な分析をするために、分析用のサーバ
ができる
• 計算時間が長くなってくると、分析サーバ上での簡易的な中間テーブル(計算キャッ
シュファイル)の作成が行われ始める
23
- 25. テックベンチャー期
• 1サービスあたり、月商で1億円以上
• 1チームの開発者25人、データ分析2人、マーケ2人程度 × nチーム
• データインフラ専門が2人程度(サービスあたり0.5人程度)
• プロダクト部門、分析部門とは別にマーケ部門ができる
• マーケ部門を前提としたツールの導入が必要になる
• 分析のためのクエリが書けない、プログラムの書けない人向けの、
リッチなBI、リッチなETLツール、他社と連携するための仕組みが必要
• マーケが他社と連携するためのETLツールの整備などが必要になる
• サービスの管理画面やユーザサポートへのデータ提供なども発生
• 中間テーブルの整備が必要になる
• 複数のサービスを同時に見る必要が出てくる
• RDB以外のデータが増えてくるので、表の形式にしたい
25
- 26. テックベンチャー期の環境
• データ分析屋の仕事
• 複数のサービス間の比較が可能なKPIやモニタリングの定義
• レコメンドシステムの構築
• データ分析そのものが価値を生み始める
• ネガティブデータの記録(表示したけどクリックされなかった)
• データパイプラインの安定性が要求される
• 分析システム
• 各サービスの生データを置くためのデータレイク層が整備
• S3やGCSなどの、オブジェクトストレージ
• 各種中間テーブルがDWH層として整備
• データレイクに対して、クソクエリを流して、クラウド破産を経験し、
コスト削減のために中間テーブルの整備を始めることが多い(と思われる)
• 分析サーバの中で動いていたバッチ類がETLツールに取り込まれ、
依存関係を考慮したパイプライン管理され始める
26
- 28. 大企業期
• 1サービスあたり月商10億円以上、それが複数
• データの使い方が極めて多岐になってくる
• ユーザの接点の多様化、オンラインデータとオフラインデータ
• 他社へのデータ提供、顧客への提供
• サービス管理画面、サポートセンターへのデータ提供等
• DWH層の肥大化でクラウド破産を経験
• DWH層に対して、直接操作をさせたくなくなる
• ユーザをランダムサンプリングした統計用の小規模なDWHの構築を模索
• 財務・経理・監査・アクセスコントロールがシステム化される
• 個人情報保護のためにETLの段階で氏名等の重要な個人情報は潰す
• データの不変性、一方向性が強く要求される
• データのアクセスコントロールが要求
誰が何を見るべきなのかを厳密に管理、不必要なデータにアクセスさせない
• データ分析インフラの予算を事業ごとに費用分配したい
28