こんにちは。 @atsfour です。
私はもともと学習参考書(理系中心)の編集者をしておりましたが、32歳でオプトテクノロジーズにエンジニアとして飛び込みました。
そのときやったことを振り返りつつ、異業種からの転職を考えてる人の参考になれば幸いです。
転職前にやったこと
スクールに通ったりするスタイルもあるかもしれませんが、座学より実践の方がいいと私は思っています。
自習もしましたが、通常の仕事の中に取り入れていくことで身につける方が効率的です。
私の場合は、そもそも元の職場で役立てるために色々やって、その結果として本業にしたくなったという経路をたどっています。
- 前職の業務の中で
- 紙や個別のExcelなどで管理されていたデータを統合
- 社内で一部使われていた Microsoft Access を使用し、進捗管理やマスターデータ管理などをDB化した
- この段階で基本的てSQLやDB設計(正規化など)の基本も勉強できた
- ちょっとした人力作業を自動化するような使い捨てスクリプトを使い方とともに提供
- 英文テキストから単語の使用頻度をカウントするものとか
- 紙や個別のExcelなどで管理されていたデータを統合
- 学習として
- 複数の言語の入門書を読み、基本を押さえた
- 私はPerl, R, Scala, Pythonとやりました
- 自力で環境構築(重要)して、あとは軽い問題を解く程度
- 競技プログラミング的なものに挑戦
- CodeIQやpaizaの問題、Project Eulerなど
- 特に、paizaでBランク取ったぐらいから、「あれ?俺イケてんじゃね?」とか思い始める
- 複数の言語の入門書を読み、基本を押さえた
この時点でWeb系エンジニアを志望してもなく、Webに関する基礎知識もほぼ皆無に近い状況でした。
オプトテクノロジーズの環境
といった感じで、2016年にオプトテクノロジーズへと転職することに。未経験のオッサンを拾ってくれたことに感謝。
とりあえず、自分が全然イケてないことがすぐにわかりました。
- 自社プロダクト
- 外注中心から自社内開発への転換期
- エンジニア組織が立ち上がり期で、拡大していた
- エンジニアがほぼ全員中途採用で、新人が入ることに慣れていた
- 各人のやるべきことが流動的で、自分の強みを活かせる仕事を見つけることができた
- 特に、開発サイドとビジネスサイドのつなぎ役として存在感を出せた
- とにかくプログラミングが好き、というタイプのエンジニアが多数所属していた
- 技術的なテーマについて、質問したり議論したりする環境は整っていた
- 評価制度
- 完全裁量労働制・実力主義な評価制度
- 年次や経験が占める部分がほとんどない
転職してからやったこと
ヒヨッコ期(〜半年ぐらい)
「役に立てる」「1人前になる」というテーマに的を絞って、選択と集中を心がけました。
- 担当プロダクトの主力言語(Scala, TypeScript)と主力フレームワーク(Play, AngularJS)のキャッチアップ
- Scala関数型デザイン&プログラミングの練習問題を黙々とこなす
- TypeScriptとAngularJSの組み合わせで、フロントエンドの環境構築を自前で色々試す
- 自分でもやれそうな仕事をひたすらやって、業務の基礎を身につける
- とりあえず手をあげ、低難易度な仕事を中心に量をこなす
- 考えたり調べたりする前に周りに聞く
- 一度聞いたことは次回からは自分で調べる
- 会議などの場で発言・質問しまくる
仕事の鬼期(半年〜1年ぐらい)
それなりに活躍できるようになったとともに、純粋な技術力や好奇心が周囲に劣ることを実感しました。
この時期に、自分がここでこれからどういう立ち位置を目指すかを検討し、非エンジニア出身であることを活かす道を模索しました。
- とにかく仕事をする
- 学習は完全に「業務上知らないと困ること」だけ
- 担当プロダクト(アプリケーション側)については、広く浅く、ほぼ全域を担当できる状態に持っていく
- (この時期、量こなすの頑張ったね、といった趣旨で表彰されたりしました)
- 人脈を広げる
- ビジネス担当のメンバーと親しくなる
- 非エンジニア向けの説明力をつける
- 担当プロダクトの仕様や背景に詳しくなる
- アーキテクチャのイロハを覚える
- 追加機能の詳細設計ができるようになった
- スケジューリングや工数感を身につける
- 自分で実際に書いた経験がないと絶対ムリ
- 設計力もないと厳しい
この時期、プロダクトはちょうどリリースを控えた追い込みの時期でした。
仕事の鬼をやりつつ子育てもなるべくやりたい、というわけで、 定時退社 -> 家族の時間 -> 深夜にもうひと仕事、 というサイクルで家族のコアタイムをギリギリ確保する感じでした。
マネージャー期(1年〜現在)
チームマネージャーという立場になり、画面よりも人と向き合う時間が増えました。
この時期ぐらいから、開発チームがスクラムを徐々に導入し始め、新たな展開に入ってきました。
- 開発者として
- まとまった機能については計画フェイズとコードレビューが中心
- 自分が書くのは宙に浮いた案件や緊急性が高いFixなど
- プロダクトの開発側の窓口として
- サポートチームからの質問の対応
- 障害発生時の一時対応と、その後の予防開発の取りまとめ
- 新規開発機能の選定や技術的な相談
会社にいることそのものの価値が上がった結果、子育て時間の確保がだんだん難しくなってしまいました。
転職やめといた方がいい、と思う例
全て私の主観です。
私はこの業界では1つの職場しか知らないので、参考程度に。
動機が「プログラミングが好きだから」だけ
30過ぎて別業界で働いている時点で、あなたは「ガチのプログラミング好きほど好きではない」と自覚すべきです。
そういう人は最初からプログラマーになるか、20代のうちに転職してます。
好きであることは重要ですが、好き以外の武器がないとここからの巻き返しはキツイと思います。
整った研修プログラムで仕事を覚えていきたい
未経験者への教育環境や仕事の進め方などが整っている組織はそれ単体で見ると魅力的ですが、裏を返すと 若い新人と差別化するポイントが少ない とも言えます。
我々は、あくまで 同じ30代のすでに経験豊富なエンジニア と、何かしらの強みを以って対等になること目指しているはずです。そのためには標準のプログラムに乗っかって受動的に学習していては間に合わないです。もちろん研修プログラムが整っていることはプラスなので大いに活かすべきですが、それに期待している状態だと厳しいと思った方がよいと思います。
準備運動が足りてない
「未経験」とか言ってますが、今どきどこの会社でも「プログラミングに近い仕事」は必ず作り出せると思います。
専業のエンジニアになる前に、自分の職場の改善の一環として技術を導入する経験は可能ですししておくべきです。
まとめ
やるべきことも、チャンスも、自分が入り込めるニッチも、十分にあったと思います。
一方で、技術力向上のための投資が相当量必要なことも確かです。それだけ投資をしても、純粋な技術力のみでエースになる、というようなことが困難であることもおそらく正しいと思います。
しかし、エンジニアリングの周辺には、エンジニアリングがわかってないとできない、エンジニアリングではない仕事が豊富にあります。そこには大きなチャンスがあります。