データサイエンティストのひよこ

分析に関する日々の相談事項

データサイエンスの組織作り１（自社データ編）

データサイエンティスト マネージメント

　2013年くらいはデータ分析ベンダーが、データサイエンティストを大量に囲い込んでいた。しかし、最近では事業会社に転職していくデータサイエンティストも非常に多くなっている。他社のデータを扱うことは、データの前処理以前のデータベースの理解から始まり、当初のスケジュール通りになかなか行かない分析プロジェクトになりがちである。それに加えて、期待値コントロールなどのマイクロマネジメントばかりが要求されることも多い。腰を落ち着けて、一つのデータに集中して分析したいという流れに加えて、製造業をはじめ多くの事業会社がDSを内製化する方針が重なり、転職が旺盛になった。
　DSの多くが事業会社に転職したものの、職場とのミスマッチが多発している。DSあるあるである。データサイエンティストの組織づくりや採用にも関わってきたので、ケースを少し振り返りたいと思う。まず、この記事にとって、身も蓋もないことだが、ここを含む社外の情報に定義を丸投げせず、自社の業務に即したデータサイエンスの目的と意義を自社で持つことだ。
www.hottolink.co.jp
数年前にも榊氏が述べている。

データサイエンス組織の目的設定

　データサイエンスは一つの企業ができるくらいバリエーション豊富な業務が詰まっている。そのため、ある一つのデータ分析部署という規模では、組織の目的、分析の目的をしっかりと決めないといけない。ただ、そのミッションは業態により異なる。例えば、自社データがあるかないか、そしてそれを、業務改善に使うのか、サービスを作るのかなどである。自社データのない会社は、他社へのコンサルティングサービスの一つのメニューとしての分析組織が求められる。自社データがある製造業や飲食業は業務やサービスの改善のための分析組織が求められる。うまくいくと、業務の差別化、業務改善ソリューションを他社向けに開発することができることもある。

　組織には、目的、業務、権限、評価を明確にすることが非常に重要である。不明瞭だと、分析技術力を必要としないが売上のあがるシステム開発かコンサルの組織が出来上がるだけになってしまうし、集めるべき人材も定まらない。スモールスタートをするのであれば、社内のもっとも売上比率の高い部署のデータの改善を目的にして始めるのも良い。

データサイエンス組織の立ち上げ事例

　立ち上げに関わったケースを少し振り返る。せっかく関わったので、ぼかして書きたい。

　事例は、ある大量のWeb調査結果のデータベースを持つ企業である。現状業務は、調査データをレポートに集計して、企業に売るということが主流の業務である。しかし、それだけでは、いくつかある競合企業との中で差別化することは難しいと感じていた。そのため、データを活かし、データを分析することで新しい付加価値をつけていくことが必要と考えた。
　ビッグデータ室というものを立ち上げることになり、準備室を創設した。分析に明るい人材が社内にはいなかったため、調査部署と集計部署と営業部署のマネージャークラスに準備室に参加してもらった。データの調査項目、これまで集計して発表した指標、顧客企業のニーズ等をまとめあげて、議論を重ねたが、残念ながら、データの新しい利用方法というのを社内で発想することは難しいと感じた。ビッグデータ室準備室のお手伝いしていた私は、データの活用戦略を考えた。

  • 目的

　法人営業を行なっている部署に、顧客企業にニーズを探ることをさせても、顧客と用途が固定されていて、新たなニーズをヒアリングをすることが難しかった。ニーズを新しく発見するには、広くデータの存在と価値を社会に公表し、興味を持った企業からのコンタクトに対応して、ケースを蓄積することを考えた。

  • 人材

　技術営業と分析グループを作り、集計や統計を行ってきた背景を持つ社員を４人あて、特に分析グループには客員研究員として大学教員と学生を参画させた。大学教員も学生も兼業として従事してくれて、人件費は非常に安く上がった。

  • 活動

　ビッグデータ室の初期は、データを利用し、対外的に発表する場を重ねることと、コンタクトを取ってきた企業への対応からケースの蓄積をすることを重視した。KPIも売上ではなく、ケース蓄積のようなものにした。そのため、営業部署などへデータのニーズを継続してヒアリングを重ねることと、レポートの項目にフィードバックをもらうことを指示したり、営業日報の閲覧などへのアクセス権が付与された。


　ビッグデータ室は、このようにして立ち上げられることとなった。最初のフェーズは、データのことを広く業界に知ってもらうために、データを集計し、個々を特定できない形の業界レポートや論文にして、自社サイトなどで発表した。当初の分析は、単純な集計だったが、これまで知られていなかった自社データが、研究機関や一般企業への宣伝となった。分析の監修を大学教員が行ったので、技術力が疑われることもなく自社の分析力の向上にもつながった。Webでのレポートの公開、学会発表、セミナー講演などを通し、データの知名度が上がり、徐々に興味を持った企業から取材以上の問い合わせが来るようになった。直接的にレポートの内容を尋ねるものでなくとも、「こんな分析できませんか？」や「こういうデータ持ってませんか？」といったニーズを知ることもできた。

　いくらか時間が経つと、有象無象に集まるニーズをサービスとして固める必要があり、分析組織も次の目的が建てられることになった。およそ１年間のヒアリングや問い合わせで様々な提案を受け、マーケ戦略や企画をデータで裏付けしたいという依頼が多かった。このため、アナリストが自社データを持って依頼企業に赴き、その場で依頼企業企画室のために分析を行うというサービスをはじめた。

  • 目的

　技術営業グループには、分析対応サービスにおける売上目標
　分析グループには、技術営業グループの担当案件を高度ソリューション化するための可能性の探索

　この頃から、人手が足りなくなり社内人事では不足し、専門人材を募集し始めた。レポート作成や依頼企業の分析はどちらもそこまで高度な分析は必要なかったため、学部レベルの統計学などと規定して人事募集を出した。一方で、大学院レベルの経済学と統計学の人材を集め、こちらから提案できる高度な分析を行える人材を用意した。
　最後のフェーズとして、類似の案件を振り返り、業界変遷の分析や可視化依頼が多いことから、クラウドアナリティクスツールを作成した。

　組織の立ち上げは、投資としての側面が大いにある。売上目標などを設定すると、売上に簡単に結びつくコンサルやシステム開発ばかりになってしまう。アナリティクスの真髄は、モデルの開発である。モデルは、粗製乱造でもたくさん作り、一定期間の後振り返り、いくつか組み合わせてソリューションにするという方法が、特定の業務に深く入り込まないため横展開もしやすいものができる。この会社は、非常に状況として恵まれていて、多くのデータ分析依頼が来た。そして、分析依頼から分析ソリューションを組むための産学連携も大きかった。

　このケースは、かなり前の事例であるので、当時はデータサイエンスもデータサイエンティストという言葉もなかった。ここで、注目されなかったところを少し最近の話題に直して、振り返りたい。

自社データの分析をするための準備

　アナリティクス室準備室のような準備部署を立ち上げて考えていく。そもそも、社内にはどのようなデータが、どのようなDBで存在するのか。各部署が持つKPIに結びつくデータを各部署が持っているのかを確認する。様々な業務を行う部署がある場合は、改善による売上や経費効果が高い部署を優先すると良い。そのため、準備室にはデータを持つ部署やデータによる改善の恩恵を受けそうな部署のメンバーを中心に集めるとよい。さらに、このような部署のDBを調査するうちに、準備室の人間がアクセス権限で悩まされたりすることがわかるので、データのアクセス権限を確認するとよい。私の知り合いのデータサイエンティストは、着任後に社内に散財するデータ探しをさせられて、倉庫の中のビニールテープでぐるぐる巻きのノートPCからデータを見つけたといって喜んでいた。が、一向に分析作業に就くことができず、スキルが死んでいくことを恐れて辞めてしまった。是非とも、ここまでのことは避けて欲しい。

　目星がついたら、分析に耐えうるDBであることも調査する。どんなデータサイエンティストでもデータがゴミのようなものでは、いい結果は出ない。特に、担当社員のお好みでデータがDBに入力されていっては困る。機械的に収集されているという網羅性が必要だ。また、同じ顧客が、部署ごとに別のIDで管理されていて、部署やDBをまたぐと一人の顧客の追跡性が失われてしまうケースもある。部署をまたいで利用する時には、組み合わせられるデータがあるかどうかも重要だ。ある会社では、営業部署とメンテナンス部署で顧客が別IDで管理されていた。広告出稿とそのクリック数は管理されていたが、クリック以降の客の動きが追えないケースなどもある。このような追跡性は、マーケティングの世界ではWeb広告に接触した顧客が、ECサイト内でどのように商品を見て回り、どの商品をいつ購入したかまで全てログとして残すことが理想である。
　これらチェックは、準備室の社内人材で難しいなら、社外のSIerに頼んでも良いと思う。データサイエンティストは、網羅的でないデータに網羅性を持たせたり、２つのデータにある人物を同一人物と特定して、データを紐づける魔法のスキルがあるわけではない。データがダメなら諦めるか、ちゃんと集めましょうという当たり前の話になるだけである。

　社内データの洗い出しが終わったら、狙っていたデータ分析ができそうなデータなのか、あるいは目的の再設定に立ち返る必要があるのか確認する。ここで、組織の目的が定まると思う。
　

  • 目的

　・経営企画/市場調査
　・サービス/業務/品質改善
　・自社データの新規展開

  • 業務範囲

　・市場調査や経営企画など役員進言のみ行う（他部署に干渉しない）
　・業務データを利用し、他部署への企画提案を行う
　・ダッシュボードやDMPの設計監理を行うのか（情報システム部門との競合）
　・在庫や配送作業の自動化（数理モデル設計）

  • 権限

　・他部署データへのアクセス
　・他部署への施策企画/現場実証
　・他部署への常駐など

　製造業や小売・サービス業での自社データが存在するような企業を前提に書いた。ここまで決まれば、多少の分析ができる業務コンサル/アナリストが必要（進言・企画提案）なのか、データエンジニアが必要（設計監理）なのか、サイエンティストが必要（モデル作成）なのかが多少はわかる。基本的には、分析の成果として評価と改善が求められればコンサル/アナリスト、最適化や自動化は機械学習エンジニアやデータサイエンティストに任せれば良い。それをシステムにするのは基盤エンジニアだと思う。
　また、有名な大学院の博士といったすごい人材は、大きな分析組織でも1人や2人いれば十分だろう。世の中の分析は、そこまですごいものは多くない。が、全く必要ないということもない。高度モデル化という行為はソリューションに繋がり、金のなる木を生む。重要で難解なプロセスであるが、溜まってきたノウハウをソリューションにする一瞬のみで必要であったりもする。常日頃の分析プロジェクトに従事していると、日進月歩の技術に追いつけないことがほとんどだから、高度モデルが必要な時に対応してもらえるよう日々勉強を重ねてもらう役割も必要だ。この手の人材を、対客業務にあてがうのはマネジメントの点から行ってあまり賢くないと思う。彼らスペシャリストの凄さは、ゼネラリストのそういう業務のものではないので、意味もなく人材を浪費する必要はない。

人材の探し方

　以前は、「統計学や経済統計やアンケート分析の経験がある方」という書き方で人材を集めることができたが、今はデータサイエンスや機械学習という使いやすい言葉で募集されることが多い。分析として、どのような領域に得意分野を持つかわからないまま、あるいは分析経験がなく、データ事業に関わっただけの人材が採用プロセスに進んでしまうこともある。
　まず、リクルート、ブレインパッド、ホットリンク、アルベルトなどの採用情報は必ず見よう。コンサルタント、データストラテジスト、データエンジニア、データアナリスト、機械学習エンジニア、データサイエンティスト、リサーチャーなど様々な職種がある。企業によって業務の範囲は異なるが、データ事業に関する提案企画やデータドリブンな業務の提案企画などはコンサル、アナリティクス・AI・IoTなどのデータサイエンス環境のシステム整備を行う基盤エンジニア、集計や数理技術を駆使した分析を行うアナリストやサイエンティストといった具合である。
　データサイエンティストは、事業にインパクトを与えるような企画を思いつき、そのための環境を整備し、データを分析し、経営層や客先担当に綺麗なパワポで伝えることができる万能な人ではない。ごく少数そういう人がいるが、あなたの会社には来ないと思っていい。たとえ、そういう人材がいたとしても、うまくいかない要因はいくらでもある。特に、足を引っ張るのは通常の社員や他部署だ。もちろん、彼らは普通に業務を行なっているだけで、邪魔をしているわけではない。データサイエンティストに業務の改善を任務として与えるなら、他部署データへのアクセス権限や、業務改善提案・指導の権限を与えるべきた。これはデータサイエンティストの能力でなんとかなるものではない。
　特に、データサイエンス業務の中でも、数理技術を扱う人は専門職で、間違っても総合職という扱いをしてはいけないと思う。極端な言い方だが、弁護士や会計士、金融業の方ならクオンツやアクチュアリーの一種といった言い方が合うだろう。数理技術は、賞味期限が１〜２年ぐらいの非常に足が速いスキルである。雑多な業務（他部署とのデータアクセスの調整等）で時間が割かれると思われれば、すぐに転職していってしまうだろう。
　データ事業の中で、どのような役割を担って欲しいのか。データ分析をして欲しいのか、データ分析担当者をディレクションするのか。データ分析は何を対象とするのかなど、採用の際には明確にする。

データ分析環境づくり

　データサイエンティストが必要とするものが分析環境である。AWSやGCPと呼ばれるクラウド環境がある。手元にハイスペックなパソコンがなくとも、データとプログラムをアップロードすれば、AWSやGCPが用意したハイスペック環境が利用できる。データをwebにアップロードすることができないという点が、多くの企業がDSを苦しめる要因であろう。もし、これがダメなら手元に200万円超の計算サーバ機を購入する必要がある。両方ダメなら、私は近似方法を使って簡易計算するだろうが厳密な答えではないので、主張も弱くなると思う。
　この点は非常に重視したい。データサイエンティストは分析に集中できる環境でありたいと思う。それがスキルであるからだ。分析のために部署中を動き回ることは、分析でない。社内調整や環境構築をすることは、分析ができなければ自身のスキルが評価される土俵にも上がれないため、必要だからしていることだ。むしろ、ここからがデータサイエンティストの仕事である。
　

施策提案と効果測定

　データサイエンス組織で、自社データを活用する場合、主に他部署支援という形で行われる。単体でお金をとって来れる場合は、紹介したような他社むけの調査業のケースに限られると思う。まずは、以上のような環境をデータサイエンティストに与え、他部署からデータを受け取って、分析をして結果を得て、他部署にデータの改善施策が分析成果の第１弾として出て来る。しかし、ここで分析組織の役割が終わってしまう訳ではない。
　分析成果は、実際の現場に適用していかなければならない。そのために、改善提案をした施策の現場への指導（の補助）を行うプロジェクトが必要である。また、そのプロジェクトもいきなり全部に適用するのではなく、スモールスタートとして、一部の地域、店舗や営業マンに絞って行う必要がある。その際に、偏ったテスト対象を選び出しては、施策の効果を適切に評価できない。データサイエンティストは、全体と似た傾向を示すテスト対象を選び出し、適切なテスト環境を構築する必要もあるのである。例えば、全国展開したいマーケティング施策をテストするときには、仙台や静岡が全国と似た傾向を示す場所として昔から知られている。もちろん、実際には、自社データの傾向を調べて、適切なテスト環境を用意する。
　テストを行なうときも、新施策実行群と現状維持群の二つに分けて効果を計る。全員に新施策を実行させても、テスト期間中の季節要因などが除去できないため、評価が不確実になる。改善施策の効果測定手法は、このようにして評価し、全体実施を決定するのである。
　最後に、改善貢献度の配分を決める。つまり、マーケティングの新施策で改善した効果のうち、分析組織による貢献を売上として配分する。例えば、新施策施行後の売上のうち前年同月売上からの上昇分のX％を分析組織による売上として記録するのである。売上でなくとも利益や来店客数のようなKPIを設定し、金額換算で分析組織の成果として付け替えるのである。もちろん、テスト時の経費を分配することもある。
　分析組織に売上貢献の配分を適切に設定したうえで、売上目標を設定する必要がある。売上目標が適切に設定されなければ、分析組織が無責任にも分析成果を振りかざすだけのコストセンターになってしまったり、有用な貢献があっても分析組織が評価されなかったりと、不幸な状況に陥ってしまうからである。

おわりに

　データサイエンスの組織立ち上げは、社内にデータがあるかどうか、社内データを社内業務改善に利用するか、社外へのサービス開発として利用するかによって目的から何から変わってきてしまう。他社のコンサルティングサービスとして、分析組織を立ち上げるなら全く異なる過程を経ることになるだろう。そのことは、またどこかで述べたいと思う。詳しいことは、質問してくだされば、追記していこうと思う。