マクロミルにいるベテランリサーチャーの方が言っていて、印象に残っているのが「Garbage in garbage out（ゴミを入れたらゴミが出てくる）」という言葉です。

どんなに立派な加工文を書いても、どんなに高難易度な多変量解析をしても、インプットデータがゴミだったら出てくる結果もゴミ。この4ヶ月、事業に必要なデータを整理するというプロジェクトを推進していたのですが、まんまと自分がこの罠にハマりました笑
（気づいたら現職在籍期間の大半がデータ整備だｗｗ）

これは、マクロミルできれいなデータに触れてきた弊害だなと思いました。出して欲しいと要望されたデータ元が整っていないなんて考えたこともなかった訳です。ただ、社内データは割ととっ散らかっていたのでちょっと考えればわかることなんだけど、スーパー営アシが助けてくれていたから意外となんとかなってた訳です・・（感謝・・・！）

今回のプロジェクトにおける問題は4つ。
1）データ構造が整っていない
2）入力項目と入力場所にバラツキがある
3）分析に必要なデータが入っていない
4）BIツールを扱うスキルがない（個人的な問題）

問題の大半は、データ構造をどう整備するかです。

いまのデータ構造がどうなっているのか？理想の構造とはなにか？の紐解きから始めるのですが、ただこのデータ構造ってのが厄介。今回、立ち上げから約2年が経過した事業のKGIやKPIを加工してアウトプットするというプロジェクトだったのですが、求められたアウトプットのために必要なデータは全てSalesforceに入っているから出せるでしょって思ってました。

ただこのSalesforceが厄介。大前提として、誰でも使える中央管理システムとしては相当優れもの。ただ、大本の設計思想を固めてから始めないと崩れる。

オブジェクト毎のリレーションが取れていない、項目の定義がバラバラ。プリコードをアドホックで追加していく。事業が高速で進んでいく中で、Agility高く進めていた結果なのだけど、結果的に、ハウルの動く城状態に陥る。

あれはどこだ？これはどうするんだ？よし、こことここを繋いじゃおう！
みたいな。よく言えば創意工夫。悪く言うと無理やりｗ

SFのデータ構造がきちんとしている前提で進めていたのに、あまりにもデータが出ないから「なんで？」って思って見に行ったら構造がきちんとできていなかった。

僕自身がSalesforceに苦手意識があって前職の時逃げ切ったと思ってたもんだから、そこの紐解きから改めて。いろんな人にアドバイスを求めました。

しかも、SFAと呼ばれる代物は業務プロセスそのもの。Salesforceのデータをいじろうと思うといろんなプロセスに影響が及ぶ。

営業しかわからなかった時は、「おいおい、営業のこともっと考えてくれよ。」って思ってたけど、これは本当に難しい。各Sectionがどのように動いていてどのように仕事をしていて、どのように入力をしているかを理解しないといけない。

この項目はいつ入れるのか？この項目は誰が更新するのか？どことどこが連携していて、何が独立しているのか？どの項目が必要で、何がないと仕事が進まないのか。

実際、入力項目が300近く積み上がっていたものの、メンバーに聞くと頻度の差はあれ使っているものは3分の1程度。スリムにする必要がありました。メンバーから出てきたのは、「誰が入れても項目がきちんと埋まっている状態にしたい。」という言葉。このワードはかなり重要。業務を高いレベルで均質化しに行くことが大事。

今回学んだのは、データ構造を整備することと業務プロセスを整備することは同義だということ。その流れの中でデータを蓄積し、それを元にデータを見ていくことが必要になる。だからこそ、必須入力項目があったりとか、聞かなければならない項目があったりする。

で、もっと言うと、なぜデータ構造を意識して蓄積しなきゃいけないか？
っていう話ですね。

それは、事業のいまを見ることで、今後の事業の行く末を考えなければならないから。経営＝リソースの再配分という原則に立った時に、いまのリソースの張り方が正しいのかどうかをきちんと見極めなきゃいけない。そして、そこに正しい打ち手を打つ必要がある。細かいPDCAサイクルないし、OODAループを回していくためにも、正しいデータがタイムリーに出る仕組みを整える必要がある。

外部環境が変わり続ける中で、適切にいまの状況を見極め、戦い方を変えていく・磨いていくことが市場で勝つためには必要だし、そのスピードが早ければ早いほど競合優位性が出てくるし、突き詰めれば独自性にだって持ち込める。

Winner takes Allの世界においては、この1分1秒が命取りになる。どこにどんなデータがあり、それが何で取れるのか？そのためにはどんな加工が必要で誰にどんな動きをしてもらわなければいけないのか。

この2ヶ月、社内のデータ構造を1から見直して理想に近づけることができた中で、この辺りの勘所はかなり磨かれた。最初から考えれば良かったじゃんって（ちょっとだけ）思ったけど、事業を立ち上げるタイミングってきっとここまで見えない。

垂直立ち上げで事業を推し進める中で、この設計思想は描けないんだよなー。広げて広げて絞る。広げなきゃ絞れないし、広げないうちに絞ると狭くなる。この塩梅が超重要。

マクロミルでデータの有用性と使い方については理解しているつもりだったけど、事業に入って改めてデータを使おうと思うと、その使い方への感覚はまた異なる。しかも、自社データをうまく扱えるところってそんなに多くないんだろうなーと。この観点でいうと、自分の営業の感覚があるっていうのが大きいし、組織長として結構数字ゴリゴリ見ていたってことが役に立った。

Salesforceの構造整備とTableauのダッシュボード構築までできるようになるとは思わなかったｗｗ（Tableauにもかなり苦労しました・・・でも超便利。全力サポートしてくれた仲間に感謝です。）

けど、SFAとBIツールはこれからの時代に必須ですね。特に、事業の中心にいる（なる）人間がこれを触れて理解できるってのはかなり大きいと勝手に思っている。SalesforceとTableauとSlackが同じ会社ってどういうことやねん！反則でしょ！

あとはもう少し、事業の勘所が磨かれて施策の効果測定やKPIとのGAPからIssueDifinitionまでやって打ち手の設計ができて。ってなったら理想だな。と思います。そこに行くためには何が必要なのかしら？というのをもうちょっと突き詰めて考えてみるのが次のSTEP（もっと言うと、頭の中にあるものを棚卸ししてみる）。

進めていく中で見えてくること、進めなきゃ見えなかったこといろいろあるけども、どこまで見えているかで出来上がりが全然違う。

実際、Tableauのダッシュボードも習熟度があがってきたいま、
なんでこの構造にした！？と過去の自分を恨む瞬間が多々あるｗｗ

ま、なんでも経験。そして振り返って戻れるタイミングで整備する。整えて整えて、また乱れて。の繰り返し。これが変わっていく。ってことなんだろな。