3.3 パフォーマンスの指標と成果の代理

概要と動機

パフォーマンス、SPACE(トピック3.1)のPは、活動と最も混同されやすい次元であり、まさにその混同を防ぐために本トピックが存在します。パフォーマンスは、あるエンジニアやチームの仕事が実際に良い成果を生み出したかを問います。出荷されて機能した機能、信頼性を保ったシステム、ビジネスやユーザーの指標を正しい方向に動かした変更です。活動(トピック3.4)はどれだけの動きが起きたかだけを問います。あるチームは、成果を決して動かさない絶え間ない小さな変更を出荷しながら、非常に活動的で低パフォーマンスであることがあります。逆もまた同様に可能です。めったに出荷しないが、その変更が確実にぴったり正しく着地するチームです。

この次元の難しさは、成果が単一の人物、あるいは単一のチームにさえ帰属できないことが多いということです。ソフトウェアの成果は、協働から、何か月も前に下され、それ以来他のプロジェクトに移った人々によってなされた決定から、どのエンジニアも統制しない市場の状況から生まれます。SPACEの研究者たちはこれについて明示的でした。パフォーマンスは、単一の数字に縮小されるのではなく、ましてや孤立した個々のエンジニアに帰属させられるのではなく、複数の収束する信号を使ってシステムやチームのレベルで測定されるべきだというものです。本トピックはその指針を真剣に受け止め、個人のパフォーマンス帰属を、便利なときに取られる近道としてではなく、能動的に避けるべき罠として扱います。

大規模なチームにとって、パフォーマンス測定を正しく行うことが、実際に成果を改善する指標プログラムと、単に目に見える忙しさを報いるだけのものとを分けるものです。多くのチームにわたってパフォーマンスを比較する企業組織は、素のアウトプット量を通じた操作に強い信号を必要とします。監督機関に技術投資を正当化する政府組織は、エンジニアリングの努力が単に成果物を届けただけでなく本物の成果を生み出したことを示す必要があります。これはまさに、トピック1.3の資産より成果を優先する原則をこの特定の次元に適用したものです。

重要な原則

パフォーマンスは仕事がどれだけの動きを生んだかではなく、良い成果を生んだかどうかを測定する。 これが活動の次元からの核心的な区別です。
複数の収束する信号を使い、決して単一のパフォーマンスの数字を使わない。 どんな個々の代理も単独で立つほど信頼できるものはありません。
チームやシステムのレベルで測定する。 個人の成果への帰属は通常信頼できず、まさに本書が全体を通じて警告する操作を招きます。
品質はパフォーマンスの一部であり、別個の関心事ではない。 出荷されるが他の何かを壊す仕事は、本当には良い業績を上げたことになりません。
決定が結びついていないパフォーマンスの信号は装飾である。 まさにトピック1.1の一般的な原則をこの次元に適用したものです。

推奨事項

単一のパフォーマンススコアではなく、複数の収束する信号を組み合わせる

複数の情報源からパフォーマンスの証拠を引き出してください。品質のための変更失敗率(トピック2.10)と欠陥流出率(トピック5.1)、仕事が重要だったかどうかのための実際の機能採用に結びついたデプロイの成果(トピック5.2)、そして純粋な指標では捉えられない文脈のための戦略的目標へのチームの貢献についての定性的な同僚やマネージャーの評価です。これらのどの一つも単独では信頼できませんが、それらが一緒になって同じ結論に収束するとき、それはどんな単一の数字よりもはるかに信頼できます。

チームレベルで測定し、個人への帰属に抵抗する

ソフトウェアの成果は、めったに一人の仕事だけの産物ではありません。それらは、設計の決定、レビューのフィードバック、それ以来チームを離れたかもしれない人々による以前の仕事、境界を横断した協働から生まれます。ある成果を単一のエンジニアに帰属させることは、通常、この現実を無視する偽りの精密さであり、個人が自由に協働するよりも功績を守ろうとする強いインセンティブを生み出します。これはまさに、トピック1.2が警告するインセンティブのゆがみの一種です。

品質をパフォーマンスの定義に直接組み込む

時間どおりに出荷されるが本番のインシデントの波を引き起こす機能は、素朴なアウトプットだけの見方がそれを届けられたとカウントしても、良いパフォーマンスではありませんでした。品質を本書の第4部と第6部でのみ測定される別個の切り離された関心事として扱うのではなく、変更失敗率、欠陥流出率、リリース後のインシデントデータを、パフォーマンスをどう評価するかに直接組み込んでください。

パフォーマンスのデータを投資とプロセスの決定に情報を与えるために使い、個人のランク付けには使わない

パフォーマンスのデータの生産的な使い方は、どこにさらに投資するか(一貫して強い成果を届けるチームはより多くの資源と自律性に値します)、そしてどこを調査するか(仕事が一貫して着地しないチームは、トピック1.1の診断的な枠組みに従って、非難ではなく助けに値します)を決めることです。パフォーマンスのデータについて個人やチームを互いに競争的にランク付けすることは、まさに本書が警告する操作と士気の損害を招き、診断的な使い方よりも良い成果を生み出すことはめったにありません。

帰属の限界について、特にプラットフォームチームやイネーブリングチームについて正直である

共有インフラストラクチャ、内部ツール、あるいはプラットフォームの能力を構築するチーム(姉妹書『software-engineering-guide』のプラットフォームエンジニアリングのトピックがこれを直接扱います)は、しばしば、成果への彼らの貢献が、どんな単一の顧客向けの指標からも何段階も離れています。本質的に間接的な仕事に無理やり合わない直接成果の指標を押しつけるのではなく、これらのチームのパフォーマンスを、彼らが可能にするチームへの効果、彼らのプラットフォームの採用、利用するチームによって報告される摩擦の減少を通じて測定してください。

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

アプローチ	長所	短所
チームあたり単一のパフォーマンススコア	提示と比較が簡単	偽りの精密さ。実際に何がそのスコアを動かしたのかという根底の信号を隠す
複数の収束する信号	より信頼でき、単一指標の操作に強い	一つの数字に要約するのがより難しく、解釈により多くの文脈が必要
チームレベルのパフォーマンス測定	ソフトウェアの成果が実際どう生まれるかに一致する	個人の貢献についての問いに直接答えられない
個人レベルのパフォーマンス帰属	評価にとってより直接行動可能に感じられる	通常は偽りの精密さ。強い操作と功績保護のリスク

中心にある緊張関係は精密さと誠実さです。チームあたり、あるいもっと悪いことに個人あたりの単一のパフォーマンスの数字は、比較しランク付けするのが簡単ですが、その精密さは通常偽りのものであり、きれいに見える数字の背後に帰属と品質についての本物の不確実性を隠します。この緊張を解消するには、より整然としていない複数信号の全体像を誠実なものとして受け入れ、それを単一の偽りに精密なスコアに縮小しようとする経営陣や業績評価プロセスからのプレッシャーに抵抗してください。

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

私たちの現在のパフォーマンス測定は複数の収束する信号を組み合わせているでしょうか。それとも実際よりも精密に感じられる単一の数字に頼っているでしょうか。あなたが現在「パフォーマンス指標」と呼んでいるものを監査し、実際にいくつの独立した収束する信号がそれに供給されているかを確認してください。
私たちは、成果が実際どう起きたかの協働的でチームを横断した性質を考慮せずに、あるチームや個人にパフォーマンスを帰属させたことがあるでしょうか。最近の成功の物語を選び、それがどれだけ、功績を認められたチームや個人の外にいる人々、決定、あるいは以前の仕事に依存していたかをたどってみてください。
私たちのパフォーマンス測定は品質を含んでいるでしょうか、それとも提供速度とアウトプット量だけでしょうか。 後で重大な本番インシデントを引き起こした出荷された機能は、高いパフォーマンスとしてスコアされるべきではありません。あなたの現在の測定が実際にこのケースを捉えるかを確認してください。
私たちは、成果への貢献が間接的なプラットフォームチームやイネーブリングチームのパフォーマンスをどう測定しているでしょうか。 正直な答えが「まあ、していません」なら、その隙間は、それらのチームを効果的に未測定のままにするか、彼らの仕事に合わない顧客向けの成果指標に対して不公平に測定するままにするのではなく、名指しし直接対処する価値があります。
パフォーマンスのデータが、正式あるいは非公式に、個人を互いに競争的にランク付けするために使われたことがあるでしょうか。 トピック3.2の満足度データのリスクと似たこのずれは、データの誠実さとチームが公然と協働する意志の両方を損ないます。
私たちの収束する信号が不一致のとき、たとえば高い提供速度だが上昇する欠陥率のとき、私たちは何を結論づけ、私たちのプロセスはその不一致をうまく扱っているでしょうか。信号間の不一致はそれ自体が価値ある情報です。あなたのチームが現在それを無視すべきノイズとして扱っているか、調査する価値のある本物の発見として扱っているかを話し合ってください。

業種別の視点

スタートアップ。 パフォーマンスは通常直接見えます。その機能は機能したか、顧客はそれを採用したか、指標は動いたか。正式な複数信号の測定は、この規模では通常不要です。危険なのは代わりに、功績や責任がめったに一人の個人だけのものではない、速く動く非常に協働的な小さなチームにおいて、成功や失敗を一人に対してあまりにも速く帰属させることです。

中小企業。 維持する余力のない正式な複数信号の計測基盤を構築するのではなく、すでに持っている提供と品質のデータ(トピック2.10、トピック5.1)を、最近の仕事が実際にビジネスを助けたかどうかについての直接で正直な会話と組み合わせてください。

企業。 ここでこそチームレベルの複数信号測定の規律がその投資の価値を発揮します。パフォーマンスを数十のチームにわたる単一の比較可能な数字に縮小するプレッシャーがここで最も強く、偽りの精密さからの損害が組織全体の資源配分の決定にわたって積み重なるからです。そのプレッシャーに明示的に抵抗し、それが重要である理由についての複数信号の主張を構築してください。

政府。 エンジニアリング投資が単に成果物を届けただけでなく本物の成果を生み出したことを示すことは、しばしば監督機関が尋ねる中心的な問いです。提供のみの代理ではなく成果指標(トピック5.3)に明示的に結びついた複数信号のパフォーマンス測定は、活動や提供の件数だけよりもはるかに強く、より擁護可能な答えを与えます。

事例

企業。 ある小売技術企業の指導層は、スプリントあたり完了したストーリーポイントでエンジニアリングチームを非公式にランク付けし、これをパフォーマンスの代理として扱っていました。提供データ、変更失敗率、リリース後の機能採用を組み合わせた複数信号のアプローチを採用した後、指導層は、最も高いストーリーポイント完了率を持つチームが、会社の中で最も低い機能採用率を持っていたことを発見しました。彼らは速く出荷していましたが、顧客が使わないものを構築していたのです。誤解を招く単一の数字のランク付けではなく、より完全なパフォーマンスの全体像に基づいてそのチームのロードマップの優先順位を再配分することで、1四半期以内に大きなエンジニアリング容量がより高いインパクトの仕事へと方向転換されました。

政府。 ある国税庁のエンジニアリングプログラムは、監督委員会に、大きなシステム投資が契約された範囲を単に届けただけでなくパフォーマンスを改善したことを示す必要がありました。ストーリーポイントやマイルストーンの完了だけを報告するのではなく、このプログラムは収束する一連の信号を提示しました。処理エラー率の減少、処理時間の中央値の減少、そして届けられた特定のシステムコンポーネントに結びついたセルフサービス完了率の成功の増加です。この複数信号の成果に結びついた発表は、前年の以前のプログラムからの単純な「予定どおりに届けられた」という報告が失敗していたやり方で、委員会の精査を満たしました。

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

偽りの精密さのある単一の数字ではなく収束する成果に結びついた信号を通じてパフォーマンスを測定することからの見返りは、より良い資源配分の決定です。どのチームの仕事が本当に成果を動かしているかを見られる組織は、重要な場所にさらに投資し、そうでない場所を調査できます。たまたま最も忙しそうに見えるチームを報いるのではなくです。上記の小売の例は典型的です。誤解を招く単一の数字のランク付けは、実際に役立ったであろう場所から投資の注意をそらしていたのです。

総所有コストは単一指標のアプローチよりも高いものです。なぜなら、複数の情報源(提供、品質、成果)からのデータを組み合わせ、その全体像を一つの比較可能な数字に縮小しようとする組織的なプレッシャーに抵抗する必要があるからです。そのコストは支払う価値があります。なぜなら代替案、偽りに精密な単一のスコアは、パフォーマンスのデータが情報を与えるはずの資源配分の決定を積極的に誤導するからです。

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

活動をパフォーマンスと混同する。 この次元が特に防ぐように設計された最も一般的な誤りです。
協働的でチームを横断した成果についての個人のパフォーマンス帰属。 通常は協働を阻害する偽りの精密さです。
パフォーマンスの定義から品質を除外する。 出荷されるが他の何かを壊す仕事を報います。
プラットフォームチームやイネーブリングチームに直接成果の指標を押しつける。 本質的に間接的な仕事に対して間違ったものを測定します。
組織的なプレッシャーのもとで複数の収束する信号を一つの偽りに精密な数字に縮小する。 複数信号のアプローチが提供するために構築された誠実さを失います。
パフォーマンスのデータを個人の競争的なランク付けに使う。 データの誠実さとチームの協働の両方を損ないます。

成熟度モデル

レベル1、開始: パフォーマンスは活動やアウトプット量と混同されており、単一の検証されていない数字で測定されています。
レベル2、発展: いくつかの品質の信号がアウトプットと一緒に考慮されていますが、一貫した複数信号のアプローチはなく、個人への帰属は今も非公式に起きています。
レベル3、標準化: パフォーマンスは、品質を含む複数の収束する信号を使って、組織全体で一貫してチームレベルで測定されています。
レベル4、管理: 収束する信号間の不一致が能動的に調査され、プラットフォームチームやイネーブリングチームは、彼らの実際の仕事に合った適切に間接的なパフォーマンスの測定を持っています。
レベル5、最適化: パフォーマンスのデータが資源配分と投資の決定に直接情報を与え、組織は、複数信号の見方が可能にし、単一の数字の見方では見逃していたであろう具体的な再配分の決定を指し示すことができます。

議論のためのアイデア

私たちが現在パフォーマンスの代理として使っている単一の数字で、収束する信号の集合に置き換えるために廃止すべきものは何でしょうか。
帰属が不明確だったために、ある成果を間違ったチームや人に帰属させたことがあるでしょうか。
私たちは現在、プラットフォームチームやイネーブリングチームのパフォーマンスをどう測定しているでしょうか。
もし来四半期、私たちの収束する信号が互いに不一致だったら、それはどのようなものになるでしょうか。
ストーリーポイントや提供件数のランク付けが、私たちの投資の注意をどこで誤導したでしょうか。

主な要点

パフォーマンスは、どれだけの動きが起きたかではなく、仕事が良い成果を生み出したかどうかを測定します。それを活動(トピック3.4)と混同しないでください。
決して単一のパフォーマンスの数字ではなく、複数の収束する信号を使い、偽りの精密さを疑ってください。
チームやシステムのレベルで測定してください。個人の成果への帰属は通常信頼できず、協働を損ないます。
品質はパフォーマンスの一部であり、別個の切り離された関心事ではありません。
プラットフォームチームやイネーブリングチームには、彼らの仕事に合わない直接成果の指標を押しつけるのではなく、適切に間接的なパフォーマンスの測定を与えてください。

参考文献とさらなる読書

Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity,” ACM Queue (2021)。
Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。
Team Topologies, Matthew Skelton、Manuel Pais 著。
Measuring and Managing Performance in Organizations, Robert D. Austin 著。