僕は本業としてプログラマをやっていて、時と場合によって異なるのだがここ5年ぐらいはRuby on Railsでサーバー側のコードを書いている。で、自社サービスの構築をずっとやっている。新規の機能を開発することもあれば、既存のコードを直すこともあるが、基本は（React使ってフロントを構築・修正する時もあるし）何でもやるわけだ。

サービスは利用者が少ない時はあまりパフォーマンスを気にしなくてもなんとかなる。100人、200人程度の利用者であれば、N+1が残っていようがなんだろうが問題はない。しかし1万、2万といった利用者になればN+1はだんだん問題になってくるわけで、最近は昔「こんなもんでええやろ」的に作られたパフォーマンス問題箇所を直している時間が増えた。「ここは問題になりそうだな」といって事前に直すケースもあるし、パフォーマンスが悪化しすぎてレスポンスがタイムアウトして「やべ〜！！」といってすぐに直すこともある。すぐにはなおせないので一時的に機能を無効化することもある。

で、それ自体はあらゆるサービス開発につきまとう宿命みたいなもので特に何ということもないんだけど、僕はこういう作業がとっても好きなんだよね。新規機能を開発しているよりも、表向き、ユーザーの使い勝手的にはあまり変わらないけど、裏側をコツコツとよくしていく。パフォーマンスがよくなっていく、そういうところに満足感を感じる人間である。

パフォーマンス改善の何がいいって、これはまず「確実にサービスにとっていいこと」である。新規機能を開発しても、ユーザー側からしたら必要なかったり、逆にUIがごてごてして使いにくくなる可能性がある。しかし、パフォーマンス改善はそういう意味ではやらないよりは100パーセントやったほうがいい。処理速度が10秒かかっていたところが1秒で終わるようになるのならそのほうがいい。世の中に飢えている人がいるよりもいないほうがいい。戦争があるよりはないほうがいい。世の中に絶対的な「正義」は存在しないかもしれないが、存在しないほうがいい「不正義」は存在する。

パフォーマンス改善は文章の推敲に似ている。パフォーマンスの悪化の問題が純粋に悪いコードであるケースも多々あるが、ネックになっている箇所がある時、もっともわかりやすく簡単にそれを解消する方法は、「その部分の仕様、本当にいりますかね？」とそもそも仕様自体に疑問を呈することで、そうやってある機能・表示を不必要だと検討して削除することができるのであれば、システムはぎゅっとまとまりよりよくなる。パフォーマンス改善はリファクタを伴うケースもあるから、コードは全体として「把握しやすく、読みやすく、改修しやすくなる」傾向にある。

僕はもともと文章の推敲はあんまり好きではなかった。文章は書いている瞬間は楽しいが、それをもっと良くしようと何度も読み返したり修正するのは（過去の自分にノーをつきつけているようで）あまり気分がよいものではない。その感覚自体はまだ残っているが、商業で原稿を書くようになって真剣に推敲する機会も増え、だんだん推敲も好きになってきた。推敲すればするほどよいというものでもないが、基本的にはこれもまた「すればするほどよくなるもの」だからだ。パフォーマンス改善の処理速度のように客観的指標こそ存在しないものの、主観的には文章の精度が上がっていく。

実生活でもそういうところがあるかもしれない。自分という人間の日々の生活も、同じ家、同じ仕事ばかりしているとだんだん行動も思考も固定化していく。肥大化していくサービス、文章のように、生活習慣もだんだんと肥大化していくものだ。僕は引っ越しが大好きだけど、引っ越しをすると知らず知らずのうちに土地と家に染み付いていた「習慣」を強制的に引き離してリセットして、自分に何が必要なのかをあらためて考えせてくれるからなのかもしれない。引っ越しという強制的な推敲装置に頼っているのだ。

引っ越しまではいかないまでも、肥大化したサービスを改善していくように、一度自分の日常行動の一つ一つをチェックして、パフォーマンス改善、推敲をかけるべきではないのだろうか──と思うけど、日常行動は「無駄こそが重要」であることもあるからなかなか難しそうだな。

客観的な指標があるパフォーマンス改善、「良い原稿にする」という主観的だがわかりやすい目標がある推敲と比べると、日常生活のパフォーマンス改善は目的がない分ぼんやりしている。もしやるなら、「一週間のうち◯◯をする時間を確保するために週に◯◯時間捻出するようにパフォーマンス改善をする」みたいにかなり具体的な目標設定が必要なのかもしれない。

とかなんとか考えながら今日の昼も日常の習慣として毎日の食事の買い出しにスーパーにいっていたのであった。考えたところまで書き残しておく。