データエンハンサーの戯言置き場

データサイエンティストを挫折した人がデータとアナリシスのエンハンスメントについて考える

はじめての方へ

このページは初めての方に向けた自己紹介とその他諸々のページです。よしなに。




自己紹介

某インターネット企業にてデータアナリストを経てデータサイエンティストになれず、データエンハンサー(自称)、アナリシスエンハンサー(自称)をやっております。 ブログの内容は個人の意見・見解であり、所属組織の意見・見解とは異なる事があります。




データエンハンサーとは

自称です。

lucies.hatenablog.com




↓それでは最新記事をどうぞ↓



分析職と技術職のズレ、ビジネス職とのズレ

はい、なんか久々に分析関連のことを書こうと思います。です。

分析官を5-6年くらいやってたんですけど、未だにあんまり状況変わってないなあって思うのが、分析屋って技術者なんだっけ?っていうこの微妙な立ち位置。

今日はそのあたりの話。

f:id:shoohnalmy:20210320111505p:plain

 

導入

データサイエンティストブーム以降、データサイエンティストになれないデータアナリスト、みたいなことをずっとやっておりました私ですが。結構このデータアナリストっていう立場はすごく難しい。

エンジニアの界隈だと「技術のわからない営業がゴミ案件とってきやがったクソが!」的な、お互いに理解できなくて対立する構造って結構起きがちなんだけど。

データアナリストはちょうど間に挟まるような立ち位置になるので、美味しいポジションといえば美味しいポジションである一方で、この美味しいポジションをうまくコントロールできないと、どっちとも対立する立場でもある。

 

分析職はデータに関わる何でも屋扱いされがち

えてして、「そんなに技術に強いわけじゃないのに技術者扱いされる」というのが結構多い気がしていて、例えば昔TJOさんも紹介していた記事にも、

tjo.hatenablog.com

データに関わるなんでも屋扱いされがち、というのはどこでも起こりがちらしい。

基本的にデータサイエンティストにしろデータアナリストにしろ、そこにあるデータを上手く捌くのが役割であるのだけれど、データを取ってくる部分(リサーチとかタグ設計とかセンサーとか)の業務をよくわからないままにさせられがち、だったりとか、分析の手前の整備部分をひたすらやらされたりとか。

 

ビジネス側からすると最終的に"数字がほしいだけ"なので、その数字をどうやって作るか、という部分はあんまり興味がなかったりするのがしんどいところ。まあしょうがないんだけど。

 

そしてエンジニアまがいの仕事をさせられる分析屋

特に最近のデータサイエンスブームで増えたような、RとかPythonとかは書けます、みたいな独学分析官とかにも多いんだけど、「コードは書けるけど開発はできない」人が結構いる

これが、分析が今ほど盛り上がってなかった黎明期にはエンジニア出身の分析官とか、エンジニアが分析屋を兼ねるケースも多かったのだけれど、今は学習環境も分析環境もだいぶ整ってきたのでエンジニアリングを通らずに分析官になれるようになった。

これは素晴らしいことである一方で、ちょっと業務の領域が広がってしまうとたちまち約に立たなくなるとか、モチベーションとずれていくケースが結構多い。

 

特にありがちなのは、ダッシュボード作成みたいなデータ集計にまつわる開発を分析官がやらされるケース。エンジニアリングを学んでないけどコードが書ける、という人は多いので、なまじこういった自動化に手を出して火傷するケースというのは結構後をたたない。

こういうのって、ビジネス側からすると分析屋とエンジニアの差なんてものはよくわからないし、エンジニアから見ても、「お前らコード書けるじゃん自分でやりなよ」みたいなことになりがちだったりして結構つらみがある。

 

けど分析屋はあくまで分析屋なので、テストのセオリーも知らなければリーダブルなコードもわからない、CI/CDみたいな概念も薄いので作りっぱなしにせざるを得ない、下手するとコードレビューすらもしてない、みたいな感じになっちゃうんですよね。

 

そういう人たちがプロダクト開発紛いのことさせられてるの怖くないですか、僕は怖い。

 

いつだって欲しいデータは手に入らない

欲しいデータを探したことがない分析職の人はすごく恵まれた環境にいるか、データの追究が甘いかのどちらかです。

多くの場合、欲しいデータは簡単には手に入らなくて、いつもイントラをあらゆる方向から検索し、あらゆる人を訪ね廻る羽目になる。うちではこれをドラクエと呼んでるが、村人からヒントを貰えれば良い方で、最後までよくわからないけどまあ良いかって妥協しながら呪文を唱えることがしばしばある。

 

"データを分析するために取得しているデータ"ってそんなに多くはなくて、大抵はのDBは第一にサービスを提供するために構築されているので、分析しやすい形式にはなっていない。

 

ビジネス側からすると、「え、DBに入ってるんでしょ?なら分析できるでしょ」ってなりがちで、分析屋からするとお前そんな簡単じゃねえわなんだこのデータ形式は、ってなりがちだし、本番稼働中のDBとか触らせてくれるはずが無いのでまずデータのdumpをお願いするところからやらなかきゃいけなかったりする。

 

一方でエンジニアからすると「そこにあるから勝手に持ってって」になるか、持っていくのは良いけど工数かかるからまず要件決めてビジネス的な価値の試算しといて、バックログに置いておくわ、になって全然ビジネス側とのスピード感が合わなくなっちゃったりして、なんなら要件定義をする羽目になる。アナリストとは一体。

 

で、アナリストというのはこの板挟みになりがちで、結局データを取得してくるところから分析して知見を出すところまでまるっとプロジェクトマネジメント的なことをさせられて、こういう仕事がしたいわけじゃないんだけどなって思いながら転職or異動していく、というのを多く見てきました。

 

けど期待値だけは上がるデータ分析職

こういうヘビーな交渉とそこそこのエンジニアリングをこなせる"有能なデータサイエンティスト"はたまにいて、そういう人たちを見てデータ分析職の期待値は結構上がっていくんですよね。

 

けど有能ではない大抵の分析屋はデータがあればなんとかなるけど「データがなければ無力」なので、この期待値に応えられない人が大半だったりするのです。つらい。

 

期待値は上がるので色々な相談は来るのだけれど、そういう相談の大半が"分析"という範疇を超えた期待をされていて、分析結果からの施策提案までであればマシで、下手すると企画まで求められたり。もしくは分析しでデータ出したあと定常的にデータを見られるようにしてほしいって言われてデータパイプライン組んでダッシュボード構築が必要だったり。

 

まあ弊社弊部で言えばだいぶマシにはなったけど、まだまだこういう環境は続きそうだなあと思う今日このごろ。

 

結局分析職にはPM力が必要

と、いうことで分析職がある程度こういう板挟みの中に置かれるのは仕方なくて、しばらく状況は変わらなそう。

この状況を打破するためには、分析職自身が強くなるか、役割を明確化し組織として対応するかのおそらく二択になるのだと思う。

 

とはいえ、大抵の分析組織は役割を明確化して分業できるほど大きな組織にはなっていないので、成果を出すためにはPM力を身に着けながら分析とかデータとか以前のプロジェクト自体の前捌きができるようにならないとダメそう。

 

こういう本も出てきて話題になっているし(昔の同僚を勝手に宣伝)

 

最近は分析職が分析するよりも、現場の人間に分析のやり方を教えていったほうが成果が出やすい、というのも通説になりつつあったりするので、組織のコンディションによるところはたぶんにあるだろうけど、"分析だけ"を求められる環境は幻であるというのがだいぶ見えてきたような気がする。

 

この辺とかもまさにそういう感じですよね。

 

自分としては幸いにもそこそこ人数の多い組織にいるので、"役割を明確化し組織として対応する"という後者に挑戦していきたいところ。今ね、ここを下支えするためのプロダクト作ってるの。

 

まとめ

ということで、まとめると、データ分析職ってアナリストだろうがサイエンティストだろうが、スーパーゼネラリストじゃないと生きていけない雰囲気が出てきたなあ最近、っていう感じ。

 

いまからキャリアをちゃんと考え直せるなら、エンジニアリングとデータサイエンスは工学系の大学/大学院である程度学べるので、そこで地力をつけた上で就職後にビジネス力を中心に身に着けていく、というのが良さそうですよね。というかこれから入ってくる下の世代は間違いなくそういう人たちがどんどん出てくる。

 

そうじゃないルートで分析職に入ってきた人は、あくまでキャリアのステップの一つとして捉えて数年で次に進むのが良さそう。こういう中間の立ち位置に慣れると、分析職の外に出てもPjMとかPdMとしての下地になる気がする。気がするだけなので今自分で実践中。

 

そんな感じであんまりきれいな結論出てないですけど、分析屋の皆様は一緒に挑戦していきましょう。

 

 

挑戦中のアカウントはこちら

twitter.com