エンジニアリングマネージャという役割で働き始めたとき最初に困ったのは、「今日ちゃんと仕事を進められた」という実感が得られないことだった。

エンジニアとしてコードを書いていたときと何が違うかといえば、一番大きな違いはコードや Issue, PR などを書く時間の確保の問題だった。
そういったやったかやってないかがわかりやすい仕事をどれだけできるかは、タイミングにかなり依存していて、例えば「採用に力を入れる」タイミングや、「機能開発の優先順位を整理して計画を立てる」タイミングとなると、関係するチームの人とのコミュニケーション量が増え、一通り会議を終えれば夜になっているということも珍しくなかった。

ひとつひとつのプロジェクトはちゃんと前に進んでいたし、（僕が関わっていたプロジェクトは長期のものが多かったのであまり経験できなかったが）目標数の内定承諾やリリースといった形でプロジェクトがゴールに到達することによって、ちゃんと仕事をしていたということの確認はできてはいた。

しかし、ある1日にフォーカスしたときに「今日は結構できたなあ」「今日は駄目だったな……」というのを主観的ではない方法で測ることができなかったので、ちゃんとやれているかという不安がつきまとってしまった。

そこで、自分がその日やったことをリストアップして、ひとつひとつにポイントを付けるようにした。
ポイントは作業の種類やボリュームによって一定のルールの元でつけられるようにしていた。
例えば、自分が主体的に進めるべきプロジェクトの会議であれば30分で4ポイント、オブザーバー的に参加する会議であれば30分で2ポイント、といった風に決めておく。
書類選考1件で5ポイント、面接は1回だいたい1時間想定で20ポイント、といった感じで、他の人に任せるのではなく自分がやるべきことはポイントを高めに設定していた。
自分がポイントを高めに設定していたのは、資料作成やマニュアル作成、採用関連や同僚との 1on1 あたりだ。

このポイントをつけるという行為は結局、自分の安心のためにやっていたので、そういった心配が払拭され始めたあたりでやめた。
トータルで半年に満たないくらいしかやらなかったが、その間毎日これをつけるようにしていた。
多いときで70ポイント、少ないときで30ポイントと、結構明確に差がでるのが面白く、また当時大量に入ってきていた会議の予定に対して、流されるままでは良くないということに気づけたのは良かった。

僕自身はあまりマメな性格ではないので、こういうことを継続するのは苦手だけれど、こういうことに抵抗がないひとは試してみると良いかもしれない。
日報を書く際についでにポイントを計算する、という感じでやっていたけど、日報を書いたら勝手に集計されるような仕組みがあれば今でも続けられたんじゃないかなあ、とは思う。
それはそれとして、 GitHub の Insights でコミット数などを見れる方がモチベーションにはつながりやすいな、というのは間違いなくある。