【雑記】メンター業務をがんばってたら最強の後輩が産まれてしまった

今年、いわゆるデータサイエンティスト的なスキルの後輩が入ってきて、私がメンターの役割を任されました（正確にはメンターになるはずのメンバーが抜けてしまい、早いタイミングで私が引き継ぎました）。

彼は、今時珍しく(?)、数学的な能力と、その手法を実世界に結びつけるセンスを兼ね備えて持っています。 ただし、プログラミングやエンジニアとしてのスキルは、入社時にはあまり持っていませんでした。

せっかくメンターになったので、ナントカっていう分析手法の話を「わかんねえなあ」って思いながら聞いてたり、「こういうこと勉強したらいいんじゃない？」とか唆したり、自分や同期がつらいと思っていたところを取り除いてたりしてました。その甲斐あったのかは分かりませんが、割と楽しんで仕事しているようだし、エンジニアとしてのスキルも順調につけていっています。

そこで、メンターの立場で心がけたことや、スムーズに業務できている要因をまとめています。ただ、元々彼の学習意欲や吸収力が高いので、どれだけ効果あったのか、汎用性のあるものなのかは分かりません。

標準をつくる

データ周りの人間は、よくわからないDBのよくわからないデータやよくわからない論理削除とかで泣いています。 つまり、「データを取得する」自体がかなりのストレスです。

私は昨年、分析用データの移行作業でつらい思いをしたので、彼にはそんな糞みたいな作業はさせたくありません。 そこで、同期の分析者の薦めもあって、SQLを投げて簡単な前処理を行う、データ取得作業のラッパーになるRのパッケージを作りました。

Hadley Wickhamの本には非常に助けられました。

Rパッケージ開発入門 ―テスト、文書化、コード共有の手法を学ぶ

「この関数を呼べば日別の売上が集計できるよ」くらいに抽象化したパッケージを用意すれば、作業上の誤りや時間の削減にも繋がるはずです。 もちろん「DBの仕様書見れば分かるよ」「基になるSQLを渡すから調べてみて」と言うこともできるし、 例えば問題が発生した際に対処するために必要だと思うのですが、標準化したやり方を用意するとスムーズです。

「標準をつくる」というタイトルはトヨタの本に書いててカッコ良かったので使いました。要するにプログラマーの三大美徳の「怠惰(lazy)」のことだと思います。

全体の労力を減らすために手間を惜しまない気質。この気質の持ち主は、役立つプログラムを書いてみんなの苦労を減らしたり、同じ質問に何度も答えなくてもいいように文書を書いたりする。よって、プログラマーの第一の美徳である。

トヨタ 仕事の基本大全

話は一旦最後まで聞く

私の場合、新卒時には「今の仕事を真に理解していないから、誰に何を質問すればいいのか分からない」という状況になることがよくありました（今でも恥ずかしながらあります…）。

もちろん当時の先輩も「何か分からないことがあったら聞いてもいいよ」と言っていたのですが、 そもそも何が分からないのかまとめられず、まとまっていない状態で話をしても「困っている」ということがなかなか伝わりませんでした。

そのため、モヤモヤしたまま作業して後で爆死するか、 伝わったとしても先輩にとっては当たり前で「そんなことに詰まってたの？」みたいに返されてしまい、 次に話かける際に遠慮して爆死していました。

そもそも、会社というコミュニティの中と外では、使っている文化や言葉も違います。 特に会社に入ってきたばっかりで、エンジニアのスキルが乏しい時期には、「gitでcommitしてpushしといて」という当たり前の会話すらできません。 どこに困っているのか聞き取って解決してあげる必要があります。

ということを偉そうに書きましたが、これらは私ではなく、彼の隣の席にいたRおじさんがやってました。 最近後輩が「別にこのタスクでRにこだわる必要ないので〜」と口にした時、Rおじさんが悲しそうな表情をしていたのを私は見逃していません。

人を動かす 文庫版

とりあえず褒める

エンジニア出身の上司は、よく気にかけていて、定期的に的確なアドバイスはくれます。 しかし、言葉がUNIXコマンドのように端的な上、「困っているときにアドバイスする」という性質上、 私は業務のアドバイスを受ける際に、どうしてもダメ出しばかり受けている気になってしまいました。

上司は「部下を成長させなければいけない」親みたいな立場なのでどうしても口うるさくなってしまうと思うのですが、 メンターはおじいちゃんおばあちゃん並に気楽な立場です。

週一で、普段の業務のフィードバックするミーティングを行っていていました。そこではほとんど

1. どんなことやったのか聞く
2. やってることに対して「いけてるね」って言う

ってやって、調子に乗ってもらうことを心がけていました。 最初に彼に振られた仕事が、ちょうど能力やスキルにマッチしていたし、自律して仕事を進められているので、褒める点には困りませんでした。

本当は「ここのコレをこうしたら良くなるよ」みたいに先輩風を吹かせたかったのですが、 あまりツッコミどころがなかったので悔しかったです。 人事に今週やったことを提出するシートの内容を、もうちょっと具体的に書いてねくらいしか言えませんでした。

荒木飛呂彦が「少年漫画は上がっていくことが王道」って言ってましたが、 同じようにちゃんと良くなっていってるって自覚してもらって、気持よく仕事に取り組んで貰えればと思ってます。

荒木飛呂彦の漫画術 (集英社新書)

想像できるようにする

普段ローカルマシンでRの分析をしていると、どうしてもエンジニアとしての汎用的なスキル（例えばサーバーやネットワーク等の知識）が学ぶ機会はあまり多くありません。

しかし、彼の能力を見ると、例えば将来的にはAWSのスポットインスタンスを立てて計算用のサーバーとして使ったり、 アプリケーションに数値計算のコードを組み込みたくなり、すぐにRのローカルマシンの世界が窮屈になる気がしました。 そのため、早めに他のいろいろなエンジニアの世界を見せるよう心がけました。

具体的には、シニアなエンジニアが主催するランチ会に勝手に登録したり、インフラの部署でLinuxのいろいろを触れるような機会があったので、 それに参加するように促したりしました。

「エンジニアなら家でも勉強できる！」というのも真実ですが、 全く触ったことのない分野は想像がつかないし、勉強を始める敷居が非常に高いです（高く感じます）。 逆に一度触れておけば、必要になったときにすぐ勉強できます。

まとめ

なんとなく感じていることなのですが、大学院できちんと結果を出してきたような人は、仕事の進め方もうまいです。 なぜなら、自己管理をきちんとして、毎日結果を積み重ねることができるからです。

よくわからないコンサルティングの方がよく「社会人と学生の違い」みたいな比較をしてますが、 要するに結果の出し先が違うだけで、本質的にはさほど変わらないはずです。 エンジニアやプログラマーが、「勉強した結果を業務に活かす」というサイクルで成り立っているからそう感じているだけかもしれませんが。

私は学生時代おおむね遊んでたし、入社後のプログラマーとしての能力も要領悪くしか伸びていません。 後輩は既に積み重ねているものが多いし、自分が数週間かけて学んだ概念を、 彼は1日あれば吸収してしまうのでターミネーターに追いかけられている気分です。 私のほうも、知識に貪欲なところや、自己主張の強いところは見習わせてもらっています。

最後に完全な愚痴なのですが、全然大したことやってないのに、必要以上に難しく見せ、 さも専門性の高い業務をやっているように見せている人もいます。 そういう人が、彼のように、ちゃんとした能力もあって、意欲もあるエンジニアの参入障壁になっていると思うと憎いです。マジで憎い。

能力のある人が孤立してしまわないように、周りがサポートしてあげられるように、 「チームで学習して汎用的なスキルにする」というプロセスも大事なんじゃないかと思っているのですが、 まだうまく考えや行動に落としきれてません。

全然まとまりないですが、これで終わります。