経営企画の価値
お疲れ様です。経営企画のたばこ部屋、第17回目の配信です。パーソナリティのきりんです。
常日頃からですね、私は経営企画としてなのか分かりませんが、事業会社でそういった役割を担うのであれば、現場に入り、現場のことを深く理解して、自分の影響範囲を広げて、
それで初めて価値が出るものであると。だから、いろんなところに協力者を作るであるとか、ディープライブをして、事業の解像度を高めるのであるという話をいつもしているわけなんですね。
それを手を変え、品を変え、いろんな表現をしているわけなんですけれども、割と根幹にある共通した思想はそこにあるわけですね。
頭で価値になるのではなくて、現場で汗を流せというような、ちょっと偏った思想かもしれませんけれども、結構そこがなければあまり価値が出ないという、そんな体験を積み重ねてきたというのもあります。
もちろん会社の規模にもよりますし、現場に入らずにマネジメントをすることの価値もあると思います。
データエンジニアの役割
それは一定以上の規模で、一定の組織をまとめる立場とかそういうところでは必要になるプレイだと思いますが、ただそういう方もすべからく現場での解像度というか、現場での仕事を積み重ねたからこそそういったマネジメントを通じても価値が出せるというだけの話であって、
やっぱり根本にあるのは経営企画とかそういった部署で働くのであれば、事業のことを理解しないといけませんし、ちゃんとその事業とか予算を作るにしてもデータを取ってくるとか、それを集計する上でのデータの定義とかいうのをちゃんと理解しないといけないと。
何の話を今日はしたいかというと、そういう自分の思想が色濃く反映されているというか、言語化をすごくうまくしてくれているような本に出会ったというので、これがデータエンジニアという本だったんですね。
なので書評ではないですが、その本の紹介というか、それを見て感じていることというのを話してみたいという、そんな趣旨でございます。
結論、経営企画であるのであれば、この本の言うところのデータエンジニアを是非目指すべきであろうなというふうに強く思ったんですね。
この本で言っている、どういうことを言っているかという話なんですが、まずモデルとして会社の組織を大きく3つに区分して分かりやすく書いていたんですね。
1つが経営、もう1つが事業、もう1つが情報システム。
この3つ、ちょっと書き方として言葉は変えていますけれども、この3つに大きく組織の区分をして、これらをうまく中心に立って、4つ目の丸としてですね、
今3つあったと思うんですけど、その4つ目として真ん中にデータエンジニアというのを置いて、それらが経営事業、情報システム、これらをちょうど横断するというか、翻訳するというか、そういう役割でもって会社を情報を滞りなく開在していこうというような、そういう役割のことをデータエンジニアであるというふうに定義をされていました。
最初は小さい組織であれば、別に経営も事業も情報システムも全部一緒なんですね。
一緒って言うとあれですけれども、少なくとも全員通過というか、何なら初期段階では代表取締役が1人でそれを全部やってましたとか、そういう時代もあるはずなんです。
それが会社が大きくなってくる、事業規模が拡大してくると、当然1人ではやりきれないので、経営と事業のほうが分離をしてくる役割分担ですね、組織ができてくるというところ。
事業も事業で自分で情報を管理していたりとか、セールスフォースじゃないですけれども、そういったツールを使って情報管理とかをするわけですけれども、それも大きくなってくると、やっぱり情報を集める専門の部隊が必要ということで、情報システムとかそういうところが分化してくると。
この組織を大きく3つに区分すると、経営、事業、上司数という3つなんですけれども、このように分化してくると、互いに言語とかミッションが異なってくるんですね。
それはそうですよね。経営としては会社の事業価値とか企業価値とかそういったものを一番に考えるわけですし、現場は現場で売り上げをとりあえず取ってくるというところだったり、デリバリーをちゃんとやりきるとかお客様のための価値を出し切るみたいなところをメインに考えるはずですから、そういう役割になると。
型や情報システムというのは、正しくデータを集めるだったり集計をするだったり保全をするだったり、そういったところになりますし、そのためには専門知識とかインフラとかITインフラセキュリティその辺りの深い知識が必要になってきますし、言語というものもどんどん分化してくる分かれてくるということになるのは理解できるかなと思います。
というところで、その3つの部署が本来やりたいこと、例えば経営として何か今後の意思決定をしたいのであるというので、過去の売上げの推移を出してくれないとか、過去の顧客別の、あるいはエリア別の売上げとか、ちょっともしかしたらあらりベースで出してほしいとかそういうこともあるかもしれませんよね。
それについてざっくりと分かればいいんだけどなという感じでフラッと言ったとするんですけど、でもそれ上司だったりとか現場の担当からするとどういう定義で、どういうメッシュで切り出せばいいのかみたいなところがちょっと分からなかったりとか、
本当はここのデータって正しくないからそこをクレンジングするのに結構時間かかるなとかって言って、すみません、3円以上くらいくださいとかそういう話をしてしまうわけなんですね。
別に全員が一緒のチームで働いていたときとか、本当に代表取締役が自分でやっていたときって荒く適当にざっと管理していたとかだと思うんですよ。
そのノリで言ってしまうと、期待する水準とか目的とかそういったものがすり合わずに本来思っていたような期待水準のデータが出てこないと。
いざ3営業日だって出てくるんだが、それがめちゃくちゃ細かいしそこまで精緻に出してくれる必要ないのになとかっていうことがあるわけですね。
要はそういったすれ違いとか期待する水準とかの違いっていうものをデータエンジニアとかそういう役割ですよね。
経営企画でいいと思うんですよ、この真ん中にいる丸って。
この開在して、要は経営ってこういうことを早く意思決定したいだけだから、細かいところ別によくって、これとこれのこの絡みを組み合わせてこういうデータって確か作れますよねっていうふうに、
具体的にあるテーブルのことを把握している立場の人がいて、かつ経営として何を目的としてこの分析をしたいのかっていうその目的も理解してる人が、
両方の仕座でものが言える人がいればそういったすれ違いは起こらないよねっていうことをこの本は言ってたわけなんですよね。
データの取り扱いと理解
それを結構エンジニアって言うと、コードを書く人なのかなとかプログラマーなのかなとかっていうそんなイメージをなんとなく持ちませんか。
僕は思ったんですよね、エンジニアって聞くと。
だからちょっと自分とはそんなに関係ないのかなとかって思ったんですが、
データエンジニアというものはそういったデータの分析の基盤を作るだったりとか、
コミュニケーションのそういったすれ違いとかそういうものを防ぐような広い仕座と役割を持った立場なのであると。
もちろんまず作ろうと思えばインフラとかそういったところも言葉とか専門性もある程度は兼ね備えているようなそういうポジションの人だと思うんですけども、
役割として、概念としてはそういった3者、経営、事業、上司数、それらをつなぐような役割であると。
そうあるべきであるということをおっしゃっていた本でした。
これが本当に経営企画のあるべき姿なんじゃないかなと思いましたし、
そのためには今はある程度経営と事業をつなぐ役割には慣れているだろうと思うんですが、
この情報システムというかインフラとかデータとかシステムの細かい部分ですね。
エンティティ、データベースの中の細かいデータ生成器材とかですね。
そういった部分がどのように構築されて運用保守されているのかっていうのって結構開発部とかエンジニアリングの部門にそれを丸投げしていて、
自分ではよくわからなくなっていることが多いと思うんですよね。
ただそこに一歩踏み込んで深く理解しようとすると、
途端に多分データを取り扱うということについてこの会社の中でのコミュニケーションがうまく回り始めるんだろうなとそんなふうに思いました。
なので自分としてもちょっと触れてこれなかったそういった領域、データエンジニアじゃないですが、
インフラとかサーバーとかそういった領域の勉強をしてみようかなと思った次第でした。
それ触れてみると本当に深くて広くて大変なんですけれども、
ちょっとまた勉強した内容をここで共有できればと思います。
本日の話は以上となります。お疲れ様でした。
