作業計測について
日報をその日の終りに雑に思い出して雑に書くの良くないので、作業時間と作業量を測りたいと思った。
作業時間
現職の開発フローで、作業時間を測れそうな対象を粒度が粗いものから並べるとこんな感じになる。
- チケット
- Issue
- Pull Request
そして、それぞれ関係性がある。
- チケットとIssueとPull Request は多くの場合1対1対1になる。
- チケット無しでIssueとPull Requestが作られる場合はバグ修正や途中で気付いた改善点など、元々はスケジュールに無かったもの。
なので、1日の作業を計測するとしたらIssueごとの作業時間を測るのが良さそう。作業時間を測るのには、toggl buttonというChrome拡張があるのでそれを使えばいい。
作業量
では、作業量の計測対象はなんだろう。
- Issue(閉じることができたやつ)
- Commit
- URL
閉じたIssueやCommitはコーディングの成果そのものなので、これを作業量として見るのは違和感ないと思う。
目に見えなくなりがちなのがコーディングする以前の調査量だ。何か作りたいけど実現方法どうしようか。よし調べるぞ。〜〜1時間経過〜〜。みたいなのはよくあると思う。コーディングはもちろん、調査も作業だと考えていいはずだ。
ではこれはどうやって測ればいいのか、と考えてみると、URLというのが計測対象の1つになり得ると思った。論文や本の参考文献リストのように、その日の作業量を表すものとして参考URLが並んでいれば、なかなかやった感があって気持ち良さそうだ。
作業時間 Issue#56 4時間00分 Issue#57 3時間30分 Issue#58 1時間30分 作業量 Issues: 2 commits: +355 −39 URLs: 38 - http://example.com/fieoajfi - http://example.com/hgoehoge - http://example.com/fioawjio - http://example.com/fiaojwfie - http://example.com/goe - http://example.com/iofjeai
こういう数値をまとめて出せるようにしておくと、いろいろ学びがありそう。ただ、この数値で同僚のエンジニアと比較されるみたいなことになるとストレスが高まりそうなので良くなさそう。自分の作業時間見積もりの不正確さやざっくりとしたパフォーマンスを知る目的に確認するのであれば良さそう。