9.1 用語集
本書全体で使われる用語と頭字語の定義。各項目は、その用語が深く導入されるトピックを示します。
活動指標(アクティビティ・メトリック)。 価値ではなく量を測定する、エンジニアリングの動き(コミット、プルリクエスト、コード行数)の件数。トピック3.4を参照。
インシデント平均確認時間(MTTA)。 インシデントの通知から誰かが対応の所有権を引き受けるまでの時間。トピック6.2を参照。
インシデント平均検知時間(MTTD)。 インシデントの実際の発生から誰かがそれが起きたことに気づくまでの時間。トピック6.2を参照。
インシデント平均復旧時間/平均解決時間(MTTR)。 失敗の後にサービスを完全に復旧させるまでの時間。デプロイによって引き起こされた失敗(トピック2.10)と一般的なインシデント(トピック6.2)の両方に使われます。
エラーバジェット。 サービスレベル目標と100%の信頼性の間の許容される不足分であり、使い切れるリソースとして扱われます。トピック6.1を参照。
エスケープした欠陥。 レビューやテストで捕捉されたものとは異なり、本番環境に到達し実際のユーザーに影響を与える欠陥。トピック5.1を参照。
稼働率(ユーティライゼーション)。 リソースの利用可能な容量のうち忙しい割合であり、到着率を処理能力で割って計算されます。待ち時間は、稼働率が完全な容量に近づくにつれて段階的にではなく急激に増加します。トピック2.7を参照。
価値ストリーム(バリューストリーム)。 アイデアを顧客が受け取る価値に変えるエンドツーエンドの活動の連鎖であり、Flow Frameworkの測定単位です。トピック2.1を参照。
技術的負債。 コードベースにおける過去の近道の蓄積されたコストであり、恥ずべき秘密ではなく管理可能なトレードオフの比喩です。トピック4.5を参照。
虚栄の指標(バニティ・メトリック)。 確実に上昇し、印象的に見え、どんな決定も変えない指標。トピック1.1を参照。
グッドハートの法則。 測定がターゲットになると、それは良い測定ではなくなるという原則。本書の中心的な統治する考えです。トピック1.2を参照。
ガードレール指標。 インセンティブのかかった指標が改善する間に劣化してはならない、ゲーミングを捕捉するよう設計された対になった対抗指標。トピック1.2を参照。
管理図(コントロールチャート)。 時間をかけた指標の正常な変動範囲を示すチャートであり、本物の変化を通常のノイズから区別するために使われます。トピック1.6を参照。
完了正確率(%C/A)。 古典的なリーンのバリューストリームマッピングから、下流のチームが手直しを必要とせずに処理できる単位の割合。トピック2.8を参照。
総所有コスト(TCO)。 事前のコストだけでなく、継続的な保守とインフラを含む、取り組みあるいはシステムのその寿命にわたる完全なコスト。トピック5.5を参照。
サイクルタイム。 リードタイムの内部的な内訳:コーディング、レビュー、テスト、デプロイの段階。トピック2.6を参照。
サービスレベル指標(SLI)。 レイテンシやエラー率などの、サービスの健全性の直接測定されたシグナル。トピック6.1を参照。
サービスレベル目標(SLO)。 サービスレベル指標のための目標範囲。トピック6.1を参照。
仕掛かり作業(WIP)。 いつでもチームあるいはシステムを横断して積極的に取り組まれている項目の件数。トピック2.5を参照。
CVSS(共通脆弱性評価システム)。 セキュリティの脆弱性の重大度を採点するための標準化された尺度。トピック6.4を参照。
SPACEフレームワーク。 開発者の生産性のための5次元の枠組み:満足度と幸福感、パフォーマンス、活動、コミュニケーションと協働、効率性とフローです。トピック3.1を参照。
SREサイト信頼性エンジニアリング。 Googleで先駆けられた、ソフトウェアエンジニアリングのアプローチを運用と信頼性に適用する規律。トピック6.1を参照。
成果のテレメトリー。 活動やアウトプットではなく実際の成果の継続的で計測された測定。トピック7.4を参照。
総合通過収率(ロールドスループットイールド)。 バリューストリームのすべての段階の完了正確率の数字を掛け合わせたものであり、手直しが複数段階のパイプラインにわたってどう複合するかを明らかにします。トピック2.8を参照。
待ち行列理論(キューイング理論)。 待ち行列の数学的研究であり、提供パイプラインに適用されて、仕掛かり作業、到着率、稼働率がどう待ち時間を動かすかを説明します。トピック2.7を参照。
タクトタイム。 古典的なリーンのバリューストリームマッピングから、顧客の需要にきれいに一致するために一単位の仕事を完了するための最大許容時間。トピック2.8を参照。
デプロイ頻度。 チームがどれだけ頻繁に本番環境に成功裏にリリースするか。四つのDORA指標の一つです。トピック2.10を参照。
デプロイのリードタイム。 コードの変更が最初にコミットされてから本番環境に成功裏にデプロイされるまでの時間。四つのDORA指標の一つです。トピック2.10を参照。
DORA指標。 DevOps Research and Assessmentプログラムからの4つの指標:デプロイ頻度、変更のリードタイム、変更失敗率、失敗したデプロイの復旧時間です。トピック2.10を参照。
DevEx(開発者体験)。 フィードバックループ、認知的負荷、フロー状態を中心に組織された、SPACEと関連するより広い枠組みづけ。トピック3.7を参照。
投資収益率(ROI)。 取り組みの財務的な収益をそのコストと比較したものであり、ここでは仮定ではなく文書化されたコストと成果の証拠から構築されます。トピック5.5を参照。
バス係数。 システムあるいは知識の一部が保守不可能になる前に利用不可能にならなければならない人数。バス係数が1であることは深刻なリスクです。トピック3.5を参照。
プロセスタイム(PT)。 古典的なリーンのバリューストリームマッピングから、待っている時間とは異なる、単一の単位に取り組むために費やされた実際の手を動かしている時間。トピック2.8を参照。
フロー速度。 与えられた期間にわたって完了したフローアイテムの数であり、Flow Frameworkのスループットの尺度です。トピック2.3を参照。
フロー分布。 与えられた期間に完了したフローアイテムのうち、各フローアイテムの種類に属する割合。トピック2.3を参照。
フロー効率。 提供パイプラインを通過する仕事の一部について、アクティブな作業時間と総経過時間の比率。トピック2.5を参照。
Flow Framework。 Mik Kerstenによって作られた管理のモデルであり、ソフトウェアの提供をバリューストリームとして扱い、4つのフローアイテムの種類と5つのフロー指標でそれを測定します。トピック2.1を参照。
フローアイテム。 Flow Frameworkの作業単位:機能、欠陥、リスク、あるいは負債の項目であり、受け入れ時に分類されます。トピック2.2を参照。
フロー負荷。 バリューストリーム内で現在アクティブあるいは待機しているフローアイテムの総数であり、Flow Frameworkの仕掛かり作業の呼び名です。トピック2.4を参照。
フロータイム。 フローアイテムがバリューストリームに入ってからその提供までの総経過時間であり、エンジニアリングだけでなくバリューストリーム全体にまたがります。トピック2.4を参照。
北極星指標(ノーススターメトリック)。 組織が提供する中核的な価値を最もよく捉える単一の尺度であり、指標の木の頂点に位置します。トピック1.3を参照。
ホットスポット。 頻繁に変更され(高いチャーン)かつ非常に複雑な、ホットスポット分析を通じて特定されるファイルあるいはモジュール。トピック4.3を参照。
ミューテーションテスト。 カバレッジを補完するものとして、テストスイートが実際にそれを捕捉するかどうかを確認するために、コードに意図的に小さな人工的な欠陥を導入する技法。トピック4.2を参照。
単位経済性(ユニットエコノミクス)。 不透明な合計としてではなく、提供された価値の意味のある単位(顧客あたり、取引あたり)あたりで表現されたコスト。トピック5.4を参照。
変更失敗率。 是正を必要とする本番環境の失敗を引き起こすデプロイの割合。四つのDORA指標の一つです。トピック2.10を参照。
FinOps。 変動するクラウドインフラの支出に財務的な説明責任をもたらす規律。トピック5.4を参照。
リトルの法則。 安定した待ち行列における項目の平均数が、平均到着率に項目がシステムに費やす平均時間を掛けたものに等しいという証明。提供に適用すると、仕掛かり作業は到着率とサイクルタイムを掛けたものに等しくなります。トピック2.7を参照。
サイクロマティック複雑度(循環的複雑度)。 Thomas J. McCabeによって1976年に導入された、コードの一部の制御フローを通る独立したパスの数。トピック4.1を参照。
指標の木(メトリックツリー)。 トップレベルの成果の指標から、その推進要因を通じて、個々のチームが所有する運用指標まで接続する構造。トピック1.3を参照。