1.0 第1部序論：測定の基礎
本書が具体的な指標を一つでも挙げる前に、もっと難しい問いに答えなければなりません。測定とは、そもそも何のためにあるのでしょうか。ダッシュボードを作ったことのあるチームは、やがて必ず、ある数字は改善しているのに、それが本来表すはずだったものが悪化していく場面を目にします。これはツールの不具合ではありません。本パートが扱う基礎を飛ばしたことの、予測可能な結果です。そもそもなぜ測定するのか、ある数字が見られていると人々が知った瞬間に何が起きるのか、活動よりも成果をどう重視するか、ある数字とその定義を誰が所有するのか、データは実際どこから来るのか、そして自分自身を欺くことなくノイズの多い信号をどう読み解くか。
大規模なチームにとって、これらの基礎はもはや任意のものではなくなります。単一のチームであれば、マネージャーが週に一度ちらりと見るだけの場当たり的な数字でも何とかなるかもしれません。しかし、数百人のエンジニアと数十のダッシュボードを抱え、上層部に報告する責任を負う組織では、そうはいきません。その規模になると、所有者が不明確だったり定義が不十分だったりする指標は、一つのチームを誤導するだけでは済みません。その数字をどう作られたか確かめもせずに信頼している、下流のすべての人を誤導するのです。そして、一度行動がその数字を操作することに適応してしまえば、それを元に戻すのは高くつきます。
企業や政府機関は、この問題をとりわけ切実に感じます。なぜなら、そこでの指標は、作成したチームを超えた結果をもたらすことが多いからです。予算の決定、公開される業績報告、監査の指摘事項、ベンダー契約。社内エンジニアリングの便宜的な道具に見える指標が、気づかないうちに、その数字を生み出したパイプラインを一度も見たことのない人々による決定にとって、疑われることのない重要な入力になってしまうこともあります。基礎を正しく整えることこそが、その重みを耐えうるものにするのです。
本パートの各トピック
- 1.1 なぜソフトウェアエンジニアリングを測定するのか： そもそも測定する理由、測定が達成すべきこと、そして学ぶための測定と評価するための測定の違い。
- 1.2 グッドハートの法則と指標の心理学： 本書の他のすべてのトピックを支配するただ一つの考え方。測定が目標になった瞬間、それは良い測定ではなくなるということ、そして人々が見られていると知った途端にほぼ必然的に操作が起きる心理的な仕組み。
- 1.3 産出より成果を：何を測定するかを選ぶ： 古典的なインプット・アウトプット・成果の区分と北極星パターンを使って、指標群の重みを活動ではなく成果へと寄せる方法。
- 1.4 指標のガバナンスと所有権： 何を測定するかを誰が決め、定義を誰が所有し、指標チャーターがどのように肥大化するダッシュボードを説明責任のない無秩序な状態から守るか。
- 1.5 データソースと計測基盤： エンジニアリング指標が実際どこから来るのか、計測と自己申告の違い、そして誰も気づかないうちにダッシュボードを静かに無効化してしまうデータ品質の問題。
- 1.6 エンジニアリング指標のための統計リテラシー： チームが指標を誠実に読み解くために必要な最低限の統計的判断力。パーセンタイルと平均の違い、サンプルサイズ、平均への回帰、交絡変数。
各トピックのつながり
これら6つのトピックは、厳密な順序で積み上がっています。トピック1.1はそもそもなぜ測定するのかを問いますが、これが重要なのは、この問いに答えていないチームは誰も行動に移さない数字を集めるだけになってしまうからです。トピック1.2は本書の残り全体が回転する軸です。どんな測定も目標になり得て操作され得ると認めた瞬間から、以降のすべてのトピックの推奨事項は、その危険性に対抗する設計から導き出されます。トピック1.3は、その警戒心を前向きな規則へと変えます。成果に重みを置くこと、なぜなら成果は安く操作することが最も難しいカテゴリーだからです。トピック1.4はガバナンスを具体化し、トピック1.5はデータを具体化し、トピック1.6は、ガバナンスと計測基盤が健全になった後でも、ノイズに惑わされないための統計的な判断力を与えます。
下流のすべてはこのパートに依存しています。第2部のフロー指標とDORA指標、そして第3部のSPACEフレームワークは、実質的にはすべて、トピック1.2とトピック1.3で示された成果重視とガードレール対の原則の具体例です。トピック8.1のダッシュボード設計の指針は、トピック1.4のガバナンスモデルを前提としています。そして本書の各トピックの末尾を締めくくる成熟度モデルは、その5段階の奥底において、まさに本パートが導入する規律そのものの成熟度モデルです。本気で測定し、自分の仕事を検証すること。