presalesfordatascientist.pdf

Transcript

1. ©2019 Crosstab Mitsuru Urushibata All rights reserved データサイエンティストのための プリセールス入門 2018年 12月 03日 @kasegu_data
2. ©2019 Crosstab Mitsuru Urushibata All rights reserved 2 自己紹介 @kasegu_data 名前 数学専攻修士修了後データ分析会社を経て広告会社へ 経歴 10年以上データ分析業務に従事。渡り歩いた業界は金融向け分析 広告 無職 広告と多様。 お金を稼ぐ事ができるデータサイエンティストを目指し、実践してきた。データサイエンティストとお金という テーマで日々キャリアを模索中 PR データ分析とビジネスのつなぎこみ データクリーニング 得意領域 *本スライドの内容は個人の見解であり、所属する組織の公式見解ではありません
3. ©2019 Crosstab Mitsuru Urushibata All rights reserved 3 1.はじめに 2.提案フェーズ 3.プレアナリティクスフェーズ 4.最後に
4. ©2019 Crosstab Mitsuru Urushibata All rights reserved 4 背景と目的 データサイエンティストが働く領域は様々です。その領域ごとに必要とされるスキルも異なります。例えば自社のサービス開発であれ ばハッキングや解析スキルが、顧客への納品を前提としたプロジェクトではそれだけではなく顧客との折衝スキルも必要となります。 一方で巷でのデータサイエンティストへの教育は前者-すなわちハッキングや解析スキル-に重きが置かれる事が多い気がします。本 スライドではそれを受け、データサイエンティストとして顧客向けのプロジェクトを行うために必要なスキルを簡単に解説したいと思いま す。具体的にはプリセールス（提案/プレアナリティクス）段階でのデータサイエンティストに求められるスキルを扱います。 他 社 向 自 社 向 B to C B to B Webサービス 法人部 門 アドテク界隈とか 伝統的大企業 原則ない 分析専門会社 広告代理店とか ハッキング/解析スキル 顧客折衝/セール ス *データサイエンティストの働くフィールドを2軸で切ってそれぞれのフィールドに重要なスキルを示した（勿論全部ある程度必要だが特にと思われるもの）
5. ©2019 Crosstab Mitsuru Urushibata All rights reserved 5 プリセールスの重要さ エンジニアにはプリセールスエンジニアという職種があります。定義は色々ありますが転職サイトの(*)言葉を借りると [プリセールスとは、システム構築やソフトウェア製品を販売・導入する際に、営業担当に同行し、ＩＴの技術的な知識を用いて、 営業担当をサポートする職業です。]です。要するには専門的な知識を用いての営業支援を行う職種です。 当然データサイエンティストも同様にプリセールスデータサイエンティストというのがいて然るべきではないかというのが私の考えです。プ リセールスの有無はプロジェクトの成否を分けるといっても過言ではないです。 *出典 https://www.elite-network.co.jp/dictionary/presales.html 顧客 営業 データサイエンティス ト 顧客 営業 データサイエンティスト 体 制1 体 制2 • Q:期待値コントロールが難しい。例 えばモデルの精度に対しての顧客希 望が現実的でない場合。 • C:工数見積もりがざっくりしすぎて価 格が不適切になる。 • D:営業段階で潰しておくリスク （データが使い物にならないとか） が後工程で発覚して納期遅延に関 わる。 上の逆になる！？ 体制の違いによるプロジェクトへの影響をQCDごとに示した
6. ©2019 Crosstab Mitsuru Urushibata All rights reserved 6 体系化されたノウハウが必要だが… 一方でデータサイエンティストのための営業といった論点に触れている書物は少ないと感じます。従って本スライドでは世間にあまり転 がっていないノウハウ、すなわち営業提案の段階でのデータサイエンティストが行動指針と具体的なノウハウを説明します。 (引用) データサイエンス協会 http://www.datascientist.or.jp/news/2014/pdf/1210.pdf 〇関連書籍 PRML 赤本 統計学入門 その他ググれば沢山 〇関連書籍 Sql関連書籍 Python R その他ググれば沢山 〇関連書籍 ビジネスを絡めた本はある がダペンポート教授のよう なCMO/CEO向けの本が 多い。 本スライドで提案する営 業とのかかわり方みたいな ものは少ない
7. ©2019 Crosstab Mitsuru Urushibata All rights reserved 7 データ分析プロジェクト 概要 合意形成 ポイント 合意形成 ポイント 合意形成 ポイント * アウトプットは必ずしも明文化されている必要はない 提案 プレアナリティクス 分析 成果物作成 • プリセールスヒアリング • 期待値のコントロール • 成果物の設定 • 提案書作成支援 • 分析方向性立案 • データ連携方法確 認 • 分析工程の合意形 成 • データ受領/確認 • マスターデータ作成 • 基礎集計 • モデリング • スコアリング • 報告書の作成 • モデル定義書の作成 • スコアリングデータの 提供 サブタ スク 主ア ウト プット • 提案書 • スケジュール • 価格 • 体制 • 成果物 • 分析方向性 • データ連携図 • 分析工程図 • データ一覧 • データ作成手順 • 基礎集計表 • モデル概要 • スコアリング概要 • 最終報告書 • 一連のアウト プットを原則す べて掲載 • 実装PJの場合モデル 定義書 • スコアリングデータ 主タス ク データ分析のプロジェクトのフェーズは大きく4つに分けることができます。本稿では前2つのフェーズに絞って解説します。 本稿の議題 いわゆるデータサ イエンティストが 得意な領域
8. ©2019 Crosstab Mitsuru Urushibata All rights reserved 8 （参考）データ分析プロジェクト 概要 参考までですが、当プロジェクト概要はデータ分析のフレームワークであるCRISP-DMと以下のように対応してます ビジネス理解 データの 収集/理 解 データの 準備/加 工 集計によ る関係性 比較 数理モデ リング （予測/ 分類/最 適化） 結果の可 視化 結果の評 価/展開 超重 要 超重 要 重要 まあ まあ 重要 超重 要 (引用) 株式会社ギックスHP http://www.gixo.jp/blog/3715 より 提案 プレアナリティクス 分析 成果物作成 • プリセールスヒアリング • 期待値のコントロール • 成果物の設定 • 提案書作成支援 • 分析方向性立案 • データ連携方法確 認 • 分析工程の合意形 成 • データ受領/確認 • マスターデータ作成 • 基礎集計 • モデリング • スコアリング • 報告書の作成 • モデル定義書の作成 • スコアリングデータの 提供 サブタ スク 主タス ク
9. ©2019 Crosstab Mitsuru Urushibata All rights reserved 9 1.はじめに 2.提案フェーズ 3.プレアナリティクスフェーズ 4.最後に
10. ©2019 Crosstab Mitsuru Urushibata All rights reserved 10 提案 フェーズ サブタスク 10 * outputは必ずしも明文化されている必要はない プリセールスヒアリング • ヒアリング • 何を • いつまでに • どのデータを 使って • いくらで 期待値のコントロール • 顧客の目的/目標確 認 • できること、できないこ との切り分け • 顧客目標に合わせた 分析方向を提案 成果物の設定 • 成果物を設定 • 分析報告書 • モデル定義書 • スコアリング データリスト 提案書作成支援 • 左記の内容を踏まえて 「スケジュール」「体制」 「価格」「成果物」を盛 り込んだ内容にする • ヒアリング情報 • あれば顧客情報 • 名刺 • IR • あればRFP • 顧客目標達成と現状の ギャップ • プロジェクト遂行のボトル ネック • ギャップとボトルネックを解 消した簡易的なロード マップ • 想定成果物一覧 • 想定成果物イメージ • 提案書の一部（全体は 営業担当者作成） input output 提案フェーズは4つのサブタスクに分けることができます。 特に成果物の取りきめは重要です。
11. ©2019 Crosstab Mitsuru Urushibata All rights reserved 11 提案 フェーズ サブタスク プリセールスヒアリング(1/2) 11 * ヒアリングの技術については別の本や/研修資料を参照 顧客ヒアリングにより、顧客の視点での目標等を整理します。ヒアリング項目は概ね顧客の目標に関わる内容と制約（データ/納期 /予算/）に関わる内容が適切です。顧客によってはRFPがある場合はそれも活用します。 顧客RFP等 顧客ヒアリング ヒアリング項目 アウトプット 項目 内容 顧客 目標 プロジェクトの目的その もの 何をす るか 目的達成のためのする べきこと どのよう に その方法論 データ 使用する（できる） データ 納期 プロジェクトの納期 予算 プロジェクトの予算 具体例 顧客情報を活用したマーケティング基盤の構 築 ・顧客を複数のクラスタに分類 ・潜在顧客をクラスタに振り分ける ・外部データすべてを変数にクラスタリングを行う・ク ラスタ数は10個 ・CRMデータ ・トランザクションデータ 3週間納品 xxx万 インプット
12. ©2019 Crosstab Mitsuru Urushibata All rights reserved 12 提案 フェーズ サブタスク プリセールスヒアリング(2/2) 12 制約事項を考慮し顧客の要望とできることのギャップを分析します（この時点でギャップがないということは滅多にない）まずはhow の部分にフォーカスします。 制約事項 顧客達成目標 (Object) ・顧客情報を活用したマーケティング基 盤の構築 何をするのか？ (what) ・顧客を複数のクラスタに分類 どのように (How) ・CRMデータを変数にクラスタリングを行う 制約が与える影響 【納期】 ・3週間納品 【データ】 ・CRMデータ ・トランザクションデータ ・潜在顧客をクラスタに振り分ける ・Aone全体に拡張するモデルを作成 ・クラスタ数は25個 【予算】 ・xxx万 想定されているデータだけではできない 多すぎるため、工数的に足りない 1 2
13. ©2019 Crosstab Mitsuru Urushibata All rights reserved 13 (例1) 納期/予算のギャップ 13 【納期/予算 由来のギャップ解消】 基本的に工数の削減が必要です。目標達成のために過剰といえる分析数を減らします。但しで過剰であることの根拠を説明する 必要があります。 削減方法の一般論を論じることは残念ながら困難であるが、2章分析方向性立案で学ぶ内容でいくばくか対応可能です。 分析1 分析2 分析3 顧客要望 必要十分な工数 1
14. ©2019 Crosstab Mitsuru Urushibata All rights reserved 14 (例2) データのギャップ 14 【データ由来のギャップ解消】 実はデータ制約は緩和できる可能性があります。顧客がヒアリング時に回答したデータは顧客が保有している全データでなく、実はと りそこねていたものがあったりするのです。したがってデータ制約のギャップ解消でまずやるべきことは受託側から必要なデータの有無を 再度確認することです。 (A) 顧客が真に利用できるデータ (B) ヒアリング時に顧客 が認識していたデータ (C) あれば 分析可能デー タ (A)-(B)が顧客の認識の外にあるデータ。このようなものが存在してしまう理由に「担当になったばかりで不慣れ」「分析にそんなデー タ必要とは思わなかったという早合点」などがある (C)∧(A)-(B)存在すれば、分析可能となる 例1) ヒアリング時に顧客データに決済情報がないと聞いていたが、後から担当者の勘違いであったと判明 例2) ヒアリング時必要ないと担当者が思いクッキー情報の有無に言及していなかったが、実は重要なデータであった 2
15. ©2019 Crosstab Mitsuru Urushibata All rights reserved 15 提案 フェーズ サブタスク 期待値コントロール(1/3) 15 前項のギャップ解消の代替案を適用。顧客の期待値は高すぎず、低すぎずにコントロールすることができます。 代替案を適用 どのように (How) ・CRMデータを変数 にクラスタリングを行 う ・Aone全体に拡張 するモデルを作成 ・クラスタ数は25個 想定されているデー タだけではできない 多すぎるため、工数 的に足りない 1 2 当初のとおり問題な く実行できる クラスタ数は10個に 変更 クラスタは少量 でも問題ない 旨説明 実はデータが あった 期待値の推移 初回ヒアリング時 ギャップ露見時 代替案提示時
16. ©2019 Crosstab Mitsuru Urushibata All rights reserved 16 提案 フェーズ サブタスク 期待値コントロール(2/3) 16 簡易ロードマップ作製し期待値をFIXさせます 簡易ロードマップ この際詳細なガントチャートは不要、メモレベルでいつから 各々の工程がどれぐらいで終わるかのみで十分。重要なの は顧客/受託側が現実的な進め方をすり合わせること 期待値の推移 初回ヒアリング時 ギャップ露見時 代替案提示時 【簡易ロードマップ】 1.データ準備 ・ファイルで受領予定。csv,tab可能。受け渡しはクラウド（情シス要確 認いついつまで）12月1日（月）予定 ・データロード 2.データクリーニング ・12月2～2日程度。都度不明点を確認する ・基礎集計を行う5日程度 →第一回めのうちあわせ（集計内容と今後の分析方向性すりあわせ） 3.分析開始 ・CRMデータからクラスタ10個作成（←事前のギャップ分析を行っている ので、リスクは回避されている） ・拡張する（これも同様前項で現実的な方法に修正したため、問題なく 進行できる） 双方で7日程度 →2回目のうちあわせ（分析結果のオーソライズ、最終報告書の章立てす りあわせ） 4.報告書作成 5日程度 FIX
17. ©2019 Crosstab Mitsuru Urushibata All rights reserved 17 提案 フェーズ サブタスク 期待値コントロール(3/3) 17 howの中で代替案がないとき、上の階層であるwhatの代替案を考えます。すべてのwhatで代替案がない場合顧客目標が達成 不可能となり、期待値は0になります。しかし達成できないものを受注するリスクを排除しています。 期待値の推移 初回ヒアリング時 ギャップ露見時 代替案無し 制約事項 顧客達成目標 (Object) ・顧客情報を活 用したマーケティン グ基盤の構築 何をするのか？ (what) ・顧客を複数のク ラスタに分類 どのように (How) ・CRMデータを変 数にクラスタリング を行う 【納期】 ・3週間納品 【データ】 ・CRMデータ ・トランザクション データ ・潜在顧客をクラ スタに振り分ける ・Aone全体に拡 張するモデルを作 成 ・クラスタ数は25 個 【予算】 ・150万 想定されている データだけではでき ない 多すぎるため、工 数的に足りない 1 2 代替案無し
18. ©2019 Crosstab Mitsuru Urushibata All rights reserved 18 提案 フェーズ サブタスク 成果物の設定(1/2) 18 成果物の取り決めを行います。目的としては受託側としては追加での納品等がないようにゴールを定める意味合いの方が強いです。 先に明示していない場合、データ加工あとのデータや加工スクリプト、モデル定義書と追加で対応せざるを得なくなります。 *ただし業務委託契約においても準委任契約であれば検収が不要であるはず（要法務確認）。したがってシステムと異なりでき上りが想定できないデー タ分析プロジェクトでは準委任契約の方がリスクが少ない。 作成データ 作成スクリプト ドキュメント 打ち合わせ資 料 最終報告書 成果物 概要 主なプロジェクト内容 モデル定義書 学習データ/スコアリングデータ Sql/Python/Rコード SPSSストリーム SASスクリプト 定例及び毎回の打ち合わせ資料 PJ全体の統括な資料 パラメータ及び数式からなる書 広告/CRMターゲティング モデル開発/実装 PoC 全体で必要 PoC ビジネス企画支援 モデル開発/実装 作成負荷 低 中 中 高 高 レポート 分析結果自体 広告/CRMターゲティング 低～中 （変動）
19. ©2019 Crosstab Mitsuru Urushibata All rights reserved 19 提案 フェーズ サブタスク 成果物の設定(2/2) 19 一方すべての成果物を作成すると負荷が大きいため、ここではおおよそプロジェクトの特性ごとに必要とされる成果物をPJ内容ごとに 示します。 これをもとになるべく負荷か低い成果物での合意形成を目指します。 広告配信 レポーティング PoC モデル開発/実装 〇 △ △ △ 〇 打ち合わせ資料 △ △ 〇 最終報告書 〇 △ モデル定義書 〇 レポート 〇 ドキュメント 作成データ 作成スクリプト 成果物/PJ内容 〇:=ほとんど要求される △:=たまに要求される
20. ©2019 Crosstab Mitsuru Urushibata All rights reserved 20 提案 フェーズ サブタスク 提案書作成支援(1/2) 20 原則提案書は営業担当者が主な作成手として我々はそれを支援する立場となります。 提案内容でも特に分析担当者が資するものとして、スケジュールと体制図があります。 ここでは非常に簡易的なスケジュールを以下に示しますが、詳細なものを要求される場合ももちろんあります。ここではガントチャート の作り方には立ち入らないため、分析担当者として提案書作成者に伝えるべきエッセンスのみに絞りました。 1.スケジュール 2.打ち合わせタイミング 3.バッファーの確保 上記３つは必ず織り込むようにします。 * 提案書の書き方の詳細にはこの本では触れない。あまりに膨大な量となり、本稿のスコープからはずれる。興味がある方は「受注を勝ち取るための 外 資系「提案」の技術---日本人の知らない世界標準メソッド 単行本（ソフトカバー） – 2015/3/20 式町 久美子 (著)を参照 大項目 中項目 1w 2w 3w 4w 1w 2w 3w 4w 1.データ準備 1.1.データ受領 1.2.データ読み込み 1.3.データ内容確認 2.データクリーニング 2.1.基礎集計 2.2.異常値処理 3.分析 3.1.相関分析 3.2.モデル作成 3.3.評価 4.報告書作成 4.1.ドラフト作成 4.2.オーソライズ 2017年12月 2018年1月 打ち合わせポイント
21. ©2019 Crosstab Mitsuru Urushibata All rights reserved 21 提案 フェーズ サブタスク 提案書作成支援(2/2) 21 体制作成。営業担当者がいれば一緒に作成します。主に我々は営業以外の体制を作成します。プロジェクト規模によるが、 PM(シニア)、メンバー（アソシエイト）×1-2名程度です。 顧客体制 分析体制 営業担当者 1名 PM シニア 1名 分析 アソシエイト 2名 データインフラ アソシエイト 1名 ・顧客折衝 ・会議体運営 ・契約書/請求書とりまと め ・プロジェクト管理 ・顧客折衝 ・レビュー ・成果物責任 ・データ集計 ・モデリング ・報告書作成 ・データ連携 ・データ格納 省略 * 一部の会社を除き、ほとんどが営業担当者がいるであろうから、データ分析者自らが行うことは少ないと思うが、本書はデータ分析者がマネジメントを行 うことができることを目標とするた、ヒト/モノ/カネに関することにも触れる
22. ©2019 Crosstab Mitsuru Urushibata All rights reserved 22 (コラム) 提案フェーズにおいての我々の役割 22 ➢ 提案フェーズにおいてのリスク回避 データ分析PJにおいてリスクとはどのようなものがあるだろうか？例えば分かりやすい例でいえば、少量データでの複雑なモデル作成 であったり、データ同志が紐づかない、大量のモデル作成による工数負荷、顧客と成果物認識の相違等のものがある。これらはすべ てPJのQCDを脅かすリスクであるが一方で、提案段階で把握し取り除くことができる物が多い。 例えば、顧客の初期の要望に「複数のモデルを作成して比較したい」というものがあったとき、ほとんどの場合で顧客目標達成より も過剰な要望、すなわちもっと少ないモデルで十分である事が多い。そのため少数モデル作成を提案し、工数負荷に関するリスクを 取り除くことができる。 ➢ 顧客の言いなりにならない 顧客要望が目標に対して過剰になりがちな理由は、データ分析に対しての理解不足が挙げられる。そのため目標達成のため保 守的（過剰）な要望をしてしまう。我々の仕事は顧客の言いなりにならずに目標のための必要十分条件を示すことである*。 ➢ 目標への必要十分条件の見つけ方 経験によるところが大きい。サーキットの1周目である若手は慎重になりすぎるくらいで丁度よい。PMやシニアの後をついて複数周 回して経験を積むのが良い。逆に言えば経験さえ積めば誰でもできるようになる。 * ダメなPMはMをやらないため、全てお客様の言う通りとしてPJを混乱させます。見つけたら逃げましょう。
23. ©2019 Crosstab Mitsuru Urushibata All rights reserved 23 1.はじめに 2.提案フェーズ 3.プレアナリティクスフェーズ 4.最後に
24. ©2019 Crosstab Mitsuru Urushibata All rights reserved 24 プレアナリティクス フェーズ フェーズ サブタスク 24 * outputは必ずしも明文化されている必要はない 分析工程作成 • 左記2つを踏まえて 具体的な分析の工 程図を作成 データ受領/確認 • データ受領/確認 • ファイルそのものの確 認 • 内容の確認 分析方向性立案 • 提案した内容を実行 するための分析方向 性を決める • どのデータでど のような分析 をして何をえる か データ受領方法確認 • データ関連のヒアリング • データはどこに あるか連携方 法は？いつま でに？ • ファイルでもら う • DBtoDB等 • 提案書 • ヒアリング内容 • 分析方向性 • データ連携図 • 左記2つのoutput • 受領データ • あればデータ定義書/ データフォーマット一覧 • 分析工程図 • 受領データ一覧 • UU数/レコード数 • カラム一覧 input output プレアナリティクスフェーズでは分析方向性と具体的なデータ連携等を確認し定めます。先の2つは場合によっては提案フェーズに入ります。 場合によっては提案フェーズ
25. ©2019 Crosstab Mitsuru Urushibata All rights reserved 25 プレアナリティクス フェーズ サブタスク 分析方向性立案(1/3) 25 分析方向性を定めるには以下のステップを踏みます（例はECサイトの場合） ① KGIの設定 ② KPIに分解 ③ コントロール可能変数特定 ④ 仮説立案 ⑤ 分析方向性立案と評価 売上/年間 訪問ユーザ 数 購買率 購買バス ケット単価 新規 ユーザ数 既存 ユーザ数 認知率 認知顧 客 注意/関 心ユー ザー数 検索 ユーザー 数 検索後 訪問率 検索率 注意/関 心率 潜在顧 客 今回はこちらは省略 KGI KGI分解図 分析アプローチstep output 課題策定より、売上/年間と設定 右図「KGI分解図」 訪問ユーザの特に新規ユーザ数が減少 傾向 ① 検索後訪問率が低い ② 認知率が低い（自社ECの） 何のために、どのような分析を行うか？ ※１ KGI（Key Goal Indicator）： 最終ゴールとなる指標 ※２ KPI（Key Performance Indicator）： KGIを達成するための実行の度合いを表す指標
26. ©2019 Crosstab Mitsuru Urushibata All rights reserved 26 プレアナリティクス フェーズ サブタスク 分析方向性立案(2/3) 26 KPIのうちコントロール可能変数を特定します。基本的に下に→がないものがコントロール可能変数。例外は「潜在顧客」のように 「打ち手」によってコントロール不可能のものは除きます。 （問題の簡単化のため、流入は全て検索のみとする） 売上/年間 訪問ユーザ数 購買率 購買バスケット単価 新規ユーザ数 既存ユーザ数 認知率 認知顧客 注意/関心ユー ザー数 検索ユーザー数 検索後訪問率 検索率 注意/関心率 潜在顧客 今回はこちらは省略 KGI コントロール可能変数 2 1 3 4 5
27. ©2019 Crosstab Mitsuru Urushibata All rights reserved 27 プレアナリティクス フェーズ サブタスク 分析方向性立案(3/3) 27 KPIのうちコントロール可能変数を特定します。分析方向性を立案し、現実妥当な分析案を作成します。（赤囲いのもの） 利用難度 低 利用難度 中 利用難度 高 利用データ アクセス解析ツールより 取得 CRMデータより取得 ①購買率 3rdパーティデータ等の 外部データ ② 検索後訪 問率 ③ 検索率 3rdパーティデータ等の 外部データ ④ 注意関心 率 アンケート情報で 取得 ⑤ 認知率 アンケート情報で 取得 仮説立案 • 顧客レコメンデーションが不足 • 訪問者の購買力が弱い • 当該サイトへの理解不足 • 広告の露出が少ないため認知が少 ない 比較軸 時間軸/他ECベンチ マーク 時間軸/他ECベンチ マーク 時間軸/他ECベンチ マーク 時間軸/他ECベンチ マーク 時間軸/他ECベンチ マーク • SEO対策が足りないため下位にラン キングされる • 入札ワードの最適化 分析方向性立案 • 顧客グループとアイテムグループを作り 高倍率を分析レコメンドモデルを作成 • 購買力が高いと想定される層を分析 • 注意関心率を分析。結果次第で広 告クリエイティブのA/Bテストを行う • 認知率を分析。結果次第でマスプロ モーションを行う • SEO対策 データ制約多し 分析結果を施策につなげずら い
28. ©2019 Crosstab Mitsuru Urushibata All rights reserved 28 プレアナリティクス フェーズ データ受領方法確認 28 分析案より必要なデータを特定しました。受領方法や受領日をすり合わせます。必要であればデータ連携図を作成します。 受領方法 受領日 形式 その他 アクセス解析データ クラウドでの受け渡し 2018年x月y日 tabファイル CRMデータ HD媒体 〃 〃 アンケートデータ CSVをメールに添付 〃 CSVファイル アンケートは先方が設計。x月y日まで回収 顧客環境 顧客DB アクセスデー タ.tab CRMデー タ.tab アンケート データ.csv ファイル チャネル クラ ウド 受託環境 分析DB 指定期間 内(*)のログ を抽出 指定期間 末のCRMの スナップショッ トを抽出 *一度指定期間を決めたら変えない。分析結果の再現性がなくなるため。
29. ©2019 Crosstab Mitsuru Urushibata All rights reserved 29 (参考) データ受領日デッドラインの設定方法 29 PERT図を用いてデッドラインを設定します。 作業開始予定日が12月15日の場合、遅くとも12月6日までにはデータ抽出作業を開始していなくてはならない。また遅くとも3つ のデータの抽出は12月13日までに終わっていなければならない。 データ 抽出 作業 開始 アン ケート 終了 データ 受領 アクセ スデー タ抽出 完了 CRM データ 抽出 完了 1日 1日 7日 1日 1日 1日 1日 12月 15日 12月 14日 12月 13日 12月 13日 12月 13日 12月6 日
30. ©2019 Crosstab Mitsuru Urushibata All rights reserved 30 プレアナリティクス フェーズ 分析工程作成 30 実際のデータを見る前に分析の工程を作成し、顧客との合意形成を得ます。 Raw data アクセスデータ CRMデータ アンケートデータ 加工図 アクセスデータをCRMデータを顧客IDで紐づ ける データクレンジング * クレンジングの詳細は実際にデータを受領 後に行った作業を書込む データクレンジング * クレンジングの詳細は実際にデータを受領 後に行った作業を書込む 分析 顧客とアイテムの協調フィルタリング分析を行 い、レコメンデーションルールを作成 購買力の高い層をデモグラ等で可視化 認知率/注意関心率を算出 デモグラ等層別で分析 認知率の高低と購買力の高低の2軸で分 析、狙うべきターゲットを特定 注意関心率の高低と購買力の高低の2軸 で分析、A/Bテストを行うターゲットを決定
31. ©2019 Crosstab Mitsuru Urushibata All rights reserved 31 プレアナリティクス フェーズ データ受領/確認 31 データを受領後にデータそのものが正しいか、破損はないか？データのカラムが正しいか、データの中身が正しいか等を確認。適宜受 領表を作成し顧客への確認を促します。 受領日 キー レコード数 ファイル名 最終更新日時 アクセス解析データ 2018年x月y日 顧客ID 1,234,567 xxx.tab xxxx CRMデータ 〃 〃 12,345 yyy.tab xxxx アンケートデータ 〃 ユーザーID 1,234 zzz.csv xxxx ▪ 受領データそのものの確認 ① ファイル数 確認事項 先方送付のファイル数に過不足ないか？ 項目 実際にあった例 圧縮/解答の際、ファイルが破損していた。確認し再度拠出 対応を依頼 ② キー キーはどれか？ 複数IDがある場合があり、なおかつ1つのものに2つ他のID がぶら下がっていたりする ③ レコード数 レコード数が妥当か？ エクセルなどでは1000万行以上であると強制的にカットされ てしまう ④ 最終更新日時 古いデータでないか？ 保存前の古いデータが送られてくることがある 【受領表】
32. ©2019 Crosstab Mitsuru Urushibata All rights reserved 32 プレアナリティクス フェーズ データ受領/確認 32 カラム内容を確認します。データクリーニングの段階で詳細に行うため。ここでは以下2つに絞って行います。 ▪ 受領データカラムの確認 ⑤ カラム仕様 カラム仕様書と同様化？ カラム仕様書にないものがあったりする ⑥ カラム定義 レイアウト表と整合性があるか？１＝男 ２＝女等の対 応があるか？ 過去２＝男、１＝女となっていたことがあった。また９９のよ うにレイアウト表にないものがあったりしたことがある ▪ カラム仕様書（あらかじめ必ず入手しておく）
33. ©2019 Crosstab Mitsuru Urushibata All rights reserved 33 1.はじめに 2.提案フェーズ 3.プレアナリティクスフェーズ 4.最後に
34. ©2019 Crosstab Mitsuru Urushibata All rights reserved 34 最後に 私は理系の大学院にいたため、まわりはあまり顧客と話すことが得意でないという人が多かった気がします。私もあまり得意ではな かったのですが新卒で就職した会社でそのような機会にめぐまれ自分が思うほど苦手でないことに気づきました。さらにハッキングスキ ルや解析スキルはkaggle上位者と比べると凡庸な能力しかなかったため、解析スキル×ビジネスコミュニケーションスキルを2つを兼 ね備えたデータサイエンティストになることが自分が生き残る道だと思い自身でノウハウを開発し体系化しました。 これは私のポジショントークになってしまうのですが、解析スキルやハッキングスキルのどちらかのみを売りとするデータサイエンティストサ イエンティストはほんの一握りのトップ以外あまり食えなくなるのではと思います。解析手法がパッケージ化されそれを利用することであ る程度コモディティ化が進み、とりあえず1点特化型のデータサイエンティストが過剰になるのではないかというのが理由です。 ですので皆様にはデータサイエンティスト協会の3つのスキルのうち2つを50点レベルでできるようになることをお勧めします。特に解 析スキルとビジネススキルの二刀流は解析/ハッキングより少数派ですので唯一の存在になれる可能性があります。そのようなものを 目指す方に本スライドがお役に立てれば幸いです。 ご精読ありがとうございました。 *本スライドの内容は個人の見解であり、所属する組織の公式見解ではありません