生産性改善のためのトイル計測

Ubie Discoveryというヘルステックスタートアップでプロダクト開発エンジニアをしている丸山@h13i32maruです。

最近、チームの生産性改善をするためにトイル計測をはじめました。今日はこのトイル計測について簡単に紹介します。

「生産性」ではなく「伸びしろ」の計測

生産性を改善するにはまずは生産性の計測から始めることが重要です。

計測指標として有名なものにFour Keysがあります。Four Keysは「変更のリードタイム」「デプロイ頻度」「変更失敗率」「平均修復時間」を計測してチームのパフォーマンスを評価するものです。このFour Keysは組織全体としての生産性の結果指標だと理解しています。例えば僕のチームでは事情によりデプロイする曜日が決まっていたり、ある機能が法的・業界ガイドライン的に問題ないかのレビューを別チームに依頼していたりします。これらによって「変更のリードタイム」や「デプロイ頻度」は変わってきます。このような結果指標はトップダウン的アプローチによって組織全体の生産性を改善していくのに向いていると思います。

一方で今回はボトムアップのアプローチによってチーム内の生産性を改善しようと動き始めました。そのためには日々の具体的な仕事の生産性を見える化し、エンジニア以外(おもにbizメンバー)とも認識を揃えながら、改善していく必要があります。とはいえ具体の仕事の生産性を計測するのは難しそうです。そこで生産性自体ではなく、「トイル」という考えをもとに生産性の「伸びしろ」を計測することにしました。

💡 Four Keysの計測やトップダウン的な組織全体の生産性改善については別途検討中です。

手作業、繰り返される作業、自動化が可能、etc

SRE領域において「トイル」という指標を計測することがあります。トイルとは以下のようなものです。

https://cloud.google.com/blog/ja/products/gcp/identifying-and-tracking-toil-using-sre-principles

「トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。」 トイルの例としては次のようなものがあります。
- 割り当てリクエストの処理
- データベース スキーマ変更の適用
- 重要性の低いモニタリング アラートの確認
- プレイブックからのコマンドのコピーと貼り付け

💡 より詳しい内容については「SRE サイトリライアビリティエンジニアリング」を参照ください。
https://www.oreilly.co.jp/books/9784873117911/

この定義や例はSRE領域の業務を背景に書かれているため、エンドユーザ向けのWebアプリケーション開発をしている僕のチームにそのまま当てはめるには少し難しいなと感じました。そこで、チーム内で共通認識を持ってトイルの計測が各自でぶれないように、「エンドユーザ向けWebアプリケーション開発においてのトイルってどんなもの?」というのを整理することにしました。

改善可能な作業を計測する

トイルの定義は前述しましたが、本質的にはトイル計測で何をしりたいかというと、以下のように書いてあります。

https://cloud.google.com/blog/ja/products/gcp/identifying-and-tracking-toil-using-sre-principles

作業効率を検証するために Google のサイト信頼性エンジニア(SRE)が使用している主な測定指標の一つが、日々の時間の使い方です。長期間のエンジニアリング プロジェクトのために時間を確保する必要がありますが、エンジニアには Google のサービスを稼働し続ける責任もあり、そこにも手作業が生じることがあります。

つまりトイルの本質とは「ある領域の業務において、作業効率が悪いものがどれだけあるか計測する」ということです。この理解をもとに、僕のチームでは以下のようなものをトイルとして計測することにしました。

定義: 「作業効率や生産性の改善余地があると感じた業務」をトイルとする。

トイル40%超え

計測方法はJiraのチケットに各自がトイルフラグをつけていくというシンプルなものです。昨年の10月からトイルの計測をはじめ、12月はエンジニアが行った業務のうち44%がトイルでした。SRE本では40%を超えると良くないとあったのですが、通常のWebアプリケーション開発においては40%はかなり多い印象です。感覚ですが20%ぐらいに抑えたいなという気持ちがあります。

💡 10、11月はシステム運用を改善する業務が多かったため、トイルの割合が高くなっていました。直近はそれらの業務が減ってきており、比例してトイルも少し減少傾向にあります。

割合を多く占めるトイルとしては以下のようなものがありました(結果だけみるとありきたりではある)。

  • デプロイ作業
  • 不具合修正
  • ユーザサポートや営業チームからのデータ集計依頼

この中でデプロイ作業はトイルの半分ほどをしめます。なのでここを改善するとチームの生産性が向上しそうです。実際にデプロイ改善については取り組むことになっています。また、不具合修正やデータ集計依頼の根本的な改善は難しそうですが、徐々にトイル撲滅をしていこうと思っています。例えば、不具合が発生しづらいようにリファクタリングをしたり、データ集計をユーザサポートや営業チームができるように環境整備やイネイブリングを行ったりなど。

トイルの撲滅は...これからだ!

生産性というと抽象度が高く計測したり改善するのが難しくなりがちですが、伸びしろ(=非効率な業務、無駄がある業務)を見える化するのは割と簡単です。それらの作業を改善すれば、生産性も改善されていくと思います。とはいえまだ見える化しはじめた段階なので、改善はまだまだこれからやっていく必要があります。

最後にUbie Discoveryではエンジニアを積極採用中です。少しでも興味を持ってくださった方はTwitterでお気軽にメンション・DMください。