この記事ははてなエンジニア Advent Calendar 2022の29日目の記事です。*1
昨日は 
id:koudenpa による 破棄し忘れたクラウドリソースに半年間金を払い続ける方法 - koudenpaのブログ でした。
今回は私のはてなエンジニアとして個人的に意識していることを一部紹介します。*2
ソフトウェアエンジニアとしての働き方
新しい概念を発明するのではなく社内外にあるものをもとに検討する
技術選定や機能実装を進める際、自分の頭で1から考えても効率が悪かったりなんらかの考慮が漏れて筋が悪いことになりやすい。考えることは悪くないが、先人の知恵を使わない理由もない。はてなでは昔からWebアプリケーション開発を色んなチームがやってきたので、社内のテキストを漁れば似たような課題に対する検討ログが残っていることが多い。まず先人のはてなエンジニアがやったことを確認してから検討するのが早い。
また要件次第では社内のログをもとに検討で十分のことも多いが、例えば10年前の知識だったりするとそもそも現代だともっとシンプルにできる場合が多いはずなので公式ドキュメントやサポートへの問い合わせ、社外のエンジニアのブログなども参考にする。
例えば私が以下の記事で紹介している環境を構築した際は実際にGoogleの方とコミュニケーションを取って検討を進めてから用意した。問題なく活用できるものとして運用している。
developer.hatenastaff.com
チームでの開発体験向上についても、こうするともっといいのでは？ということをその場その場で1から考えても良いけど、それって実はExtreme Programmingにあるアレじゃない？ということがあったりする。勘で改善を進めるのではなく、先人のソフトウェアエンジニアがまとめたものをなるべく参考にしたい。
blog.stenyan.jp
業務で利用しているOSSについて自分が気になった箇所・ハマった箇所は他者も気になっているはずなので issue を探したり、なければ自分で立てたりPull Requestを出す
せっかくOSSを活用しているなら、ハマりポイントについて他の人が自分の二の舞にならないようにどんどん改善していけると良い。コードを自分で書くのが難しい場合でもissueを立てるだけで他の人とそこでコミュニケーションをとって代替案を提案してもらえたり、要望が高ければ作者が自分で対応してくれたりする。
直近の自分の事例を少し紹介すると、たとえばRenovateがデフォルトの設定でDockerfileのNode.jsバージョンをLTS無視してあげることを気にしていた。
blog.stenyan.jp
はてなでは共通のRenovate設定置き場があるので、そちらにPull Requestを出して全社で利用可能な状態にした。
github.com
とあるプロダクトで volatiletech/sqlboiler を活用しているが、 golangci-lint を通したときに sqlboiler 生成コードがLinterに怒られていることに気づいた。本家にPull Requestを出してマージしてもらった。
github.com
Auroraを使っているプロダクトの aws-cdk のコードを触っている際に、元々定義されている定数が最新のバージョンに追従していないことにたまたま気づいた。どうやら人間が足していくフローのようだと気づいて追加した。
github.com
以前以下のようなブログを書いたことがある。
blog.stenyan.jp
Perl用のActionも存在していることを知って見に行ったら perl-version-file に対応していなかったので issue を立てたら対応していただけた。
github.com
私も元々「仕事の延長戦上でOSSに貢献する」がハードルが高くてなかなかできない口だったが、上記のissueやPull Requestの差分は大したことではなく、でも多くの人の今後の開発体験向上になるのでインターネットをよくすることに貢献できていると思っています。*3
リモートワーク時の振る舞い
何事もテキストとして残す
とにかく何でもテキストとして残す文化があるので、自分もこれに従って仕事している。ハマったことについてブログに書くことはもちろん、日頃仕事しながら思ったこと、作業しながら気づいたことも全て書き出している。弊社ではScrapboxを利用しているので*4、そこに自分用作業ログコーナーを作ってひたすら書き続けている。
テキストとして残していくことには大きく2つ効果がある。1つは脳内で思っていることを一度書き出すことによって思考が整理されて仕事を進めやすいという点。もう1つは何かしら困ったときに他のエンジニアに作業ログを見せてすぐさまサポートしてもらえることです。
困ったときに手ぶらで相談してもまずは何をしたのか？という確認から入ると効率も悪いし、思い出しながら書いていくとそもそも自分でもやっていたことを忘れている可能性があるので、やりながら残すようにしている。数ヶ月後の自分が見直すときにも活用できるので便利です。
オンライン上の存在感を高める
最終的に成果を出せば問題はなくはないが、オンライン・オフライン状況がひとめでわかるほうが仕事相手として働きやすい。
Scrapboxにテキストを沢山残すだけでなく、私はSlackなどでも沢山発言している。オンラインの場合Slackの発言の様子から調子の良さ、忙しさ、困り度などが確認しやすい。
率先して沢山発言することによって心理的安全性の向上も意識していて、ちょっとした雑談とかも多く混ぜている。困ってることなどが言いやすい状況になれば、他の人も困っていると素朴にSlackに言ってくれるようになり、はやい段階でヘルプに入れるようになり、仕事も順調に進む。
ちなみにオフライン時のアピールとしてはGoogle Calendarに不在予定をあらかじめ抑えておく*5、GitHubのステータスをbusyにしてレビュー依頼がこないようにしておくなどもやっている。
終わりに
はてなエンジニアとして意識していることを書きました。はてな特有の話題でもなく一般的に実施できることだと思うのでみなさんも参考にしてもらえたら嬉しいです。
さて明日のはてなエンジニア Advent Calendar 2022の担当は 
id:hogashi です。
*1:Advent Calendarといえば25日で終わりですが、はてなエンジニアで書きたい人が沢山いるので26日以降もしばらく続いています。
*2:あくまで私個人の話なので、人によって考え方は様々です。
*3:はてなエンジニアのバリューズとも考え方が揃っていると思います。
*4:エンタープライズ版でクライアント情報もセキュアに管理。株式会社はてなのScrapbox利用術 | by Scrapbox | Mediumの時と違って今では全職種が当たり前のように活用しています
*5:祝日とか昼休みも明示的に不在予定を入れて相手が誤って祝日に予定を入れても自動辞退させている
