継続的改善を探求する

  • 5 分

継続的改善は、DevOps 分類の 8 つの機能の 1 つです。

継続的改善が必要な理由を探す

継続的改善では測定が使用されます。これは必須です。 測定せずにどうやって改善点を特定するのでしょうか。

2017 年公開の Forrester レポート『Faster Software Delivery Will Accelerate Digital Transformation』(ソフトウェア デリバリーの高速化によりデジタル変革が加速) では、リード タイムとプロセス タイムの間にかなりの無駄があることが示されています。 測定しなければ、違い (つまり組織がどれだけ浪費しているのか) がわからないことがわかります。

それぞれの無駄がプロセスに及ぼす影響を測定すると、改善するために作業の優先順位を簡単に決められるようになります。

Diagram shows significant waste between the lead time of 123 days and the process time of 39 days. This amounts to a wait time of 84 days.

出典: Forrester、『Faster Software Delivery Will Accelerate Digital Transformation』(ソフトウェア デリバリーの高速化によりデジタル変革が加速)、2017 年 3 月 9 日、Diego Lo Giudice、Christopher Condo、Christopher Mines、Luis Deya 共著

しかし、測定しない場合、どうやってカスタマー エクスペリエンスを向上させるのでしょうか。 Forrester の調査によって、「試した機能と使用した機能の重複が小さい場合、開発者は顧客に関するさらに適切な分析情報を必要としている」ことが明らかになりました。 試されたアプリケーション機能と使用されたアプリケーション機能の重複は約 35% です。

Diagram shows there is only a 35% overlap between features being tested and those being used.

新しい機能の使用状況や影響を測定せずに、どうやって適切なソフトウェアを構築できるのでしょうか。 間違う可能性が 65% あるため、違いを知ることが大切です。

継続的改善とは

DevOps プロセスを継続的に公平に観察することで、チームは潜在的な改善点を特定できるようになります。

すべての改善には変更が必要ですが、すべての変更が改善につながるわけではありません。 だからこそ、DevOps を採用している組織にとって、測定が重大な成功要因なのです。 Peter Drucker は、「評価できないければ改善できない」と述べています。

効果的なフィードバック メカニズムの欠如により、ビジネスへのアプリの影響を改善することが困難です。 このため、DevOps 改善のために、データに基づいた調整を行うことに重点を置いて学習中心のアプローチを促進する環境の作成が重要です。 Diagram shows that we should use measurement and impact to generate improvement. The measurement should lead to a positive behavior change. Organizations should evolve to a practice of continuous learning and feedback to create Continuous Improvement on software delivery performance.

測定とメトリック

まず、測定について考えてみましょう。 Nicole Forsgren、Jez Humble、Gene Kim 共著の『Lean と DevOps の科学 [Accelerate] テクノロジーの戦略的活用が組織変革を加速する』によれば、ソフトウェア デリバリー パフォーマンスの最も重要な基準は次の 4 つです。

  • 変更のリード タイム: ソフトウェア デリバリー パフォーマンスの速さの基準。 コードがコミットされてから、運用環境でコードが正常に実行されるようになるまでにかかる時間
  • 配置の頻度: 応答時間、チームの結束力、開発者の能力、開発ツールの有効性、DevOps チーム全体の効率に関する、直接的または間接的な基準。
  • 平均復元時間: サービス インシデントが発生したときに最優先のアプリまたはサービスの復元に通常かかる時間。
  • 変更の失敗率: 運用に対する変更 (ソフトウェ リリースやインフラストラクチャ構成の変更など) が失敗した割合。

運用の正常性メトリック、使用状況、ベロシティ、ライブ サイトの正常性などを測定するのは、DevOps リーダーの責任です。 つまり、アクティビティではなく、影響を測定してください。 メトリックが役立つのは、それについて対処できる場合のみです。

スクラム チームは、チームのキャパシティ、チームのベロシティ、バーンダウン、バグ数を測定しますが、これらのメトリックはチームのコンテキスト内のみで意味を持ちます。 しかし、DevOps のリーダーは影響に注目し続けることが重要です。

重要

アクティビティではなく、影響を測定します。

測定項目:

使用方法

ベロシティ

ライブ サイトの正常性

  • 取得
  • エンゲージメント
  • 満足度
  • チャーン
  • 機能の使用状況
  • ビルドの所用時間
  • セルフテストの所用時間
  • 配置の所用時間
  • 学習の所用時間
  • 検出の所用時間
  • 通信の所用時間
  • 軽減の所用時間
  • お客様への影響
  • インシデント防止項目
  • ライブ サイト経年劣化問題
  • 顧客あたりの SLA
  • カスタマー サポート メトリック

測定しない項目:

  • 最初の見積もり
  • 実績時間
  • コードの行数
  • チーム キャパシティ
  • チーム バーンダウン
  • チームのベロシティ
  • 検出されたバグ数

重要

メトリックはビジネスの成果に影響を与えます。

KPI を習慣に合わせることが重要です。 これは、ビジネスの望ましい成果の実現に役立ちます。

KPI を補強してチームを成功に導く重要な習慣は次のとおりです。

  • チームの自律性と組織の位置付け: 何を、どのように、なぜビルドするのか。 すべてのリーダーシップとフィーチャー チームが透過的かつ効率的にコラボレーションを進めるためには、組織全体で共通のリズムすなわちハートビートが必要です。
  • お客様の関心: すべての取り組みは、直接的または間接的にお客様の評価に影響を及ぼす必要があります。
  • 運用優先の考え方: 機能やバグの処理方法を、開発、テスト、運用サポートの各段階で区別しない考え方。 運用環境では、すべてを自動化し、バージョン管理し、微調整する必要があります。
  • シフト クオリティ レフトとフェイル ファスト: 機能デリバリー サイクルのできるだけ早い段階で、テストとセキュリティの両方について、レビュー、評価、承認を奨励し、品質向上とフェイル ファストの考え方を推進します。

Diagram shows the relation between metrics, KPIs, habits and business outcomes. Metrics support KPIs, which should align with habits to achieve the business outcomes. KPI examples include lead time, deployment frequency, mean time to restore, and change fail rate. These KPIs should be aligned to habits like: team autonomy and organization alignment, customer focus, production-first mindset, and shift quality left and fast. This alignment helps achieve business outcomes like a quicker time to market, higher quality, less waste, and end-to-end security.

継続的なフィードバック

次に、コラボレーションのために継続的なフィードバックを使用する方法を考えてみましょう。

よく話題になっている最新のアプリ開発者はスタートアップ出身です。 どうしてそれほど成功しているのでしょうか。 そのリーン プラクティスは、何年もの洗練されたプロセスから解放されました。

リーン スタートアップによって、アイデアを開発、実現、および改良するための最適なパスが確立されました。これは、優れた肯定的フィードバック文化の導入によるものです。

  • 早期にリリース、頻繁にリリース
  • 実行可能な最小の製品から開始
  • 仮説駆動型開発を使用
  • 顧客からのフィードバックによる継続的な改善

Diagram shows the cycle of continuous feedback. We start with ideas, build the code, and measure results to collect data. The date will help us learn and generate new ideas. Continuous feedback minimizes the total time through the loop.

バリュー ストリーム マッピングによる継続的改善

測定とフィードバックがあれば、改善はデータ駆動型の作業になります。

継続的改善をサポートする 1 つの効果的な方法は、バリュー ストリーミング マッピングによるものです。 バリュー ストリームは、組織が顧客の要求を実現するために行う一連のアクティビティです。

バリュー ストリーミング マッピングは、作業の実行方法において、つながっていない部分、冗長な部分、欠落部分を見つけて解決することができる、きわめて効果の高い方法です。 これは単なるツールではなく、実証済みの管理方法の基盤になるチームベースの手法です。

バリュー ストリーム分析では、デリバリー プロセスを分割し、リード タイム、サイクル タイムおよびアイドル タイムを測定できます。これによって、チームがワークフローに対してデータに基づく調整を加えられます。

これらの測定は、チームによる計画、効率が変動する箇所の特定、潜在的なプロセスの問題の識別に役立ちます。

Diagram shows the stages of the delivery process. Lead time is the total time on all stages. Idle time is the time between two stages. Process or cycle time measures the duration of a stage.

ヒント

リード タイムとサイクル タイムが短くなるほど、チームのスループットが速くなります。

プロセス改善のために将来の変更箇所を特定するには、不必要な非付加価値作業と必要な非付加価値作業の違いを識別できる必要があります。

不必要な非付加価値作業はまさしく無駄です。顧客は価値を認めません。また、存続可能な企業であり続けるために、そのような作業を行う必要はありません。 リソースを消費するだけで製品に価値は付加されません。

Diagram shows that lead time includes unnecessary and necessary non-value-adding process time, as well as value-adding process time.

データ駆動型 DevOps: メトリックが体験を導く

DevOps による変革は体験です。DevOps の体験を進めるための最も効果的な手段は、データ駆動型 DevOps です。

Diagram shows the flow of the DevOps journey. Teams begin transformation and identify quick wins. Automation helps low performers progress to medium performers. Automation increases test requirements, which are dealt with manually. A mountain of technical debt blocks progress. Technical debt and increased complexity cause additional manual controls and layers of process around changes, slowing work. Relentless improvement work leads to excellence and high performance! High and elite performers leverage expertise and learn from their environments to see jumps in productivity.

DevOps の有効性を測定し、DevOps 変革のイニシアチブに透明性をもたらすために、包括的なアプローチの確立をお勧めします。 成功を強調するメトリックに焦点を当てることで、DevOps が必要とする学習と実験を促進する文化を生み出します。 そのような成功を認識できるように、間違った行動を罰するのではなく正しい行動を奨励してください。