TL;DR

野見という男（気後れするような高い目標を掲げよう）
（なんでもやります！頑張ります！ではなく）先輩の業務のコレくださいを決めよう
（自分のではなく）レポート先のゴールを決めよう
（いきなり手を動かすのではなく）分析の設計書を書こう
（黙々とインプットするのではなく）発表しよう

野見という男（気後れするような高い目標を掲げよう）

ある日、「データチームに新卒一年目の期待の新人を配属するから、その人の人生を背負う覚悟で向き合うように！」と上司に言われまして、東山はビビりました。
この時入ってきてくれたのが、野見さんという方です。
この野見さんが、部の月間MVPを獲得するまでの奮闘を通じて、参考になる部分を紹介していくわけですが、最初にお伝えすべきは彼の人となりかなと思いますので代表的な発言を紹介しておきます。

「ぼく、新人賞とりたいでーす！」
「将来の目標年収は3,000万円でーす！」
「活躍したいんで、ぼく、なんでもやりまーす！」
「東山さん、ぼく、目標は絶対に下げたくないんです！」

高い目標をかかげ、達成のために手段を選ばず努力する、こんな若者がいるんだなぁと感動しました。

この後、彼はさまざまな困難を乗り越えていくわけですが、それを可能にしたのは↑のようなスタンスをそもそも持っていたことが大きかったなと思っています。

僕自身の学びとして、まず気後れするくらいの高い目標を掲げること、それを宣言することを心がけるのがいいなと思いました。

(なんでもやります！頑張ります！ではなく）先輩の業務のコレくださいを決めよう

さて、「新人賞をとる」という目標を前にして考えたときに、大事なことは何かを野見さんと話しました。

結論としては

成長速度の証明として「もう先輩の仕事奪いました！」っていえるようにしよう

ということになりました。

「一連のこの業務を全部おねがいする」前提で動くことで、以下のようなメリットがありました。

都度タスクを与えられるような「下請け」状態ではなく、「次のためにここもやっておこう」という工夫の余地があった
「色々やってるけど、オレなにやってるんだ？」という状態にならなかった

新人の方はちょっと↑の「先輩の仕事のコレください！」って言いにくい部分もあるかもしれないですが、先輩にとっても既存業務を減らして新しいことにチャレンジできる機会にもなるので、ぜひWin-Winとなるように提案してみてください。

（自分のではなく）レポート先のゴールを決めよう

野見さんが「うわぁうまくいかーん」ってなってた時がありました。
お客さまにがんばって分析結果を伝えたんですが、(・ω・｀)という感じで全然響かなかったのです。

原因は、お客様の「課題についての分析」はしていたのですが、「課題に対するネクストアクション」が提示できていなかったことでした。

この時の学びをまとめると

データ分析のゴールは自分が言いたいこというではなく、お客様の課題に対してネクストアクションが決まること
「面白い結果」はいらない、ネクストアクションがほしい
相手のドメイン知識がないと課題の把握が浅いのでドメイン知識をとろう

この振り返り後の野見さんは、お客様が分析結果をどのように使えるかをよく勉強するようになりました。
具体的には先方のIRを読み込んだり、先方のブログを読んだりして、具体的な行動の提案までできるようになっていました。

↑を踏まえて、分析の要件定義には「（レポート先の）ゴール」を記載するようになりました。
このゴールを達成するために何を提案するべきかまでが我々の射程であると認識するためです。

（いきなり手を動かすのではなく）分析の設計書を書こう

配属当初によくあったこととしては、探索的データ分析のフェーズでやたら大量の図を作って、「うーんわからん、あれ、今何やってんだっけ」ってなってしまうことでした。

これは「よし、要件わかったしとりあえず作り始めよう」と基本設計をかかずにコーディングを始めるのに結構似ているなと思いました。

うちのチームでは分析にも基本設計書を書くようにしています。
記載する具体的な内容は↓のような感じです。

要件
仮説
- 「リモート勤務期間が長いと職場の一体感がなくなる」などの真偽を与えられる命題のようにします
- 複数の仮説をいくつも必要になる場合にはWhyツリーなどで仮説群を整理したりします
指標
- 仮説を評価するための具体的な指標を明記します
- ↑の例ですと、「リモート期間（日）」と「職場の一体感のアンケート平均値」みたいなイメージです
図
- レポート時に提出するであろうグラフを書いておきます
- ↑の例ですと、時系列的な変化がみたいと思うので横軸にリモート期間、縦軸にアンケート平均となる折れ線グラフなどでしょうか
ネクストアクション
- 仮説が支持/棄却された場合のお客様目線でのアクションを記載するようにします
- ↑の例ですと、「週に一回出社日を設けてみる」など介入の具体例を記載します
方法
- 群分けの定義や集計期間、抽出条件などのETL処理まわりの各条件を記載します

割と特徴的かなと思うのは、仮説、指標、図、ネクストアクションあたりを記載しておくことかなと思います。

これくらいの段階でチーム内でレビューをおこなうことで、分析のやり方などについての手戻りはかなり少なくなったと思います。

（黙々とインプットするのではなく）発表しよう

この記事を書くにあたって、野見さんに印象に残ってることなど聞いたんですが、初期のころででかかったのは、「勉強内容を発表する」というのを週一とかで実施していたことだったようです。

データサイエンスの背景知識などない状態での配属だったので、課題図書を決め、インプットした内容を週一くらいで勉強会で発表する、というのをやってもらっていました。

同期で学生時代に機械学習をやっていた人もいる中で、「しどろもどろの発表をして、自分全然わかってないやん」て痛感したそうです。

僕としては単に、

インプットはアウトプットすると理解深まる
アウトプットの場が決まってるとインプット頑張るだろ（アドベントカレンダーみたいに）
お客様で説明の練習するわけにいかないから内部でやろう

くらいの認識でしたが、野見さん的には以下の効果もあったようです

「できない自分」みたいなのを隠そうとしなくなった
どうやったらできるかを色んな人に頼るようになった

さいごに

いかがだったでしょうか。
野見さんとは全く違うキャリアの方でもいくつかは学びになる部分があったのではと思っています。
あと、 これから育成を頑張る方にとっても「野見さんの育成」は完璧 と思っていただけたと思います！

新人データサイエンティストの野見くんが部内の月間MVPをとるまでに乗り越えたこと