「変更のリードタイム」採用のススメ

2023年9月22日 16:42

はじめに

Hi-Outcomeの中森です。
エンジニアリングプロセスにおいて、質とスピードはトレードオフではなく、両立可能な指標であることがわかっています。
t_wadaさんの講演『質とスピード』や、その講演の元となったState of DevOpsレポートでは、この点が詳しく説明されています。
エンジニアチームの生産性が企業の業績の予測要因になることが統計的な事実として示されている以上、エンジニアチームの生産性を可視化することは非常に重要なことです。

4keysの指標の1つであるリードタイムは、プロジェクトの進行状況を把握し、改善点を見つける上で大変重要です。
リードタイムを可視化し改善することで、エンジニアリングプロセスの最適化やエンジニアチームのパフォーマンス向上に繋げることができます。
しかし、一般的にリードタイムと言われる際、3つの異なる指標（「リードタイム」、「サイクルタイム」、「変更のリードタイム」）が混同されて使われているのを目にします。そのため、本記事では、これら3つの指標の違いに焦点を当て、エンジニアチームの生産性を可視化する指標として、「リードタイム」「サイクルタイム」ではなく、「変更のリードタイム」」を採用すべき理由について述べたいと思います。

各指標の定義とその違い

百聞は一見に如かず。 3つの指標を図に表すと、以下のようになります。範囲が広い順に、「リードタイム」、「サイクルタイム」、「変更のリードタイム」となっています。

なぜ「「変更のリードタイム」」を採用すべきなのか？

以下で、3つの指標について詳しく取り上げる前に、「変更のリードタイム」を採用する理由だけ列挙しておきますので、頭の片隅に入れてお読みください。

計測がしやすい
各期間内で登場するステークホルダーがエンジニアに限定されるため、改善のオーナーシップが取りやすい
狭い定義のものから計測し始めて、徐々に効果測定の範囲を広げた方が改善がしやすい

では、以下で、3つの指標について詳しく見ていきます。

リードタイム

機能の要求が現れてから実際にプロダクトに反映されるまでの時間のことを指します。つまり、「この機能を作りたい」という要求が現れたタイミングを計測の始点としています。一見、有用に思える「リードタイム」は以下の点から、エンジニアチームのパフォーマンスを測定する上であまりオススメできません。

1.分散が大きく計測が非常に難しい

「リードタイム」はバックログにIssueが滞在する期間を含むので、分散が必然的に大きくなります。
作るものが決まっているならいざ知らず、多くのアジャイルチームが直面する状況は、機能要求の実現方法それ自体が決まっていないことが大半だと思います。
機能によっては仮説を立てたり、ユーザーインタビューをしたりとコーディング以外の作業が多くなったり少なくなったすることで、分散が大きい指標となりがちで扱いづらいです。
よってエンジニアチームの生産性を可視化する指標としてはあまり適切ではないと考えます。

2.エンジニアチーム以外のステークホルダーの影響をもろに受けてしまう

機能要求が現れた時点からプロダクトがリリースされるまでには、プロダクトオーナー・営業・カスタマーサクセスなど非常に多くのステークホルダーが関わっています。当然エンジニアチームが制御できない要因が多くなるわけなので、エンジニアチームのパフォーマンスを測定する上であまりおすすめできません。継続的な改善によってエンジニアチームの生産性が高まったとしても、ステークホルダー側がボトルネックになった場合には、「リードタイム」は改善されないという状況が発生しうるのです。これでは、エンジニアチームの改善が目に見えないので、エンジニア組織のバーンアウトを生み出すリスクもあります。

サイクルタイム

当該機能の開発に入ってから、それがプロダクトに反映されるまでの時間を指します。
ユーザーインタビュー等の作業が終わり、いよいよ開発フェーズに入ったとしても、デザイナーチームのデザイン作成や、QAチームとの受け入れテスト作成など、まだまだエンジニア以外のステークホルダーが関わっています。 当然、調整等々が発生したりしなかったりするので、「リードタイム」ほどではないですが、分散が大きくなります。
結果、「サイクルタイム」はエンジニアチームの生産性を可視化する上であまり適切ではないと考えます。エンジニアチームとチームに密接に関係する少し大きめの粒度でのスループットの指標としては適切そうです。

変更のリードタイム

first Commitがなされてから、プロダクトに反映されるまでの時間のことを指します。
ここまで来るとエンジニアチーム以外のステークホルダーの影響を受けることはほとんどなくなります。
やっとエンジニア自身がコントロールできる範囲に入りました。
ステークホルダーがチーム内のメンバーに限定されるので、指標の改善・悪化に対してエンジニアチームは唯一の責任者となり、改善に向けた取り組みを行うことができます。
改善を行う際には、オーナーシップを持てるかどうかは非常に重要な要素です。
また、改善の積み重ねが着実に効果を生んでいるという実感を持てるかも重要な要素です。それらを考えてみても、「変更のリードタイム」はエンジニアチームの生産性を可視化する上で最も適切な指標だと考えます。

まとめ

今回は混同されがちなリードタイムについて取り上げました。
「リードタイム」、「サイクルタイム」、「変更のリードタイム」の指標はすべて異なる目的を持ち、異なることに役立つことができます。
中でも、「変更のリードタイム」がエンジニアチームの生産性を可視化する上で最も適切な指標だということをお伝えしました。
まずは、「変更のリードタイム」を計測することから始めて、「サイクルタイム」「リードタイム」の計測を行い改善を行なっていくのがオススメです。スコープをできるだけ小さくして、改善の効果を確認しながら、改善を繰り返していくことが大切です。
次回以降の記事で、リードタイム改善のための具体的な取り組みについてもお伝えできればと思っています。

おわりに

私たち「Hi-Outcome」は、開発チームの規模が10-100名の企業を中心に、開発スピード向上にコミットした開発支援を行っています。

開発にお悩みの方がいましたら、是非お気軽にお問い合わせください。
開発スピード向上サービス: https://corp.hi-outcome.com/
開発の予測精度向上サービス: https://corp.hi-outcome.com/inspection