エンジニア1年目の思考ログと気づいた大切なこと
エンジニアとして働く前
専門学校生としての4年間
2017年からエンジニアを目指して専門学校に入学し、やっと4年の時を経てエンジニアになることが出来ました。
専門学校としては資格取得をメインとする、よくあるIT専門学校であり、プログラミングの授業はほとんどなかったので独学で4年間プログラミングを学び続けてきたことになります。
当初は2年制のコースに入っていて、19卒になる予定でしたが就活をした際にTeamLabさんを受けさせていただいたところ1次面接で落とされました。当時自分は情報収集力もありませんでしたし、プログラミング経験もほとんどありませんでした。資格だけで評価されると勘違いしていたのです。
自分が面接官であったとしても選考から落としていたと思います。そのおかげで市場価値を意識するようになり、今があると思っています。
そこから2年間色々なことに触れてきました。学校の方で強制される資格試験もそれなりにやってきました。
- AtCoder
- 今は参加者が多くて勝てそうにないですが、緑くらいまではやりました
- ロジック考える力はここで養われたので、やってよかったと思っています
- 技術書典
- 初参戦は4で、「これがエンジニアの人たちか・・・」と胸を踊らせていました
- Qiitaアウトプット
- 初投稿が2018年で、無教養で内気な私がアウトプットをする為にしたこと、自信のなさが表れています
- Flutter
- 触ったのは2020年頭頃、最初期でリソースが全くなかったので英語リソースやGithubのissueを読む力がここで培われました
- 触れたUdemyのコースはこれで、リファクタリングの楽しさ等もここで知りました
- Unityゲーム開発
- チュートリアルレベル。かんたんなコイン落としなど作って「ゲームプログラマーの人は大変だ・・・」と思っていました
- Ruby On Rails
- Rails チュートリアル全盛期ですね。この頃にTwitterで「Railsチュートリアルでポートフォリオを作って転職！」みたいなトレンドがありましたね。懐かしい。
- Bot作り
- Discord Bot, LINE Botが手軽に作れたのでHerokuの勉強がてら作ってました
- Flask
- 当初はDjangoに触れていたのですが、フルスタックすぎて、わけが分からなくなってしまったため、最小構成のFlaskが好きで触ってました
- React
- フロントエンドも触りたいと思っていて、TypeScriptを学びつつ、Reactも触っていました。
- 技術書典の場のノリで買ってしまった りあクト！がすごく優秀でわかりやすかったので場のノリって意外と重要なんだなぁと実感しました
資格はIPAのやつです。エンベデッドとネスペは2点くらい足りなくて落ちました。
- 基本情報
- 応用情報
- デスペ
- セキスペ
技術書マニアだったので色々買い漁っては目を通してました。ただ、「人間一番必要だと思ったときが一番学習効率が良い」ので習熟度としては微妙だと思います。頭の片隅に置いてある感じですね。
21卒としてエンジニア人生スタート
4 ~ 6月 新人研修期間
エンジニア1年生としての最初の期間は例に漏れず研修を行ってました。
研修内容は基本的なものとLarave, Vueでしたが、研修期間は自分の手元でLaracastを見つつ、独自に情報をキャッチアップしてました。独学の時間が長くなってしまうと自分で学びがちになります。
この時期はDB設計なども空き時間に勉強してました。データベーススペシャリストを取ったとしても実戦とは乖離しすぎているので、現場に近い知識を習得したかったのが動機になります。
ここらへんで読んだ書籍は以下です。
6 ~ 7月 Docker環境構築
M1 Macが出てすぐだったため、VirtualBoxが使えませんでした（これは今も？）
なのでDockerを用いて会社の自社サービス開発環境を整えるという仕事が最初の仕事（？）になりました。
Docker自体は触れるつもりもあり、知識を積める良い期間になったのですが、0から構築するのは結構骨が折れた思い出です。
以下の本を参考にしました。
7月 ~ 8月 テストコードにハマる
インフラを学んだ後に実案件のテストコードを担当しました。ここが自分の人生の中でも転換期になると思っています。
カバレッジ率90%を目指すというアンチパターン テストをたくさん書くということで慣れないPHPやPHPUnitで悪戦苦闘をしていました。
「テストコードとは何」から始まり、飽くなき探究心・好奇心で学びまくりました。
- テストコードは何を担保すべきなのか？
- テストコードをキレイに書く方法は？
- テストコードの目指すものは何なのか？
- テスト容易性とは何なのか？
- ユニットテストはどこまでカバーするのが正しいのか？
- テストコードのベストプラクティスは何なのか？
上記のようなWhat?が溢れんばかり出てきてしまい、日夜テストコードのことしか考えることが出来ませんでした。
ソフトウェアテストからテスト容易性に繋がり、テスト容易性から設計に繋がり、設計からDDDに繋がってきています。
また、これはソフトウェアテスト技法ドリルの受け売りですが、実生活でテスト駆動を意識することで相手に理解しやすい話し方や例示ができるということを知りました。
自分の今の目標としては、
- リグレッションからの保護
- リファクタリング耐性の高い
- 迅速なフィードバック
- 保守性が高い
という4つの柱を適切な分配で両立させたテストコードを普及させ開発者を幸せにする。というのが目標になっています。
- テストで迅速なフィードバックを得ながら開発
- テストハーネスによる安全なリファクタリング
- テストによる心理的安全性の確保された新規機能の開発
- 仕様変更時のテストメンテナンスコストの低減
- 上記が担保された開発者が幸せに開発が行える環境
を提供することができれば、もっと開発者が幸せになり、幸せな開発者はエンドユーザーに高品質を届けられ、ユーザーの幸せを生産することができるのではないでしょうか。
自分はそれを信じて、今を生きています。
熱くなりすぎました。この期間で読んだ書籍が以下になります。
9 ~ 10月 バックエンドAPI開発
ある案件のバックエンドAPI開発に携わりました。OJT期間ということもあり、工数が0で自分の責任範囲は大きくなく、要件定義書から実装に落とし込むような練習みたいなものでした。
自分の中でテストコードのベストプラクティスがまだこの段階では模索中であったため、酷いテストコードを書いてしまった思い出もあります。
幸い影響範囲が大きくなく、修正も容易だったことが救いですが勉強の必要さを感じられました。リポジトリパターンなどに触れつつ案件開発を進めることが出来ましたが、今となってはこのリポジトリパターンに細やかな疑問を感じています。
自分の知識量が上がったのもそうですが、コードの良し悪しが見分けられるようになってきたので大きな成長を感じます。
以下を読みました。
11月 ~ 現在 バックエンドAPI開発
世間的にも話題になるようなアプリのバックエンドAPI開発に携わることになりました。
納期も厳しく、様々な人の手が加わったコードで、要件も難しい案件でメンタルをすり減らしながらコーディングしていた思い出です。
アルゴリズムの重要性を体で実感しましたし、パフォーマンスの良いEloquentの書き方も意識するようになりました。ここでもテストコードのメンテナンスコストが大きくなりつつあり、一番テストに対して真摯に向き合っています。
PHPUnitとLaravelで上手くテストをするために試行錯誤を繰り返しながら見つけた個人的ベストプラクティスもありますが、なんとか今はそれをガイドラインとして落とし込もうとしている最中になります。
ただDDDを学んできて、このテストガイドラインの存在がちょっと揺らぎつつあります。
例えば、「リクエストデータはリクエストデータでImmutable Classを作る」という方針が自分の中で答えだと思っていたのですが、（あとから知ったのですが）これまんまData Transfer Objectの考え方なんですよね・・・。
なのでテストガイドラインも現時点の考えのスナップショットを撮る気持ちで書くつもりですが、DDDの知見を深めた時にさらなるベストプラクティスを見つけられて改善できると思っています。
Spatieの教材信者になっていたり、Eloquentでパフォーマンスを出すためにはSQLをちゃんと学んでインデックスを意識しながらクエリを作らなきゃいけないという事実に気づいて、次はSQLをもっと勉強すべきかな？と感じています。
ただDTOの概念を知ってからリスコフの置換原則や依存性逆転の原則などの概念がやっと理解できましたし、Facadeがもたらす秩序の破壊も理解できました。オブジェクト指向（もしくはプロセス指向）も深く掘り下げていきたいと考えています。
以下の教材で学びました。
職務経歴書みたいな進め方をしてしまいましたが、1年の反省と言ったらこのような形になりました。
エンジニアとしての気づき
Eloquentはインデックスを意識しながら書く
前述でも述べましたが、LaravelのEloquentは簡単に書けるが、インデックスを意識するとしないとでは雲泥の差でパフォーマンスが変わってしまうということを実感しました。derived tableを意識しながらサブクエリを書くと有効にインデックスを使えるなどの小技を知り、突き詰めるためにはSQLを再度奥深くまで学ぶ必要があると感じました。 書籍はお家にあるので、時間があるときにぜひ読み進めようと思っています。
アルゴリズム力はあればあるほど良い
競プロは実務では役に立たない、という層が一定数いますが自分はそうは思いません。競プロのアルゴリズム力は普段の実装でも大いに貢献してくれますし、論理的に物事を考えられる力は大きな力になります。
また競プロはテスト駆動開発を素で行っていることになるので品質の高いコードを書く意識が強くなります(保守性は別)
コーナーケースを考えられる力も培う事ができますし、時間がある時は積極的に競プロをしていこうと思っています。
少しずつ読み進めています。
独学が1番だが、仲間は居たほうが良い
エンジニアは基本的にみんな独学になります。ただ、共に方向性は違えど学ぶ志が同じ人達と時間を共にする、ということはかけがえのないことだと思います。
モチベーションの維持にも繋がりますし、自分のウォッチしている範囲外から情報が入ってくる可能性があるため視野が広がりやすくなります。
今の会社では全体的に独りで学ぶ、といった傾向のが強く、情報共有が行えているのは一部の同僚くらいですが、ゆくゆくは会社全体で一体感を持って切磋琢磨できる環境に身を置くことが出来たら・・・と強く思っています。
コードの先は人
おそらく109回くらい言われていることでしょうが、「コードの先は人」 ということを強く実感しました。
コードだけ書いていればいい、という人も時にはいますがチームとして開発を行っていく上で一番大切なのは、和気あいあいと会話をする能力だと感じました。
会話が少なく、険悪なムードのチームではどんどん閉鎖的になってしまい、情報の共有自体行われる事が少なくなってしまいます。 心理的安全性も良くないので、モチベーションにも影響が大きく出ますし、ミスを恐れる・自分のタスクだけを淡々とこなす方針に寄っていってしまうため、チームでの協力という文化が失われます。
そうなってしまうと品質の面でも影響が出てきますし、テストも雑だったり、更にバグを生み出しやすい環境に近づいていき、最終的に待つものは死となります。
人と協力してチーム開発を行っている以上、尊重すべきなのは「コード」ではなく、「人間」ということを肝に命じながら末永いエンジニア人生を歩んでいこうと心に誓った一年になりました。
自分はリモートワークの中で、いかに心理的安全性を確保するため絵文字を多用するように推進した記事を書いたり、なるべく人とコミュニケーションを取るように話しかけていました。また、Slackだとリアクション絵文字をたくさんつけることによって「認識している」という実感を与えてコミュニティを活性化させる取り組みも意識的に行いました。
これからも良いチームビルドとは何なのか？を学びつつ、開発者が幸せな環境を作り出す努力を続けて行きたいと思っています。
