例: 決済プラットフォームチームの指標憲章
指標憲章の具体例です。トピック1.4、指標のガバナンスとオーナーシップで 説明した1ページの文書にあたります。要点はその形です。明示された目的、はっきりした非目標、名前のあるオーナー、 レビューの周期。これだけ短い憲章は、ファイルにしまうためではなく、読まれるためのものです。
- チーム: 決済プラットフォーム
- オーナー: プラットフォームエンジニアリングマネージャー
- レビュー: 四半期ごと、プラットフォームレビューで
目的
この憲章は、決済プラットフォームチームが自らのデリバリーと信頼性について追跡する指標を管理します。 チームの内外の誰もが、何が測られ、なぜ測られ、何のために使われないのかを見られるようにするために存在します。
追跡するもの
| 指標 | 信頼できる情報源 | オーナー |
|---|---|---|
| デプロイ頻度 | CI/CDパイプライン | プラットフォームリード |
| 変更のリードタイム | Gitとデプロイパイプライン | プラットフォームリード |
| 変更失敗率 | インシデントトラッカー、デプロイごとにタグ付け | オンコールリード |
| 失敗したデプロイからの復旧時間 | インシデントトラッカー | オンコールリード |
| P99 APIレイテンシ(SLI) | オブザーバビリティ基盤 | SREリード |
| エラーバジェットの消費 | オブザーバビリティ基盤 | SREリード |
非目標
これらの指標は、単独でも組み合わせでも、エンジニアのランク付け、人事評価の査定、あるいは範囲、人員、システムの成熟度も比較せずに このチームを他チームのロードマップと比べるために使われることはありません。上に述べた目的以外の使用には、 エンジニアリングディレクターとチーム自身の承認が必要です。
ガードレール
上のインセンティブを伴う指標はすべて、ガードレールと組み合わせてあります。変更のリードタイムは変更失敗率と併せて監視され、 チームがよりリスクの高い変更を出荷して速度の数字を良くすることはできません。デプロイ頻度は、同じ理由でエラーバジェットの消費と併せて監視されます。
レビューの周期
チームはこの憲章を四半期ごとにレビューします。連続する2四半期のあいだ、どの判断も変えなかった指標は、引退の候補です。