「炊いたん」過去記事：機械学習を新たに学んで転職活動に生かす話
過去記事を放流して新しい「機械学習の炊いたん4」のプロモーションに活かす試み。とはいえ、この記事はQiitaやZennに書けないような「テクニカルな内容を一切含まない」半分ネタ記事なので、自身のブログで放流しておきます。
半分ネタ記事とはいえ、人材採用を行うにあたっての考え方は今でも大きく変わりません。人材募集をする側の企業として、自分で書いたことに気をつけるようにしてから、この記事で書いたミスマッチングも減ってきたと実感しています。2年ほど前の記事ですが、お楽しみいただければ幸いです。
Pythonを使えるサーバアプリケーションエンジニアを募集したら謎のAIエンジニア志向の応募が多くて困惑する採用担当エンジニアの苦悩（というより機械学習を新たに学んで転職活動に活かすための話）
TL;DR
最近機械学習を学んでそれを仕事にしたい転職志望者は、これまでのキャリアと地続きのシナリオを立てられるかが大事。企業側も、ちぐはぐな面談をせずに済むよう、十分な情報を出していきましょう。転職サービス・エージェントは、うまく橋渡しできるように努力しようね。
はじめに
先ほどは機械学習ネタと見せかけて飼い猫を見せびらかすお話を書いてしまいましたが、またしても技術書にはふさわしくない（かもしれない）コラムを書いてしまおうと思います。
さて、先のお話にも書いたとおり、私は音声に関するWeb APIをプロダクトとする企業に勤めております。弊社で使用する要素技術には機械学習・深層学習も使っておりますが、実際にAPIを製品ととして提供するにあたっては、それだけではございません。API設計からインフラ設計、実装にテスト、リリース、運用に関わるもろもろ（監視や集計）、ドキュメント整備や顧客問い合わせへの回答など、多岐に渡ります。おそらくWebサービスを提供する企業の多くは上記を担当する方々がいらっしゃることでしょう。
前提として、私はそれら「プロダクトとして提供するための開発運用を行うチーム」に所属し、このチームメンバーのエンジニア採用に関わっています。ただ、開発言語にPythonを用いているせいか、上記のバックグラウンドがほぼ無いにも関わらず「キャリアチェンジを目的にここ半年で機械学習スクールを受講して修了した。Pythonはそこで初めて使用した」という応募者が一定数いる、という状況に苦悩しています。
昨今、AIというバズワードおよび「AI人材が不足」「AIエンジニアは高報酬」といったニュース記事が多々流れてきます。そのトレンドに乗り、キャリアチェンジを目論むこと自体は否定しません。機械学習・深層学習を理解し使いこなすためには数日でできるようなことではないので、日常業務のあとに新たに学習するモチベーション、やり遂げる能力・根気は素直に素晴らしいと感じます。
しかし、一企業の開発チームで採用を担当するようになって、これらキャリアチェンジ志望者と企業のマッチングは非常に難しいと感じています。転職志望者は、自分が経験した企業以外では、どういう仕事をしているかはわからないものです。ましてやキャリア「チェンジ」となると分からないことの方が多いでしょう。一方で、エンジニア人材採用においては企業側にも原因がないとは言えません。AIをバズワードとして使うことはどちらかというと企業側の方が多いでしょう。企業のプロダクト利用者（企業または一般顧客）には「最新技術を用いて高度なことをしている」ように見えたほうが響きますし。
転職サービス・エージェントにも課題がないわけではないと思います。近年様々な（特に「エンジニア特化」や「高収入マッチング」を謳った）転職マッチングサービスが出てきています。しかし、初手のマッチングには違いがあれど最終的には人と人との面談を経て転職は決まるものです。
次節では、「ここ1年以内に転職活動をして、現在は採用活動をしている」私の立場から、機械学習・AIを転職に活かしたいエンジニア、（機械学習に関わらず）エンジニアを採用したい企業側の双方についてよりよいマッチングができるようになるために何が必要か、を書いてみたいと思います。
ちなみに、以下はGAFAおよびそれらを受ける転職志望者にはおそらく当てはまりません。強者同士の転職市場に入る自信がない、入る気がない（スタートアップ志向だから、など）ような方に読んでいたけたらと思います。
「より良い」転職志望者になるために
私が社内の開発チームの採用活動に本腰を入れるようになって数か月、転職エージェントから紹介された、または応募のあった志望者の履歴書・職務経歴書に、すべて目を通すようにしています。私の所属する会社の求人には、Pythonを条件にしているからか、「AIエンジニア」「データサイエンティスト」のような職種を希望している方の割合がかなり高いと感じます。いけないことではないのですが、見たときに、つい「無いな」と思ってしまうのは「機械学習・AIとその方の過去の経歴のギャップが大きい」ケースです。
一例を挙げると、以下のような経歴です。
- 学生時代は文系学部
- ホームページ制作会社に就職してHTMLコーダーとして案件をこなす
- 働きながらAIエンジニア向けスクールに半年通って修了（ここで初めてPythonを触る）
- AIエンジニアやデータサイエンティスト志望で転職活動
ちょっと極端ですが、実際に何名か似た感じの経歴を見てきましたし、そうでなくてもここ数か月〜半年間、業務でお試し利用したことを理由にしたAIエンジニア志望の応募もありました。
このような場合、少なくとも私の感覚では志望通りの転職は難しいと考えます。十分なバックグラウンドなく機械学習やAIをメインに据えて仕事をするポジションに人をアサインする判断を企業側もしづらいでしょう。
実務で機械学習・AIを用いるには、その前段でのデータ収集の仕組み・実際の収集のフロー構築、学習後も、そのデータをどのように活用するか、機械学習用のPythonコードをいくつか覚えるだけでは対応しきれません。機械学習・AIの理論を深く追究するのであればなおさら、半年どころでは学べない数学への深い造詣が必要と考えます。
職務経歴書を見る企業側としては、よほど「AIをかじったことのあるエンジニアを大量に欲しい」ような会社でない限り（あるのか？）、機械学習以前のキャリアと複合的に見るはずです。（私は見ます）
- 大学で何を学んでいたか（工学への基礎的な素養はあるか）
- これまでのキャリアが「経験豊富」なのか「専門分野に造詣が深い」なのか「どちらでもない」のか
- チーム開発や関係部門と連携して業務ができるか
などなど。
全く合致しなければ企業側もスルーできるのですが、悩ましいのは企業で募集している別領域の人材の要件を満たしている（例えば、サーバ／クライアントアプリケーション開発経験やインフラ構築経験が豊富）のだけど、機械学習エンジニアの志望と完全にはマッチしないというパターンです。入社してからも学習やキャリアチェンジの機会があるケースもあるため、機械学習・AIの専任のエンジニアという選択肢だけでなく、企業の求めるポイントを抑え、徐々に求めるキャリアを目指す方が（特にキャリアチェンジを目指す場合は）お互いにWin-Winだと思います。
なので、行きたい or 気になる企業があったときは、これまでのキャリアと照らし合わせてアピールできるようにするのがよいでしょう。（してほしい）
具体的にどうするのか
本節は、通常の職務経歴書はすでに書いてある前提で書きます。
ポイントは、以下がきちんと繋がったシナリオを描いて伝えられるか、です。
1がITエンジニアである場合は、割と簡単ではありますが、それでも2との関連性が薄い／示せないと不当にダメな感じがでてしまいます。 3は必ずしも応募時点でわかるものばかりではないですが、エージェント経由で事前に質問するなどして聞けることを聞いておくとシナリオにリアリティが出るでしょう。
いくつか例を挙げてみます。
1と3の業務内容に接点がある場合
これまでは、＊＊業界で業務系サーバーアプリケーションエンジニアとして自社サービス開発を行ってきました。開発ではプログラミング言語○○やフレームワーク△△を用いてアプリケーション開発を主にやってきましたが、※※な機能を実現するために機械学習を用いる必要があり勉強して身につけました。 御社のこの求人に対して、これまでのキャリアを活かして開発を行いつつ機械学習を用いて機能改善し、事業に貢献したいと思います。
みたいな感じで。（もうちょっと具体的な感じにしたほうがいいかもしれない）
1と3の業務内容に接点が少ない場合
どのような業務でも共通的に使えるスキルがあれば、それをアピールした方がよいかと思います。（マネジメント、提案スキル、対人コミュニケーションなど）
これまで＊＊業界でウェブサイト制作業務をメインに業務を行ってきてプログラム開発・実装はあまり経験はありませんがスキルアップを目指し機械学習を学びました。 機械学習以外の業務は直接リンクしませんが、制作現場ではチームマネジメントを行い、顧客への提案業務も行ってきましたので、これらの経験を活かし、エンジニアチームを率い顧客データを活用した新サービス・新機能の提案・開発を行っていきつつ、他の必要技術も学んでいきたいと思います。
自分にないスキルは、「これから学んでいく」という姿勢が大事ですね。
そもそも1がまったく関係ない仕事だった場合
これはさすがにダメかもしれんね。
これまでアパレル系の企業でショップ店員をやっていたのですが、高度なコミュニケーション能力が求められる割りにお客さんに合ってない商品を薦めたりしていたことに危機感を覚えてAIを学びました。 ちゃんとエンジニアとして店員さんも仕事が楽になってお客さんも満足するような、そんなシステムをいつか作れるようになりたいとの思いが芽生え、エンジニアを志望しました。
志望先の業界にもよるけど、書いてみたらなんかいける気がしてきた。
企業側は何を伝えるべきか
今度は逆に、採用する側の企業ができる／やるべきことについて考えてみましょう。
企業としては機械学習・AIエンジニアがピンポイントで欲しい場合を除き、自社のプロダクトに関連する技術をカバーできるエンジニア集団が必要になるでしょう。その際、機械学習を半年学んだので採用して！と来られても困りますよね。なぜそういう人が来るかというと、求人の情報が十分ではないからです。
コーポレートWebサイト、求人サイトや転職エージェント向けの説明には、機械学習を触るにせよ触らないにせよ、どういう業務領域の人材を求めているか、できるだけ正確に伝える必要があります。技術を売りにしている企業であれば、コーポレートWebサイトには「AIを使って」とか美辞麗句が並んでいると思いますが、必ずしもAI専任エンジニアを最優先で必要となる状況は（規模が小さい会社であればあるほど）ないはずです。
特に、私が「これを伝えるべき」と考えているのは、自社の「業務フロー」です。
流通業や販売業、金融業では当たり前のように「業務フロー」は整備されていたりしますが、エンジニアの「業務フロー」は明らかにされることは経験上あまり見かけません。「開発フロー」は書いてあったりもしますが、「アジャイルで〜」と書いてあるだけだったりもします。
私が想定している「業務フロー」は、もう少し幅広く、以下のような感じです。
- 直接関係する部門や顧客と、それらとやりとりする内容（インプット・アウトプット先）
- 自部門では何を開発／整備して、何をしないのか（インプット・アウトプットの内容）
- どういうチーム運営がなされるか（定例の打ち合わせや報告会、社内イベント）
特に、1と2が明確になることで、転職志望者は自身のやりたいことやレベル感、例えば機械学習を触れるか（勉強できるか）、を判断できるようになると考えています。ちなみに、私はこれらを考えるようになってから、面談まで進めた場合でも、冒頭でまず、自社の説明・応募してもらった業種の仕事内容・業務フローをできる限りきっちりと説明するようにしています。
転職サービスやエージェントに期待すること
ここまで書いたことを転職志望者と企業が正しく意思疎通できるよう、できるだけ正確に相手に伝えて欲しいです。また、エージェントさん自身も、技術用語に踊らされるだけでなく、精度の高いマッチングを実現できるようになってもらえるとうれしいな、という願望もあります。（直接言ってたりもしますが）
おわりに
新卒の就活とは違い、中途採用だと即戦力が求められることも多いですが、キャリアチェンジとなると実務経験がない or 少ないままに転職活動することになりますのでその辺の矛盾に悩むことも多々あると思います。そのような際にこの文章が少しでも役立てばと思い書いてみました。
転職は企業と人の双方に納得できることが重要ですので、入ってから「想像していた内容とは違った！」ということのないようにしたいですね。
技術書典11で「機械学習の炊いたん４。」を出しました
審査を経てようやく販売可能になったのでリンク。
今回は「TensorFlow入門者がRustで推論実行するまで」という章を書きました。宣伝ツイートで1ページめだけ読めるようにしてあります。
3章 TensorFlow入門者がRustで推論実行するまで by @emergent
— tomo-makes@技術書典11「機械学習の炊いたん4」 (@tomo_makes) 2021年7月11日
あの「Rust本」著者が、既刊のメタルネタを離れ、今作ではTensorFlowを触るという冊子のテーマにどストライクな記事を書きました。
じわじわ来ているRustでの推論、ツール化までを取り上げます。私もこれ読んでRust触ってみます。 pic.twitter.com/JcNJGQb43Q
執筆した感想など
「機械学習の炊いたん」シリーズはこれまでの1〜3まで参加してきましたが、正直なところをいうと私はもともと機械学習に慣れ親しんできたわけでもなく、端的にいうと「誰かが作った機械学習を使って作られたツールを使うだけの人」でありました。つまり、TensorFlowやPyTorchといったフレームワークにろくに触れることもなく、DockerイメージやAPIで叩けば使えるものを切って貼って繋げて(∩´∀｀)∩ﾜｰｲとしていただけでした。
1〜3のシリーズではなんとかネタを絞り出して切って貼って繋げて(∩´∀｀)∩ﾜｰｲしてやってきたのですが、昨年「実践Rustプログラミング入門」の執筆に関わる程度にはRustに傾倒している自分が「Rustで機械学習やらんでいいのか…？」という気持ちになりまして。
せっかくTensorFlowがRustバインディングを公式で出してくれているので、これを使いこなせればできることの幅も広がるだろうというわけで、機械学習の基礎勉強もそこそこにTensorFlowのチュートリアルをちょこっとだけやり、今回の記事を書きました。
技術書典11ではエムスリーさんの新刊で、vaaaaaanquishさんにより「Rustによる機械学習概覧」という記事も書かれていてタイムリーな感じがします。こちらは私と違って普段から機械学習に触れている方なので内容は非常に濃く、今後使うライブラリ（クレート）の選定の参考になると感じました。一方の私は「Rustの裾野を広げるマン」として、機械学習の勉強をちまちまやりながら、Rustで機械学習に入門しやすくなる情報を増やしていけたらいいなと思います。
で、どのように「機械学習の勉強をちまちまやる」かについては、今回の執筆にあたってTensorFlowのチュートリアルを4つしかやっていないので、残りのチュートリアル（まだまだいっぱいある…）をやったり、TensorFlow Hubのモデルを使って色んなケースの推論を実装してみて、前処理後処理も含め自身を鍛えていきたいなと思います。普段は、Rustでasyncなサーバー作るマンなのでその辺と機械学習モデルを組み合わせるまでは到達したい気持ち。このリポジトリをもっと拡充していきたい。
というわけで、今後とも「機械学習の炊いたん」シリーズをよろしくお願いします。
おまけ：過去の「機械学習の炊いたん」シリーズでの自分の記事
機械学習の炊いたん
CHAPTER 1 機械学習エンジニアは一日にして成らず
飼ってる猫で顔認識やってみたよ、というだけの記事。
CHAPTER 3 機械学習を新たに学んで転職活動に生かす話
仕事でソフトウェアエンジニアの採用面接やってて感じた話を踏まえてのコラム。
機械学習の炊いたん2
作って遊ぼうデスメタル
楽曲音源分離モデルWave-U-Netを使って、ボーカルをデス声化しようというお遊び。
機械学習の炊いたん3
Spleeterと音声認識を使って空耳検出器をつくる
楽曲音源分離モデルSpleeterと音声認識などを使って洋楽の空耳検出を自動化しようという試み。
Rustを学習してからHaskellを学ぶと理解しやすい
というポジショントーク（？）。タイトルは「手続き型言語をやってきた人には」と付けたほうがいいかも。
この週末、「すごいHaskellたのしく学ぼう！」を読み直していました。
- 作者:ＭｉｒａｎＬｉｐｏｖａｃａ
- 発売日: 2017/07/14
- メディア: Kindle版
最初に読んだのはたしか2018年初めだったと思います。10年ぐらいまともにプログラミングしていない状態から読んだので、Haskell独特の表現にかなり苦労しました。たとえば、
- 型クラス（
Eq,Showなど） - データ型（
data Bool = True | Falseなど） - 型変数の表現（
head :: [a] > a） - 型引数（
Maybe a = Just a | Nothingのa）
などなど。
そもそもの知識がC、Java、Rubyぐらいしかない状態で読んだので、「型引数をとる型で別の型をラップして、fmapなどで中の値にだけ関数を作用させる」ということがすごく高尚なことに思えて。それはなんとなく「難しいことをやってる」感を持つにはいいけどあまり理解はしていなかったように今では感じます。
さてそんな私ですが、2年ほどRustを学んで仕事でも使うようになり、Rustの言語仕様には慣れてきました。そこで久しぶりにこの本を読み返してみると「これはRustでいう○○だな！」というふうに理解しやすくなっていました。
- 型クラスはトレイトを
deriveするってことか - データ型は
enumそのものだ - 型変数はRustでいう関数のシグネチャに似てるし、型制約は（Rustの）
where句で表現しているやつ Maybe a型はOption<T>と同じ意味か
Rustは元々Haskellの影響を受けているので上記は当然かもですが、手続き型言語のパラダイムしか身についていなかった私には、RustをやってからHaskellを読むのが合っていたようです。Haskellは関数・引数・型の表現にあまり括弧を使わない言語仕様であるからか、慣れにくいところはあるかもしれません。Rustは記法として括弧をよく使うため、それらの関係性が見た目にもわかりやすかったのです。
いやまぁ、ぶっちゃけるとRustだけではなくて、ここ2年ぐらいでいろいろなプログラミング言語を学習してきたおかげが一番大きいのかもしれませんが。
Rustコンパイラの優しさに触れながらフィボナッチ関数のクロージャを作る
きっかけ
A Tour of Goを見てたら、クロージャを用いてフィボナッチ数列を出力する例題がありました。
fibonacci()関数の中は自分で作成する必要がある問題だったのですが、解答としてはおそらくこんな感じ。
package main import "fmt" // fibonacci is a function that returns // a function that returns an int. func fibonacci() func() int { x := 0 y := 1 return func() int { ans := x x, y = y, x+y return ans } } func main() { f := fibonacci() for i := 0; i < 10; i++ { fmt.Println(f()) } }
なんとなくPythonのジェネレータとも近い雰囲気を感じましたが、こちらはイテレータオブジェクトを生成するのでちょっと違いますね。Pythonでyieldを使って書いたのがこんな感じ。
def fib(i): x = 0 y = 1 for _ in range(i): ans = x x, y = y, x+y yield ans for v in fib(10): print(v)
Rustで書く
さて、そういえばRustでこういうの書いた覚えがないなーと思って挑戦してみました。最終的にはこうなりました。
fn fibonacci() -> impl FnMut() -> i32 { let mut x = 0; let mut y = 1; move || { let ans = x; let tmp = x; x = y; y += tmp; ans } } fn main() { let mut f = fibonacci(); for _ in 0..10 { println!("{}", f()); } }
最初は、たぶんコンパイラに怒られるだろうと、fn fibonacci() -> Fn() -> i32 なんてシグネチャで書いてみたのですが案の定怒られまして。だけどコンパイラさんが「dynつけろ」「FnMutにしろ」とか丁寧に指示してくれるので、一旦は以下のような形で動作させることはできました。
fn fibonacci() -> Box<dyn FnMut() -> i32> { // ... Box::new(move || { // ... } }
でも、Box使うのなんかやだなーと思って外してみたら「impl Trait使えばええんやで」とコンパイラさんがまたしても教えてくれたので上記のような形になりました。
↓温かいアドバイス
= note: for information on `impl Trait`, see <https://doc.rust-lang.org/book/ch10-02-traits.html#returning-types-that-implement-traits>
help: use `impl FnMut() -> i32` as the return type, as all return paths are of type `[closure@src/main.rs:4:5: 10:6]`, which implements `FnMut() -> i32`
|
1 | fn fibonacci() -> impl FnMut() -> i32 {
| ^^^^^^^^^^^^^^^^^^^
Rustコンパイラさんの優しさに涙が出そうになった夜でした。これからも推し続けます。
Elmで遊んでみた
普段仕事ではバックエンド寄りの開発をメインにしているけれど、少しWebフロントエンドも知っておかないといけない状況になった。Rust好きおじさんなのでYewを勉強しようかと迷ったけど、以前から気になっていたElmに入門してみることにした。
やったこと
- 公式ガイド（日本語翻訳版） を読みながら写経した（3h）
- 仕事で開発したAPIの結果（JSON）を受信して表示するだけの簡単なWebアプリを2つほど作ってみた（1.5日）
- Project Eulerを解いてブラウザ上で結果を表示するWebアプリを作成した（1日）
できたもの
以前から、新たにプログラミング言語を学習するときはProject Eulerの問題を解くことにしている。手続き型言語であればforループで書けばいいところを関数型言語では再帰を使わなければならないなど、同じ問題でも記述方法が異なったりして楽しい。
それで、Elmの場合は言語自体がWebフレームワークと言ってもよいので、ブラウザ上で動作するものを書かねばなるまいと思い、問題番号のボタンをクリックすることで計算処理を実行し結果を表示するようにした。
しかし一番作るときに大変だったのは、新しい問題を追加するときにコード生成させるシェルスクリプト（add.sh）を実装するところだったりして…。
つまずいた点
- ElmはHaskell同様遅延評価だと思っていたら正格評価だった。Project Eulerの問題は最初からパラメータは与えられているので引数なしの関数にしたら（つまりはほぼ定数）、ページロード時に計算処理が走るようになってしまって起動が重くなった。
- 切り捨て除算（
(//)）を行ったときに整数が32ビットに切り詰められる動作で計算が合わずハマった
Elmのいいところ
- The Elm Architecture（TEA）で言語ランタイム側が面倒なメッセージングなどを引き受けてくれるのでシンプルにコードを書ける
- Haskellでコードを書いた経験が少しあったので言語仕様にとっつきやすかった
- パイプライン演算子は、Elixirのパイプ演算子やClojureのスレッディングマクロと同じように使えるのでこれらも記述がシンプルになりありがたい
- エディタ（IntelliJ IDEA）で、保存時に
elm-formatにフォーマットかけるように設定していたらガツガツコードフォーマットが変わっていくのが気持ちいい
万人にとっての良さというより、自分にとっての良さの列挙になってしまった…
さいごに
良いお年を！
アラフォーからベンチャーのプログラマーに転職して2年経ったけど、正直な感想書いてみる。
以前こんな記事があった。タイトルはそれを少しもじった形。より正確に書くなら、「アラフォーでベンチャー企業のエンジニアに転職して2年経ったけど、〜」となるかな。
そこにこんなブコメを書いたらいくつかスターをいただいたので、少し時間が経ってしまったけど書いてみることにします。
未経験じゃなくて、PM系キャリアからアラフォーでPG＠ベンチャーに転身した話なら書けるけど需要ある？
現在の会社に転職したのが2018年9月なので2年とちょっと経過したことになる。未経験からの転職エントリはよくはてブの人気エントリーに上がっているけど、私のようなパターンの人の転職エントリってあんまり見たことないので。
以下に該当するような人にはひょっとしたら役立つかもしれない。
- ある程度、情報系のバックグラウンドがある
- 就職してからは、仕様作って外注する立場だったり、プロマネ職で開発よりリソース調整が業務のメインだったりする
- でもやっぱり自分の手でコードを書いてプロダクトを作る職に転職したい
書いてたらめちゃくちゃ長くなったので先に謝っとく、ごめん。
前職までは何をしていたか
私自身について簡単に書いておく。→簡単にならなかった。4年コーディング、9年企画＆マネジメント職、ということを書いている。あとは飛ばしてもよい。
現職は3社目。大学は電気・情報系（5類）に入学したが、別に小さい頃から電子工作に興味があったとかパソコンをバリバリ使ってたなんてことはなく、入学してから初めてコンピューターに触れた。家電メーカーで開発していた父親に憧れて、どちらかというと電気電子工学を学ぶつもりだったけれど、2000年あたりのインターネット常時接続時代到来とともにネットワークにどっぷりハマり、進路は情報系に転換。そのままソフトウェア開発者志望で最初の某家電メーカーに就職した。
最初の家電メーカーでは、最初の4年間ぐらいは組み込み向けLinux上のソフトウェアをCでコーディングするようなお仕事をしたり特許を書いたりしていたが、その後入ったプロジェクト（緊プロ）で電子書籍サービスの事業立ち上げチームになり、どちらかというと企画メインで、ソフトウェア開発やコンテンツ製作そのものは開発パートナー企業に委託して、パートナー企業と自社の間を行ったり来たり打ち合わせの連続するような仕事だった。まだまだ未熟だったのでものすごく非効率な仕事の仕方をしていたかもしれない。
その後、サービスインすると、協業先とのジョイントベンチャーに出向してオンライン書店の運営をしたり、解体後は自社にもどって営業に近いことをしていたり、と徐々に開発職ですらなくなっていったのであった。
そこで最初の転職をしようとするが、開発職は自分でコーディングするような会社はどこも落ちた。実績でいうと「◯◯の開発をしました」だったり「△△サービスを作りました」だったりとアピールできるものの、実際は自分でコードを書いてないのでコーディング試験で落ちる。プロマネというほどきっちりとした開発プロセスを学んでもいないので開発リーダー職も落ちる。
そんな折に、電子書籍サービスの開発でお世話になったパートナー企業からお声がかかってそちらに転職した。そこでは、受託開発もやっているが、独自技術を使っての製品を大企業に提案して、そのライセンシングと合わせて開発委託業務をもらうようなことを主にやっている会社だった。ここでも、自分でコードは書かないが、最初はアプリ仕様やその後の運用を提案しながら仕事をもらえて結構楽しかった。
その後、同じ顧客の案件で炎上していたプロジェクトがあったのでそこに入り、なんとか頑張ってこなしたら同じアプリ案件をずっと担当することになりそのまま開発リーダーになっていた。その仕事で、顧客や対向サーバー開発担当の某SIerと折衝や自社内のリソース管理を通して、開発プロセスや品質の考え方を学ぶことができた。オフショア開発は安易に手を出すと死ぬということも学んだ。
終電どころかタクシーで帰宅して朝10時に出社するような生活がちょくちょくあって疲弊したというのもあるが、やっぱり自分でコードを書いて開発したいという思いは捨てきれなかった。このとき37歳。
現在どういう会社にいるか
リンク先ブログの書き方に倣うと、情報通信サービス系の自社開発企業、ではあるんだけど、音声処理技術をメインとしたフェアリーデバイセズという会社にいる。社長がゴリゴリのエンジニアで、プロダクトの多くは社長自身が開発したものであった。
入社当時社員20名程度という小規模な会社だが、研究チームと開発チームがあり、私はそこの開発チームに入った。
年齢層は高いかどうかよくわからないが平均年齢35ぐらいといった感じ。社長は私より年齢が一個下だがめちゃくちゃ頭が切れるタイプである。
会社全体の文化としては、企業というより大学の研究室に近い感じで、フレックスでもあるが遅くまで残業することは推奨されておらずのんびりとした雰囲気であった。コロナ以前ですら就業規則にリモートワークが組み込まれていたので、埼玉県から通っている私には非常に働きやすい環境である。
会社としての仕組みは現在でもまだまだ整備中だが、社員の働きやすさを第一に考えて整備されてきているので、規模が大きくなってきても堅苦しいところは少なく、よい会社であると感じている。
どうやって入社したのか
さて、なぜこういう技術オリエンテッドな会社に、私のような「典型的な技術職ではない」人間が「技術職として」入社できたのか。私自身の想像では、10%が実績、20%がハッタリ、残りはタイミング（運に近いかも）だと思う。
私は、長らくコーディング職から遠のいていたとはいえ、ITプロダクトや事業の開発には身を置いていたので、職務経歴書にはそれなりのプロダクト開発経験が並びはする。なので、書類選考は通ることが多い。ただ、1回目の転職活動時は、上述の通りスキルが合わないため、スキルも見合うように半年程度は業務時間外でプログラミング学習をしてきた。
- 「すごいHaskellたのしく学ぼう！」を読んで実践する
- Project Eulerの問題をいろんな言語（Python、Ruby、Haskell、C、C++あたり）で解いてみる
- 通勤時間でTuring Complete FMなどのテック系ポッドキャストを聴く。聴いて出てきた話題を調べて試してみる
と言ったことをやってきた。
それでも、本職プログラマーの人に対しては技術的な優位性はそこまでアピールできない。しかし、前述の経験から「プロダクト開発をゴールまで導く」「開発チーム作りができる」というポイントをメインでアピールしつつ、その中で自分もコードを書いていくんだ、という気概を面接の場ではアピールした。
最終面接では、社長の矢継ぎ早の質問や議論にかなり苦戦した。正直ここまで頭も口も回る人間がいるもんかと感じたけど、答えられる質問には即答し、わからない質問にはわからないと即答し、プロダクト開発のディスカッションに対しては経験を活かしていくつかのパターンで提案する。結果的に、これで内定を得ることができた。ただし、これは後述するが、マネジメント経験があるメンバーを会社が欲していたというところによるところが大きい、と入社後に知ることになる。なので「残りはタイミング」と書いた。
ちょうど今日、たまたまはてブの人気エントリーに上がっていた以下の記事を読んだが、スタートアップの成長過程で「2. 若い社員を増やしたがる」で書かれている「マネージャー不足」に陥る（あるいは陥らないようにしようと考えている）時期が来るはずである。なので、そのような企業とマッチングすることができれば、プログラマー職から離れている人でもプログラマー職に返り咲くパスを作ることはできると思う。
ちなみに、面接に関する余談。私は面接の場で「C言語をやってきたので（プロダクトのメイン開発言語である）C++にはすぐ追従できます」と口走ったが、これはとんでもない誤りであった。この時点で落とされなかったのはラッキーとしか言いようがない。
入社して何をやってきたか
なんだかんだ2年経ったので色々やったが、最初の半年ぐらいのことを思い出しながら書いてみる。
入社して、開発チームに1エンジニアとして配属された。最初はチームリーダーから、ちょっとした機能開発のテーマをもらって、まずは1週間ぐらいでそれを対応した。開発対象のソースコードリポジトリ自体はGitHubのプライベートリポジトリにあったが、開発を始めてからリリースまでの間にすぐに課題が山積されていることに気づいた。
- リポジトリが大量にあるが、どれが何のリポジトリで何の機能を持つものか一切ドキュメントがない
- Redmineは形だけはあったがほぼ運用されておらず、タスク管理されていない
- タスク管理されていないので、誰が何をやっている（やってきた）か、メンバー同士が把握していない。週に一度、今週は何やったよーという報告を各自がするだけである
- 顧客からの要望や不具合指摘が営業チームから入ってくるが、誰もアサインされないので
/dev/nullに消える。催促されたら誰かが急いで対応するのできっちり検討されてないプロダクトができあがる。 - 商用サービスをリリースする手順も共有されていないので、日中にえいやとサーバーが再起動されていた（チーム内にちゃんとできない人がいないわけではなかった）
- テストがろくにされていないので、デグレる→直す、が頻発する
- それらの課題がわかっていても「やらなきゃなー」で再び
/dev/nullへ
要は、チームとしての体を成していないのであった。なので、まずは当たり前の開発体制を1から作ることを始めた。
- 開発チーム内の体制づくり
- 開発チーム外とのやりとり
- 社長や営業チームと話し、会社としていつまでに何を作りたいか、計画が必要なものをヒアリングして回り、上記の計画に反映していった
- 開発チームへの要望や指摘を入れるルートを一本化した（基本的には私がフロントで受け、タスクチケット化し、対応時期と担当者を決めて連絡する）
とまぁ、書き出してみると色々大変そうだが、誰もやりたがらなかったことなので裁量を持って対応でき、当時は私含め6人のチームなので業務時間の三分の一程度でそれらをやりながら残りは自分に開発タスクをアサインしてコードを書く仕事を進めることができた。ちょうど、商用サービスが開始したばっかりで大きな顧客がまだいなかったというのもラッキーだった（当時の状況では大きな顧客がつくこともなかったかもしれないが）。
そこから半年かからずにそれなりに軌道に乗るようになったので、チームで1on1という名の個人面談を勝手に始めて各人の状況や感想を聞くようにしたり、足りないスキルを補うために採用活動をしたり…としてたら、入社後1年ぐらいしてマネージャーに昇格し、今に至るという感じである。
マネージャーになってからは会議の時間が激増して一時期はほとんどコードを書けなくなったけど、今度は自分のタイムマネジメントをしながら死んでもコードを書く、という形でやってたら（途中をめっちゃ端折るけど）「実践Rustプログラミング入門」を出版していた。
前職までとの違い
冒頭のブログ主さんは中学校教員とプログラマー職で比較しているけど、私の場合は業界自体は変わらないので「それなりの規模の会社」と「小規模のベンチャー企業」という観点で比較してみる。
生活の安定に関して
いい年した大企業経験者からすると、小規模のベンチャーへの転職で懸念になるのは収入面であろうと思うが、技術者であるところを鑑みられているからか、特に不満のない収入を得られている。これは当社だけでなく、転職活動時に別で内定を頂いたスタートアップ企業も同程度の年収提示をしてもらえたので業界的にそうなのであろう。（そうでないと得られないスキル領域であるのかもしれない）
あとは、自分の裁量で仕事量と就業時間をコントロールできるので、家族との時間もそれなりにとれている（少なくとも前職よりは）と思っている。どうだろう。こればっかりは妻に聞いてみないとわからない。子供はいない。いたらまた違うのだろうが、当社の子持ちの人は9時〜18時のような時間で勤務していたりするし、子育てしながら時短勤務のプログラマーもいるので、柔軟な働き方ができる就業環境にはなっていると思う。
精神の安定について
大企業だと自分のコントロールできないところで色々決まったり、受託開発だと顧客都合で頻繁に連絡があったり、と心が乱されることが多かった。これは、プロマネをやっててもそうだし、プログラマーであっても同じだろう。
現在は基本的に顧客のフロントに立つことはなく、技術的なやりとりのために自分がフロントに立つ時は電話での連絡をさせない・不定期な緊急会議をしないということを意識することで非常に安定するようになった。顧客が何度も会議を求めてくるようなときは、だいたい開発状況がつかめなくて不安になっているときなので、極力一発で黙らせるように心がけている。
黙らせる、というと言葉が悪いが、要するに、
- 相手が何の情報が欲しいのかを事前にヒアリングし、
- 準備して過不足なく情報提供し、
- ついでに電話をかけてくる担当者のその先にいる上司にどう報告すればいいのか・何を調整してくればいいのか、も教えてあげる
ということである。
コントロールできる範囲
仕事上の裁量は大きいし、プログラマーとしての成長は自分次第だし、で、コントロールできる範囲については文句なしで現在の方が大きい。「こんなの作ってどうするの？？？」という話には遠慮なくNoと言えるのは大きい。
リモートワーク
これは、前職まででも勝手にやっていた（ルールとしてOKだったわけではないが…）ので特に変わった感じはしない。今ならコロナ禍で大企業でも整備されてきたのではないだろうか。
技術イベントや勉強会への参加
前職までも、技術イベントへの参加はできたが、事前申請や事後レポートが必要だったりで多少面倒であった。今は、ある程度事前に経営陣と「こんなこと話すよ」と合意しておけば勝手に行って話をしてもよいので自由である。むしろ、個人としてのプレゼンスを外で発揮してこいというのが会社の方針なのでまだまだ足りないと思っている。もちろん、これはマネージャーである私の特権でもなんでもなく、技術メンバー全員に推奨していることである。
コミュニケーション
ロジカルなコミュニケーションが必要なのはもちろん前職まででも変わらないが、社交辞令や謎マナーを強要してくる人がいないのがとても居心地がよい。
求められる能力
これに関しては、冒頭のリンク先のブログに書かれているのがその通りなのでそのまま引用する
コミュニケーション力
チームの中で溶け込んでやっていける能力、というか態度・姿勢。
といっても普通に話せる能力があれば大丈夫だと思う。
説明力
自分の考えを他者に正確かつわかりやすく伝えられる能力。これが一番大事な気がする。
自走力
質問すればすぐに誰かが答えてくれるような環境ではあるが、当然ながら業務もあるわけで、一から手取り足取り教えてくれることを期待してはいけない。
すぐに「教えてくれ」ではなく、まずはいろいろ自分で問題解決のトライをしてみる、という態度が必要とされる。
一点追加で書くが、マネージャー視点から欲しい能力としては、「報連相ができること」（特に相談）である。
自分としては、悩みを吸い上げやすい環境を作ろうとしているし、悩んでいそうな人にはこちらからアプローチするが、プログラマーの特性として、課題にぶち当たるとそのまま永久に帰ってこれない渦に飲み込まれて悩んでしまう人が一定数いる。メンバーの仕事に道筋をつけるのもマネジメントのうちなので、渦に飲み込まれてしまう前に、自分の取り組もうとしていることがこれでいいのか、これしかないのかを相談すること、相談のタイミングを見極めることも能力のうちであると考える。
周囲のメンバーにはそういうことを言ってはいるが、プログラマーとしての自分はまだ発展途上だし、同じ成長課題を抱えているのである。自分のことを客観視しながら仕事をしないといけない。
転職の年齢について
元ブログでは「ほとんど関係ない」と書いているが、アラフォーともなると、20代のときのような体力もなく身体的な衰えが感じられたりするので、「転職後10年ガッツリ働く」ことを考えているなら40になる前に転職するのがいいのではと思っている。というか私はその焦りがあったので37で転職を決意した。
現在の、人を採用する側の観点でも書くと、アラフォー以降となるとプログラマーとしてはよっぽど尖っている人でないと少なくともチームマネジメントなどのコーディング以外の要素を求めてしまう。50を超えた人であれば、引退が近いことも想定して「数年間の採用でもメリットがあるか」を観点に含めてしまう。あと、大企業の人であれば、だいたいそのぐらいの年齢だと管理職になっていて、プログラマーやってると言われると逆にコミュニケーションに難があるのでは？と勘ぐってしまうこともある。傾向として。
あとは、年齢が高くなりすぎると、それまでの経験を活かすというよりは、大上段に構えて自分の知見をひけらかすタイプの人がいたりするので、素直な人が多い技術者の中にそういう人を放り込むのはリスキーだろう。
おお、それはまさに、こんなブログを書いている私のことではないか。みんな、私の言うことなんて聞いてはいけない。
（おわり）
私だって『実践Rustプログラミング入門』を書きました
8月22日に『実践Rustプログラミング入門』を発売してからすでに1か月弱経ってしまいましたが、共著者の1人として参加するという貴重な経験をしましたので、私もブログにしたためておこうと思います。書かずにいる間に増刷が決まっていました。ありがとうございます！
他の共著者の方々のブログ記事
執筆のきっかけや感想など
2019年のクリスマス、フォルシアの松本さん（id:matsu7874）からのメールでRust本執筆にお誘いいただいたのがきっかけでした。その後、年が明けてから共著者陣で集まりテーマをブレストし、大まかな方向性が決まったと記憶しています。しかし、3月ぐらいまでは皆なかなか筆が進まず…という状況で、4月に入るか入らないかあたりでみなさんエンジンがかかったような気がしています。
最初のブレストの際におおまかな章立てと分担は決めたものの、少し書き始めたところで全体を俯瞰すると「あれも足りないこれも追加したい」と色々意見が出てボリュームが増えていきました。校正に出すタイミングでは、時期的にフルリモートワークのときでしたが、日中に会社の仕事をやってから間髪入れずに執筆・レビュー作業に突入していて、本業なんだっけ状態に陥りつつも、非常に充実した日々でした。ちなみに私は、4章と、11章の「FFI」「Rustを仕事で使う」、3章のFutureを書きました。
それにしても、7人も執筆者が集まると、自分の知らないRustのネタや知識がたくさんあるということを思い知らされました。メンバーの中でプログラマーとして一番未熟な私にとっては、執筆やレビュー自体がとても勉強になり、ますますRustのことを好きになることができました。
現状の自分の立場にも恵まれ、Rustを趣味だけではなく業務で実戦投入することができたことは、これからもRustを使い続ける口実にはなるでしょう。Rustを使ったソフトウェアプロダクトの開発は、いいことが多いので、これからもどんどん発見・発信していけたらと思います。
私とRust
ここから先は、ほぼ自分語りです。
私がRustを本格的に勉強し始めたのは、2019年の初頭だったと思います。新卒で就職した2005年から、数年のソフトウェア開発者（家電のソフトウェアをC言語で書いていた）だった期間を経て、それ以降は長らく開発の上流工程やプロマネ的な立場でばかり仕事してきました。ここでいう上流工程とは、企画や基本設計ぐらいの領域を言っています。つまり、プロダクトのコードを触ることはほとんどなく、業務の合間にちょっとしたスクリプトを作成する程度。それなのに、40歳まで後2年というところでやっぱりコードを書く仕事をしたいと思い、現在の会社に転職しました。当然選考を受けている時点ではソフトウェア開発者としての期待値はそんなに高くなかったと想像していますが、チームマネジメントをすることを期待されて（だと思っています）採用してもらえました。そのときは自分含め6名だけの開発チームだったので、チーム環境の整備しつつ、既存のC++プロダクトをベースに機能追加やバグ修正を積極的にやっていきました。
しかし、入社当初持っていた「C言語をやっていたからC++もすぐ習得できるだろう」という考えは甘く、やればやるほどC++は難しい…と実感することになります。既存プロダクトの多くはC++で書かれていて非同期処理も多用されていました。ロジックが難しいということもありましたが、C++をメンテナンスできる人は限られる一方、非同期処理由来のバグはどんどん見つかって増えていく→自分ほか数名でバグを直さないといけない、という悩みがありました。そんな経緯もあって「もっと別の言語で安全に作り直せないだろうか」と考え始めたのでした。
そんな中で、いろいろ調べているうちにRustを知ることとなり、半年ほどの自分の勉強期間を経て、新規に作成するサブシステムを、自らRustで開発して商用ローンチまで持っていくことができたのでした。言語仕様やコンパイラの動作を実際に試していくうちに、Rustは非常にプロダクト開発向きだという思いがどんどん大きくなっていったのを覚えています。開発に着手するまでに「Rustはすごく良い！なぜならば〜（省略）。だからこれは私がRustで作る！」と社長やチームメンバーにアピールしまくっていました。今思うと、半ばゴリ押しだったな、と。
プロダクトがWebサーバーであり、ちょうどactix-webのバージョンが1.0.0になったばかりだったのはいいタイミングだったと思えます。着手タイミングあたりで、マネージャー（管理職）になったのもあって、「日中はマネージャーのお仕事、それ以外の時間は全部コード書く時間」みたいな生活をしてたような気がします。帰宅してからも土日もずっとRustでコード書いていた（か、試行錯誤していた）ような気がします。
そのときは、まだFutureを知ったばかりで、サンプルコードを読んで動かして、関係しそうなクレートのコードを読んで試行錯誤して…と、あまりスマートじゃないやり方でしたが、徐々に馴染んでくると、「コンパイラに怒られて直して、動かすとちゃんと動く」というRustの開発体験が非常に心地よく感じるようになってきました。怒られ続けて丸二日、みたいなときもありましたが…。
そのような日々を経て、バックエンドでプロダクトをローンチできたときは、感激もひとしおでした。そんなこんなの体験談をShinjuku.rsに投下していたら、松本さんに執筆のお声がけをいただけたので、これはもう是非！という形で引き受けていました。その後は冒頭に書いた通りです。
おわりに
『実践Rustプログラミング入門』は、発売後すぐに非常に好評をいただき、2週間経たずに増刷が決まりました。これには、Rustや競プロ界隈で名を知られた共著者の方々のおかげによるところが大きいですが、私も仕事での立場上、他社の人と関わることも多いので、この本を持ってRustを世の中の企業にもっと広めていければいいなと思います。
