思ってたんと全然違うデータサイエンティストのリアル

なんでこのnoteを書こうと思ったのか

こんにちは！つかぽんたんです。
普段はXでデータサイエンティスト関連の勉強とか仕事のことについて発信してます。
https://twitter.com/tsukapontan_

2023年10月に大手通信キャリアの営業職からコンサル系のデータサイエンティストに転職したんですが、この半年を振り返ると、もうそれはそれは多くのギャップに苦しんだ半年だったのでその素晴らしい（苦悩の）思い出を記録しておくべく、このnoteを書くことにしました。

同じように未経験からデータサイエンティストになろうとしてる人や、データサイエンティストってどんな仕事なんや？って気になる人の参考になれば嬉しいです。

そもそもデータサイエンティストってどんな仕事？

友達に「今仕事何してるの？」って聞かれて「データサイエンティストしてるよ」って返すと100人中２〜3人くらいは伝わるけど、ほとんどの人は「何それ？美味しいの？」ってくらい認知されてないマイナーなお仕事。（まあ、そうだよね。割と最近できた言葉だし。）
簡単に言うとめーーっちゃたくさんのデータをあれやこれやいじってそこから色々な事実や示唆を見つけてそれをビジネスに繋げるお仕事なんですが、まあ一言で言うと

データ分析のプロ！

って感じです。とりあえず今日はこれだけでも覚えて帰ってくださいね〜〜〜

未経験で転職して陥った落とし穴

そんなデータサイエンティスト（以下DS）ですが、データサイエンティスト協会によると、DSには求められるスキルが大きく３つあります。

• データサイエンス力

• データエンジニア力

• ビジネス力

データサイエンティスト協会HPより

一つ目のデータサイエンス力は、いわゆる統計学や機械学習、AIの理論とかの知識。
二つ目のデータエンジニア力はPythonやSQLのいわゆるプログラミング知識。
そして三つ目はデータ分析を使ってビジネス上の課題を解決する力。
と言う感じで僕は解釈してます。

転職前は
「元営業だし、新規事業を立ち上げようとしたこともあるし、ビジネス力はあるだろ！データサイエンス力とデータエンジニア力を磨かなきゃ！！」
なんて思ってましたが

実際になってみて最初にぶち当たった壁がなんと
ビジネス力の欠如でした！！

一番自信を持ってたところだったこともあり、まじでめっちゃきっつい思いした（今もしてる）ので、その内容をつらつら書いていきます。

営業とデータサイエンティストの違い

何をするべきか自分で全部考える

多分ここが一番営業と違う！！
と言っても過言じゃないくらいには苦しんだとこ。
例えば、営業だと売り上げを作るために、

1. お客さんのことを調べて

2. 提案資料を作って

3. 商談して

4. 見積書作って

5. 契約とってくる

っていう一連の「型」が存在してて、その中でどうすれば契約してもらえるか考えられればよかったんです。
やることがある意味はっきりしてるんで、慣れてくると、割と作業感がありました。

一方DSになったは今は上司からふわっとした課題だけ与えられて、そこに向かうにはどんなことをしなきゃいけないか、を自分で考える必要があるんですね。
そこに決まった「型」なんて存在せず、ロジカルにするべきことを洗い出して構造化して実行というのを繰り返さなきゃいけない。

言うは易し、なかなか何からやればいいか最初わからず、上司などに相談するんですが、ここでも壁にぶち当たります。

オープンクエスチョンで聞くな！！

オープンクエスチョンとクローズドクエスチョンって知ってますか？
YesかNoで答えられるのがクローズドクエスチョン。それ以外がオープンクエスチョンです。
うちの会社では基本的に上司にオープンクエスチョンで質問や相談するのはNGです。

配属当初、先輩に「このタスク何からやればいいですかね？」とカジュアルに相談したらめちゃくちゃ注意されました。
どんなにわからなくても自分の中で何がわからないのかをはっきりさせたり、わからないなりにも仮説を立てて、それが合っているか？みたいな聞き方をする必要があるんですね。
営業の時は経験豊富な先輩にカジュアルに聞けば色々教えもらえてたので、このギャップに最初めっちゃ苦しみました（苦笑）

構造化されてない文章に価値はない！

若干言い過ぎな気はしますが、とはいえ本当にこんな感じの風潮があります。
Slackで質問一つするのにも↓こんな感じで文章の形式を整える必要があります。
▪️質問
▪️背景、経緯、事実
▪️仮説
何も考えずエイヤー！って人にSlackを送った日には多分無視されるか「意味不明です」と返ってきます。

特に議事録。
営業の時は新卒研修で議事録作成をやるも、実際の現場ではもはや議事録を取らないことがほとんどだったし、取ったとしても、宿題と決定事項を軽くメモする程度でした。

それがDSになった今、議事録はマジでちゃんと作らないといけない。本当に議事録に対する考え方が全然違う！！
アジェンダごとに発言者がわかるように議事を取りつつ、ToDoと決定事項を構造化してまとめる必要がある。しかもただ聞こえてきたことを書くのではダメで、要点を抑えて必要十分な情報を記録していかないといけない。

でも構造化することに慣れれば、自分の思考の整理もできて、結構質問事項を整理してたら自己解決できたなんてことが増えてきた。
これは結構成長感じるポイントでもある。

知ろうとしないことは悪

営業の時は大企業だったこともあり、扱う商材はマジで無限にあり、全然詳しくない商材を提案することなんてざらにありました。
もちろん詳しいことに越したことはないのですが、社内のサポート体制がしっかりしていたこともあり、あんまり自分から調べることをしなかったし、知らなくても全然成り立ってました。

ただDSではこのスタンスはマジで許されない。
配属されてまだ全然プロジェクトを理解できてない時に、議事録を任され、何を言ってるのかもわからないので、わからない単語をとりあえず聞こえてきたまま書いて（まあみんなはわかってるでしょって気持ち）そのまま先輩に見せたらめちゃくちゃ詰められました。
なんで自分で調べたり質問してこないんだ？って

確かに同じプロジェクトのMTGとはいえ、自分が任されてた領域とは違う内容だったので、まあわからなくても仕方ないっしょみたいなスタンスだったんですが、DSはそういう細かいところから示唆が出てきたりするので、わからないことはとことん調べ抜くことが求められます。実際は完全に理解するのはなかなか難しいかもですが、そのスタンスが大事なんです。これは本当に反省してます。

スケジュールに合わせて仕事するんじゃなくて、仕事に合わせてスケジュールを組む

営業の時は、決められた納期に向かっていかにタスクを遂行できるかが大事でした。最初にスケジュールが与えられて、そこに向かってどう動くか優先順位を付けていく感じ。

この考え方が染み付いてた僕は、タスクをもらった時に最初にDueを設定してそこから逆算してタスクの時間を割り振って、結局時間内にタスクが終わらない！なんてことが起きてました。

そんな時、先輩からこんなアドバイスをもらいました。
「定時内で確実に遂行できるタスク工数を見積もって、そこからスケジュールを設定すればいいんだよ。もしそれで間に合わないことがわかったら残業することを考えるんじゃなくて、スケジュールを調整することをまず最初に考えるべき」

これを言われた時はハッとしましたね。
もちろん、守るべきデッドラインは存在しますが、大半のタスクはスケジュールを調整できます。
守れないスケジュールを上司に伝えて、タスクが終わらないと評価を落としますが、自分が対応できる範囲でスケジュールを立ててタスクを進めると、むしろ信頼を得られます。これに気付いてからはだいぶ気持ちが楽になりました。

次の半年に向けて

日曜日にカフェでこの記事を書いてますが、本当にきつかったなあと若干明日からの仕事が憂鬱気味になってます。笑

とはいえ、今の環境はめちゃくちゃ成長できるなあという感覚があるのも事実。
あとこの記事では触れませんでしたが、DSのメインである分析業務は割とずっと楽しいです。

上司からは最初の半年が一番きついよって最初に言われてたので、ここからどんどん自信を付けて頑張っていきたいですね。

思ったより長文記事になってしまいましたが、ここまで読んでくれてありがとうございます！
ぜひいいねしてください！！！！！！！

これからもちょくちょくnoteの更新がんばります！