ビジネスにおける「データ分析」の重要性が増している昨今、組織の中に「データ分析グループ」を持っている企業は今では何ら珍しくありません。一方で、データ分析グループはこれまでのものとは異なる、新しい組織形態でもあります。2016年2月18日に目黒雅叙園にて行われた「Developers Summit 2016」でEmotion Intelligence社の中山ところてん氏が発表したセッションの内容は、その辺りの問題点とマネジメント手法の変遷について非常に詳細な形で解説がなされていました。本記事ではその内容について要点を整理し、レポートして行きたいと思います。
データ分析グループの仕事の範囲と、そこで見てきた"失敗例"
中山氏はまず前提として、氏が所属する企業のデータ分析グループのデータ分析の流れについて説明を行いました。大きく分けると「研究」「開発」「システム運用」「アプリ運用」「営業活動」の5つの流れに大別することができ、データ分析グループは研究からアプリ運用まで、広い範囲においてデータを解析し改善していくことでビジネスにその価値を活かしていく、という責務を負っています。

しかしこの位置付けで業務を行っていく中で、さまざまな失敗例を中山氏は見てきたと語ります。以下6つの失敗例がその内容です。
失敗例その1 プロセス毎に会社が切れている「大企業」
データ分析においてデータを手に入れることはまず何よりの前提条件となるが、プロセス毎に会社の連携が切れている大企業のようなケースだと、会社の壁を超えてデータを入手することが非常に困難。

失敗例その2 データサイエンティストの仕事傾向
高学歴・研究者のデータサイエンティストを採用したものの、研究的な仕事しかしたがらないので困った。難しい問題を難しく解きたがる傾向もあり、結果として売上に繋がっていない。
失敗例その3 研究系とアナリスト系の対立
現場を改善するためにアナリストを雇うも、データ分析グループ内で空中分解し対立。現場の改善と研究でサービスのコアに入っていかず、サービスが進歩しなかった。
失敗例その4 「簡単なお仕事」
データ分析グループはスキルセット的に広範囲をカバーしており、エンジニアと営業の間に落ちた問題を拾うこともある。感謝されるので良いといえば良いのだが、この辺りの内容については所謂「(SQLを叩いてExcelで集計する、というような)簡単なお仕事」のため、本質的な価値を生み出す仕事ができていない。
失敗例その5 仕事範囲・領分の重複
データ分析グループの仕事の「領分」は、エンジニアの領分と重複することが多い。言語や品質の面でエンジニアと対立してしまい、いくら分析をしても本番導入に進めることができていなかった。
失敗例その6 データレイク(データ分析基盤+データ処理基盤)の不在
データ分析インフラ環境に対する投資を行わず、人だけ雇う。結果、分析以外のところに多大な工数が掛かる形となってしまった。

会員登録無料すると、続きをお読みいただけます
- 修正履歴
-
- 2016/03/09 22:28 中山氏のお名前が一部、中川氏になっておりました。大変失礼いたしました。
この記事は参考になりましたか?
- この記事の著者
-
しんや(シンヤ)
2010年末~2013年前半位までの期間で興味のある勉強会に頻繁に参加。参加してきた勉強会のレポートブログとTogetterをひたすらまとめ続け、まとめ職人(自称/他称含む)として暫く過ごしておりました。色々な縁あってDevelopers Summit 2013では『公募レポーター』も務めました。2013年05月『出張ブロガー』を経て2013年08月にクラスメソッド株式会社へ転職。現在は業務(AWS及びその周辺技術を扱う)の...
※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア
