社会人アプリケーションエンジニア2年目の振る舞い方

本職はアイドルのつもりだが、一応アプリケーションエンジニアもやっている、ということで。

今半期の public な振り返りの代わりに、最近どういう風に仕事をしているのかをまとめていく。参考までに、前半期の振り返りエントリはこちら：

blog.arthur1.dev

目的を意識してコーディング・コードレビューのやり方を変化させる

これまでの自分は、コーディングもコードレビューもかなり長い時間を掛けて取り組んでいた。どう実装したら美しいのか、既存のコードから浮かび上がるメンタルモデルとマッチしているか、などと、深く考えれば考えるほどドツボにはまってしまっていた。

今期の自分は結構吹っ切れていることが多かった。素早く価値を届けたいのだからこのあたりは見逃そうとか、理想はこうだけど今はこれがシンプルで最速だね、という気持ちでシュッとコードを書いたりレビューしたりしていた。動けば OK の気持ち。

一方で、リファクタリングが目的となる Pull Request については、過度な共通化をしていないか、抽象化の度合いが大き過ぎ（あるいは小さすぎ）やしないか、などをじっくりと考えた。コードレビューでは「なぜそうするのか」を明記すると変更を受け入れられやすい。目的にフォーカスして思考を集中させるのを続けたことで、良いコード設計のための思考を具体的に言葉で説明する能力も上がったんじゃないかなあと思う。

材料が揃っているなら自分で決める

なにか物事を決めるときに多数決を取るのをやめた。そもそも自分は多数決は好きではないが、これを仕事に持ち込んだ形。ちょっとしたことが決まらずに仕事が進まないもどかしさを感じていたのかもしれない。リモートワークだと全員の反応を伺うのも難しいし尚更である。

決定のための材料を集めて、自力で集めたもので十分と感じるならばそれで決めてしまい、不十分だと感じたら他の人からも材料を集めてから決めるようにした。2択あって「どっちがいいと思いますか？」という質問をするのを極力控え、自分が重み付けした価値の和が最大になるような択を選んで自信を持って提示するようにした。

ちょうどそんな振る舞いを意識的に始めた頃、たまたま GitLab の意思決定に関する記事を読んで、ある程度一緒じゃんと思った。

about.gitlab.com

触ったところを少しだけ良くしていく

自分が価値提供のために触ったところで、古い仕組みや直すべき箇所を見つけたら、素早く価値提供する妨げにならない程度に良くする活動をした。レガシーを取り除くためだけの仕事では現場が疲弊していくことが知られているので、あくまで仕事の延長上で気づき、すぐできそうなものをやるというスタイルにした。

これは、多機能な SaaS でも頻繁に使われる機能は一部に偏っているだろうという仮説に基づいている。届けられる価値などから決められた優先度順に並び替えられた Product Backlog Item をこなしていくと、ユーザーがたくさん使う機能に関するコードの改修頻度が高いはずだ。SaaS におけるアジャイル開発の前提として未来永劫にわたって完成という状態になることはないと思っている。その場所やその周りは今回だけでなく今後も改修される可能性が高いだろう、だから綺麗にしておこう、という理屈。

と書いたものの、実際はここまで考えて取り組んでいるわけでは決してなくて、後付けで理由を取り繕うスキルが比較的高いというだけである。

良い状態にするためには、何を以て良いとするかを知らなければならない。自分はどの分野においてもスペシャリストではないし、今後も何かに尖るつもりはない。チームにはそれぞれの関心のある技術領域を深く勉強している人たちがいるので、そういう人たちが分かりやすく啓蒙してくれるのに従ってやっている。

これらすべての振る舞いの根底にあるもの

このエントリにやたらと出てくるワード、それは「価値」である。前半期の振り返りにこんなことを書いた。

来期どういう風に生きたいかはまだあんまり考えていないのですが、とにかく価値提供したい、という気持ちが今は強いです。

FY2023上半期を振り返る・広く浅く - Diary of a Perpetual Student

この発言の裏には、前半期はあんまり価値提供できなかったね、という意図がある。今半期は、前半期に引き続きメインの仕事以外の課外活動を引き受けつつ、価値提供のためにもそれなりに頑張れた。来半期にはこれらの取り組みをもっと省エネに持続可能にできたらいいなと思う。そうすると自然とトランスファー可能なスキルになるのではないか。