いま仕事はベンチマークの自動化をやっているのだが、リリースが近づくにつれ自動化は誰か得意な人にまかせて速くするのもやってくれよ、というプレッシャーをかけられている。むー。

自動化のインフラを作ってくれた人はたしかに自分より自動化は得意だと思うけれども、ベンチマーク書くのは自分にやらせてほしいのだよなあ。これはチームにとっての利点と自己都合、それぞれ別の動機がある。

チームにとっての利点は、要するに自分の方が良いベンチマークを書けるというか、結局速くする仕事をやるのは自分なのだからユーザである自分の都合を完全に理解している人間すなわち自分が書く方が的をいたものができる、というもの。同僚信用してないの、といわれると言葉をにごしたくなるが、自分の要望や優先度のコミュニケーションコストとか高いのだよ。そしてベンチマークの実装は単純仕事だけでもなく探索的な側面もあり、つまりベンチマークを書く中で高速化のアイデアを思いついたり、逆に問題点を発見したり、自明でない箇所の測定をする方法を見出したりするのですよ。

自己都合としては、性能の専門家を目指すにあたり自分は良いベンチマークを書けるようになりたいから、訓練したいのだよね。安定したベンチマークはどうしたら書けるのか。トラブルシュートのコツ。現実的かつ安定した負荷のかけ方などなど、ベンチマーク書くの全然自明じゃないじゃん。それができたら専門家として一段レベルアップできると思うのだよね。バグレポート付属の systrace という断片的な情報を元にカンで直すのではなく、ちゃんと再現できる環境を作って、測定して、それを速くする。そうありたいでしょ？

それを締め切りがあるからとかいってできることだけやれみたいな圧力をかけられるのはほんといや。おっさんの成長にも配慮してくれ！定時で帰るからって差別すんな！

この話にはいくつかの含意がある。すなわち

• 疎な締め切りはクソである（今年度百回目につき新しい情報なし）
• 自己都合の仕事についてはやっぱちょっと時間外労働したほうがいいのでは（いやです）
• プレッシャーをうけても適度にしらばっくれるのが大切である

まあ基本的には自分の仕事が遅いせいなので、何らかの形で責任は果たします・・・。

追記 (2019-12-01)

その後性能インフラチームはでかくなり、仕事を横取りするのもどうかと身を引いて高速化業に専念した。しかし結果といてずっと気になっていた指標をベンチマークに追加できず、当然のように regress したのだった。