Toggl Track でタイムトラッキングしてみた話

こんにちは！あしたのチームでエンジニア、デザイナー採用担当をしている齊藤、貫井です！
再始動したTechBlog、順調に投稿続いております！
20卒エンジニアの松本さんの記事に続き、今朝、フロントエンドシニアのmitaniさんの記事が公開されました！
時間の使い方、そして自分のタスク分析について、ぜひ読んでいただきたい内容でしたのでWantedlyにも転載させていただきます！

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

はじめましてー！
あしたのチームでフロントエンドエンジニアをしている mitani です。

さて、みなさんは自分の時間の使い方をしっかり把握できているでしょうか？
ちなみに私は日々仕事を行う中で時間の使い方に以下のような課題を感じていました。

どのタスクにどれだけ時間使ったかわからない
今後やるタスクにどれだけ時間がかかるか予測できない
時間の使い方の課題を洗い出せない

これらの課題を解決するためには時間の使い方の可視化が必要だと考え、4週間タイムトラッキングで日々の作業を記録していくことにしました。今回は私が実践したタイムトラッキングの方法とその結果得られたことをご紹介したいと思います。

※ この内容は 9/24 に実施された社内 LT 大会で登壇した際の内容を弊社エンジニアブログ向けにリライトしたものになります。（LT 大会の様子はこちら → 記念すべき第1回 LT大会が開催されました！ | 株式会社あしたのチーム）

使用サービス

タイムトラッキングサービスにはいくつかありますが、以前にも使ったことがあった Toggl Track を使用しました。かつては Toggl という名前でタイムトラッキングサービスのみを提供していましたが、最近になっていくつかサービスが増えタイムトラッキング部分は Toggl Track という名称になったようです。

ブラウザに拡張機能をインストールすることで様々な Web サービス上で直接計測の開始・停止できるようになる点がすごく便利で気に入っています。また Web API が公開されており各種ツールとの連携プラグインが OSS で公開されていたり、なければ自分で開発することもできます。ちなみに私も Toggl Track で記録した1日のサマリーを Markdown リスト形式で出力する CLI ツールを開発・公開しています｡
tapioca24/toggl-day: toggl-day is a CLI tool to show today's Toggl Track summary report.

タイムトラッキング実践

日常的に使用するサービスなので面倒くささが少ないことは重要です。そのため以下のような方針で省エネタイムトラッキングを行いました。

Tag は使用しない
Desktop アプリを使用する
GitHub Integration を使用する

Tag は使用しない

Toggl Track には Project と Tag という分類方法があります。

分類方法説明Project各タスクが所属する Project をひとつだけ付与できるTag各タスクと関連する Tag を複数付与することができる

記録したデータを分析するためにはある程度タスクを分類する必要がありますが、細かく分類しすぎると記録コストが上がって面倒臭くなってしまいます。どの程度の分類が必要なのかは目的によりますが、一旦ざっくり Project のみを使用し Tag を使用しないという方針で進めてみました！

Desktop アプリを使用する

Web アプリだけを使用すると、タブの行き来が面倒なので Desktop アプリを Slack の横に常駐させました。タスク入力欄は過去の履歴からインクリメンタルサーチができるので、過去に行ったタスクを再度入力する際に便利です。

GitHub Integration を使用する

私は日々の作業として PR レビューを頻繁に行っていますが、これらの作業を行う際には GitHub の PR ページから記録を開始しています。これにより簡単に PR ごとに記録を分けることができ、またタイトルが自動挿入され命名規則が統一されます。「PR レビュー」といったざっくりとしたタスクとして記録するのではなく、何の PR をレビューしたのかを分けて記録することで、後からレビューの所要時間が長かった PR を洗い出したり、件数あたりの所要時間などを分析することができるようになります。

4週間タイムトラッキングした結果

8/23 ~ 9/19 までの4週間タイムトラッキングをした結果次のことがわかりました。

時間の使い方が可視化された

私の場合ですがミーティング関係が毎週 20% 前後は固定で入っていました。つまり1日のうち少なくとも約 20% は手を動かす作業に充てられないということが分かりました。

時間の見積り精度があがった

4週間で99件の PR レビューを実施していたので、平均的には1日あたり5件処理していました。それまでは溜まっているレビューリクエストをどのくらいで消化できるのか全然分からなかったのですが、これまでの実績からある程度の信頼性を持って見積もれるようになりました。

タスクの分析が可能になった

99件の PR レビューの所要時間の度数分布を算出してみると、以下のようになりました。

10分以内で終わるタスクもあれば120分以上かかるタスクもあり、PR の粒度にばらつきがあることが分かりました。また「50分未満で完了するタスク」と「それ以上かかるタスク」にざっくり分けてみると、件数ベースでは前者が8割なのに対して所要時間ベースでは後者が8割を占めるということが分かりました。つまり PR レビューの所要時間の8割は2割の PR に消費されているということを示しています。

さらに所要時間の長かったものの内容を確認すると、レビューに広範囲の前提知識が要求される「新規コード・コンポーネント追加」や「リファクタリング」が占めていました。そのため担当者は事前周知やモブプロなどでメンバーに前提知識を共有したり、タスク分解して小さい粒度で PR を作成することでレビューコストを下げると良さそうという改善案が見えてきました。