ある日突然文系営業がデータ分析担当者になったら

223 Views

February 10, 25

スライド概要

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

ある日突然文系営業がデー タ分析担当者になったら

2.

自己紹介 • 埼玉大学教養学部教養学科卒業 • 新卒から営業職として3社で合計13年ぐらいのキャリアを積んできました。 • 現在の会社は医療材料系のメーカーで9年ぐらい営業としてキャリアを積んできました。 • 事業部内でデータ収集の担当者を一人置くことになり、4年前に任命されました。 • 2年前に全社としてデータ活用の機運が高まり、管理部に異動し、今期から専門部署が 創設され、メンバーとしてアサインされました。 • 今回はデータ収集担当者に任命された直後からの話をしていきたいと思います。

3.

データ担当者任命直後 • マーケ担当者がそれぞれ個々人でデータ収集から分析、施策立案までを担っていた。 • マーケ担当者が繁忙なため、データ収集から一次加工までを誰かに分業することで 作業負担を軽減したいというのが当初の目的であった。 • 各担当者から現状収集している情報の一覧および収集、一次加工の要望がリストが 存在しており、まずはそれらの実装に取り組んだ。 • まずはそれらの実装に取り組むことになったが、特に一次加工は都道府県、 顧客属性別など細かい粒度での集計が非常に多く、エクセルで実行するには限界を 感じるデータ量であった。

4.

エクセルでの集計 • 関数処理が数百単位で存在しており、1シート更新するのに半日以上かかる。 • エクセルが不安定になるため、処理失敗や関数の消失が頻繁に起こる • 関数で規定されているため、毎月流し込むデータもきれいに加工して合わせる必要がある

5.

エクセルからの乗り換えの検討 • 2021年当時、統計系の主要言語として「python」「R」が有名だった • エクセルでマクロを使うことも検討したが、そもそもエクセルの限界を感じていたの で除外。 • PythonとRは大差なかったが、pythonのほうが汎用性に富む一方で自由度が高すぎ て学習コストが高いようにみえた。 • 特に関数の自作、classなどの概念は初見では理解できなかったため、最初から関数 が揃っているRを第1候補とした。 • 記法がエクセルライクで()の中に関数を入れ子で書けるのもエクセルから乗り換え るという意味でハードルが低かった。 • RstudioとRをインストールするだけで環境構築できるというのもわかりやすかった。 (Anacondaでのインストールがよくわからなかった)

6.

エクセルを基本に覚えることができます • 計算したいデータを「変数」に代入し、計算したい内容を「関数」で実行します。 エクセルで言うと ここが関数 エクセルで言うと ここが変数 数字を代入して 関数で計算する ここに答えが出てくる

7.

データ型もエクセルを下敷きに学習できました。 データフレーム データの型が混在している 行列 (文字の列と数字の列を混在させたりできる) ベクトル型 マトリックス 1列になっているもの リスト エクセルで言うと 複数シートにまたが るもの 行列になっているもの データの種類

8.

エクセルからの移行で苦労した点 • CSVファイルを読み込むときにエンコードが必要なことを知らず、文字化けの解消だけで3時間 ぐらいネット検索した。 • List型の取り扱いが上手くいかないことが多かった。Sapply(df[name==a,b])みたいな VLOOKUP風のことをすると複数該当してもいいようにリスト型でデータが入るため、扱いき れなくなった。Unlistした時にベクトルの長さが一定の値になることが保証されていない。 →一度CSVに書き出し、再度読み込むとdata.frameとして使いやすくなる。 • 変数の命名規則を作ったほうが扱いやすい→最初は「a,b,c」で順に変数を作ったが、手直しが 必要になったときに困る。 • 計算結果は変数に保存され、即時的に確認できない。また、直感的なデータ確認などはエクセ ルのほうが優れており、集計結果の確認をRだけで行うのは大変 Rだけに頼らず、エクセルも併用することでより使いやすくなる!

9.

Rに乗り換えてよかったこと • 処理の頑健性が向上した →そもそも記述したコードが消えずに保存される。列番号だけでなく、列名での 指定も可能になるため、カラム順序の変更にも対応可能になる。 • For構文によってデータ追加への対応が自動化出来るようになった。 →毎月列が追加されるようなデータでも整形する必要なく流し込めるようになっ た。商品ごとにエクセルに分けて出すなども数行の記載で完了する。また、商品 が追加、削除されても自動で追随してくれる。 • 同じ作業は何度でも繰り返せるため、一度確定した処理方法を見直す必要がなく なり、他の作業に集中できるようになった。

10.

エクセルで資料を提供していたが、ダッシュボードにし てほしいと言われる • エクセルで提供していましたが、ある日マーケティングの担当者からダッシュ ボードみたいにグラフで見たいという要望が来た。 • 会社側に伝えるが、予算はつかないと言われる。 • とはいえ、なにかできないか検索したところ、googleのサービスで DataPotal(現LOOKERSTUDIO)を発見した • 会社でGWSに入っており、ドライブの容量が無制限だったので、無料で使えそ う

11.

GCPにあるBIツール「LOOKERSTUDIO」 で実現しました • 閲覧ログが見れないなど一部制限があるが、無料 版でも基本的なBIの構築が行える。 • ノーコード操作である。 • Googleアカウントで閲覧・編集の権限管理を行う ことができる。 • フィルターによるデータの絞り込みが行えたり、 カーソルを当てたりドラッグなどで強調するなど、 閲覧者が動的にデータを見ることができる。 • 接続しているデータを更新することでグラフも自 動で更新することができる。

12.

構成図 取得データ データ加工・UP データ蓄積 データ可視化 • ローデータをエクセル(CSV)で取得し、Rで加工し、グーグルシートにエクスポート、 更新する。 • グーグルシートとLOOKERSTUDIOを接続し、グーグルシートのデータを更新すること で自動でLOOKERSTUDIOのグラフも更新される。

13.

エクセルを横型から縦型に変更する必要がある • LOOKERSTUDIOのデータ取り扱いはSQLに準拠しており、カラム志向でデータを作 成する必要がある。 • 一方でエクセルで取得するデータは人が見やすいように横型の設計で作成されている。 • そのため、spreadsheetに変換する前に横型から縦型に変換する必要がある • また、「年平均」「3ヶ月合計」などの計算はLOOKERSTUDIOでは難しいので、あら かじめ集計してデータに入れ込んでおく必要がある。 • Gather関数での変換が便利(本来はpivot関数でやるべきでしょうが)

14.

GOOGLEスプレッドシートの更新を自動化する • Googledriveパッケージとgooglesheet4パッケージを使用することでグーグル を操作することが出来る。 • それぞれのパッケージを使用すると、初回はアカウントの認証が要求される。

15.

2回目以降の認証 • 初回に設定を行っておくと、2回目以降はアカウントの数字を入力するだけで認 証される。 • drive_auth()関数、gs4_auth()関数で最初に認証しておくとコードの実行途中で 認証の入力待ちが発生しなくなり、便利。

16.

グーグルにアップする際の実際 • Drive_ls関数でドライブのフォルダ内を探索し、sheet_write関数でスプレッドシートを更新す る。 • Drive_ls関数は完全一致以外でも引き当たるリスクがあるため、命名規則に注意する必要がある。 • Drive_ls関数はフォルダ内の全ファイルを探索するため、フォルダ内のファイル数が多すぎると グーグル側のリクエスト制限に引っかかるため、注意が必要。 • また、スプレッドシート自体はdrive_create関数で作成することも出来るため、if文を使って 作れるようにしておけば、事前にファイルをつくる必要もなく、より省力化出来る。

17.

グーグルにファイルをアップするときの注意点 • ファイルが小さいときには処理速度が早すぎてグーグルのリクエスト制限に引っ かかる可能性があるので、sys.sleep()関数で速度を調整するほうが安定しやすい。 大体100秒前後を目安にすると安定する。 • また、forループの途中でエラー停止するリスクが高いため、tail()関数でベクト ルの長さから処理が終了した個数を引いた数を入力すると続きから始めることが 出来るので、便利。

18.

可能な限り一つのファイルに収める • LOOKERSTUDIO上でも複数ファイルの統合が出来るが、関数設定などができな くなるため、必要なデータは可能な限り一つのソースにまとめておいた方が良 い) • 商品マスタ、顧客マスタなどをもとに売上のドリルダウン、ドリルアップを出来 るようにしたいときにJOIN関数を使ってデータをまとめるのは必須。 • エクセルだとVLOOKUPで1セルづつ細々合体させなければいけないことを考え ると非常に便利だが、やれることの範囲が広がるがゆえにRDBに関する基礎知識 が必要となる。

19.

データの大きさをコントロールする必要がある • Googleスプレッドシートの仕様の都合上、データは1000万セルしか格納できな い。 • LOOKERSTUDIOとの連携を考えると、実際には5~600万セル程度に収めておか ないと連結されず、データ量の上限問題は深刻になりやすい。 • アップロードするデータがある程度以上の大きさになるとアップロード用にデー タを変換するのに非常に時間がかかり、メモリの消費量も負荷が高まるため、作 業時間という意味でも1ファイルあたりの大きさはコントロールしたほうがよい • データ量に制限が入るため、分析要件を詳細に設定して、表現を限定する必要が ある。

20.

基本情報技術者の取得 • ここまで来るとシステム設計に近い思考法が必要となり、エンジニアとしての基 礎を固める必要が出てくる。 • データサイエンティスト検定、G検定、OSS-DB試験など色々な試験はあるが、 汎用性や知名度、学習範囲の広さなどを考えると基本情報技術者試験を受験する ことが基礎知識の取得に最適だった。 • データ分析者として独り立ちするにはストラテジー、マネジメントやアーキテク チャの基礎知識も要求されるため、応用技術者試験も検討したほうが良いが、そ の前段階としても基本情報技術者の取得はベスト

21.

個別テーマの分析 • データの可視化までが出来るようになってくると、R本来の使い方である統計処 理の説明力が増加し、分析として実装しやすくなる。 • スプレッドシートを更新すれば改めてデータ配信を行わなくてもBIが自動反映し てくれるため、ワークフローとして分析を組み込むことも可能になる。 • 特に現職のような会社の場合、統計的素養がない方がほとんどなため実際にはBI によるグラフ化を工夫するだけでも多くの知見が得られるが、それ以外にもアソ シエーション分析であったり、重回帰分析での各説明変数の値から活動や顧客属 性の重要度の推定、ロジスティック回帰による重要活動の抽出などを行った。 • とはいえ、P値が何かすらわからない人も多いので、分析の妥当性は結論から推 測するしかなく、各担当者の施策の補強用の後付資料として使う形になった。

22.

データドリブンな文化の定着 • データ分析の最終目的はデータを使ってPDCAの速度と精度を向上させることにある。 • 速度の向上は「より早くデータを理解すること」で果たされ、精度の向上は「より深くデータ を分析する」ことで果たされる。 • より深くデータを分析するうえでは分析者側の事業特有の知識(ドメイン知識)の習得と、利 活用者側の理解・教育が必要となるため、まずは「より早くデータを理解すること」に対する アプローチによって関係性の構築を図る必要がある。 • そのためにはデータの可視化とそれによる直感的理解を供給することが効果的である。

23.

社内で初めてのデータ分析担当者になったなら • エクセルだけでは処理能力が不足しがちになるため、分析ツールの追加が必要となるケースが多い。 • エクセルユーザーが乗り換える場合、既存の関数のみで大抵のことが出来、エクセルと似たような 記述ができる無料ソフトのRは学習コスト的にも、経済コスト的にもコストパフォーマンスが非常 に良い。 • 処理内容を記録し、いつでも再実行可能になるため、業務を自動化・構造化しやすくなる。 • 業務を構造化出来るようになると業務の体系化と構築が出来るようになり、そのためには基本情報 技術者、応用情報技術者等の資格学習が役に立つ。 • いきなり高度な分析を行っても利活用者側が理解できないため教育が必要であり、また分析者側も そもそも統計知識などに不足するため、まずはデータの可視化を通じて信頼関係の構築、データの 取り扱い方法の教育・理解を深めていき、段々と深化させていくほうが安定化しやすい。

24.

ENJOY!