この記事はモチベーションクラウドシリーズアドベントカレンダー2021の8日目の記事です。
データチームを立ち上げる方はぜひ上司の方と回避策検討にご利用下さい
「DX推進の一環として、データ活用の専門部隊を立ち上げたい」というような相談を受けるエンジニアは増えているのではないでしょうか？（勘です）
これから立ち上げを中心的にされていく方に向けて、データチーム（社内のデータ活用をサポートする部隊）の立ち上げで得た失敗と学びを共有したいと思います。
TL;DR
- ミッション/ビジョンをちゃんと定めよう
- 粘り強さを得るため
- スコープをフォーカスするため
- チームで必要な役割を明確にして、分担しよう
- データエンジニア、データアナリスト、ビジネストランスレータ-が最小単位
- レポートする人/される人という受発注関係はやめよう
- 分析依頼者に仮説出し、分析方法、ネクストアクションまで企画段階で一緒に作る
背景
私は2年ほど前にリンクアンドモチベーションというコンサルタント事業が中心の企業で、最初のデータサイエンティスト/エンジニアとして、データ活用のための部隊を立ち上げました。
どのような業務があって、何にデータ活用することが事業に貢献することなのか手探りの日々でした。
ミッション/ビジョンをちゃんと定めよう
落とし穴: 思ったより依頼来て忙殺 → あれ、何がしたいんだっけ？
チーム立ち上げ当初は私しかいなかったので、まずは仕事を創るところから始まりました。
なので一つ一つの仕事にフォーカスできていたのですが、少しずつ知名度が上がると、気付いたら色んな分析の依頼や相談が集まるようになっていました。
これ自体は嬉しいことですが、キャパシティを超える依頼数になってくると、当然やることの優先度をつけるようになります。
そのときに課題になったのは以下2つです。
- (部署を超えた依頼は特に)どれがビジネス上優先すべきものなのか分からない
- あれ、そこもうちのチームの守備範囲なんですっけ？というアイデンティティが薄れてくる
一つ目は、例えば既存ビジネスの堅調な成長を支えるためのグロースハックと、新規事業のための概念実証のどちらを優先すべきなのか？などは、比較する軸の検討からになってしまい、優先度をつけること自体困難です。
もう一つのアイデンティティの希薄化というのは、発想が自由に取れすぎるので、かえって「こんなことをしたらどうだろう！」という個々人の工夫や提案がしにくくなり、指示待ちの状態につながります。
回避策: ミッション/ビジョンでスコープを明確にしよう
上司が出してくれた助け船は、以下でした。
「東山さんの部隊にやってもらうのは、当面はこの2つ！モチベーションクラウドの継続率をあげること！組織人事のノウハウであるモチベーションエンジニアリングをデータサイエンスで実証したり、進化させること！」
↑を受けて、チームのミッションを定めました。
また、5年分の中長期経営計画があったので、その中で我々が実現するものも明確にし、ビジョンに落とし込みました。
これにより、「我々は何屋で、重要なことはこれだ！」というのがチーム内外で認識が揃ったと思います。
チームで必要な役割を明確にして、分担しよう
落とし穴: 絶対必要ではなく、あったらいいなを作ってしまう
データ活用あるあるなのかもしれないですが、「作ったダッシュボードがあまり活用されてない」など、なかなか現場のPDCAの中に埋め込むのは大変です。
重要なのは、現場の方が活用するために
- 必要なデータは何か？
- それはなぜか？（どんなビジネス課題にひもづくのか）
- そのデータが上がったり下がったりしたら何をするのか？
と言ったことをしっかりと捉えた上で作ることです。
チームの役割の認識として「データエンジニア/データアナリストの集団」というところもあり、↑をものすごく現場とすり合わせる工程が今から考えると弱かったなと思います。
回避策: データエンジニア、データアナリストだけでなく、ビジネストランスレーターも必要
業務にしっかり定着するまでヒアリング/説明/改善をする泥臭いポジションとして、ビジネストランスレーターというものがあるそうです。
リンクした記事では、次のような役割のことです
データサイエンスチームからのレポートの内容や分析結果を分かりやすい言葉でビジネスサイドの人たちに説明し、一方でビジネス・経営サイドの視点にも立ち、その結果をどのように生かしていくべきか具体的な意見やアイディアを伝え、課題解決を遂行していきます
我々のチームではこのポジションに野見君(2年連続、2回目)をアサインし、現場に価値が届くところまで磨き上げることしています。
あと、重要な点はチーム内で「この役割が必要だ」という認識をしっかりと作り、野見君が意見をしっかりと発言できる土壌を醸成することです。
うちのチームの場合は、現状のチームはスタートアップ企業のようなもので、何が顧客（現場）に受け入れられるかよく分からないのだから、MVPによる仮説検証をしっかりと回して行こう、泥臭いことを厭わずに「（データサイエンスの殻に閉じこもることなく）なんでもやろう」と話し合いました。
データチームに必要とされる役割は他にも色々あるようですので、ご自身の環境に合わせて適切なものを設計したいですね。
レポートする人/される人という受発注関係はやめよう
落とし穴: レポートを報告してもなかなか終わりが見えない
「東山さん、先週のレポートなんですが、先方からXXのデータも出して欲しいと依頼が来てます、ちょっと他の開発もあるので優先度の相談したいです」
こういう相談がメンバーから増えてきました。
話を聞くと、↓のような孫請けのような状況ではこのようなことが往々にして起こることがわかりました。
- 先方の経営層が「こういうデータみたらいいのでは？」と発案
- モチベーションクラウドの運用担当の方が弊社のコンサルタントに相談
- コンサルタントからデータチームに相談
このような状況だと、もともと発案されたときの問題や課題が分からないので適切なレポートが難しいのです。
また、より根本のところだと、「データ分析は絶対的、客観的な結論が出る」というもの ではない ということを関わる人全員に伝えておかないといけません。
集計する期間などの絞り込みだけでも結果は変わりうるので、データによるレポーティングは「意思決定に関わる人が納得感のある暫定的な解をつくる営み」であることをお伝えすべきです。
回避策: 発案者の方と一緒に仮説出しから分析方法、ネクストアクションまで決める
我々のチームでは
- ビジネス課題
- 課題の原因(仮説)
- 分析方法(仮説をどのようなデータ加工/抽出することで納得感があるか)
- 打ち手案
を発案者の方と一緒にワークしながら企画段階をすり合わせるステップをとるようにしました。
結びに
いかがだったでしょうか。
立ち上げ期のデータチームは、単なる機械学習やデータエンジニアリングだけでなく、合意形成などの泥臭さが非常に重要だと痛感しております。
また、それを成し遂げるためには、このような困難を理解してサポートしてくれる上司の存在は大変重要です。
今回の記事でいえば、ミッションのところでチームのスコープを絞ったり、適切な人員の配置など、より上位からの構造的なテコ入れが必要だったりします。
是非上司の方の協力を得られるように、相互の情報交換を心がけていただくと良いかと思います。