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

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

はじめての方へ

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




自己紹介

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




データエンハンサーとは

自称です。

lucies.hatenablog.com




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



データサイエンティスト周辺のキャリアパスを真面目に考えてみる

f:id:shoohnalmy:20210124134818p:plain

データサイエンティスト周辺のキャリア例

 


この記事について

さてどうもです。ごきげんよう

 今日はデータアナリストのキャリアについて。

 

結構色んなところで、データサイエンティストになるには、とか、データサイエンティストに高度な分析は必要ないとか、色々言われてたりするんですけれども。どの言説もポジショントークっぽいというか、それぞれの置かれた状況しか見てないんじゃないかなーという気がしておりもやもやとしております。

 

ということで、今日はこのデータアナリスト・データサイエンティスト的なキャリアを選んでしまった人たちが取れるキャリアパスについてのお話をちょっとしてみようと思います。

 

データの仕事をしている人たちにも色んなパターンがあって一概にパターン化するのは難しくて、あんまりきれいな線路がひかれているわけでは決して無いんですよね。「データサイエンティスト」って一口に言っても、組織の置かれた状況によって様々な役割が求められてしまうのではないかなあと思います。

 

※どういう組織にどういう役割が必要なのか、は別の記事で書く予定。

 

そんなわけで、そのあたりをまるっと整理しつつ、データサイエンス周辺にどういう役割が必要とされるのか、というのを書いてみようというのがこの記事の趣旨。

 

自分がどういうキャリアを築きたいのかを明確にし、その上でそのキャリアを描くためにはどういう組織に属さないといけないのか、というのがなんとなく見えてくるとありがたい限り。

 

 

今回の記事で紹介する役割ざっくり

f:id:shoohnalmy:20210124135721p:plain

 

さて、この表でだいたい説明しきったのだけれど。このあたりが主要な役割なのではないかと思います。

組織が小さいときはそれぞれが片手間でお互いの領域に踏み込んでいる事が多いのだけれど、大きくなっていくにつれてどんどんと分業していく感じ。ですが、バックグラウンドと経験に応じてなんとなく振り分けができていく感じ。

 

ということで個々に紹介していきましょう。

 

【基本職】データアナリスト

まずはここがスタート地点。どんなアナリストもエンジニアも、SQLPythonも書けなければそれはデータを扱うものとしてどうなのっていうところですよね。

 

 - SQL

ビッグデータ分析・活用のためのSQLレシピ

ビッグデータ分析・活用のためのSQLレシピ

 

 

データサイエンティストを目指すぞっていって独学で分析し始めると、Pythonは結構みんな使えるようになっていくんだけど、SQLは意外と抜けている人も多い。研究系の出身者なんかはSQL弱かったりするんですよね。

 

実務っていう意味では、大抵のデータは何かしらのDBに入っていて、何かしらのSQLライクな言語で処理する事が多いので、SQLが書けないとスタート地点で躓いちゃう事が多いのでここは抑えておいて欲しいところ。

 

更にいうと、標準SQLと方言の使い分けだったり、HiveとかPrestoみたいな分散処理の特徴までわかるとなお良いけど、ここのレベルは恐らく実務を通しながらじゃないと身につかないかも。

 

最近は分析のためのSQL、みたいな本もあるのでそういうのをちゃんと通っておけばOK。とりあえずSQLはみんなやっとこうな。

 

 - ドメイン知識

あとはドメイン知識が無いと、ここから上にはどこにも進めないのでこれは実務を通してある程度身につけておく必要がある。

業界の利益構造や業界に特有の指標、業界用語などは最低限身につけておかないと、会話が成り立たないのでこれも必須。

 

実務を通して嫌でも身についていくが、意図的に知識を付けてブーストしておくと立ち上がりが早い。XX業界が分かる本、みたいなのを一冊読んでおくだけでもかなり違うはず。

 

 

 - IT基礎知識

意外と見落とされがちなのが、ITの基本的なスキルのところ。データアナリストの業務はIT業界の中にあり、IT知識が必要になるケースは多々あります。

 

特にデータ分析の多くはインターネットに依存するので、HTTPとはなんぞや、Cookieとはなんぞや、みたいな、インターネットを支える基本技術のところはある程度ざっくりとでも良いので、基本的な知識を抑えておくとよいでしょう。

 

それから、分析をやっているとどこかでハードルになってくるパフォーマンス・チューニングにはコンピュータそのものの理解が不可欠ですし、どこかでやってくる分析結果の実装の部分では必ず開発に関わる知識が必要になる場面もあるので、このあたりも。

 

基本情報技術者試験が通ってれば十分、ITパスポートだとちょっと物足りないかも、くらいの温度感だと思っておくととても良いです。

 

 

インターネットに関わるデータ分析もおおいので、このあたりは基本的に押さえておくとはかどるかと。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

  • 作者:山本 陽平
  • 発売日: 2010/04/08
  • メディア: 単行本(ソフトカバー)
 

 

 - ロジカルシンキング

そして、自分ができてると思っている人ほどできてないスキルの代表、ロジカルシンキング

自分はロジカルシンキングが得意だって思っているそこのあなた。あなたが多分一番できていないタイプのスキルです。

 

 

これは別に参考書籍とかはなんでも良いというか、本だけ読んでもあんまり意味なくて、とにかくディスカッションの場数を踏むことが重要。ロジカルにメッセージを作り、それをレビューし合うような経験をいかに積めるか、というのが大事。日常的に意識的にできる環境を作っておきましょう。

 

 

ロジカル・シンキング Best solution

ロジカル・シンキング Best solution

 

 

 

 

【上級職】データコンサルタント

さてここからは上級職のご紹介。

  • 必須スキル:プレゼン
  • あると良いスキル:プロジェクトマネジメント、営業力、データビジュアライズ

 

この人達の役割は、とにかく意思決定者と直接関わり、データや分析をビジネスに役立てていくのが主な役割。分析結果を意味のあるメッセージに変え、意思決定者にデータに基づいた意思決定をさせるのが一番のお仕事。

 

便宜上「コンサルタント」って書いてるけど、コンサル相手は社内にいることも社外にいることもある。

 

この人達はビジネスの役に立てば良いので、分析手法などは後回しでOK。ロジカルな分析さえできれば、クロス集計のみで十分に成果が上がる。むしろデータのビジュアライズやプレゼンなど、いかにして意思決定者にデータを見せるか、という部分にフォーカスするほうが成果が上がりやすい。

 

 - プレゼン

プレゼンに関しては、世の中にいくらでも本はあるけど、一番重要なのはとにかく場数を踏むこと。

場数を踏みながら、たまにプレゼンのコツ的な情報は集め、また場数を踏む、という経験学習を中心に組み立てるのが良い。と思う。知らんけど。別に私も得意じゃないし。

そんなのは得意な人に聞いてくれ。

 

誰に何を伝えるのか、という目的意識に合わせ、データや分析を手段として使う、というのが重要。

 

 

 - プロジェクトマネジメント

これも、意外と見過ごされているスキルの一つ。分析だろうが営業だろうが、それを一つの「プロジェクト」と捉えて推進していくスキルは様々な場面で役に立つ。

 

世の中のプロマネ本はどうしてもシステム開発に寄りがちなので、中々参考書籍などは見つけづらいんだけど。先日発売された「AI・データ分析プロジェクトのすべて」あたりはかなり良いので、こういう部分で知識を入れておくと良い。

他にもPM本というのはかなり多岐に渡るので、こういうところで知識を入れつつも、あとは場数をきっちり踏んでいくのが良さそうです。

 

 

 - 営業力

フリーランスなんかには必須のスキル。私にはよくわからん。しかし必須であることはわかる。

これも分解していくと奥が深いスキルだとは思うんだけど、いかんせん私は営業経験が無いのでよくわからない。書いてはみたけどよくわからないので誰か得意な人は解説してください。

 

営業力が無いと、コンサル力がどれだけあってもまず話を聞いてもらえないっていうスキル。多くの会社で「営業」って呼ばれるタイプの職種は存在すると思うので、分業ができるのなら必ずしもコンサルが身につける必要は無いのかもしれない。

けど、自分のプレゼン相手について何も知らない、というのは全くもってダメだと思うので、ある程度は身につけておく必要があり。

 

 - データビジュアライズ

どちらかというと営業力よりはハードスキルっぽいこっちのスキル。データを見やすく、直感的に整えていくスキル。

これも割と、「自分は出来ている」と思っている人ほど出来ていないスキル。

 

どういうときにどういうグラフを使うのか、というグラフの選択から、PythonやJSのライブラリを使った複雑な可視化まで手段は色々。

手段は色々あるが、大抵はExcelをきれいに使えれば結構いける。Excelのデフォルトグラフは余計な情報が多くて非常に見づらい事が多いので、情報を削り整えていくだけでもかなりきれいにはなる。

 

Excelのグラフそのまま貼り付けをまず卒業しよう。

データ視覚化のデザイン

データ視覚化のデザイン

 

 

【上級職】データマネージャー

 

さてこれは結構聞き慣れない人も多いのかもしれないが。「データマネジメント」というのは分野としては結構広く、データが活用されていくに従って重要度が増していく役割。

  • 必須スキル:データマネジメント
  • あると良いスキル:関連法・規約

私もこの役割はうまく定義できていないのだけれど、基本となるのはDMBOKという、PMBOKのパクリっぽくて全然違うフレームワーク

 

データの活用が進めば進むほどに、データの管理やセキュリティ、ガバナンスなどなど、課題がどんどん増えていく。その上、このあたりはデータアナリストやデータサイエンティストがやるべき領域とも、データエンジニアがやるべき領域とも微妙にずれているという厄介な領域。

 

あまりジャンルとしても華やかではなくて、泥臭い部分も多いのだけれど、こういう人たちがいると全体がうまく回っていくという戦略のコアを担う人材、あるいは部署。

 

 

 - データマネジメント

私もまだまだ勉強中ではあるのだけれど、すでに述べたように基本はDAMA(データマナネジメント協会)が定めているDMBOK。このDMBOKには13の領域があり、まあまあ小難しい事が語られている。

 

その中身は、下にデータマネジメント知識体系ガイド、というのを貼っているけど、読むのがつらくなる。これを30分で分るレベルにまで要約した本などもあったりするのでおすすめ。

 

データを管理するためには、基本的なデータエンジニアリングから分析のビジネスへの展開、セキュリティや関連法律の理解をしつつ、これらを組織とプロダクトのマネジメントに落とし込んでいくスキルが必要であって実はかなりヘビーな領域。

 

ここを極め尽くすと行く先はCDO(Chief Data Officer)なんていう役職が見えてくる。と思ってる。

 

データマネジメントが30分でわかる本
 
データマネジメント知識体系ガイド 第二版

データマネジメント知識体系ガイド 第二版

 

 

 - 関連法・規約

データ周りは法律も難解な部分が多かったり、常にルールが変わり続けている分野でもある。

個人情報保護法みたいな国内法はもちろん、たとえばGDPRのような海外の規則にまで精通している必要があることも多い。

 

その他にも、GoogleAppleのようなTech Giantたちがデータに対してどういう規約を設けているのか、どういうシステム設計にしているのか、というのをある程度理解しておかないと、気づいたときには手遅れになっている可能性もある。

 

これらの理解を全員がする必要は無いが、必要なときに必要な対策を打てるよう、精通した人がいると安全。

 

【上級職】機械学習エンジニア

みんなの憧れ、機械学習エンジニア。

  • 必須スキル:機械学習、エンジニアリング全般
  • あると良いスキル:データエンジニアリング

アナリストが分析した結果を実装する人たち。現実的に、機械学習が必要になる場というのはかなり限られているのでほぼ領域は見えている。金融業界や広告業界、大規模ECのレコメンドシステムなどなど。

基本的に一つのキー(例えばユーザーIDとか)に紐づくデータが大量にあって初めて機械学習が必要になるので、そのレベルにまでデータが集まっている、という時点でかなり大規模なサービスにしか需要がない。商品が10個しかないならレコメンドシステムなど必要無く、ルールベースでどうにでもなっちゃう。

 

一方でこの分野は、ベースのビジネスモデルさえ出来ちゃえば明確に売上を作れるスキルなので、そういうところでは非常に価値が高い。ビジネスモデル次第でいくらでも高給が期待できる。

当然、高給取りになろうとおもったらそう簡単にいくわけではなく、ビジネスに直結する人材は大きな企業でも数人いれば足りてしまう、狭き門でもある。

アナリストからこっちにジョブチェンジするのもかなり厳しい。

 

一生懸命本を読んで勉強してるレベルの人だと多分一生なれなくて、学生時代から最先端の論文を読んで実装しまくってるレベルの一握りじゃないと本物にはなれなそう。

 

ということで参考書籍は無し。arXivやらgoogle schoolarで探してください。

 

【上級職】データエンジニア

最後はデータエンジニア。

  • 必須スキル:エンジニアリング全般、特に分散処理やDB周り。
  • あると良いスキル:エンジニアリング全般、データマネジメント。

アナリストの上位互換というよりはエンジニアの一領域、と捉えたほうが自然かもしれない。が、アナリストに結果的にこういう仕事をさせている組織は多い。

 

主な業務はデータ分析そのものよりも、データを分析するためのデータパイプライン構築や、データ分析を定常化する際のダッシュボード構築などがメイン。

 

通常、アナリストは単発の分析をするときに試行錯誤をしながらデータをいじる。そのため、これをいざ実装しよう、となったときにはパフォーマンスやSLAなどは一切考えられていない。

そのため、分析自体をスケールさせていこうと思うと、こういったエンジニアの存在は必要不可欠になってくる。アナリストに実装させるとろくな事にならない(思い出)

 

Hadoop系の分散処理関連技術を使った大規模パイプラインの構築や、RedshiftやPostgreあたりを使ったDWH構築、各種BIツールを使ったダッシュボード構築などがメインの業務。

アナリストの技術力や社内の制約次第では、分析環境の構築もこの人たちの役割になってくるし、データマネジメントチームが弱ければデータマネジメントっぽいことまでやらされる事になるだろう。

 

実際はこの領域もかなり広いレイヤーがあるのでクラスター構築レベルのインフラ構築、SREみたいな領域からやらないといけないケースもあるはず。

この領域も私あんまり詳しくないので詳しい人は仲良くしましょう。

 

まとめ

いまこそこの言葉を使うときだ

 

 

いかがでしたか?

 

 

初めてこの言葉を使うような記事を書いたので感無量です。これでこのブログも量産型いかがでしたかブログの仲間入りを果たした。

 

 

思ったよりも長くなってしまって、いつもの3倍以上の文量になってしまったけれど、結構このあたりはやらなきゃいけないことは多くて、どうしてもチームの規模が大きくなるまでは便利屋みたいなエース級人材が少人数で頑張る事になりがちで。

 

でも本当は、ちゃんと質の高いデータ活用をしようと思ったらある程度専門家を集めて育てて強いチームを作っていかないと、どうしてもどこかに歪みが出てしまうなあと最近はよく思うのです。

分析屋だけ増やしてもエンジニアだけ増やしてもダメで、ある程度バランス良くチームを作っていかないといけない。

 

ということで、興味があってどっか協力できそうなところがあれば、ご一緒しましょう。一緒にキャリアを考えていけるお仲間募集中。

【専門性の身につけ方】あなたが本を出版するならそのタイトルはなんですか?

専門性を身につけるなら本を書けって楽天大学の仲山さんが言ってた。

 

あなたが本を出版するなら、そのタイトルはなんですか?

 

 

f:id:shoohnalmy:20210117184838p:plain

導入

よく、若いうちは専門性を身に付けろとかって言われるけど、専門性って言われてもよくわからんよね。面接しててもよく言うんですよみんな、猫も杓子も。「専門性を身に着けたい」って。特にデータ分析みたいな業界で働いてるとみんな言う。

 

でも実際、じゃあそんなにみんな専門性高く働いてるの?っていうと別にそんな事もないなあと思うんですよね。社内を見渡すと。意外とただ業務を頑張っていても「専門性」のレベルにまで達しないというか。「社外に出して恥ずかしくない人材」というレベルには達してないなあと思うんですよね。中々そのレベルにまでいかない。ということで今日はそんな話。

 

本題:専門性とはなにか。

 

昔、リニューアル前にこのブログでも取り上げたことのある、楽天大学学長の仲山さんという方が、専門性とはなにかっていう問いに、

「本を書くことじゃないですかね」

ってさらっと答えてて。これがすごく心に残っているんです。

 

 

↓昔書いた読書記録

note.com

lucies.hatenablog.com

 

仲山さんのが当時聞いた講演で言っていたのは、本を出版するって薄い新書でも20万文字くらい書かないといけないから、かなり大変だよ、と。

 

20万文字って原稿用紙で500枚分、PPT資料にしたらスライド1000枚とかになるんじゃないですかね。そのボリューム感のものをいきなり出せって言われてもまあ無理じゃないですか。無理。あ、無理だって思ったんですよ、当時。

(余談だけどここに挑戦するためにブログのリニューアルとかしたんだけどこの話はまた今度)

 

ということで、ここに至るまでのステップアップを考えてみてます、というのが今日の最初の図につながるわけです。

 

LEVEL1-2 社内で勉強会をしろ

f:id:shoohnalmy:20210118215220p:plain

まず最初のステップは小さくてもいいのでまず自分が勉強会をするならどういう事が話せるか、というネタ作りから。このネタは、結構普通に仕事を頑張ってれば多少は出てくるはず。

チームとか会社とか、所属によって規模が違うのでまあ内輪でしゃべるのか、知らない人を交ぜるのか、くらいの温度感で分ければいいと思います。ベンチャーとかだとほぼ同じ意味になっちゃうかも。

ポイントは、「社内なのでまあ社外秘だけどそのまま出してもいいか」っていうレベルってこと。

 

 

基本的に日々の業務で、今回の案件ではどういう新しい事をするかという事を意識しながら仕事をこなしていくと、それだけで話すネタは一気に増えると思います。

更にいうと、こういう「新しい事」のネタを集めるために、日々の情報収集は欠かさないのが大事。(日々の情報収集については長くなるのでまた今度。)

 

例えば今まで使ったこと無いライブラリを使ってみるとか、使ったことないデータを使ってみるとかが分析官だとやりやすいかも。

そうじゃなくても、いつもと違うPPTの見せ方してみるとか、いつもと違う色使いをしてみるだけでも発見はある。そういう細かい発見を積み重ねられるか、というところでまずは差が出始める。

 

こういうところから30分のプレゼン資料を作る、というのはそんなに難しくないはずで、意識するかしないかの問題。これができないならまずインプット量が足りていないか、インプットの質が悪いと思うと良い。

 

LEVEL 3-4

f:id:shoohnalmy:20210118215254p:plain

このフェーズに行き着くまでに一つ、抽象化のハードルがある。大抵の場合、事例には社外秘が含まれる事は多くて、中々おいそれと共有できないものは多い。

これを無理やり出しちゃうっていう手はあるがバレると怒られるので、抽象化をする。

 

抽象化することにはいくつかメリットがあるんだけど、一番のメリットは他に応用できるようになる、ということ。

事例は所詮事例でしかないので、それはn=1のデータでしかない。それを他で応用するためには、抽象化して事例から考え方に昇華させる必要がある。この考え方の引き出しを如何に増やせるか、というのがこのLEVEL3-4のフェーズ。

 

別にLEVEL4は大学の講義である必要は無いんだけど。でもまあ60-90分一人で喋ろうと思ったら1テーマだと結構きついんですよ。ましてや「やってみた」とかいうレベルだと講義にはならないですからね、ちゃんとした知見にしていかないといけない。という意味で大学の講義みたいなものをイメージしてもらうのが良いかと。

修士論文だとLEVEL3止まりか、厚みによってはLEVEL4くらいかな。

 

「こういう施策を打ちました」というのはただの事例だけど、ここから「こういう施策を成功させるためにはこういう法則があります」というところまでに昇華する。

抽象化はパターン化と置き換えてもいいが、要するに単なる一事例を超えた知見が無いと、社外に出せるレベルに行き着かない。単なる事例共有会を超える必要がある。

 

LEVEL 5

f:id:shoohnalmy:20210118215547p:plain

ここまで来るとあとは物量。こういう抽象化された知見の引き出しがいくつ作れるか、という話になってくる。一つの領域、一つのテーマにおいて知見の引き出しが20万文字に達するレベルにまで広く深くしていく。ここまで行き着くには多分広さと深さの両方が必要。どっちかとかじゃない。

 

20万文字というのは原稿用紙で500枚、PPTなら1000枚、大学の講義なら1クール。そういうレベルの知見が揃うと、本にできるレベル。ちなみにこのブログがだいたい2000文字強くらいなので、このブログ記事なら100記事分くらい。

 

2000文字書くのは正直そんなに辛くないのだけれど、100記事分のテーマを集められるか、というとかなりしんどい。けどそのくらいまで知見がたまらないと「専門性」とは言えないという事でもある。大学教授ってすごい。

 

一応物量が必要じゃない例外もあるとも思ってて、例えば査読付きの博士論文とか。多分20万文字の作文書くよりも辛いと思うけど。修士論文レベルだとちょっと弱いですよね、このレベルだと。

 

 

 

まとめ

ということで、自分も本出してるわけじゃないので後半は想像。でも20万文字書けって言ってたから20万文字書くのに今年は挑戦してみようかなって思ってたりします。

 

いずれにせよ、

「自分が本を出すならどういうタイトルになるか」

というのを意識しながら仕事をするというのは、専門性を身につけるにあたってはかなり有効な問いなのではないかと思ってます。

研究テーマを決めるというのも近いかもしれない。「テーマ」が無いと専門性って言わないレベルのものしか身につかない気がする。

 

そしてここまでいっても、最初の楽天大学仲山さんのいう加減乗除の2つ目、減のフェーズである、と。キャリアの先はどこまでも続いているなぁ。

 

 

ということで「専門性」という言葉の解像度を上げるための一つの考え方として。今日はそんなところでした。

データエンハンサーとはなんぞや。

f:id:shoohnalmy:20210111212131p:plain

 

先に結論書いておきます。

  • 分析官がやりたくない仕事全部やる

 

お久しぶりのご挨拶

お久しぶりです。どうもこんにちは。

どうもまあお陰様で仕事はまあまあ忙しくしております。

まあまあ忙しくてもはや読書すらしていないのでそんなに記事を書くタイミングもなく放置していたのですが。ちょっとリニューアルしてまた始めようと思い立った次第です。

 

ということでリニューアル記念の自己紹介記事です。改めまして今後とも宜しくお願いいたします。

 

さて、元々私はデータアナリストとして仕事をしていたのですが、最近はあんまり分析っぽい業務はあまりしていなくて。分析とかデータに関わる色んな事をやってて、業務幅が広がりすぎててなんだか自己紹介が非常にしづらいんですよね。

ということで単なる思いつきで、データエンハンサーと自称することにしてみました。広まっていくと良いけどそんなに甘くはないでしょう。けどこういう仕事してる人、結構いるんじゃないかなーと思います。

 

データエンハンサーのお仕事

 

f:id:shoohnalmy:20210112210058p:plain

 

一言で言えば、データの価値を上げるために必要な事は全部やります。というお仕事。

元々がアナリストなので、SQLやら何やらを書いてみたりHadoop触ってみたりしながらデータを弄っていたのだけれども。最近はどうやら、「データアナリスト」「データサイエンティスト」を目指したい人は結構いて、割と採用は順調にいってるし、社内からのコンバートも順調に増えていてまあ人はいるんですよね。

 

で、一時期のデータサイエンティストブームもあって、こういう格好良い分析!格好良い機械学習!格好いいデータビジュアライズ!みたいなことはやりたい人が結構いるんですよ。

いっぽうで、こういう人たちが共通してやりたがらないのが、データの整備や前処理、管理、インフラの整備や分析結果からプロダクトへの適応、ダッシュボードづくりなどなどなどなど。

こういうのやらないと分析屋として大成しないぞ、とは思うんですけど。

 

現実問題として、多くの会社で右側の「分析」をやりたかったのにやってることはひたすら集計だ、とかひたすらダッシュボードづくりだ、とか、文句を言う「データサイエンティスト()」は後をたたないわけです。

 

ということで、データサイエンティストたちが活躍するために、その周辺ぜんぶやる縁の下のハイパワーマンたちにもちゃんと名前をつけてあげよう、というかむしろ俺に名前をくれ、ってことでこんな名乗りをしています。広がれ。上がれ、俺のバリュー。

 

なぜデータエンハンサーという名前なのか

ほかにもいくつか候補はあって、

  • アナリシスエンハンサー
  • データディレクター
  • データマネージャー
  • データプロデューサー
  • データインプルーバー(improver)
  • データプロモーター 
  • 便利屋
  • 雑用

などなど色々あるんだけど、あんまり役割っぽくしっくりくるのがなかったんですよね。USでもdata scientistとかbig data engineer以外はそんなに統一された名称もなさそうだし。

 

多分、領域としてはData Managementっていうのが一番近いとは思うんですよ。

https://www.dama.org/cpages/home

DAMAっていうコミュニティがあって、ここがデータマネジメントとは11の領域から成る!みたいな事を言っている。気になる人は「DMBOK」とかで調べてみると良いかと。

 

ただ、「Management」と日本語の「管理」って言葉のニュアンスがだいぶ違うと思ってて、管理って訳されちゃうとあんまりしっくりこなくなっちゃうなーと思ったんですよね。もっと攻撃的な表現にしたかった。

 

ということで最終的にエンハンサーと名乗ることにしてみた所存。

 

かるく検索はしてるんだけど世界的に特にそういう人はいなそうな雰囲気。なんか変なニュアンスだったりしないと良いんだけど。英語苦手。

 

具体的なお仕事

もう少し具体的な仕事内容を書くと、

  • 分析環境構築&管理のプロジェクトマネージャー
  • 内製集計プラットフォームのプロダクトマネージャー(お飾り)
  • データマネジメント
  • 分析業務効率化
  • データ教育
  • あと普通に組織のマネージャー

あたりを生業にしております。もうコード書く仕事をしなくなって暫く経つのでたまにコード書くとすごく楽しい。

 

分析だけじゃなくて、分析の周辺って結構課題が山積みで、この辺を順番につぶしていくと実はかなり仕事がスケールしていく事がわかってきたので。格好いいデータサイエンティストを目指すよりも、分析もできるけどまあ何でもやりますよっていう何でも屋の方が実はキャリアパスとしてはおすすめなのかもしれない。

 

というかデータサイエンスの仕事をしてる人の95%が経験すると思うんだけど、世の中の天才データサイエンティストたちにゃあちょっと努力したくらいじゃ勝てんのよ。ということで、そういう天才たちを圧倒的にサポートする立ち位置というのは結構美味しいポジションです。

 

そんな話もこのブログでは徐々に発信していこうかと思います。

 

という自己紹介と今年の所信表明でした。ギリまだ年始といって許されるだろ、ギリ。