1.1 なぜソフトウェアエンジニアリングを測定するのか

概要と動機

ソフトウェアエンジニアリングは、製造業とは違う形で測定に抵抗します。工場のラインは同一の製品を生み出すので、その数を数えれば何か実質的なことがわかります。しかしソフトウェアの仕事は、絶えず変化する要件のもとで一品ものの成果物を生み出すため、コミット数、行数、クローズしたチケット数といった素朴な数え方は、提供された価値についてほとんど何も教えてくれません。ソフトウェアの仕事を測定することの難しさと、物事がうまく進んでいるかどうかを知りたいという切実な必要性との間にあるこの隔たりこそ、本書全体が存在する場所です。本トピックはその隔たりを誠実に埋めることについて扱います。ソフトウェアの仕事を部品のように数えられるものだと装うのではなく、測定がエンジニアリング組織にとって何ができて何ができないのかを正確に見極めることによってです。

測定は、組織が自信を持って他に答えられない問いに答えるために存在します。私たちの提供速度は速くなっているのか遅くなっているのか、品質は改善しているのか悪化しているのか、エンジニアは燃え尽きていないか、この投資は報われているのか。メトリクスがなければ、こうした問いにはその場で最も自信ありげに話す人、たいていは最も上位の、あるいは最も説得力のある人が答えることになり、その答えはしばしば間違っています。測定を省くソフトウェアエンジニアリングのチームは、自らの成果について判断を下すこと自体を避けるわけではありません。ただ、証拠の代わりに、雰囲気や逸話、直近の出来事への偏った重視にもとづいてその判断を下すだけなのです。

大規模なチームにとって、これはあれば望ましいものではなく、構造的に必要なものになります。6人のチームなら、日々の会話を通じて状況についての共通理解を持てます。タイムゾーンや事業部にまたがる600人の部門では、それはできません。その規模では、共有され信頼された数字こそが、小さなチームがただで得られる非公式な状況把握の、唯一の実用的な代替手段です。企業のリーダーシップは、同じ予算を奪い合う数十のチームへ投資を配分するためにメトリクスを必要とします。政府のエンジニアリング組織は、充当された予算が単なる活動ではなく実際の能力を生み出したことを議会や国民に示すためにメトリクスを必要とします。どちらの場においても、「私たちは一生懸命働きました」は証拠にはなりません。擁護可能な数字こそが証拠になります。

重要な原則

判断するためではなく、学ぶために測定する。 エンジニアリングメトリクスの第一の目的は、決定に情報を与えることであり、人やチームに点数をつけることではありません。
決定が結びついていない数字は装飾にすぎない。 あるメトリクスの読み取り結果が次に何をするかを変えないのであれば、それはダッシュボードに載せる価値がありません。
測定は手段であり、目標そのものではない。 目標は、持続可能なチームによって、より確実に届けられる、より良いソフトウェアです。メトリクスはその目標に奉仕するためだけに存在します。
すべてのメトリクスにはコストがかかる。 計測基盤、レビューにかかる時間、そしてトピック1.2で扱う行動のゆがみのリスク、これらはすべて何らかのコストを伴います。メトリクスはそのコストを埋め合わせなければなりません。
沈黙もまた一つの決定である。 何かを測定しないことを選ぶのは、結果を伴う選択であり、中立的な既定値ではありません。

推奨事項

ダッシュボードではなく決定から始める

何かを計装する前に、そのメトリクスが情報を与えるはずの決定に名前をつけてください。「新しいデプロイパイプラインがインシデント率を下げたかどうかを知りたい」は決定の形をした問いですが、「ツールがエクスポートできるものすべてを追跡しよう」はそうではありません。決定から逆算して考えることで、メトリクス群は小さく保たれ、誰かがなぜそれが存在するのかと尋ねたときに、どのタイルも擁護可能なものになります。あるメトリクスが情報を与えるはずの決定に名前をつけられないなら、まだそれを構築しないでください。この、産出よりも成果を重視する規律については、トピック1.3でさらに掘り下げます。

診断的な利用と評価的な利用を分ける

システムの問題を診断するために使われるメトリクス(なぜ私たちのリードタイムが徐々に伸びているのか)は、人やチームを評価するために使われる同じメトリクスとはまったく違う振る舞いをします(誰のリードタイムが最も悪いか)。前者は調査と改善を促します。後者は隠蔽と操作を促します。なぜなら、その数字には今や評判上あるいは金銭上の結果が結びついているからです。あるメトリクスがどちらの用途のためのものかを、明示的に、文書として決めてください。そして、診断用のメトリクスが、リスクを意図的に再検討することなく評価的な利用へとずるずると移っていくのを決して許さないでください。この区別は本書を通じて繰り返し登場し、トピック1.4で説明する指標チャーターの非目標セクションで公式化されます。

測定を事実ではなく仮説として扱う

メトリクスは、あなたが本当に気にかけている何かの代理であり、その何か自体ではありません。デプロイ頻度は提供能力の代理であって、提供能力そのものではありません。すべてのメトリクスを、継続的に検証され続ける仮説として扱ってください。この数字は今も私たちが気にかけているものを追跡しているのか、それとも世界が変わってしまい、代理指標だけが取り残されてしまったのか。この問いを固定された頻度で見直すようにし、2年前にうまく選ばれたメトリクスが今日もうまく選ばれたままだと決めてかからないでください。特にツール、チーム構造、あるいは(第7部を参照)仕事そのものの性質が変化する中では、なおさらです。

測定していないことを可視化する

大規模な組織において、最も危険な隙間は悪いメトリクスではなく、計装が難しいという理由で誰も測定していない領域です。開発者体験、チーム間の依存関係の摩擦、組織的知識の消失。こうした隙間は、既定で見えないままにしておくのではなく、指標チャーターの中で明示的に名指ししてください。自分たちが何を測定していないのか、そしてなぜなのかを知っている組織は、そうした領域が存在すること自体を静かに忘れてしまった組織よりも、はるかに強い立場にあります。

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

アプローチ	長所	短所
重厚な計装、多数のメトリクス	広範な可視性、死角が少ない	ダッシュボード疲れ、操作の対象面が広がる、保守コストが高い
最小限の、決定駆動のメトリクス	焦点が明確、オーバーヘッドが低い、どのメトリクスも擁護可能	選ばれた集合の外側で生じる問題を見逃すリスク
診断専用のメトリクス	誠実な報告と調査を促す	経営陣が非公式に評価的に使ってしまう可能性が残る
個人評価に結びついたメトリクス	説明責任があるように感じられ、経営層への説明が容易	強い操作のインセンティブ、信頼の毀損、たいてい間違ったものを測定してしまう

中心にある緊張関係は網羅性と焦点の間にあり、それは診断と判断の対立によってさらに鋭くなります。メトリクスが少なすぎると、危機として表面化するまで気づかれない死角ができます。多すぎると、誰もそのどれにも基づいて行動できなくなり、しかも評価的な重みを付けたメトリクスのすべてがゆがみを招きます。これを解決するには、最小限で決定駆動の状態から始め、特定の名指しされた決定がそれを必要とするときだけメトリクスを追加し、トピック1.4のガバナンスの仕事の中で診断専用の境界線を既定で崩れるに任せるのではなく明示的に守ることです。

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

現在のダッシュボードにある各メトリクスについて、良い読み取り結果と悪い読み取り結果はそれぞれどんな決定を引き起こすでしょうか。 どちらの読み取り結果も同じ行動、あるいはまったく行動を起こさないことにつながるなら、そのメトリクスは装飾です。ダッシュボードをタイルごとに見て、それぞれについて正直な答えを強制してください。この演習は、たいてい一度座るだけで肥大化したダッシュボードを半分にまで減らします。なぜなら、ほとんどの膨張は、今も理由のあるものとして誰かが意図的に追加したメトリクスからではなく、誰も取り除かないメトリクスから蓄積するからです。
私たちのメトリクスのうち、どれが診断的に使われており、どれが静かに評価的になってしまったでしょうか。 システムの制約を理解するために構築されたメトリクスが、誰も意図的にそう決めたわけでもないのに、チームや個人をランク付けするために使われるようにずれていくことがあります。しばしば、それはレビュー会議での何気ない一言が習慣になることから始まります。一度そのずれが起きると、その数字はもはや信頼できるものではなくなります。なぜなら、人々にはもはや正確にする理由ではなく、見栄えを良くする理由があるからです。すべてのメトリクスの意図された用途を文書として書き留め、現在の運用をそれと照らし合わせてください。
計装が難しいために測定していないことは何で、その隙間は私たちにどれだけの代償を払わせているでしょうか。 最も危険な死角は、まさに簡単には測定できないという理由でダッシュボードに決して載らないものです。チーム間の依存関係の摩擦、組織的知識の消失、あるいは脆い回避策の静かな蓄積。誰もが内心では心配しているのに誰も追跡していないものの一覧を持ち寄り、なぜそうなっているのかを正直に見つめてください。
もし明日このメトリクスを削除したら、誰が気づき、何を失うでしょうか。 誰も惜しまないメトリクスは、どんな決定にも情報を与えていないメトリクスです。この問いは、純粋に惰性だけで生き残っている見栄えだけのタイルを浮かび上がらせます。数十のチームダッシュボードを抱える大規模な組織にとって、この刈り込みの規律は、そもそも新しいメトリクスを追加する規律と同じくらい重要です。
ダッシュボード上の各メトリクスを作成し維持するのに、計装の背後にあるエンジニアリング時間も含めて、実際にどれだけの費用がかかっているでしょうか。メトリクスは無料ではありません。パイプライン、ダッシュボード、そしてある数字について議論するのに費やされるレビュー時間、これらすべてが繰り返し発生するコストを伴いますが、それは一つの目に見える項目としてではなく、多くの小さな作業に分散しているために過小評価されがちです。実際の計装と保守の労力を持ち出し、問い1で得た決定の価値と比較してください。
測定が判断の代わりになってしまっている場所、そして判断が測定の代わりになってしまっている場所はどこでしょうか。 どちらの失敗モードも現実に存在します。すべての決定をダッシュボードに外注してしまうチームは、その数字が見逃すものを捉える文脈的な判断力を失います。入手可能なデータを無視し、その場で最も声の大きい人の意見を優先するチームは、本トピックの冒頭で述べたまさにその問題を繰り返します。目指すべきは、判断に情報を与えるメトリクスであって、判断を置き換えるメトリクスではありません。

業種別の視点

スタートアップ。 数名のエンジニアであれば、本トピックが警告するもののほとんど、評価的な利用へのずれ、死角、ダッシュボードの肥大化は、誰もが日々話しているという理由だけで簡単に避けられます。危険なのはむしろ逆で、チームが負担できないオーバーヘッドのように感じて、測定そのものを完全に省いてしまうことです。決定の形をした問いを2つか3つ選び(十分な速さで提供できているか、品質は保たれているか)、それだけを計装してください。

中小企業。 専任のプラットフォームチームやデータチームがなければ、独自の計装を構築するのではなく、既存のツールがすでに報告しているものに頼ってください。決済処理業者のダッシュボード、サポートツールの応答メトリクス、CIプロバイダのビルド履歴は、たいてい最も重要な決定をカバーしています。それが伝えてくれることに基づいて行動すると証明できるようになる前に、専用のエンジニアリング分析プラットフォームを購入する誘惑には抵抗してください。

企業。 中心的なリスクは、管理階層を通じて積み上がっていく中で、メトリクスが診断的な利用から評価的な利用へと静かにずれていくこと、そして刈り込みの仕事を誰も所有していないためにダッシュボードが堆積によって肥大化していくことです。この規模ではガバナンス(トピック1.4)は任意ではありません。事業部を横断して定義を標準化し、指標プログラムそのものに定期的な廃止レビューを組み込んでください。

政府。 ここでのメトリクスはしばしば法定または予算上の重みを持ち、それが正しく行うことの価値と、間違えることのコストの両方を高めます。議会や監督機関に報告される数字には、文書化された方法論、報告期間を通じた安定した定義、そしてその限界についての誠実さが必要です。「現在これは測定していません」を、隠すべき個人的な欠陥としてではなく、擁護する必要があるかもしれない一つの答えとして扱ってください。

事例

企業。 あるグローバル保険会社のエンジニアリング組織は60を超えるスクラムチームにまで成長しており、それぞれが独自の非公式なダッシュボードを持ち、どれも互いに比較できませんでした。経営陣は基本的な問いに答えられずにいました。10件の戦略的プラットフォーム投資のうち、実際により速いソフトウェア提供を生んでいるのはどれか。解決策はメトリクスを増やすことではなく、より少なく、より良いものにすることでした。この組織は同じパイプラインデータからどこでも同一に計算される、共有された決定駆動のDORAメトリクス(トピック2.10)の核を定義し、チーム固有のダッシュボードを40件廃止し、2四半期以内についに共通の基盤で投資領域を比較できるようになりました。

政府。 ある国税庁のデジタルサービスチームは、監督委員会から複数年にわたる近代化プログラムの投資対効果を示すよう求められました。このチームの既存のメトリクスは完全に内部向けで活動ベースのものでした。完了したストーリーポイント、クローズしたスプリント。そのどれも委員会の実際の問いには答えていませんでした。チームは代わりに小さな成果メトリクス群を構築しました。市民の申請問題を解決するまでの中央値時間、デジタルチャネルの採用率、そして新システムにおける流出欠陥率です。そしてそれらを文書化された方法論とともに四半期ごとに報告しました。委員会の問いは「働いていることを証明せよ」から「どうすればこれを次の省庁でも再現できるか」へと変わりました。これこそ、うまく選ばれたメトリクス群が生み出すべき成果です。

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

意図的な測定からの見返りは、決定の質です。「プラットフォームへの投資後、リードタイムが30%改善した」と証拠とともに言える組織は、その投資を擁護し、うまくいったことを繰り返し、うまくいかなかったことをやめることができます。逸話に頼る組織はそのどれも自信を持って行うことができず、どちらの側も信頼する数字を誰も指し示せないために、予算サイクルのたびに同じ議論を蒸し返すことになります。

測定のコストはダッシュボードではありません。それは継続的な規律です。計装、定義の保守、そして本トピックが推奨する定期的な刈り込み。その総所有コストは現実のものですが、大規模な組織がその場で最も説得力を持って論じた人に基づいて数百万ドル規模の技術決定を下すという、代替案のコストに比べればささやかなものです。指標プログラムからの見返りは、メトリクスそのものではありません。それによってより良く下されるようになった決定なのです。

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

ツールがエクスポートするものすべてを測定する。 ダッシュボードをノイズに変え、対応する決定の価値が何もないまま、巨大な対象面全体で操作を招きます。
名指しされた決定のないメトリクス。 保守の労力を費やすだけで、誰にも行動可能な何かを伝えない装飾です。
診断的な利用から評価的な利用への静かなずれ。 ある数字への信頼を破壊する、最も速い単一の方法です。
メトリクスを仮説ではなく事実として扱う。 2年前には正しかった代理指標が今日は間違っているかもしれず、誰もそれを確認していません。
悪い数字が存在しないことと、良い数字が存在することを混同する。 一度も見られることのないメトリクスは、何かが間違っていることを教えてはくれません。
何を決めるかを決める前に測定能力を構築する。 問いを探し求める計装は、本物のエンジニアリング時間を無駄にします。

成熟度モデル

レベル1、開始: メトリクスは、そもそも存在するとしても場当たり的で、作った人個人のものであり、それらのどれがどんな決定に情報を与えているのか誰も言えません。
レベル2、発展: いくつかのチームには基本的なメトリクス群が存在しますが、ほとんどはフレームワークやツールの既定値をそのまま写したものであり、決定へのはっきりしたつながりはありません。
レベル3、標準化: 追跡されるすべてのメトリクスに文書化された目的と、診断的か評価的かの明示的な分類があり、それが組織全体で一貫して適用されています。
レベル4、管理: メトリクスは、それが情報を与える決定に照らして固定された頻度でレビューされます。もはや役に立たなくなったメトリクスは廃止され、メトリクス群全体がその価値だけでなくコストについても測定されます。
レベル5、最適化: 測定は生きた能力です。組織は自らの死角を日常的に特定し、自らの代理指標が今も現実を追跡しているかを検証し、指標プログラムそのものを、ただ維持するだけのものではなく改善すべきものとして扱います。

議論のためのアイデア

今日尋ねられたら、保持する理由を最も説明しづらいメトリクスはダッシュボード上のどれか。
直近の四半期で、意見ではなくメトリクスを使って下した決定は何か。
私たちの組織のどこで、診断的なメトリクスが静かに評価的になったか。
私たちは何を測定することを恐れているのか、そしてなぜか。
もし明日指標プログラムが消えてしまったら、どの決定が悪化するか。

主な要点

測定は決定に奉仕するために存在し、それ自体のために存在するのではありません。決定が結びついていないメトリクスは装飾です。
診断的な利用と評価的な利用を文書として分け、両者の間での静かなずれに注意してください。
すべてのメトリクスを、それが表すものについての仮説として扱い、確定した事実としてではなく、一定の頻度でその仮説を見直してください。
沈黙、つまり何かを測定しないという選択は、それ自体が結果を伴う一つの決定です。死角を既定で見えないままにしておくのではなく、可視化してください。
指標プログラムの総コストは現実のものです。各メトリクスが提供する決定の価値と、明示的に比較検討してください。

参考文献とさらなる読書

Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。
How to Measure Anything, Douglas W. Hubbard 著。
Measuring and Managing Performance in Organizations, Robert D. Austin 著。
Thinking, Fast and Slow, Daniel Kahneman 著。
Google の DevOps Research and Assessment (DORA) プログラム、dora.dev。