ソフトウェア開発の現場において、「私たちのチームはどれくらい優秀か？」を正しく測ることは非常に困難です。
書いたコードの行数でしょうか？それとも、こなしたタスクの数でしょうか？
DevOps分野のバイブルである『LeanとDevOpsの科学』では、見せかけの生産性を測ることを否定し、ソフトウェアデリバリのパフォーマンスを正しく計測するための「望ましい尺度の条件」と「4つの具体的な指標（Four Keys）」を提示しています。
今回は、組織を真の高業績へと導くための正しい指標のあり方を解説します。
山脇 弘成（SSAITS代表）
PMP®有資格者・Webプロジェクトマネージャー。
大手メディアや官公庁のWebプロジェクト実績多数。
「技術」だけでなく「対話」を重視し、御社の「ほんとは、こうしたかった」を形にします。
望ましい尺度が備えるべき「2つの条件」
具体的な指標を見る前に、そもそも評価尺度をどう設定すべきかという「2つの大前提」を確認しておきましょう。
「グローバルな成果」に焦点を当てること
特定個人の出力や、特定チームだけの成果を測る指標は、組織内に深刻な対立を生み出します。
例えば、開発チームの目標を「どれだけ多くの新機能を作ったか」、運用チームの目標を「どれだけシステムの安定性を保ったか」と別々に設定したとします。
すると、開発側はとにかくスピード重視で質の悪いコードを運用側に丸投げし、運用側は自分の評価を下げる「システム変更（リリース）」を頑なに拒絶するようになります。
本書ではこれを「混乱の壁」と呼んでいます。この壁を取り払い、開発も運用も協力して達成できる「組織全体のグローバルな成果」を測る指標でなければなりません。
「生産量」ではなく「成果（価値）」に焦点を当てること
「どれだけ忙しく働いたか」「どれだけ大量の作業をこなしたか」という見せかけの作業量（アウトプット）を評価してはいけません。
測定すべきは、その作業が組織の目標達成や顧客への価値提供にどれだけ役立ったかという「本当の成果（アウトカム）」です。
スピードと安定性を測る「4つの指標（Four Keys）」
上記の2条件を満たし、パフォーマンスを「スピード（テンポ）」と「安定性」の双方からバランスよく評価するために、本書では以下の4つの尺度が選ばれています。現在では「Four Keys」と呼ばれ、業界標準となりつつある指標です。
スピードを測る指標
デリバリのリードタイム
顧客の要望から提供までの全期間（リードタイム）のうち、不確実性の高い「設計段階」を除いた、「コードのコミットから本番稼働までの時間」に焦点を当てます。
この製品デリバリのリードタイムが短いほど、市場からのフィードバックを素早く得ることができ、不具合にも迅速に対応できるようになります。
デプロイの頻度
リーン開発では、1度に処理する作業のかたまり（バッチサイズ）を小さくすることが重要視されますが、ソフトウェアは目に見えないためサイズの測定が困難です。
そこで、代わりに「本番環境へのデプロイ頻度」を計測します。デプロイ頻度が高いということは、バッチサイズが小さく保たれ、こまめに価値が提供されている（＝大事故が起きにくい）ことを意味します。
安定性を測る指標
平均修復時間（MTTR）
いくらスピードを上げても、システムがダウンしたままでは意味がありません。予想外の稼働停止やサービス障害などのインシデントが発生した際に、復旧までにどれくらいの時間がかかるか（MTTR：Mean Time To Restore）を計測します。
変更失敗率
ソフトウェアのリリースやインフラ設定の変更を行った結果、本番環境での稼働に失敗し、ホットフィックス（緊急修正）やロールバックなどの追加対応が必要になってしまったケースの発生率です。
指標は「罰する」ためではなく「改善する」ために使う
『LeanとDevOpsの科学』が提唱するこの4つの指標は、単なるコードの行数やシステムの稼働率ではなく、「いかに早く・小刻みに（スピード）、かつ安全に（安定性）顧客へ価値を届けられているか」を正確に浮き彫りにします。
しかし、これらの指標を導入する際、マネジメント層が絶対にやってはいけないことがあります。それは、この数字を使って「成績の悪いチームを罰すること」です。
数字を個人の評価やペナルティに結びつけた瞬間、現場は「バグを隠蔽する」「簡単な作業だけを選んで数字を稼ぐ」といったハック（不正）を始め、指標は全く意味を持たなくなります。
「Four Keys」は、あくまで現在の自分たちのボトルネックを見つけ、継続的改善のプロセスを回すための羅針盤です。評価のためではなく、チームをより良くするためのツールとして、この正しい指標を活用していきましょう。