「データ活用」をキーワードにネットで検索すると、導入したツールの成功事例の記事を
よく見かけますが、「これからデータ活用を進めようとしている方」にとっては、
「どうやって導入するまでに至ったのか？」も気になるのではないでしょうか？
そんな「これからデータ活用を進めようとしている方」に向けて
弊社におけるデータ活用を進めるまでの道のりを
* 目的設定編
* 稟議決裁編
* 導入編
* 運用体制構築編
の全4回に分けてご紹介します。
「上手くいったこと」もあれば、「上手くいかなかったこと」もあるので、
ざっくばらんに書きたいと思います。
全4回のうち、本記事は「運用体制構築編」として、導入プロジェクトを振り返って気付いた
課題と、その課題への対策として運用体制を構築したことについてご紹介したいと思います。
要約
持続可能性を持った運用を行うためには、データ活用の専門組織が必要だと思います。
データ活用を持続可能性を持って運用を行うためには
・データ活用の戦略立案
・キレイなデータを保つための業務プロセスの構築・維持・改善
・キレイなデータを保つための仕組みの構築・維持・改善
・キレイなデータを管理する基盤の設計
が必要だと感じていて、これらを片手間でやるには荷が重いためです。
導入プロジェクトの振り返り
導入編では「どうやってTableauを使えるようにするか？」について記載しましたが、
実際にはその前段として、「Tableauで使うデータを用意する」という工程がありました。
Salesforceを主なデータソースとすることを決定し、オブジェクトを構築した後に、
そのオブジェクトに合わせた形でデータを投入するという工程です。
主に独自のスプレッドシートで管理されているデータを投入したのですが、
これがめちゃくちゃ大変でした。
大変だったことTOP3を挙げてみます。
第1位：データを結合したいんだけど、、、
データが複数のスプレッドシートに分かれているのは良いんですが、
独自の管理番号を持っていたり、ゼロ落ちしてるとかの表記ゆれが発生していると、
VLOOKUP関数を使って1つのシートにデータをまとめようとしてもN/Aの嵐。
第2位：これって区分値なんだよね？
例えば製品名とかです。
あるデータでは正式名称を使っているけど、別のデータでは略称を使っていたり。
これもまた表記ゆれの問題ですね。
第3位：同じデータが・・・
マスタとして管理しなきゃいけないデータに重複が発生してると
どっちを残して、どっちを消すかの判断が難しいんですよね。
さらに難しいのは、似たようなデータです。
同じデータなのか、似てるだけで別のデータなのかはもう聞くしかない。
他にもデータの横持ち/縦持ち問題だったり、いろいろ苦労はありました。
これらの問題って、その瞬間でキレイにしてもまたすぐに汚くなるんですよね。
持続可能性を持った解決を図るには、個人の努力には限界があるので、
組織的な対応が必要になると思います。
組織に必要な役割
データ活用の戦略を立案する役割
最も重要な役割です。
自社のビジネスを踏まえて必要なデータの要件に落とし込める人。
そして、得られたデータからビジネスの未来を描き、データと共に語り、
経営に影響を与えられる人。
そんな人いねーよ、って感じですよね。
でも、興味と素養がある人はいると思います。
そういう人を育てる環境を作るためにも組織は必要だと思います。
キレイなデータを保つための業務プロセスを作る役割
これはデータに関する業務とアプリの両方を知っている人が担うべきだと思います。
業務を知っているだけだとアプリで実現しにくい要件が出てくる可能性がありますし、
アプリを知っているだけだと運用負荷が高い業務プロセスになる可能性があるためです。
もちろん業務を優先するのですが、アプリでの実現可能性とのバランス感覚が必要です。
キレイなデータを保つための仕組みを作る役割
これはアプリケーションを知っている人が担うべきだと思います。
ただ、業務も少しは知っている、もしくは、利用シーンをイメージできる必要はあります。
ここでいう「仕組み」は入力制御などのアプリの機能としてできることも重要なのですが、
より重要なのは、どの項目をマスタとして管理する必要があるか？を考えられることです。
更に言うと、他アプリとの連携を加味してマスタ設計ができるか？です。
データ活用が進むに連れて、活用したいデータの範囲は広がります。
例えば都道府県という項目があって、アプリAでは「東京都」として登録されていて、
アプリBでは「東京」として登録されているとします。
この2つのデータを組み合わせる時、いずれかのデータを加工する必要が出てきます。
面倒ですよね？
データの入力時にこのようなところの整合性を取れる仕組みを作ることは重要です。
キレイなデータを管理する基盤を設計する役割
上で複数のアプリをデータソースとしてデータを結合する話をしました。
この結合はどこでするのでしょうか？
もちろんTableauで行うこともできますが、頻繁に結合する事があらかじめわかってるなら、
あらかじめ使えるデータにしておいてくれよ、と思いますよね。
こういう時に必要になる役割です。
いわゆるDWHを中心としたModern Data Stackを設計する役割です。
この役割にはアプリより深いところにあるインフラの知識を持った人が適切です。
構築できるスキルがあれば尚良いです。
組織の位置付け
データ活用の進み方だったり、確保できる人材など様々な要因によって、
経営企画部門や情報システム部門の一部としたりすることがあると思います。
たまたまIBM社が出してる資料を見つけたので、良かったら参考にしてみてください。
どのような状況だとしてもして、共通して言える事は2つあると思います。
1つ目は業務部門から独立した部門横断的な組織にした方が良いと思う事。
データ活用は遅かれ早かれ、部門を跨いだデータのやり取りが発生します。
そんな時に特定の業務部門の特色が色濃く出てしまうと、活用するデータに
偏りが出てしまうと思うためです。
2つ目は役員との距離が近いところに設置した方が良いと思う事です。
データ活用の文化を醸成するにあたって、もちろん現場部門の業務効率化も重要なのですが、
経営陣の迅速な判断に貢献する事も重要です。
距離が近い事でデータ活用戦略として必要な観点を得やすくもなります。
その結果、必要なデータがより明確になり、「経営に必要だから」という
御旗のもとにデータ収集が可能になります。
そして集めた情報を上手く活用できれば、データ活用にかかったシステムコストの
ROIの説明もしやすくなります。
もしかしたら予算確保もしやすくなるかもしれません。
この点はTableau社が提供しているBlue printも参考になると思います。
まとめ
導入を振り返って、「あー、大変だった」で終わらせるのはもったいないです。
そこで終わらせると、その大変な想いを未来の誰かがまた味わう事になります。
データ活用を持続可能性をもって発展させるためには、データ活用専門の組織は
必要だと思います。
そしてその組織に必要な機能は以下の通りです。
・データ活用の戦略立案
・キレイなデータを保つための業務プロセスの構築・維持・改善
・キレイなデータを保つための仕組みの構築・維持・改善
・キレイなデータを管理する基盤の設計
また、組織をどこに設置するか？についても触れさせていただいたので、
ご参考にしていただければと思います。
最後に
弊社ではこの辺の話を経営陣に理解してもらう事ができ、新組織の立ち上げに至りました。
「思います」で終わる文章が増えてしまったのは、組織を立ち上げたばかりなので、
まだ定量的な成果が出ていないためです。
とはいえ、社内のデータに対する意識は少し変わったかなと感じています。
世の中の流れもあると思いますが、新組織立ち上げの意味が伝わった事もあると思います。
今後は定量的な成果創出に努めていきますので、結果が出たら続編を書いてみようかな
と思っています。
追記
4回に渡って弊社の取り組みについて書いてきましたが、きっかけはDATA Saberという
認定プログラムに挑戦しており、その中で「Ordeal 10」という課題に取り組んだことです。
「自分だったらどうするか？」という問いについて概要は記載したのですが、
この問いに回答したときに、世の中でデータ活用が進みゆく中で、当時の自分のように、
プロジェクトの進め方の取っ掛かりを探すことに困ってる人も多いのでは？と思い、
投稿しました。
同じような境遇の方の一助になればと思います。