ケイパビリティを基に予測されるのがパフォーマンスで、パフォーマンスを基に予測されるのが成果（組織パフォーマンス）です。
ザックリとそう書かれていますが、つまりはそれぞれ相関する値を軸にして結果を観測していきましょうというお話になります。

柔軟なインフラ

クラウドコンピューティングを導入し、以下の５つの重大特性を満たしている組織が柔軟なインフラを備えているとされる。

• オンデマンドのセルフサービス：人間の介入なしでコンピューティングリソースをプロビジョニングできる
• 幅広いネットワークアクセス：携帯電話、タブレット、ラップトップ、ワークステーションなどのさまざまなプラットフォームを介して機能にアクセスできる
• リソース・プーリング：プロバイダーリソースはマルチテナントモデルでプールされ、物理リソースと仮想リソースがオンデマンドで動的に割り当てられ、国・州・データセンターなどのより高い抽象レベルで場所を指定できる
• 迅速な弾力性：弾力性を持ってプロビジョニングおよびリリースされ、オンデマンドで外側または内側に迅速に拡張でき、無制限であるかのように見え、いつでも任意の量を割り当てることができる
• 測定されたサービス：クラウド システムは、ストレージ・処理・帯域幅・アクティブなユーザーアカウントなどのサービスの種類に基づいて、リソースの使用を自動的に制御・最適化・レポートできる

つまりは、Google CloudやAWSのようなクラウドサービスで上記の特性を頭に入れてシステムを組みましょうというお話。

この５つを満たすための障害が以下の２つ

• それらを実行するために連携する必要がある組織機能間の連携と協力が不十分
• 技術・プロセス・組織の変更への投資が不十分

ドキュメンテーションの質

ドキュメントの品質と組織パフォーマンスには相関性があり、収益性の目標達成にも繋がる。
良いドキュメント品質かどうかは以下の指標を利用する。

• サービス利用時信頼性：取り組んでいるサービスやアプリケーションを使用したり操作したりする必要がある場合、ドキュメントに頼ることができる
• 障害時信頼性：トラブルシューティングが必要なインシデントや問題が発生した場合、ドキュメントに頼ることができる
• わかり易さ：ドキュメントの理解しやすさ
• 見つけやすさ：取り組んでいるサービスやアプリケーションについて理解する必要がある場合、適切なドキュメントをすぐ見つけることができる
• 網羅性：ドキュメントがどれだけ網羅されているか
• 整理されているか：ドキュメントがどれだけ整理されているか（※具体的な説明がなかったので"整理"が何を指すか謎）
• メンテナンスされているか：ドキュメントが変更に追従されているか
• 正確性：サービス・アプリケーションの機能と要件が正しく反映されているか

ドキュメント品質は全ての技術ケイパビリティに良い影響を与える。
以下の表はドキュメント品質の優劣による、各ケイパビリティへの作用を表したものである。

技術ケイパビリティ

「柔軟なインフラ」と「ドキュメンテーションの質」に強い相関を持つのが技術ケイパビリティです。
　11つに項目が分かれており、デリバリーパフォーマンスと相関を持ちます。また、後述する「セキュリティのシフトレフト」、「継続的デリバリー」とも強い相関を持ちます。

• コードの保守性：コードを壊すことなく、様々な変更を加えることができる
• 継続的インテグレーション：コミットされたコードに対して、テストなどがトリガーされる
• データベース変更管理：データベースへの変更をコードとしてバージョン管理できる
• デプロイ自動化：デプロイがほぼ手動による介入がないほどに自動化されている
• チームのツール選択権：実務に関わる人がツールの選択をできる
• 疎結合アーキテクチャ：他のサービスと疎であり、テスト・デプロイを独立して行うことができる
• 監視とオブザーバビリティ：監視・オブザーバビリティがあり、システムの状態が把握できる
• テスト自動化：手動による回帰テストなど開発完了後のテストプロセスが存在せず、CDの一貫として自動で信頼性の高いテストが行われること
• テストデータ管理：自動テストのために適切なテストデータが利用可能になっているか？自動テストの実行を阻むテストデータになっていないか？
• トランクベース開発：アクティブなブランチ数を抑え、コードロック期間が短いトランクベース開発を行っているか
• バージョンコントロール：Gitなどのバージョン管理システムを利用しているか

セキュリティのシフトレフト

セキュリティのレビューやセキュリティライブラリ・ツールの利用、自動テストにセキュリティテストを組み込むなど、開発の早期に行うことを「セキュリティのシフトレフト」と呼びます。

「Googleのソフトウェアエンジニアリング」にも書かれていますが、シフトレフトは重要な概念で早期に欠陥を発見することで後々発見するよりも傷を浅くすることができます。セキュリティのみならず、テストの文脈でも語られていたりします。

ソフトウェアの設計段階からInfoSecチーム（=セキュリティ情報チーム）が関わり、ツール開発やセキュリティテストを自動テストに組み込むなどのタスクを担ってもらう。

継続的デリバリー

継続的デリバリーは継続的デプロイメントと違い、継続的にリリースを行うためのプロセス整備などリリース準備までを担います。
継続的デプロイメントは変更が自動的に本番環境に適用されるような実際のリリースを担います。

four keysが測定するソフトウェアデリバリーパフォーマンスをより向上させ、デプロイメントのペインを軽減しデリバリーに関わるスタッフの不安感などを軽減します。

継続的デリバリーは組織能力の促進に強い相関があり、これを支えるのは各々の技術ケイパビリティだったりします。

ただし、注意すべき点として「four keysは組織ケイパビリティを観測する指標ではない」ということであくまでも「技術ケイパビリティを観測する指標である」ということ。つまりfour keysの観測結果を改善したとしても組織ケイパビリティに寄与するとは限らない。

生産的組織文化

信頼性があり、情報の流れが最適化された良い組織文化を持つ組織は良いソフトウェアデリバリーパフォーマンスと組織パフォーマンスを持ちます。

Westrum博士の組織類型という、情報の流れを組織の類型別にまとめたものがあります。

ref: https://cloud.google.com/architecture/devops/devops-culture-westrum-organizational-culture?hl=ja

この類型の「創造的な組織」になろうと改善することでソフトウェアデリバリーパフォーマンスと組織パフォーマンスの改善につながります。

情報の流れを改善するための行動は以下の６つです。

• 積極的に協力する
• 情報を積極的に活用する
• リスクを共有する
• つながりを奨励する
• 失敗を調査する
• 新規性を積極的に受け入れる

組織文化が生産的かどうか？の測定としてはアンケートが有用とWestrum博士は述べています。

変更承認の効率化

あまり馴染みがない文化なのだが、重大なサービスの変更において変更諮問委員会（CAB）を通して変更を評価し、承認・非承認を決定するという概念がある。

ただし、DORAによる調査では変更承認は開発プロセスの中で行われるべきで、よろしくない変更は早期に発見・修正、または自動化によって補完されるべきとある。
これはソフトウェアデリバリーパフォーマンスに関連する話で、CABを設置しプロセスに組み込むことでデリバリープロセスが遅れ、更に変更失敗率の低下に関連することもないらしく、逆に変更失敗率が高くなるという可能性がある。

そのため、開発プロセスとしてレビュー文化を醸成し、継続的テストや監視・オブザーバビリティを据えることで悪い変更の検出・防止・修正を図ることによりソフトウェアデリバリーパフォーマンスの向上につながるのである。