アラフォーからベンチャーのプログラマーに転職して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を超えた人であれば、引退が近いことも想定して「数年間の採用でもメリットがあるか」を観点に含めてしまう。あと、大企業の人であれば、だいたいそのぐらいの年齢だと管理職になっていて、プログラマーやってると言われると逆にコミュニケーションに難があるのでは？と勘ぐってしまうこともある。傾向として。
あとは、年齢が高くなりすぎると、それまでの経験を活かすというよりは、大上段に構えて自分の知見をひけらかすタイプの人がいたりするので、素直な人が多い技術者の中にそういう人を放り込むのはリスキーだろう。
おお、それはまさに、こんなブログを書いている私のことではないか。みんな、私の言うことなんて聞いてはいけない。
（おわり）
