継続的なデリバリー: ビジネス価値、メリット、課題、指標

1. ベロシティ

自動化されたソフトウェア デリバリー パイプラインは、組織が市場の変化に的確に対応するのに役立ちます。新機能の保存期間を短縮するには、迅速な対応が最も重要です。市場に出すまでの時間を短縮することで、組織は競争相手に打ち勝ってビジネスを継続する機会が増えます。

スピード自体は成功指標ではないことに注意してください。品質を伴わないスピードは無用です。継続的なデリバリー パイプラインで誤ったコードが迅速に本番環境に投入されることに価値はありません。

2. 生産性

生産性は幸せに変わり、幸せなチームは士気が高まります。

見つかった欠陥すべてについてのバグレポートを作成するといった退屈で反復的なタスクを人間のかわりにパイプラインで実行することにより、生産性が向上します。これにより、パイプラインが処理を実行する間、チームはビジョンに集中できます。それに、誰もが面倒な作業をツールに代行させたいと願っています。

パイプラインによって報告された課題をチームが調査して修正をコミットすると、パイプラインが再度実行され、問題が修復されたかあるいは新たな問題が意図せず発生したか、検証が行われます。

3. 持続可能性

ビジネスはスプリントだけでなくマラソンでも勝利を目指します。競争に抜きん出るには勇気が必要です。常にリードし続けるのはさらに困難かもしれません。それには訓練と厳しさが伴います。24 時間 365 日、がむしゃらに働いていてはすぐに燃え尽きてしまいます。その代わり、スマートに働き、反復的な作業は休憩を必要とせず口答えもしない機械に任せましょう。

テクノロジー企業であるか否かを問わず、すべての組織はテクノロジーを駆使して差別化を図っています。自動化されたパイプラインは手作業を削減し、人件費はツールよりも高額であることから、やがて経費削減につながります。経験の浅いリーダーは多大な先行投資を懸念することがありますが、適切に設計されたパイプラインがあれば、組織はよりよく、そしてより早く顧客のニーズに応えることができるようになります。継続的デリバリーは、ビジネスが機能および修正を提供する方法に柔軟性をもたらします。特定の機能セットを特定の顧客、または顧客グループにリリースし、設計どおりの機能と拡張性を確実に実現します。機能のテストと開発を実施し、複数のリリースに備えながらも製品では使用しないでおくこともできます。マーケティング部門が毎年恒例の業界コンベンションで「大ヒット」を収めたがっている場合でも、継続的デリバリーによってそれが可能になるだけでなく、簡単に実現することができます。

予算: 少なすぎますか?

継続的デリバリーの構築には、組織の優秀な人材が必要になります。これはコストを考えずに実行できるようなサイドプロジェクトではありません。若手メンバーを割り当て、最新ツールの購入費用を節約してプロジェクトをスタートする組織がいる事実には常に驚かされます。その組織はある時点で軌道を修正し、アーキテクチャデカップリングと弾力性のある継続的デリバリーパイプラインに投資するため、上級アーキテクトを割り当てることになります。

意図的に低く見積もらないでください。ビジョンに基づき、その実現が中断されることのないように適正な資金を確保しておきましょう。継続的デリバリーパイプラインの MVP (minimum viable product: 最低限の機能を持った製品) を実現し、その後組織内で拡張します。

あなたのチームは未来志向ですか?

予算があったとしても、最終的に人の問題で実行できないことがあります。

チームは恐れることなくチームの仕事を自動化して、新しいプロジェクトに進む必要があります。手動で実行していたタスクを自動化されたエージェントが実行することに不安に抱えている人がいる場合は、不適切な人を採用していることになります。

行き詰まったときはギアを変えてみましょう。チームがより速い馬しか求めていないときに車を与える方法を考えます。経験豊富なチャンピオンの手を借りて勢いよくスタートを切り、この最初の山を乗り越えましょう。結局のところ、人は最大の財産であり、彼らが正しいことを行うように訓練すべきです。正しいことを行うのを簡単に、間違ったことを行うのを難しくすれば、嬉しい結果に驚かされることでしょう。

優先順位の欠如

「ラインを止めて継続的デリバリーのパイプラインを構築しよう!」と言ったプロダクト所有者はいません。

彼らを弁護して言うなら、彼らは世界をあっと言わせる新しい機能で競争に先手を打つことに集中しているのです。同時に、もしすべてのスプリントプランナーが製品の機能よりもパイプラインを重視してトレードオフするようになったら問題があることがわかります。

いくつかのプロダクトバックログでは、パイプラインはあったとしても底近くで必死に持ちこたえています。目先のことしか見えないリーダーは、パイプラインに伴う作業をチームにとって有益な投資とは見なさず、費用として分類します。彼らは自分たちが招いた長期的な損害を否定し続け、残念ながらそれで済ませてしまう場合があります。

Pipelines は衛生です。ビジネスを継続するなら、「衛生は重要ですか?」と自問してください。もちろん、重要です!

パイプラインは大量のトランザクションデータを処理します

ソフトウェア開発チームの生活の典型的な一日を想像してみてください。チームはビジネスで優先された機能、その機能のテストの順にコミットして、デプロイを継続的なデリバリー パイプラインと統合することで、すべての変更が自動的にデプロイされるようにします。チームはこの新機能を追加した後にアプリケーションが遅くなったことに気が付いて、パフォーマンスの課題の修正をコミットします。また、チームはパフォーマンス テストを追加して、アプリケーションをテストからステージングまでをプロモーションする前に、悪い応答時間が発生することを確認します。

これらのコミットをトランザクションとして考えます。そしてこれが、ソフトウェア開発チームの進む方法なのです。世界をあっと言わせる製品が誕生するまで、トランザクションにトランザクションを重ねます。その繰り返しです。組織内のすべてのエンジニアやチームでこれらのトランザクションが繰り返されれば、自由に使えるトランザクションデータが大量にたまります。

パイプラインのトランザクションデータの分析

トランザクションデータを分析して価値ある情報を抽出できますか?もちろんです!

すべてのトランザクション データと同様、量に忙殺されてしまっては理解に至りません。組織のインサイトを収集するために分析を集約して実行する必要があるのは、そのためです。分析は、木を見て森を見るのに役立ちます。ここでは、パイプライン分析とインサイトから実践を改善した 3 つの例を紹介します。

毎週発生する数百件ものデプロイのうち、アプリケーション A のデプロイ失敗数はアプリケーション B のそれの 3 倍に上ることがわかりました。この発見によって、環境の安定性と構成管理に関するアプリケーション A の設計の選択肢を調査しました。チームがデータ センターで不安定な仮想マシンを使用してデプロイしていたことと、アプリケーション B がコンテナー化されていることを確認しました。イミュータブル インフラストラクチャへの投資を優先して、その投資収益率が良好であることを確認するために 1 か月後に再確認しました。思ったとおり良好でした。測定できることは修正できるのです。

もう 1 つ例を挙げましょう。アプリケーション B の静的コード分析エラーが過去数四半期にわたり着実に上昇傾向にあることが分かったときのことです。これは、アプリケーション B の背後にいるチームに、より良いコードを書く (再) 訓練が必要であることを示唆しています。また静的コード分析ツールが誤検知を報告したことが分かりましたが、これはコーディング違反が存在しないときにフラグを立てたことを意味します。そこで、よく知られた業界標準の分析ツールにアップグレードしたところ、誤検知はある程度減少しました。コーディングワークショップを企画し、そこで正当な静的分析エラーを議論して解決しました。その結果、チームの仕事は再び順調に進むようになりました。

別の興味深い事実として、アプリケーション A は、アプリケーション B および C よりも単体テストでのコードカバレッジが低かったにもかかわらず、昨年本番環境で発生した問題が最も少なかったのです。単体テストを作成し、コードカバレッジを測定すること自体に問題はありません。それらの処理を過剰に実行することはチームにとって生産性がないと同時に、顧客の役にも立ちません。これが得られた教訓です。

主要業績指標 (KPI)

組織を正しい方向に導くときは、人の意見だけに頼るわけにはいきません。はじめに、具体的な成功像に基づいて KPI を定義する必要があります。次に、KPI を数か月単位、四半期単位、年単位で分析してデータに基づいた決定を下す必要があります。

組織的 KPI と部門的 KPI

多くの場合、各部門はそれぞれ独自の成功指標を定義しています。各部門が自分たちの成功像を具体的に理解することは、その指標が組織の目標と結びついている限り、良いことです。

テスト環境、ステージング環境、本番環境における失敗

いくつかの組織では、開発者にテスト環境を、QA にステージング環境を、運用者に本番環境を所有させています。開発者がテスト環境で実行する単体テストのコードカバレッジレポートに埋もれるのではなく、彼らが所有している環境かどうかを問わず、一歩下がってすべての環境の全体像を把握することが重要です。

パフォーマンス テストによるステージングの失敗の割合が高くなる可能性があります。これは、パフォーマンス ベンチマークが正しくないかコードが遅いことが原因である可能性があります。比較分析では、パイプラインが本番環境における統合スモーク テストで最も失敗することが示されたため、調査が必要となります。根本原因は、製品の実際のバグであるか、バグのあるテスト コード、不正確なテスト データ、不適切なテスト構成、製品とエンジニアリング間の誤解などである可能性があります。

さらに深く掘り下げると、不適切なテスト構成が横行していることが判明することもあります。頻繁に発生する統合の失敗を修復するために、優先的にこれらの課題を修復できます。また、開発者が本番環境までコードに責任を負うことは DevOps パラダイムにも一致しています。

安定性指標

KPI を定義したら、1 つの KPI に偏りがあってそれが特定の方向に大きく傾いていないかどうかを理解することが重要です。偏りや大きな傾きがある場合は、重心を中央に近づける他の KPI とバランスを取る必要があります。そのような KPI の 1 つは安定性です。

開発者は安定性を FeatureLeadTime (機能リードタイム) で測定します。FeatureLeadTime (機能リードタイム) とはある機能が本番稼働するまでにかかった時間のことです。機能は複数のコミットで構成されることから、CheckIn2GoLive でより細かい FeatureLeadTime (機能リードタイム) を測定します。CheckIn2GoLive はチェックインが本番稼働するまでにかかった時間です。

パイプラインがコードをテストからステージング、本番環境までプロモーションするのにかかる時間で概算できるため、Checkin2GoLive をパイプライン経由で測定します。さらに、バグ修正がテストからステージング、本番環境まで同じパイプラインを通過するため、Checkin2GoLive は MTTR (平均解決時間) の欠陥も反映します。

興味深いことに、運用チームはリスク回避を好むことからスピードに否定的な意味合いを感じるようです。彼らは障害を反映するために見過ごされた欠陥の数を測定し、見過ごされた欠陥ではなくパイプラインによって検出された欠陥の割合で安定性を定義します。

ビジネスでは、顧客満足度やリピート顧客の数によって安定性を定義します。これは主観的に思われますが、顧客から報告された欠陥の数または顧客フィードバックの調査によって、この指標を概算できます。

安定性の指標は Dev、Ops、ビジネスが独自の観点から自分の意見に固執する古典歴な例ですが、いずれかの視点に依存するよりもさまざまな視点を取り混ぜた方が組織にとっては有効です。ですから、組織にとって公平な安定性の指標を作りましょう。

コード品質のインデックス

異なる視点を考慮する必要があるもう 1 つの例はコードの品質です。コードの品質は単体テストで測定されたコードカバレッジによって反映されるという意見がある一方、循環的複雑度によって測定すべきという意見もあります。標準的な静的分析ツールは、コードの重複、セキュリティの脆弱性、潜在的なメモリリークを報告します。実際これらはすべてコード品質の測定基準であることから、これらすべて、場合によって他の要素も取り入れた指標を作成します。

ビジネス KPI と技術的 KPI

組織が注目するもう一つの代表的な KPI は、スプリントで提供される価値です。よくある悪しき慣行は、それ自体に付加価値のないリリースの数を記録することです。ビジネスには何の影響ももたらさずにソフトウェアを A 地点から B 地点に少し移動させることもできますが、それは十分とは言えません。一部の組織では、そのスプリントで新たに実行されたテストの数、または実行されたテストの総数を測定する場合もありますが、それもビジネスの結果を示しているとは言えず、単に技術的な取り組みを測定しているに過ぎません。スプリントで得られる価値は、ビジネスに関連するものでなくてはなりません。

ビジネス KPI の例として、前四半期に獲得した顧客の数や前月に獲得した広告のクリック数が挙げられます。パイプラインはこれらのビジネス指標には直接影響しません。ビジネス KPI と技術的 KPI をマッピングする理由は、技術的な職人技とビジネスゴールの関係を理解するためです。

ビジネス KPI をパイプラインにマッピングすると、パイプラインの RoI (投資収益率) を計算するのに役立ちます。リーダーシップチームはこれらの指標を使用して改善の余地がある分野を把握し、予算を計画します。

ジャーニーに出発する