1.3 産出より成果を:何を測定するかを選ぶ

概要と動機

あらゆるエンジニアリングメトリクスは3つのカテゴリーのいずれかに分類され、それらを混同することは、グッドハートの法則を完全に無視することに次いで、本書における2番目に多い失敗モードです。インプット指標は費やされた労力を測定します。エンジニアの工数、投じられたドル、コミットされたストーリーポイントです。アウトプット指標はシステムが生み出したものを測定します。出荷された機能、マージされたプルリクエスト、クローズされたチケットです。成果指標は実際に重要だった変化を測定します。維持された収益、回避されたインシデント、ユーザーのために節約された時間です。チームはインプットとアウトプットに引き寄せられがちです。なぜならそれらは数えやすく、チームの統制下に完全にあるからです。価値は、ほとんど常に成果の中に宿っていますが、成果は現れるのが遅く、測定にはノイズが多く、どのチームの仕事に起因するのかを特定するのが難しいものです。

本トピックは、その引力に意図的に抵抗することについて扱います。すべてインプットとアウトプットだけで組み立てられたダッシュボードは、実際にはまったく価値を生んでいなくても印象的に忙しそうに見えることがあります。誰も使わない機能を何十個も出荷し、1週間後に再オープンされるチケットを何百件もクローズし、あらゆるストーリーポイントの見積もりを達成していながら、製品の実際の成果、つまり継続率、満足度、収益は横ばいか悪化しているかもしれません。そうした忙しさのどれも、アウトプットだけのダッシュボード上には問題として表れません。なぜなら、アウトプットだけのダッシュボードは、それを見るようには作られていないからです。

企業や政府の規模においては、この区別が、経営陣が生産的なチームと単に活動的なだけのチームの違いを見分けられるかどうかを決定します。ある部門は、何年もの間、優れたアウトプットの数字(出荷された機能、クローズされたスプリント)を発表し続けながら、資金提供者や議会が実際に気にかけている成果、つまり維持された収益や短縮された市民の待ち時間は、その下で静かに蝕まれていくかもしれません。「ロードマップを届けた」は「ロードマップが物事を良くした」と同じ主張ではなく、成果に重みを置いた指標群だけが、この二つを見分けることができます。

重要な原則

インプットとアウトプットは代理であり、成果こそがそのものである。 届く限りにおいて、指標群の重みを成果へと寄せてください。
測定のしやすさは、何かを測定する理由にはならない。 最も数えやすいものは、たいていインプットとアウトプットです。それらが最も重要だからではなく、機械的に捉えやすいからです。
成果に近づくほど、帰属づけは難しくなる。 成果の帰属づけが難しいからといってアウトプットに逃げるのではなく、そのトレードオフを意図的に受け入れてください。
チームはインプットとアウトプットを統制できるが、成果には影響を与えられるだけである。 それに応じて説明責任を設計してください。チームが実際に統制できるものについてはチームに責任を持たせ、成果はチームを横断して共有される信号として追跡してください。
少数の推進要因を伴う単一の北極星成果は、アウトプットタイルの壁に勝る。 網羅性は、ダッシュボードの純粋な量からではなく、構造から得られるべきです。

推奨事項

採用する前にすべてのメトリクスを分類する

候補となるメトリクスについて、それが3つのカテゴリーのどれに当たるかを問うてください。「週あたりのマージ済みプルリクエスト数」はアウトプットです。「マージされたプルリクエストのうち、1週間以内に本番インシデントを引き起こした割合」は、量ではなく結果を測定しているため、成果により近いものです。この分類には30秒しかかかりませんが、あるメトリクスがチームや組織のダッシュボードに追加される前には必須であるべきです。なぜなら、それはダッシュボードが価値を測定していると信じながら、数えやすいアウトプットで静かに埋め尽くされていくのを見つける最も速い方法だからです。

単一の成果の下にメトリクスツリーを構築する

フラットな一覧を追跡しないでください。メトリクスをメトリクスツリー(KPIツリーと呼ばれることもあります)として整理してください。頂点にある成果指標を、それに因果的あるいは数学的に供給している推進要因へと分解し、各チームが実際に所有する運用上のアウトプットとインプットの指標まで下ろしていきます。頂点の成果が動いたとき、ツリーはどの下位の推進要因を調査すべきかを教えてくれます。「数字が下がった」を「パイプラインのこの特定の段階が原因だ」に変えてくれるのです。あなたの領域がそれを支えるところでは、頂点に単一の北極星指標を名指ししてください。届けられた価値を最もよく捉える尺度、プラットフォームチームにとっては変更失敗率と対になったデプロイ頻度、プロダクトチームにとっては中核機能の週間アクティブ利用などです。

ダッシュボードだけでなくレビューでも成果に重みを置く

メトリクスツリーは、実務でどう使われるかによってその価値が決まります。スプリントレビュー、四半期ビジネスレビュー、経営陣への報告では、成果レベルの数字を先頭に持ってきて、その下にあるアウトプットとインプットの指標は、それを置き換えるためではなく、動きを説明するためだけに使ってください。「今スプリントでチケットを40件クローズしました」と成果の文脈なしに報告するチームは、その仕事が重要だったかどうかについて何も伝えていません。「流出欠陥が30%減少し、それを牽引したテストへの投資はこれです」と報告するチームは、何か本物のことを伝えています。

成果指標の遅い反応を受け入れ、より速い先行指標と対にする

成果指標はしばしば遅行的です。十分な時間が経過してから、ある結果を確証するのです。その遅れは、学びを遅らせるという意味で、本物のコストです。すべての成果指標を、少なくとも一つの先行指標、つまりより早く動いて成果を予測するメトリクスと対にしてください。そうすれば、チームは遅くて権威ある数字がようやく届く前に舵を切ることができます。デプロイ頻度は提供成果にとっての先行指標です。上昇する欠陥流出の傾向は、来るべき信頼性の成果にとっての先行指標です。先行指標を使って早く行動し、遅行する成果指標を使って自分が正しかったことを確認してください。

トレードオフ:長所と短所

カテゴリー	長所	短所
インプット指標	チームの統制下に完全にあり、数えやすい	実際の価値への結びつきが最も弱く、量によって操作されやすい
アウトプット指標	数えやすく、所有権が明確で、フィードバックが速い	影響よりも活動を報い、価値が下がっていても上昇しうる
成果指標	本当に重要なものを直接反映し、安く操作することが難しい	遅く、ノイズが多く、単一のチームに帰属づけるのが難しい
メトリクスツリー構造	日々の仕事を戦略的価値に結びつけ、診断を助ける	正しく構築し保守するには本物の分析的な作業が必要

中心にある緊張関係は統制可能性と価値です。インプットとアウトプットはチームの統制下に完全にあるため、それについてチームに責任を負わせたくなる誘惑があります。成果は価値を担っていますが、単一のチームの影響力の範囲には部分的にしかありません。良い機能であっても、エンジニアリングとはまったく無関係な理由で失敗することがあるからです。これを解決するには、チームが完全に統制するインプットとアウトプットについてはチームに責任を負わせつつ、成果は組織全体が共同で所有する共有信号として追跡し、「仕事はした」と「それが役に立ったか」の間の説明のつかない隙間として放置するのではなく、明示的なメトリクスツリーを通じてつなげてください。

チームで話し合うべき問い

現在の私たちのダッシュボード上の各メトリクスは、インプット、アウトプット、成果のどれであり、その三者間のバランスは正直な物語を語っているでしょうか。ほとんどのダッシュボードは、正直に監査してみると、ほぼ完全にインプットとアウトプットであることが判明します。なぜなら、それらはツールが既定で報告するものだからです。すべてのタイルを分類し、その内訳を数えてください。成果タイルがまったくないダッシュボードは、活動を測定し、それを成果として提示しているのです。
私たちの単一の北極星成果指標は何で、それをメトリクスツリーを通じて各チームが実際に所有するものまでたどることができるでしょうか。 この接続構造がなければ、動いている最上位の数字は、どこを見ればよいかの手がかりを何も与えません。チームは自分たちの日々のアウトプット指標が重要な何かにどうつながっているのかを見ることもできません。もし現在の最上位指標があれば持ち寄り、その場でツリーを構築してみてください。
私たちは、チームが影響を与えることしかできず統制できない成果について、どこでそのチームに責任を負わせているでしょうか。 これはよくある苛立ちと静かな操作の源です。なぜなら、自らの統制が及ばない要因によって形づくられた成果のために罰せられたチームは、本物のシステムを改善するよりも自分自身を守るあらゆるインセンティブを持つからです。こうした不整合を特定し、説明責任を調整するか、欠けている手段を追加してください。
遅行する各成果指標について、私たちはどんな先行指標を持っており、それはどれだけ前もってそれらを予測するでしょうか。 純粋に遅行指標だけのメトリクス群は、安く軌道修正するには手遅れになってから初めて自分が間違っていたことに気づくことを意味します。成果指標を持ち寄り、それぞれに本物の先行指標が存在するか、それとも報告期間の間、目隠しで飛んでいるのかを確認してください。
レビューや振り返りで私たちが祝っていることのうち、どれだけがアウトプット(「Xを出荷した」)で、どれだけが成果(「XがYをより良い方向に変えた」)でしょうか。チームが仕事を祝うために使う言葉は、時間とともに彼らが何を最適化するかを形づくります。しばしば、それはダッシュボードよりも強く作用します。1スプリント分、自分たちのレビュー会議に耳を傾け、その内訳を正直に数えてください。
もし私たちの主要なアウトプット指標が一夜にして倍増したら、成果指標は必然的に改善するでしょうか、それとも悪化しうるでしょうか。 この思考実験は、本来仕えるはずだった成果から切り離されてしまった、あるいは積極的に対立してしまったアウトプット指標、たとえば採用を増やすよりも速く保守の負担を増やす機能の量のようなものをあぶり出します。

業種別の視点

スタートアップ。 一つの成果、典型的には顧客が価値を得続けているかどうかの代理となるもの、たとえば週次の継続率や活性化率を選び、初日からそれを北極星として扱ってください。投資家に報告したくなる誘惑はあるものの、製品が実際に誰かのために機能しているかについて何も教えてくれない、累計機能数のようなアウトプット虚栄メトリクスへの引力には抵抗してください。

中小企業。 既存のツール、販売時点情報管理、サポートデスク、分析ツールは、たいていすでに成果に近い数字、再購入率、チケット再オープン率を報告しています。維持する余力のないカスタムの成果計装を構築するのではなくそれらを使い、それが既定のビューだからというだけで素の活動件数に頼ってしまう誘惑には抵抗してください。

企業。 支配的な失敗モードは、それぞれのチームが局所的なアウトプット指標を最適化しているものの、それらを合計しても一貫した組織的な成果にはならないというポートフォリオです。メトリクスツリーを意図的に構築し、事業部を横断して成果の定義を標準化し、あらゆる主要な取り組みに対して、アウトプット計画だけでなく、資金提供前にその成果仮説を述べることを求めてください。

政府。 監督機関と国民は、「作業指示書どおりに届けた」と「成果を改善した」の違いについて、ますます理解を深めています。アウトプットだけの報告は、まさにその精査を招きます。法的かつ実務的に可能な限り、成功を市民向けの成果(待ち時間、エラー率、満足度)として定義し、アウトプット指標しか得られない場合にはその理由を明示してください。

事例

企業。 ある物流会社のエンジニアリング部門は、2年間にわたって「四半期あたりに出荷された機能数」が一貫して上昇していると報告していましたが、その間、会社の中核的な顧客満足度スコアは静かに横ばいになっていました。新しいエンジニアリング担当副社長は、実際のビジネス成果である時間どおりの配送率を頂点に据えたメトリクスツリーを構築し、それをハブでの滞留時間とラストワンマイルの成功率を経て、チームレベルのエンジニアリングのアウトプットまで分解しました。1回の報告サイクル以内に、アウトプットの多い複数のチームが、北極星指標に測定可能な影響を何も与えていない領域で機能を出荷していたことが明らかになり、投資はツリーが実際に重要だと示した推進要因の方へと移されました。

政府。 ある国民保健サービスのデジタルチームは、複数年にわたる患者記録近代化プログラムについて「作業指示書に対して届けられたモジュール」を報告していました。監督委員会は別の問いを投げかけました。臨床医は管理データ入力に費やす時間を減らせたか。チームは成果指標、患者対応あたりの管理業務時間の中央値を後付けで導入し、あらゆる提供マイルストーンを達成していたにもかかわらず、初期のモジュールがワークフローの摩擦により実際にはこの時間を増やしていたことを発見しました。後続のモジュールは成果指標を直接中心に再設計され、プログラムの公開報告は提供チェックリストから前後比較による成果の比較へと移行しました。

ビジネスケース:動機、ROI、総所有コスト

成果への重みづけからの見返りは、無駄の回避です。あるアウトプットの流れがどの成果も動かしていないことをほぼリアルタイムで見ることができる組織は、丸1回の予算サイクルを費やして苦い経験からそれを知る前に、その投資の方向を変えることができます。大規模なエンジニアリング組織における支配的な隠れコストは、投資不足ではなく、本来資金提供されるべきではなかった、どんな本物の成果からも切り離された、うまく実行された仕事です。そしてアウトプットだけのダッシュボードは、その切断にまったく気づくことができません。

成果測定の総所有コストは、アウトプット測定よりも高くつきます。なぜなら、成果は定義し、帰属づけ、計装することが本当に難しく、本物のメトリクスツリーを構築するには、ツールが既定でエクスポートするものをそのまま受け入れるのではなく、意図的な分析作業が必要だからです。そのコストは、ある程度以上の規模の取り組みであれば支払う価値があります。なぜなら、代替案、つまり自信を持って報告された1年分のアウトプットが実際には何の価値も生んでいなかったと事後に発見することは、事前の分析よりもはるかに高くつくからです。

アンチパターンと落とし穴

完全にアウトプットタイルだけのダッシュボード。 活動を測定し、それを成果として提示します。
統制できない成果についてチームに完全な責任を負わせる。 苛立ちを生み、不当な非難から身を守るための操作を招きます。
遅行する成果に先行指標がない。 修正するには高くつきすぎるようになって初めて、チームは自分が間違っていたことを知ります。
成果を重視すると主張しながらレビューではアウトプットの言葉を祝う。 公言された優先順位と、実際に生きられるインセンティブが乖離し、実際に生きられるインセンティブが勝ちます。
ツリー構造のないフラットなメトリクス一覧。 動いている最上位の数字は、どこを見ればよいかの手がかりを何も与えません。
成果測定を試みるには難しすぎると扱う。 組織を恒久的に、数えやすいインプットとアウトプットへと既定に戻してしまいます。

成熟度モデル

レベル1、開始: メトリクスはほぼ完全にインプットとアウトプットであり、組織の成果指標を名指しできる人も、それへの経路をたどれる人もいません。
レベル2、発展: 一部のチームは非公式に成果指標を特定していますが、共有されたメトリクスツリーはなく、一貫した先行指標もありません。
レベル3、標準化: 文書化されたメトリクスツリーが、共有された北極星成果をチームが所有するアウトプットまで接続し、組織全体で一貫して適用されています。
レベル4、管理: 先行指標と遅行指標がともに追跡され、一緒にレビューされます。チームは統制できるものについてのみ責任を負い、成果測定には実際に資源が投じられています。
レベル5、最適化: 成果測定は資金提供と優先順位づけの決定に直接組み込まれています。組織は、丸1回の予算サイクルが経過する前に、アウトプットは多いが成果の低い仕事から投資を日常的に振り向け直しています。

議論のためのアイデア

私たちの組織にとって唯一最も重要な成果指標を名指ししてみてください。全員がそれに同意できるでしょうか。
まだどんな成果にもたどり着けていない、現在の最大のアウトプットへの投資は何でしょうか。
私たちの説明責任の構造は、どこでチームが統制できない成果についてそのチームを罰しているでしょうか。
もしすべての純粋なアウトプットタイルを削除したら、私たちのダッシュボードはどう見えるでしょうか。
出荷された機能が実際に役立ったかどうかを知るまでに、現在どれだけの時間がかかっているでしょうか。

主な要点

すべてのメトリクスをインプット、アウトプット、成果として分類し、意図的に指標群の重みを成果へと寄せてください。
単一の北極星指標の下にメトリクスツリーを構築し、動いている最上位の数字が原因を指し示すようにしてください。
チームには統制できるもの(インプット、アウトプット)について責任を負わせ、成果は組織全体が共同で影響を与える共有信号として追跡してください。
遅行する成果指標にはすべて、より速い先行指標を対にし、遅い数字が間違いを確証する前に舵を切れるようにしてください。
アウトプットだけのダッシュボードは活動を測定しそれを成果と呼びます。これを安心材料ではなく警告として扱ってください。

参考文献とさらなる読書

Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。
Lean Analytics, Alistair Croll、Benjamin Yoskovitz 著。
Measure What Matters, John Doerr 著。
The Lean Startup, Eric Ries 著。
Key Performance Indicators, David Parmenter 著。