1.5 データソースと計測基盤

概要と動機

メトリクスは、その下にあるデータと同じだけしか信頼できません。そして、ほとんどの指標プログラムは、それに供給されるパイプラインを検証するよりも、はるかに多くの労力をダッシュボードの設計に費やしています。これは順序が逆です。一貫性のない、自己申告の、あるいは静かに壊れた計測基盤の上に美しく設計されたグラフは、まったくグラフがないよりも悪いものです。なぜなら、それは間違っているのに権威があるように見えるからです。本トピックは、本書の残り全体が前提とする、華やかさのない基盤について扱います。エンジニアリングデータが実際どこから来るのか、いつ自己申告よりも自動化された計測基盤を信頼すべきか、そして誰も気づかないうちにメトリクスを静かに無効化してしまうデータ品質の失敗についてです。

ソフトウェアエンジニアリングのデータは一握りの情報源の種類から来ており、それぞれ異なる信頼性の特徴を持ちます。バージョン管理とCI/CDパイプラインは、実際に何が起きたかについての客観的で、タイムスタンプ付きの、偽造しにくい記録を生成します。課題追跡システムやプロジェクト管理ツールは、人間が状態を正確かつ迅速に更新することに依存した記録を生成しますが、それはしばしば一貫性を欠きます。アンケートは、満足度のようにどんなシステムも観察できないものにとって貴重な自己申告データを生成しますが、想起バイアスや社会的望ましさの効果を受けます。オブザーバビリティ・プラットフォームは、客観的ではあるものの、計測されたものしかカバーしないシステムレベルのテレメトリを生成します。あるメトリクスのデータがどのカテゴリーから来ているかを知ることは、それをどれだけ信頼すべきか、そしてどんな失敗モードに注意すべきかを教えてくれます。

企業や政府の規模においては、データの出所とダッシュボードでの最終的な利用との間の距離が、複数のシステム、統合、変換を通じて広がるため、データ品質の問題は増幅します。ソースシステムではある意味を持つフィールドが、報告層に届く頃には微妙に異なる意味を持つようになることがあり、下流の誰もそれに気づきません。なぜなら、その数字は今もそれらしく見えるからです。計測基盤を正しく整えることは、フレームワークを正しく整えることほど刺激的ではありませんが、それは本書の他のすべてが立脚する基盤です。

重要な原則

システムがイベントを直接観察できる場所では、自己申告よりも計測基盤を優先する。 パイプラインからのデプロイのタイムスタンプは、チームが自己申告するデプロイ件数よりも信頼できます。
自己申告は、直接観察できないもののためだけに使う。 満足度、知覚された摩擦、幸福感には記録システムの代替がありません。直接尋ね、アンケートをうまく設計してください(トピック3.7)。自己申告はそのカテゴリーのためだけにとっておいてください。
すべてのメトリクスのデータには、ソースシステム、収集方法、既知の失敗モードがある。 定義だけでなく、この三つすべてを文書化してください。
データ品質は静かに劣化する。 1年前は正しく機能していたパイプラインが、今日は静かに壊れているかもしれず、ダッシュボードは文句も言わずに間違った数字を表示し続けます。
変換の下流ではなく、真実の地点で計測する。 イベントとダッシュボードの間のあらゆるホップは、意味がずれていく機会です。

推奨事項

信頼する前に、すべてのメトリクスを実際のソースシステムに対応づける

ダッシュボード上の各メトリクスについて、根底にあるイベントを生成する具体的なシステムを名指ししてください。デプロイイベントのためのCI/CDパイプライン、コミットとマージイベントのためのバージョン管理ホスト、停止記録のためのインシデント追跡システム、自己申告の満足度のためのアンケートプラットフォーム。正確なシステムを名指しできないなら、その数字が実際どこから来ているのか本当は知らないのであり、その信頼性を評価することはできません。この対応づけはトピック1.4のガバナンスチャーターの前提条件であり、別個の演習ではありません。

報告時点ではなく、イベント時点で計測する

最も信頼できるデータは、イベントが起きた瞬間に自動的にそれを捉えます。パイプラインは完了した瞬間にデプロイを記録し、バージョン管理システムは着地した瞬間にマージを記録します。人間が後でステータス欄を更新するのを覚えていること、チケットを「完了」とマークすること、スプレッドシートに手動でデプロイを記録することに依存するデータは、実際のイベントから離れるほど、そして責任者が忙しくなるほど、精度が低下します。自動化されたイベントが存在する場所では、同じ事実について人間が報告する代理よりもそれを優先してください。

アンケートは人にしか教えてもらえないことのためにとっておく

本当にシステムのテレメトリからは観察できないものがいくつかあります。エンジニアが自分の仕事を意味のあるものだと感じているか、あるプロセスが苛立たしいと感じられているか、燃え尽きのリスクが高まっているか。これらは直接尋ねる必要があり、よく設計されたアンケート(トピック3.7がその仕組みを扱います)が正しい道具です。間違いは、代わりにシステムが直接観察できたはずのもののために自己申告を使うこと、パイプラインから引き出す代わりにエンジニアに自分自身のデプロイ頻度を見積もらせることです。これは客観的でありえたデータに不必要なノイズとバイアスを持ち込みます。

データ品質チェックをパイプラインそのものに組み込む

メトリクスのパイプラインを、本番コードと同じ厳格さで扱ってください。あるソースがデータの送信を止めたとき、あるフィールドの分布が予期せずずれたとき、あるいは件数が予期せずゼロに落ちたときに旗を立てる自動チェックを追加してください。古くなった、あるいは壊れたデータを現在のものであるかのように静かに表示するダッシュボードは、「データが利用できません」と目に見える形で示すダッシュボードよりも悪いものです。なぜなら、前者は信頼を目に見えない形で損なうのに対し、後者は少なくとも自分自身の限界について真実を語るからです。

収集方法を定義とともに文書化する

あるメトリクスの定義(「変更のリードタイム」)は、その収集方法(バージョン管理における最初のコミットのタイムスタンプから、パイプラインにおける本番デプロイのタイムスタンプまでを測定し、ホットフィックスのブランチは除外する)なしには完全ではありません。同じ定義を持ちながら異なる収集方法を持つ二つのチームは、それでも比較不可能な数字を生み出すでしょう。トピック1.4の指標チャーターに両方を記録し、どちらか一方への変更も、同じ文書化されたレビューを必要とする変更として扱ってください。

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

情報源の種類	長所	短所
自動化されたパイプラインの計測基盤(CI/CD、バージョン管理)	客観的で、タイムスタンプ付きで、偽造しにくく、継続的な労力が低い	構築し保守するための前払いのエンジニアリング投資が必要
課題追跡システムとプロジェクト管理データ	広く利用可能で、チームになじみがある	人間の勤勉さに依存し、しばしばチームを横断して一貫性を欠く
アンケートと自己申告	主観的な経験(満足度、幸福感)にとって唯一の情報源	想起バイアス、社会的望ましさバイアス、回答疲れ
オブザーバビリティとテレメトリのプラットフォーム	豊かで、リアルタイムの、システムレベルの信号	明示的に計測されたものしかカバーせず、規模が大きいと高くつきうる

中心にある緊張関係は客観性と網羅性です。自動化された計測基盤は最も信頼できる情報源ですが、主観的な経験をまったく観察できません。一方、アンケートは自動化がまさに到達できない場所に届きますが、本物のバイアスのリスクを伴います。この緊張を解消するには、イベントが直接観察できる場所ではどこでも自動化された計測基盤を使い、自己申告は本当に人に尋ねる必要があるものだけのために特別にとっておき、システムが提供できたはずのデータの怠惰な代替としては決して使わないでください。

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

私たちの最も重要な5つのメトリクスについて、それぞれの正確なソースシステムと収集方法を名指しできるでしょうか。それとも、データが実際どこから来ているかを知らないまま定義を前提としているでしょうか。これは驚くほどよくある隙間です。あるメトリクスがフレームワークやベンダーの既定ダッシュボードから採用され、現在のチームの誰も、根底にあるデータを生成しているシステムがどれで、どのような仕組みかを実際には知らないのです。グループ演習として、それぞれを起源までたどってみてください。
私たちのメトリクスのうち、システムが直接観察できるはずのことについて自己申告に頼っているものはどれで、その自己申告を本物の計測基盤に置き換えるには何が必要でしょうか。自己申告のデプロイ件数、自己申告の労働時間、自己見積もりのサイクルタイムは、自動化がより確実に捉えられるはずのものに間違ったデータソースを使っているよくある例です。これらを特定し、最も賭け金の高いものから置き換えることを優先してください。
私たちのデータパイプラインの一つが静かに壊れたら、私たちはどうやってそれに気づくでしょうか。 ほとんどの組織は、誰かがある数字がありそうもないと気づいたときにだけ、壊れたメトリクスパイプラインを発見します。それには何か月もかかることがあります。現在、あなたのパイプラインのどれかに自動化されたヘルスチェックがあるか、もしないなら、どれが最初に最も必要とするかを話し合ってください。
システム間の変換が、誰も意図的にそう決めたわけでもないのに、メトリクスの意味を変えてしまった場所はどこでしょうか。 ソースシステムではある意味を持つフィールドが、統合や移行の後には微妙に異なる意味を持つことがあり、その結果の数字は間違っているのにそれらしく見えることがあります。最も結果の重いメトリクスの完全なデータ経路をたどり、変換の地点を探してみてください。
私たちの指標チャーターには、定義だけでなく収集方法も文書化されているでしょうか。 二つのチームが同じメトリクスの名前と定義を共有していても、異なる収集方法からそれを計算していれば、実際には比較不可能な数字を生み出すことになります。この特定の隙間について、チャーターのサンプルを監査してください。
ある数字が予期せず動いたとき、私たちは本物の傾向とデータ品質の不具合をどう見分けるでしょうか。 メトリクスの突然の変化は、しばしば本物の変化か壊れたパイプラインかのどちらかの最初の兆候であり、両者を見分けるには、迅速に調査できるだけデータソースをよく知っている必要があります。直近に遭遇した説明のつかないメトリクスの変化について、あなたのチームの実際のプロセスを話し合ってください。

業種別の視点

スタートアップ。 小さなスタックであれば、ほとんどのメトリクスは、カスタムのパイプラインを構築することなく、CI/CDプロバイダ、バージョン管理ホスト、そして軽量なアンケートツールから直接得られます。危険なのは、チームが速く動いているという理由で、基本的なヘルスチェックさえ省いてしまうことです。あるデータソースが今もイベントを送信しているかという5分間の自動チェックは、静かに目隠し状態で飛ぶことに対する安い保険です。

中小企業。 維持する余力のないカスタムデータパイプラインを構築するのではなく、既存のツールの組み込みの報告機能に頼ってください。どの数字が自動化されたシステムから来ていて、どれが誰かがスプレッドシートに打ち込む見積もりなのかを明示してください。たとえ同じページに載っていたとしても、両者はまったく異なる信頼性を持つからです。

企業。 データ品質の問題は、統合、移行、事業部の境界にわたって積み重なります。最も結果の重いメトリクスのために、中央集権的でよく監視されたデータパイプラインに投資し、自動化されたデータ品質チェックを標準的な慣行として構築し、事業部を横断してメトリクスを比較するときはいつでも、定義だけでなく収集方法も監査してください。

政府。 データの来歴は法的あるいは監査上の重みを持つことがあります。公開される業績数値は、その値だけでなく収集の連鎖全体について、外部監査を生き延びる必要があるかもしれません。データ系譜を明示的に文書化し、方法論が変わった後でも過去の収集方法の記録を保持し、ある数字が現在何を示しているかだけでなく、それがどう作られたかを正確に示す準備をしてください。

事例

企業。 ある金融サービス企業のエンジニアリング指導部は、2年間「変更のリードタイム」を追跡していましたが、18か月前のデータパイプラインの移行が、タイムスタンプの情報源を最初のコミットからプルリクエストの作成へと静かに切り替えており、誰も気づかず承認もしないまま、すべてのチームにわたって見かけ上のリードタイムを平均で数時間短縮していたことを発見しました。この修正は、各メトリクスの分布を週ごとに比較し、統計的に異常な変化を人によるレビューのために旗立てするデータ品質チェックを導入し、その後の1年でさらに二つの静かなパイプラインの問題を捉えました。

政府。 ある運輸機関の公開向けサービス信頼性ダッシュボードは、自動化されたセンサーのテレメトリと、地域事務所から手動入力されたインシデント報告の組み合わせに依存していました。監査の結果、人員の少ない地域が体系的に軽微なインシデントを過小報告していたことが判明しましたが、それは不誠実さからではなく、単に手動入力がより緊急の仕事と時間を奪い合っていたためでした。これはつまり、公開された信頼性の数値が、資源不足の保守が見過ごされることを最も許容できない地域において、まさに現実よりも良く見えていたことを意味します。この機関の修正は、可能な限り手動のインシデント入力を自動化されたセンサー起動のログ記録に置き換え、公開される数値とともに手動報告のカバレッジについての文書化された見積もりを加えました。

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

堅実な計測基盤からの見返りは自信です。自分のデータを信頼する経営陣は、それに基づいて決断できますが、静かに壊れたパイプラインに痛い目に遭わされたチームは、あらゆる数字を疑い始め、それがメトリクスに依存するあらゆる決定を遅らせます。その自信の喪失は高くつき、修復が難しく、元の計測基盤への投資にかかったはずのコストよりもはるかに長くかかって再構築されることがよくあります。

優れた計測基盤の総所有コストには、信頼できるパイプラインを構築する前払いのエンジニアリング作業と、データ品質監視の継続的なコストの両方が含まれますが、どちらもそれ自体の目に見えるダッシュボードのタイルを生み出さないため、投資不足になりやすいものです。その投資不足は見せかけの節約です。悪いデータに基づいて何か月もの決定がなされた後に、静かに壊れたパイプラインを発見するコストは、それを初日に捉えていたであろうヘルスチェックを構築するコストよりもはるかに高いのです。

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

ソースシステムを知らないまま数字を信頼する。 フレームワークやベンダーの既定値から採用されたメトリクスで、データが実際どこから来ているのか誰もたどっていません。
システムが直接観察できたはずのことを自己申告する。 客観的でありえたデータに不必要なノイズとバイアスを持ち込みます。
メトリクスのパイプラインに自動化されたデータ品質チェックがない。 静かに壊れたパイプラインは、検出されないまま何か月も間違った数字を表示し続けることがあります。
収集方法ではなく定義だけを文書化する。 同じメトリクス名を持つ二つのチームが、それでも比較不可能な数字を計算していることがあります。
「0」や古いデータを、情報源の失敗の兆候もないまま現在のものであるかのように表示するダッシュボード。 目に見える「データが利用できません」というメッセージよりも悪いものです。
手動入力の負担のために体系的に過小報告する、資源不足の地域やチーム。 まさに最も注意を必要とする領域と相関するデータ品質の隙間です。

成熟度モデル

レベル1、開始: 誰もメトリクスをそのソースシステムまで確実にたどることができず、パイプラインにヘルスチェックはなく、失敗は気づかれずに過ぎていきます。
レベル2、発展: 一部のメトリクスには文書化された情報源がありますが、収集方法は一貫しておらず、データ品質チェックはせいぜい場当たり的です。
レベル3、標準化: 統治されたすべてのメトリクスがそのソースシステムと収集方法を文書化しており、イベントが直接観察できる場所ではどこでも自己申告よりも自動化されたパイプラインが優先されます。
レベル4、管理: 自動化されたデータ品質チェックがすべての結果の重いパイプラインを監視し、異常をレビューのために旗立てし、データ系譜が文書化され監査可能です。
レベル5、最適化: 組織はデータ品質を、それ自体の監視とインシデント対応を備えた第一級のエンジニアリング規律として扱い、公開されたどんなメトリクスについても求めに応じて完全な来歴を示すことができます。

議論のためのアイデア

この会議の場で今すぐ、生で、私たちの上位3つのメトリクスを正確なソースシステムまでたどれるでしょうか。
私たちの現在のメトリクスのうち、システムが直接測定できたはずのことについて自己申告に頼っているものはどれでしょうか。
今日、私たちのメトリクスパイプラインのどれかに自動化されたヘルスチェックがあるでしょうか。
私たちが最後に静かに壊れたデータパイプラインを発見したのはいつで、それはどれだけ長く間違っていたでしょうか。
手動のデータ入力が、報告された現実と実際の現実の間にどこで隙間を生んでいるでしょうか。

主な要点

システムがイベントを直接観察できる場所ではどこでも、自己申告よりも自動化された計測基盤を優先してください。自己申告は本当に主観的な経験のためにとっておいてください。
すべてのメトリクスには、定義だけでなく文書化されたソースシステムと収集方法が必要です。
データ品質は静かに劣化します。偶然壊れていることを発見するのではなく、自動化されたチェックをパイプラインそのものに組み込んでください。
変換の下流ではなくイベント時点で計測し、実際に起きたこととダッシュボードが示すものとの間のずれを最小化してください。
静かに壊れたパイプラインのコスト、つまり悪いデータに基づいて何か月もの決定がなされることは、それを捉えていたであろうヘルスチェックのコストをはるかに上回ります。

参考文献とさらなる読書

Observability Engineering, Charity Majors、Liz Fong-Jones、George Miranda 著。
Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。
Data Quality: The Accuracy Dimension, Jack E. Olson 著。
How to Measure Anything, Douglas W. Hubbard 著。