人並みのエンジニアになるまでにやったこと、読んだもの
最近マネージャーになってエンジニアとして一区切りついたので、やってきたことを振り返りたいと思います
エンジニアを目指している学生や、若手のキャリパスの参考になればと思います
ファミコンゲーム移植時代
自分の場合、最初のきっかけは大学入学です。当時の自分はPCを触ったことがなかったのですが、ゲームが作りたくてなんとなく情報工学科のある大学に進み、そこではじめてプログラミングというものに出会いました。
当時はプログラミングが面白くてしかたなかったので、その時もらったC言語の教科書の問題を全部解いてました。
その教科書の問題が終わるころにはC言語がある程度かけるようになっていたので、dxライブラリというライブラリを使ってスーパーマリオの1-1をつくりました。(ホントはc++なんですが、当時はC言語と区別がついてなかったです)とりあえず動くものを作れたのは当時のモチベーション的にはかなり良かったです。友達に見せて自慢してました。
今思うと入りがファミコンゲームの移植だったのが、いい入りだったなと思います。
- フレームワークじゃなくて、ライブラリを使ってたのでオレオレフレームワークを作る必要があった
- インスタンスと画面で動いているキャラクターが一致しているので、オブジェクト指向がわかりやすい
特にフレームワークを使ってなかったのが、今振り返るとよかったところですね。フレームワークを使うと動くものを簡単に作れるのでそれはそれでいいのですが、自分の場合はフレームワークに頼らずにものを作ったおかげで色々な設計の経験が得られた感じがします。
読んでためになったもの
忘れたけど多分これ
新・明解C言語 入門編 (明解シリーズ)
オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識
競技プログラミング、リファクタリング時代
このあたりからちょっとエンジニアっぽくなってきました。当時めちゃくちゃ流行ってたruby on railsを触ってwebサービスを作り始めたり、ubuntuを使い始めたり、emacsをめちゃくちゃカスタマイズしたり。
この時代は色々やってはいましたが、競技プログラミングがメインでした。競技プログラミングが流行り始めた？タイミングだったので、出場者が少なくてオフラインの本戦に割と簡単に出れたり、codevsみたいな対戦系のマラソンマッチがいくつかあったり、割と恵まれた環境でした。当時はまだatcoderも出たばっかりで、色の概念がなくて、段位で成績がわかるみたいな感じだった記憶があります。
あとは過去に作ったゲームのリファクタリングを暇なときにしてました。リファクタリングをするにあたって設計の本をちょいちょい読んでたのですが、なんとなくこうやってやればうまくいくみたいな経験則が本にいい感じまとめられて、自分の設計は間違ってないなという自信がつきました。この頃は知識を得るために本を読むというよりは、自分のこのやり方ってみんな使ってるイケてるやつだよね？みたいな答え合わせをしたくて本を読んでました。
読んでためになったもの
Ruby on Rails チュートリアル
プログラミングコンテストチャレンジブック [第2版] ～問題解決のアルゴリズム活用力とコーディングテクニックを鍛える～
Java言語で学ぶデザインパターン入門第3版
枯れたサービス時代
競技プログラミング経由で誘ってくれた会社が何社かあって、そこの中の一社に入ることができ、エンジニアになりました。
最初の仕事はソースコードしかないサービスのリプレイスでした。当時もらったサービスは色々なチームをたらい回しになって、うちのチームに流れ着いた所謂「枯れたサービス」でした。
リプレイスにあたってまずやったのが、タスクが既存コードの読解です。他人が書いたコードを読むということ初めてちゃんとやったので得るものは多かったです。
- 枯れたサービスとはいえ当初は拡張性を考慮して作られてた片鱗が残ってたので、拡張性のある実際のコードを見ることができた
- 先人が書いたコードを理解せずに場当たりに改修を入れのが、積み重なるといつか崩壊するという事実を見ることができた
- 大量のコードを読むことでコードの読み方を勉強することができた
特にコードの読み方が勉強できたのはいい経験だったと思います。エントリーポイントから読んでいって事実を積み上げていくという読み方ができるようになったので、場当たり的な改修や考慮漏れが避けられ、良い実装ができるようになりました。
またリプレイス後に自分が書いたコードの運用を実際に経験したできたことで、運用のときに困る設計の知見も得られたこともよかったです。今は便利なものがたくさんあるので動くものを作るまでは比較的簡単につくれると思いますが、長期間の運用に耐えうるコードを書くのは難しいと思います。そういうコードがかけるようになるには、自分が書いたコードをある程度の期間自分で運用するという経験が必要だと思います。そういう意味で自分が1から書いたコードを運用できた良い経験でした。
その後、担当サービスのクローズまで担当して他のサービスに移動になります。
読んでためになったもの
エリック・エヴァンスのドメイン駆動設計
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
新装版 達人プログラマー 職人から名匠への道
花形サービス時代
新しく担当になったサービスは花形サービスで、規模も1チーム運用から4チーム運用になった大規模サービスでした。
そこでの最初の仕事はサイトのリニューアルでした。
複数のドメインが関連するサービスを初めて担当し、フロントエンドにも初めて触ったので新しい知見が得られました。
- 大規模サービスかつマイクロサービスではドメインを意識しないとうまく責務を凝縮できず、ただ複雑なだけのサービスが出来上がり運用がのコストが爆上がりする
- フロントエンド(ここではブラウザ上で動くJSのことを指してます)はページの状態管理と状態をビューに反映させるだけでも複雑すぎるので、フロントエンドにビジネスロジックを乗せるのは難易度が高い
当時触ってたサービスはフロントエンドに関してはフレームワークを使っておらず、フルスクラッチで書く必要がありました。その時点で難易度が高いのに、フロントエンドにもビジネスロジックをもたせてしまったせいで、責務がうまく分割できず2000行、3000行もあるファイルがいくつもでき、パフォーマンスも悪く、運用もかなりしんどいものになってしまいました。
あと枯れたサービス時代にDDDを読んでいたときは理解できなかったドメインという概念がわかるようになったのは収穫でした。大規模サービスに携わって複数のドメインが複雑に絡まっているのを実際に経験したことで、DDDを読んだときに理解できなかったところが理解でき、うまく自分の中身落とし込めたと思います。
またこの時は中心メンバーとして働いていたので、マネージメント的なところも勉強して、小規模プロジェクトのマネージメントもしてました。
読んでためになったもの
Webフロントエンド ハイパフォーマンス チューニング
チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで
プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで
そしてマネージャーへ
花形サービス時代に色々経験させてもらったおかげで視座が高くなり、メンバーのポジションだとやりたいことができなくなってるなというのを感じはじめました。そのタイミングで運良くマネージャーのポジションが空いたのでマネージャーにさせてもらいました。今はほとんどコードはかけてないですが、ゴリゴリコード書いてたメンバー時代とはまた別の楽しさがあり、マネージャーになって良かったなと感じています。次はプロダクトマネージャーとかやってみたいですね。
まとめ
今の便利な技術をたくさん使って新しいものを作ることに面白さを感じて、それ軸にキャリアを歩む方もいると思いますが、自分の場合はプログラミング自体に面白さを感じて、プログラミングを軸にキャリアを歩んで来ました。改めて振り返ってみると、オレオレフレームワークをつくったり、基礎的なところから順を追って経験できたので、いい感じに技術を積み上げて来られたのでプログラミングを軸としたキャリアではちゃんと階段を登ってこれたなという印象です。
自分から若手のエンジニアや、エンジニアに向けてのアドバイスはこんなところかなと思います。
- 他人のコードを読む機会があったらちゃん読むこと
- 今の時代はgithubで見ようと思えば見えるので、どれかよんで見ると良いかと思います
- いきなりフレームワークに頼りきりになったり、最新の高機能な言語を使うだけではなく、C言語など低レイヤーの触れる言語でなにかを作ってみたり、フレームワークを使わずにサービスを作ってみたりすること
- いきなり便利なものを使うと動くものはすぐ作れますが、そういうものに頼らずに作ってみると使った技術の周辺知識も必要になり、新しい発見があるのでおすすめです。
Discussion