「エンジニア35歳定年説」が許されるのは小学生までだよねーとか思っていたら、実際にはそんな感じになってしまったあるエンジニアの半生を振り返ります。ご参考まで。
第一期
- サービスリリース前
- 自分でサービスをガリガリ作っている
- というかサービスを作ることしかしていない
- １日１６時間くらい仕事をしても、プログラミングしかしていないので疲れない
- 仕様の検討をしながら作るので、基本全ての時間は開発をしているという認識
- フルスタックエンジニアというある種の全能感を満喫する
第二期
- サービスリリース後
- 運用（ユーザーサポートなども含む）が入ってくるのでサービス開発のスピードが落ちる
- エンジニアを採用（業務委託含む）する
- 仕様の調整やコードレビューなど、開発以外の仕事が少しずつ増えてくる
- でもまだまだ自分が圧倒的にメイン開発者
- コードレビューやマージ、リリースは自分が全てやる
- システムの全体からディテールまでほぼ完璧に把握している
第三期
- サービスが軌道に乗ってきて、エンジニアをたくさん採用する
- とはいえ人事とかはまだ整っていないので、採用のオペレーションや面接などでかなり時間をとられるようになる
- コードレビューにもかなり時間をとられるようになる
- 自分のレビュー待ちがボトルネックになることがある
- レビュー、マージ、リリースを権限委譲しはじめる
- システムの全体像は把握しているが、ディテールに少しずつ自分が把握できていない部分が出てくる
- 自分より圧倒的に優秀なエンジニアが入ってきて、その人が書いたコードは正直よくわからないみたいなことも起こりはじめる
- とはいえまだまだシステムのコアの複雑な部分（別名：秘伝のタレ）は自分しか把握できていないので、そのあたりの改修は自分でやったりとエンジニアとしてのアイデンティティを保つことはできる
- 同時に、初期の実装が後から入ってきたエンジニアにdisられることが頻発する
- まだ自分が書いたコードが半分以上残っていて、ある意味メインエンジニア（というちっぽけなプライドにすがる）
第四期
- 一人ひとりの状態が把握できなくなってくるので、1on1を始めてみたり、目標設定や人事考課的なものが始まったり、そういったマネジメント的な何かに時間をとられることが増えてくる
- プログラミングをする時間がだいぶ少なくなってくる
- 自分のレビュー待ちがボトルネックになることがしょっちゅう起こるようになる
- 機能によっては自分がほとんど分からないケースが出てくる
- システムの全体像も油断するとよくわからない箇所が出てくる
- 自分が書いたコードが生き残っている部分もどんどん減ってくる
- 徐々に自分を「エンジニア」だということに自信がなくなってくる
- このあたりになると自分しか把握できていない部分はだいぶ少なくなってきて、そこだけが自分のエンジニアとしての存在価値になる
- 仕様について質問されコードを読んで答えたらコードリーディングをミスっていて嘘を教えてしまう、コードレビューで間違った指摘をしてしまうなどの事件が起こりエンジニアとしてのアイデンティティを喪失する
- 個人でサービス作ることでプログラミングから離れないようにしようと画策する、が、実際にはやらない
- マネジメントをするために何をすべきかがよくわからないが、実際にサービスを作ってきた知識と経験でなんとか凌ぐ
第五期
- 第四期に加えて、部門をまたぐ調整・問題解決や予実管理、会議の資料作成などでほぼ業務時間が埋まる
- システムの進化にキャッチアップすることが不可能になり、◯◯は△△さんが詳しいよ、といえるだけのポインタおじさんになる
- たまにコードを書いて、若手エンジニアにレビューで切られる、自信を喪失してますますコードから離れる、の負のスパイラル
- というか若手の方が優秀なのでマネジメントでバリューを出すしかない、と悟る
- が、マネジメントの道は長く険しい
- エンジニアが技術を学ぶように、マネージャーはマネジメントを学ぶことが必要だと思うようになる
第六期
- ポインタおじさんですらなくなる
- プログラミングもマネジメントも本質は同じだと思えるようになる、、、予定
第七期以降