大手企業でエンジニアスキル（職能）を磨くためにした二つのこと

はじめに

色々な境遇の人がいますが、僕の場合は自分のスキルを軸にキャリアを形成したいと考えてきました。森岡毅さんの本でも、職能に生きろ、的な話があって共感した記憶があります。ただ職能を伸ばそうと考えたときに企業と職能の相性が悪かったり、やりたい業務が出来なかったりして転職する人も多いと思います（少なくとも僕の観測では）。
そんな中で僕は、職能のためにやりたいことと業務を近づけるために色々工夫して、スキルを伸ばしつつ同じ企業で８年間仕事し続けています。実はたまたまうまくいった、そんな内容も多いかもしれませんが、転職の他にも選択肢の一つとして示せればいいなと思い、という記事に残すことにしました。特に書籍や論文の引用はないので、完全に主観的な記事によってポエム化しているかもしれません。

主張

結局のところ技術的な職能を身に付けるのなら、現場で技術全般に触れるしかないと思います。業務ではアウトソーシングするからプライベートでは勉強する、なんてのは一時的には良くとも継続性とパフォーマンスに難があると思っていて、やりたいことを業務とどうにかして近づけることが最短で最高効率の手段だと考えています。なので後はそれをどう実現するのか、ということにつきます。もちろん手段が転職であってもなんでも良く、僕の場合はそれは同じ企業内で立ち回りを工夫することでした。

以下二点を軸にエピソード踏まえて説明します。

• やりたいことを主張するより、自分の強みをぶつける

• やりたいことをやるにはそのための実績と信頼を積んでおく

エピソード

1. やりたいことを主張するより、自分の強みをぶつける

僕は数学専攻を卒業してから数学を活用した研究職につくために就職先を探しました。当時、数学専攻はかなり就職に不利でしたが、これからデータ活用の領域を強めていく方針の企業に拾われて、研究所（製造業）でデータサイエンティストとして働くことになります。
研究所でも色々あって、技術の研究をして論文出している人もいれば、企画を練ったりベンダーコントロールをする人もいました。当時のAIやデータサイエンスの領域は、自社には難しいんだから外部にやってもらおう、少なくともその中継ができる人が社内にいればいい、という風潮でした。
実際、僕が入ったチームもそんな感じで、自分で手を動かしている人はいるものの、社内のスキルは重要視されていないな感じました。その時にはっきりとガッツリ技術のことを自分でやりたいなと思いました。ベンダー利用に傾向していたのは自然な話で、そのチームは組み込みやWEBアプリの開発、企画系をやっていたという分析の専門家ではない人の集まりだったからです。

チームに入ってまずやったのは、自分の適正が技術にあることを示すことでした。マネージャーが優秀であれば、僕の適正を理解して合う仕事をふってくれるだろうと信頼していたからです（そうでなければ見切りをつけていたと思います）。まずマネージャーは僕のことを知るために、アイリス分類問題をやってみてくれ、とお試し問題を出しました。資料化まで含めてなのでプレゼン力含め全般を見られていたのだと思います。僕はいい機会だと思って自分の強み（数学）をぶつけてみました。

ネットで調べると、アイリスのデータは教師あり学習として学習機に突っ込んで結果を出すものが多く見られました。これだと面白くなかったので、僕は混合ガウス分布を使ってアイリス分類を解くことにしました。データは三種類の種が含まれており、また値はガウス分布に従うことが理にかなっているからです。またこれらは確率論で説明するのに非常に合っていたので、数学専攻としては腕の見せ所でした。
成果発表時は、混合ガウス分布の解説とその利用でアイリスを解いたこと、なぜこの手法なのか等を数式を用いながら説明しました。これは功を奏してマネージャーからは、上層部にプレゼンしたりベンダー調節する役割が欲しかったけど君は技術側やった方がいいね、という回答をもらいました。

その後の業務はやりたいことができて、数あるテーマの中でも社内で研究した方がいい内容を回してもらえ、その成果を論文にまとめたりしていました。２年後くらいには研究テーマを作って、当時の最先端の技術を再現したり自社のドメインに応用したりしてきました。こういった経験から、やりたいことを主張するより、自分の強みをぶつける方が色々スムーズなんじゃないかと考えるようになりました。

2. やりたいことをやるにはそのための実績と信頼を積んでおく

その後同僚から、アウトソーシングして出た成果物（システム）が使い物にならないから、それをアウトソーシングして直してもらうベンダーコントロールのプロジェクトを依頼されたが、つまらなそうで困った、と相談されました。ちょっとこれはいい機会かもしれないぞ、と思いあるチャレンジを打診しました。

チャレンジとは、僕と同僚と先輩三人で、そのプロジェクト受けるけどやり方は好きにさせてくれ、というもの。もともとシステム開発には不満があって、なんでこの人たち自分でつくらないんだろうとずっと思っていました。それに、今までデータ分析する中でプログラミングスキルは身についていたと思っていたし、自分達ならできるだろうという自信もありました。加えて、先輩が前職場でウォーターフォールに疲弊した経験から、アジャイル開発に興味を持って調べて知見を持っていたこともあり、スクラムでこの開発をやってみようということにしました。
その後マネージャーを説得してプロジェクトをやる許可をもらって、僕たち三人は認定スクラムマスターを取ったりいろんな勉強をしながらプロジェクトに勤みました。同僚がPO、僕がSMで分析と開発、先輩が主にクラウド（インフラ）を担当して、指定期間以内にシステムの改修を完遂して大成功をおさめました。

その後、データサイエンスからシステム開発に職種を変えることにしました。なぜかというと、スクラムで取り組んだプロジェクトが楽しかったこと、内製でアジャイル開発ができるとアウトソーシングに対して優位性があるということ、研究結果が成果（市場投入）につながっていないこと等を認識したからです。そこでまたマネージャーにチャレンジを提案することにしました。
提案したチャレンジは、困っている事業部門の課題を見つけたから内製でシステム開発して保守運用も全てやってみたい、というもの。スクラムの経験からうまく成果に繋げられるんじゃないかという確信があり、運用ははじめてだけどやってみたいと説明しました。回答としては結局OKで、今までの研究への取り組みなり、スクラムでプロジェクトを助けたことなど、実績と信頼があるからいいよ、ということでした。ただ、運用についてはとても心配されて、責任もあるし前例もないしベンダーに依頼した方がいいんじゃない？と言われましたが、そういう経験をしたいから提案したんだとキッパリと断りました。

ここでは、やりたいことをやるにはそのための実績と信頼を積んでおく必要がある、と認識しました。まずスクラムの成功経験がなければマネージャーは許可しないだろうし、プロジェクト完遂への意欲も信頼がなければ理解されなかっただろうと思います。

おわりに

やりたいことを主張するより強みをぶつけるのは、マネージャーの想定に自分のやりたいプランがあることが前提です。二つ目のエピソードは、マネージャーがとりうる選択肢の中に内製化がないので、やりたいことと任せられる理由をセットで提供する必要がありました。このあたりが使い分けできていくと、双方にとって仕事がやりやすくなるんじゃないかと考えています。今ではマネージャーサイドも担当していることもあり、そこからの視点でもこの考えは妥当だったのではないかなと思います。