開発者の時間記録：自分の作業履歴を残す

開発者の時間記録は、自分の仕事時間を残す個人用の記録にできます。エディターのプラグインや画面を撮影するエージェントがなくても残せます。

記録があれば、短いはずの仕事が一週間を使った理由を調べられます。「いろいろ」より具体的に仕事を示し、会議の合計も見られます。

記録の目的

個人の時間記録は、実務上の四つの問いに答えられます。

1. 今週、実際に何をしたか。 評価の時期に、「基盤に取り組んだ」ではなく日付付きの仕事の一覧になります。
2. 仕事にどれだけかかったか。 見積もりと実績を比べ、抜けていた部分を見つけます。
3. 一週間を何に使ったか。 機能開発、デバッグ、レビュー、会議、周辺の作業を分けます。優先順位がぶつかるとき、会議の合計は具体的な話し合いの材料になります。全体の所要時間を知りたいなら、準備も含めます。
4. 何を請求するか。 顧客に直接請求するなら、相手が分かるメモ付きの時間が必要です。

何を、誰のために、どれだけしたか、自分のために簡潔に残します。

手動の時間記録に、開発者向けのいくつかの工夫を加えます。

開発者の記録に必要な最小限の項目

実際に書き続けられるほど、各行を小さくします。

「PROJ-142：購入手続きの競合状態を修正」なら、振り返りや請求のときも意味が分かります。「コーディング」では分かりません。

顧客や管理職が見る可能性のある行には、相手の言葉で結果を書きます。何を直し、出し、確認したかです。webpackとの格闘は私的なメモに残します。

構造を増やしすぎないでください。課題管理ツールを写したタスク階層は不要です。

案件や顧客の仕事をまとめ、デバッグ、レビュー、会議を分類すれば、案件をまたいで時間を比較できます。

単純な日なら、メモだけで十分です。

来月見ても意味が分かる一日

仮の一日を示します。

最後の行は、本人のメモと予定表を元にした推定です。後のコミットは仕事の特定を助けますが、所要時間を確定するものではありません。

エディターの活動ではなく作業を記録する

IDEの活動履歴には、自分用の記録として考えたい二つの不足があります。

一つ目は、開いたエディターが仕事の証拠ではなく、閉じたエディターも休みの証拠ではないことです。ライブラリーの文書を読む、紙にデータモデルを描く、不具合の原因が分かるまで天井を見て考えることも仕事です。エディターだけを見る記録は、その仕事を逃すことがあります。

二つ目は、案件や目的が分からないことです。リポジトリ名やタイトルで案件が分かる場合もあります。共有の文書ページだけでは、どの顧客のための調査か分からないことがあります。

分類がなければ、履歴を後から解釈します。そこで自動の時間記録にも自分の判断が必要です。

裏で動く活動履歴を、後から分類する予備の材料にできます。作業記録の抜けを補うために使えます。

まとまった作業を単位にします。仕事に向かったら開始し、別の作業、会議、顧客へ移ったら止め、休憩では一時停止します。その境目に短いメモを添えると、後で振り返る材料になります。

自分の問いに答える記録です。雇用主の監視とは別に残せます。メモは、雇用主や顧客が社外のシステムに書き留めてよいと認める範囲にとどめます。

記憶が新しいうちに抜けを補う

コミットやプルリクエストは、何をしたか思い出す材料になります。予定表やメッセージで、ほかの部分も補えます。

その手掛かりから抜けた作業を推定し、推定と明記します。一時間離れた二つのコミットが、一時間の作業を証明するわけではありません。間に休憩や別の仕事があった可能性があります。

調査やデバッグで、コミットが一つも残らないこともあります。覚えているなら、その仕事も含めます。コードの変更だけを仕事全体として扱わないようにします。

役立つ推定ができなければ、所要時間は不明のままにします。次の作業は、仕事中に記録します。

記録した時間で見積もりを振り返る

仕事の時間をすべて記録すると、見積もりと比較できます。

チケットに見積もりを書き、作業を記録し、比べます。比較できる仕事の中で、二つの点を探します。

• 抜けていた仕事の余裕。 似た修正で、見積もり外の確認やテストが繰り返し必要なら、次はその時間を含めます。慣れない仕事には、さらに不確かさを見込みます。
• 時間が増えた場所。 コーディング、デバッグ、統合、環境設定、レビューを比較します。傾向が見えたら、その部分を分けて見積もります。

固定料金にも使えます。終了後、料金を全時間で割れば、費用を引く前の一時間当たり売上が分かります。時間は似た仕事の計画に使います。次の料金は、その単価を繰り返すのでなく、費用と収入目標に照らして決めることができます。

顧客案件のデバッグと手直しを記録する

顧客向けの仕事をしない人は、この節を飛ばしてください。デバッグや手直しを単に「開発」と書くと、後から内容が分からなくなります。

デバッグ。 時間と結果を記録します。「決済処理の重複Webhookの不具合を調査して修正」なら、顧客にも内容が伝わります。

振り返りに役立つ場合は、テスト、デバッグ、手直しを別々に記録します。自分の記録には、請求書に載せない時間も残せます。

手直しには別のタグを付け、かかった時間を見えるようにします。請求可能時間と請求対象外時間の記事も記録の整理に役立ちます。

思わぬ難題。 小さく見えたタスクでも、依存関係の衝突で4時間かかることがあります。実際の時間を記録し、何が障害になったか書きましょう。

請求書で使う時間数が少なくても、自分の記録には4時間を残します。元の記録を「たぶん2時間」に書き換えると、情報を失います。

顧客以外の仕事も見えるようにします。提案、請求、顧客から求められていないフレームワークの学習も、請求する仕事と同じ週の時間を使います。省くと、一週間のうち事業に必要な時間が実際より少なく見えます。

TimeRetainの使いどころ

開発者の記録には、触れたシステム、夜遅い仕事、会議の量、請求するなら顧客名や単価が含まれます。記録を残すために、アップロードする必要はありません。

TimeRetainは、端末に記録を残す手動タイマーです。レビュー、会議、デバッグの時間と、その回の成果を見られます。IDEを監視しません。

請求するなら、メモで提供した仕事を説明します。請求しない手直しも自分の記録に残し、案件全体の時間を見られます。

主な記録は端末に残ります。同期を有効にすると、暗号化したコピーがTimeRetainのサーバーに保存されます。

1週間から始める

仕組みを作り込む必要はありません。一週間、実際の作業だけを、案件や顧客、開始、終了、チケット付きの短いメモで記録します。忘れた作業は、その日の記憶が新しいうちにGitとメモから推定します。裏付けられない部分は空けておきます。

読み返して、会議の合計を一週間の印象と比べます。一つか二つの仕事で見積もりと実績を比べます。仕事の振り返りや請求に役立ち、手間に見合うなら続けましょう。