🎅GMOペパボエンジニア Advent Calendar 2023の8日目の記事です。
昨日はしおりんさんの寒さを吹き飛ばせ！GASとChatGPTで目指す自動投稿への挑戦🚀 - shiorinのアウトプットでした。たしかにブログを書いたらXに投稿する流れがあるので、自動化できたら便利そうだな〜と思いました。MuuMuu Sites、自分も使ってみます。
2021年12月からWebエンジニアとしてお仕事をいただくようになったので、今月でちょうど2年になります。 この1年は色々とチャレンジさせてもらって、成長できた実感があります。
エンジニア2年目って何ができるの？どんなことができるの？という関心がある程度ありそうなので、それに応える形で書いていけたらと思います。（2年目といっても人により千差万別ではありますが）
できるようになったこと（順不同）
- Railsを使った基本的な実装
- RDBの基本的なテーブル設計
- GitHubでの開発作法
- 基本的なLinuxコマンドでのCLI操作
- ログをちゃんと見てデバッグする
- テストコードが意識的に書けるようになった
- 余裕があればTDDで開発する
- Kubernetesの全体像をざっくり理解して、最低限のCLI操作ができるようになった
- 既存コードを真似ながらNext.jsの開発
- 仕様を把握している状態でのコードレビュー
- 新機能開発時のシステム設計
- そこまで複雑ではないシステム
- スクラム開発
- チケットを切って見積もりしてスプリントゴール達成を目指す
- 技術的な内容を整理して書く
- テックブログや技術書典15への寄稿
- クラウドインフラの基礎知識
- Google Cloud ACEの合格
- GPT、copilotを使ったコーディング
できていないこと（順不同）
- 一次情報をメインに調査する（公式リファレンスなど）
- 検証が不十分なままできる、できないの判断をしてしまう
- 周囲のエンジニアをリードする
- あるべき設計は何かという観点でのレビュー
- フロントエンド全般
- 先を見通して行動する
- スプリントゴール達成のために素早く実装する
- 体調管理
- その他、数えきれないほど多くのこと
こうやって書き並べてみると、1年前よりもできるようになったことがたくさんあります。約1年在籍してみて、ペパボの「いるだけで成長できる環境」とはこういうことなんだろうなと実感します。 ただ、たぶん意識できていないだけで、もっとできるようになったことはあるし、逆にできていないことを自覚していない領域もまだまだありそうです。
以降、学びになったことを思いつくままに書いていきます。
テストをちゃんと書く
自分が実装したあるコードが原因で、インシデントを起こしてしまいました。インシデントが起きた理由は大きく2つあり、変更を加えたpublicメソッドのテストを書いていなかったこと、Pull Request（以後PR）の差分が大きすぎてレビュワーがテスト不足に気づけなかったことです。
必要なテストが抜けるぐらいなら、不必要なテストを含めた上でPRを出すぐらいの気持ちがいいのかなと思っています。コードレビューをする上で、テストコードは「何を実現したいのか = 仕様」が明確化されており、レビューを容易にしてくれます。必要なテストが抜けているとは、すなわち仕様が明記されていない状態であり、レビュアーは実装が仕様を満たせているか確認する術がなくなります。（PRのdescriptionに書かれていればまだなんとか）
一方で過剰にテストが書かれている場合、少なくとも仕様は明確に伝わるはずです。ただ、仕様とは異なる動きを検証していてテストが通っていたら、それは実装が間違っているので直さないといけないです。また、不要なテストが多いとそれはレビュアーや将来の開発者にとってノイズになり、コードの理解容易性を下げてしまいます。（しかも、テストは消しづらい。変更によって何かが壊れるのが怖いから）
つまり、必要十分なテストを書くに越したことはないですが、テスト不足はインシデント（バグ）の原因になるのでやめていこうという話です。また、PRの差分が大きいとレビュアーの負担が大きくなり、実装者本人も含めてテストが不足していることに気づけなくなるので、なるべくPRは小さく分割して出していこうと心に決めました。
検証してから判断する
筋の良さそうなコードを書いたが動かなかった、だから少し冗長な別の実装パターンを採用した。こんな感じの動きをしてしまうことがあります。動かなかったのはなぜかログを吐き出して見てみたり、デバッグコード（binding.pry）を仕込んでみたり、コンソールで擬似コードを動かしてみたりといった検証をしないまま「動かない」という判断を下してしまっている。実装に詰まって誰かに相談する時も、自分でできる限りの検証を行って、何かしらの仮説を持った状態で話を持っていった方が解決しやすいのは明らかです。それなのに焦りや不安から、この実装はダメだとつい性急に判断してしまうことが度々ありました。公式リファレンスやソースコードなどをちゃんと読むことも含めて、検証をちゃんとやることを意識していきたいです。
GPTsを脳死で使わない
2023年はchatGPTやGitHub copilotを駆使することで、現場の実装スピードが大幅に上がったようです。ただ、これらのAIツールは何かしらのインプットをこちらから与えなければ動いてくれないですし、その回答もインプットに基づいた形で返ってきます。適切なインプットを与えるためには、必要な知識や発想を使用者が持っていなければならず、方向性を誤ったインプットを与えると、その回答ももちろん誤ったものになりがちです。（AIは賢すぎて、それは間違ってます、正しくはこうですと言ってくれることもありますが）
実力のある方は、質問する前に自ら一次情報にあたったり、きちんとデバッグした上で思考やコーディング作業の補助としてGPTsを使っている印象があります。ターミナルのエラーコードを雑に投げて「これはなぜですか？」と聞くのを繰り返していては自身が成長しないですし、質の良い回答も返ってこないので、まずは調べて仮説を立てるということを基本にしていきたいです。（一方で雑に質問して思考をクリアにしていくような使い方もあるので一概には言えない）
印象は大事
自分がいくら頑張っているつもりでも、それを周囲に知らせていなければもちろん頑張っているとはみなされないということに最近気づきました。それに、周囲が気づいてないということは、誰かの役に立つような成果に結びついていないからかもしれません。日々仕事をしているとたくさんの情報量を浴びることになるので、誰かと議論したりするときには思考のショートカットの表れとして、無意識のうちに印象に基づいて判断していることがあるなと思います。悪い印象を抱かれていれば、言っていることを簡単に飲み込んでもらえず仕事もスムーズには終わらなくなります。ペパボで「みんなと仲良くすること」が重視されているのは、こういう実利的な側面もあるんだろうなと思いました。社内のルールはちゃんと守る、笑顔で挨拶する、助けてもらったら感謝を伝える、ミスをしたら謝る、など当たり前のことを当たり前にできるようになりたいです。（できていないことがあって風呂場で反省会をしたりする）
小さく分ける
先ほど書いたようにPRを小さく分割するのもそうですが、あらゆる仕事において小さく分けることは有効そうです。人は基本的には怠け者（簡単にできることならやるけど、大変そうなことはなかなか腰が上がらない）で認知資源も限られているので、大きくて大変そうなタスクを渡されると、それを解決する思考よりも「それがいかに大変であるか」という思考で頭が埋められてしまいがちです。小さく分けると精神的ハードルが下がり、仕事にすぐ着手できます。また、どう解決するかも考えられるようになります。結果として仕事が早く終わるようになります。また、小さく分けるには全体像を把握しなければならないので、その過程で現状を整理でき、何が問題なのかも見えてきます。その状態で出てくる解決策も筋の良いものになるはずです。
ここまでつらつらと書きましたが、理想はこうなんだろうなという話で、まだ自分の中で当たり前の動きにはできていないので、小さく分けるを標語にやっていきます。
終わりに
もっと技術的なことを書いた方がアドベントカレンダー的にはいいよなと思いつつも、自分としては良い振り返りになりましたし、今後の仕事で意識すべきことも明確になったので書いてよかったです。1年後の自分がこれを読んだときにどう感じるか楽しみです。
明日はgurasanさんの記事です。お楽しみに！
