はじめに
本日の参考文献
LeanとDevOpsの科学
ソフトウェア開発のパフォーマンスに影響を与える要因について調査をしているDevOps Research and Assessment(DORA)という団体が発表したレポートについての本。
約3万件の企業やチーム(業界業種、組織規模問わず)を対象に行った「State Of DevOps Report」の結果と考察についてまとめている。
Four Keys Metrics
State Of DevOps Reportでは下記の4点の指標において高いパフォーマンスを発揮している企業ほど、ビジネス上の業績(収益性、顧客満足度、市場シェアなど)の面でも優れた結果を出す傾向があることを示した。
| 指標 | 定義 |
|---|---|
| デプロイ頻度 | 変更を本番環境にデプロイ、あるいはエンドユーザーにリリースした頻度 |
| 変更のリードタイム | 開発者がチケットに着手してコードを書き始めてから、本番環境へリリースされる時間 |
| 変更失敗率 | デプロイによって本番環境で障害が発生する割合 |
| MTTR(平均修復時間) | 本番環境での障害から復元までにかかる時間 |
デプロイ頻度
ユーザーに対してより頻繁に新しい機能を提供できたり、改善要望の応えたりできるため顧客満足度が高いと推測できる。また新しいアイデアに対する実験、テストを繰り返しやすくなることで、高い競争優位性を確保できていると考察。
変更のリードタイム
短いリードタイムにより、顧客への価値提供が早くなり、市場のニーズに迅速に対応できると考察。
変更失敗率
本番環境での障害が発生する割合が低いほど、顧客満足度は高いと考察。
MTTR(平均修復時間)
障害からの回復時間が短いほど、復旧が迅速であるほど、顧客満足度は高いと考察。
各4つの指標について高いレベルで達成できている企業やチーム(= ハイパフォーマー)とそうでない企業、チーム(= ローパフォーマー)を比較した時に、
- デプロイ頻度は約417倍以上
- 変更のリードタイムは1/4320
- サービス復旧時間は1/4320
- 変更失敗率は1/7
差があることが調査からわかっている(2022年の調査結果より)
DOARは毎年調査結果を報告しており、この差は年々開きつつある。
参考:2024年度の調査
調査結果によって得られたハイパフォーマ、ローパフォーマーの各メトリクスの数値は以下

↓日本語訳
| ソフトウェアデリバリーパフォーマンス指標 | エリート | 高 | 中 | 低 |
|---|---|---|---|---|
| デプロイ頻度 | オンデマンド(1日に複数回デプロイ) | 週に1回以上~月に1回 | 月に1回以上~半年に1回 | 半年に1回以下 |
| 変更のリードタイム | 1時間未満 | 1日以上~1週間 | 1か月以上~6か月 | 6か月以上 |
| サービス復旧時間 | 1時間未満 | 1日未満 | 1日以上~1週間 | 6か月以上 |
| 変更失敗率 | 0%~15% | 16%~30% | 16%~30% | 16%~30% |
本書では、これらのメトリクスに対して統計的に有意な形で正の影響を与えるケイパビリティ(組織として保有できる機能・能力)を24個特定できたと述べられている。
以下に、ピックアップして紹介していく。
継続的デリバリ関連のケイパビリティ
すべての成果物をバージョン管理で管理
アプリコードやインフラのコンフィギュレーション(IaC)、ビルドやデプロイの自動化のためのスクリプトなども含めたすべての成果物を、Gitなどのバージョン管理システムを利用して管理しているチームほど有意にパフォーマンスが高かった。
テストの自動化
信頼性の高い(= 偽陰性、偽陽性のない)自動化されたテストを、継続的に高い頻度で実施しているチームほど有意にパフォーマンスが高かった。逆にテストを自動化していなかったり、機能の開発やリリース作業が完了してからはじめてテストに取り掛かるようなチームほど、ローパフォーマーである傾向がみられた。
小さな変更を頻繁にメインブランチに統合している
開発者が小さな変更を頻繁にメインブランチに統合する開発手法のことを「トランクベースの開発」という。
featureブランチの寿命が短いチーム(例:1日未満)や、現在アクティブになっているfeatureブランチの数が少ないチーム(例:3つ以下)ほど、ハイパフォーマーである傾向がみられた。
featureブランチの寿命や数が多いほど、マージのコスト(コンフリクトの解消、デグレの確率)が高くなることが原因と推測される。
デプロイの自動化
デプロイのプロセスを自動化しているチームほど、ハイパフォーマである傾向が高かった。
自動化全般の作業に言えることであるが、反復作業はコンピューターに任せて、人間のリソースを問題解決に割くことができているチームほど、パフォーマンスが高いと推測される。
アーキテクチャ関連のケイパビリティ
疎結合なアーキテクチャ
アーキテクチャ特性の中でパフォーマンスに最も大きく影響を及ぼしたものがふたつあった。それがテスト容易性とデプロイ容易性である。
テスト容易性
テストの大半を、統合環境(例:複数の独立したサービスがともにデプロイされている環境)を必要とせずに実施できること。
デプロイ容易性
アプリケーションを、他のアプリケーションやサービスからは独立した形で、デプロイまたはリリースできること。
この2つの特性をもたせるには、システムが疎結合である必要がある。疎結合アーキテクチャがパフォーマンスに与える影響を調査したところ、有意な影響を与えることが判明した。
チーム外の人物の許可を無くても、対象システムに大幅に変更を加えることができたり、他サービスに依存することなくオンデマンドでデプロイ、リリースすることができるためと推測される。(つまりチームとアーキテクチャは疎結合になっている方が良い。逆コンウェイ=システム構造が組織構造に影響与える)
【参考】テスラの変更頻度とアーキテクチャ
テスラでは毎日60個以上の新しい部品を生産導入、販売している(他の多くの自動車会社は数年に一度、モデルチェンジの発表を行っている)
部品同士が疎結合になっており、担当開発チームが独立して動けることで可能になっているらしい。
組織文化関連のケイパビリティ
下記はWestrumが提唱した3タイプの組織文化とその特徴である。
| 不健全な(権力志向の)組織 | 官僚的な(ルール志向の)組織 | 創造的な(パフォーマンス志向の)組織 | |
|---|---|---|---|
| 協力態勢 | 協力態勢が弱い | ほどほどの協力態勢 | 協力態勢が確立 |
| 情報伝達 | 情報伝達を阻止 | 情報伝達を軽視 | 情報伝達に積極 |
| 責任追及 | 責任追及 | 責任追及が強い | リスクを共有 |
| 仲介 | 仲介を阻止 | 仲介を許す | 仲介を奨励 |
| 失敗 | 失敗は責任転嫁へ | 失敗は処罰 | 失敗は調査へ |
| 新規性 | 新規性をつぶす | 新規性を簡便化 | 新規性を奨励 |
State Of DevOps Reportの中で、これらの組織文化とソフトウェアデリバリのパフォーマンスの関係性についても調査した。
※調査対象の企業が上記3つのうちどの組織に属しているかの調査と、その企業のパフォーマンスを測定。
結果、創造的な(パフォーマンス志向の)組織である企業が、ソフトウェアデリバリの指標においてもハイパフォーマーである有意な傾向がみられた。
組織が縦割りになっていないほうが、余分なリードタイムがかからないのが大きいと推測。
おまけ:パフォーマンスと無関係だった要素
筆者たちは当初、下記の要素もパフォーマンスと関係があると予測していた
- 業務領域(たとえば公共系、医療系等はスピードが遅い)
- 組織規模(たとえば大企業はスピードが遅い)
- SoEかSoRか、組み込みソフトウェアか否か、といったシステムのタイプ(たとえばSoRはSoEよりスピードが遅い)
しかし業務領域や組織規模にかかわらず、すべてのグループにおいて「ハイパフォーマ」「ミディアムパフォーマー」「ローパフォーマー」の該当者がいることが判明した。
またSoEかSoRか、組み込みソフトウェアか否かといったシステムのタイプも、パフォーマンスには有意な影響を与えないことが示された。
これらの要素より「継続的デリバリの実践度」「テスト容易性・デプロイ容易性を備えたアーキテクチャ」「創造的な(パフォーマンス志向の)組織である」といった特性の方が、パフォーマンスにとって重要であることが判明した。
【参考】24個のケイパビリティ
継続的デリバリの促進効果が高いケイパビリティ
- 本番環境のすべての成果物をバージョン管理システムで管理
- デプロイの自動化
- 継続的インテグレーション(CI)の実装
- トランクベースの開発手法の実践
- 小さな変更を頻繁にメインブランチに統合すること。寿命の長いfeatureブランチを持たないこと。
- テストの自動化
- テストデータの適切な管理
- 情報セキュリティのシフトレフト
- 継続的デリバリ(CD)の実践
アーキテクチャ関連のケイパビリティ
- 疎結合のアーキテクチャ
- チームへのツール選択権限の付与
製品・プロセス関連のケイパビリティ
- 顧客フィードバックの収集と活用
- 全業務プロセスの作業フローの可視化
- 作業の細分化
- チームによる実験の奨励・実現
リーン思考に即した管理・監視にかかわるケイパビリティ
- 負担の軽い承認変更プロセス
- 事業上の意思決定における、アプリケーションとインフラの監視結果の活用
- システムの健全性の予防的なチェック
- WIP(work in progress:進行中の作業)制限によるプロセス改善と作業管理
- 作業の可視化による、品質の監視とチーム内コミュニケーションの促進
組織文化にかかわるケイパビリティ
- 創造的な組織文化の育成
- 学びと奨励と支援
- チーム間の協働の支援と促進(「縦割り」の脱却)
- 有意義な仕事を可能にするツール等の資源の提供
- 改善を推進するリーダーシップの実現と支援