継続的デリバリーのビジネス価値

Continuous delivery improves velocity, productivity, and sustainability of development teams.

Juni Mukherjee Juni Mukherjee

継続的デリバリーが必要な理由

What emotions does the word "release" trigger in you? Relief? Elation? A fist-pumping sense of accomplishment? When new features are finally out to customers and bugs are fixed, everyone's happy, right? Well, the dark secret in many organizations is that shipping a release takes a huge amount of effort. If your team is still living with manual testing to prepare for releases and manual or semi-scripted deploys to perform them, your feelings may be closer to "dread" and "blinding rage".

Emotional cycle of manual delivery screenshot | Atlassian CI/CD

それがソフトウェア開発が継続性に向かう理由です。継続的なパラダイムでは、高品質な製品が頻繁かつ想定通りに顧客に向けてリリースされます。したがって、リリースに伴うセレモニーとリスクが減少します。日々パイプラインに依存していれば、数週間または数か月に一度実行される場合よりもはるかに早く欠陥に気付き、解決できます。つまり、製品リリースの頻度を増やすことで問題を減らすことができます。

The emphasis on continuous integration, continuous testing, constant monitoring, and pipeline analytics all point toward an overall trend in the software industry - increasing your ability to react to market changes. Make no mistake - CD is not the exclusive domain of "unicorn" companies and tech darlings. Every team – from the humblest start-up to the stodgiest enterprise – can and should practice continuous delivery.

この記事ではこうした切り替えに関するビジネスケースを見ていきます。必要となる作業と、CD パイプラインを使用してソフトウェアをリリースすることによるメリットを説明します。

継続的デリバリーの主なビジネス上のメリット

継続的デリバリーはソフトウェア開発チームのベロシティ、生産性、持続性を向上させます。

First off, velocity

Automated software delivery pipelines help organizations respond to market changes better. The need for speed is of utmost importance to reduce shelf time of new features. With a low Time2Market, organizations have a better chance to outmaneuver their competition and stay in business.

Remember that speed by itself is not a success metric. Without quality, speed is useless. There is no value in having continuous delivery pipelines shoot erroneous code into production at speed.

セキュリティバグ

So, in the world of continuous delivery, velocity means responsible speed, and not suicidal speed.

第 2 に生産性

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

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

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

Software Development

Third, sustainability

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

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

Top challenges of continuous delivery

継続的デリバリーが正しいことは間違いありませんが、弾力性のある継続的デリバリーのパイプラインを設計して構築することはときに組織にとって困難です。CD は、技術的プロセス、運用上の文化、組織的思考の大規模なオーバーホールを必要とするため、しばしば開始時に大きなハードルがあるように感じられることがあります。長年にわたって放置されている可能性が高い、会社のソフトウェア配信インフラに対して多額の投資が必要になるという事実からも、さらに受け入れがたく感じられる場合があります。

There are many problems that organizations face and the following three are the most common pitfalls - budget, people, and priority.

予算: 少なすぎますか?

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

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

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

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

Teams should fearlessly automate themselves out of their jobs, and move on to new projects. If you have people who are apprehensive of automated agents performing tasks they were otherwise doing manually, you are housing the wrong people.

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

優先順位の欠如

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

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

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

Pipelines are hygiene. If you want to stay in business, ask yourself “Is hygiene important?”. You bet it is!

継続的デリバリーの指標

OLTP (オンライントランザクション処理) および OLAP (オンライン分析処理) は業界でよく知られた 2 つの手法です。どちらの概念も継続的デリバリーのパイプラインに適用でき、組織を正しい方向に導く分析を得るのに役立ちます。具体的に見ていきましょう。

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

Imagine a typical day in a software development team’s life. The team commits a feature that business prioritized, commits tests for that feature, and integrates deployments with the continuous delivery pipeline, so that every change deploys automatically. The team realizes that the application got sluggish after adding this new feature, and commits a fix for the performance issue. The team also adds performance tests to make sure that bad response times would get caught before promoting the application from test to staging.

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

専門職

次のセクションでは、パイプライン分析とこれらのトランザクションデータの有効な活用方法について説明します。

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

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

Like with all transactional data, the sheer volume prevents us from making any sense. That’s why we should aggregate, and perform analytics to glean insights into our organization. Analytics help us see the forest through the trees, and here are three examples how we improved our practices from pipeline analytics and insights.

Out of the hundreds of deployments that happen every week, we learned that the number of deployment failures of application A are thrice as high as those of application B. This discovery led us to investigate application A’s design choices on environment stability and configuration management. We learned that the team used flaky virtual machines in their data center to deploy, while application B was containerized. We prioritized an investment into immutable infrastructure and checked back in a month to make sure the return on that investment was good. Sure enough, it was. What can be measured, can be fixed.

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

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

主要業績指標 (KPI)

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

組織的 KPI と部門的 KPI

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

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

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

The percentage of failures in staging due to performance tests could be high, and it could be due to incorrect performance benchmarks or sluggish code. A comparative analysis might show that pipelines fail the most on integration smoke tests in production, and that would warrant an investigation. The root cause could be real bugs in the product or could be buggy test code, inaccurate test data, incorrect test configuration, misunderstandings between product and engineering, and the like.

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

安定性指標

Once we define KPIs, it is critical for us to understand if a single KPI has bias and skews heavily in any one particular direction. In case it does, we need to balance it with other KPIs that puts the center of gravity close to the middle. One such KPI is stability.

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

Measure CheckIn2GoLive via pipelines, since this can be approximated by the time a pipeline takes to promote code from test to staging to production. Additionally, CheckIn2GoLive also reflects MTTR (mean time to resolve) defects, since the bug fix travels through the same pipeline from test to staging to production.

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

Business defines stability by customer satisfaction or the number of repeat customers. While this sounds subjective, you can approximate this metric by the number of defects raised by customers or with customer feedback surveys.

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

Code quality index

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

ビジネス KPI と技術的 KPI

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

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

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

ジャーニーに出発する

継続的デリバリーが適切なのか、継続的インテグレーションで十分なのか、継続的なデプロイが最上なのか、といった議論で時間を無駄にするのはやめましょう。それを見極めるのは今です。尻込みしていてはやがてビジネスは失速し、自分を責めるほかなくなります。現在導入に向けてどの地点にいるかはあまり問題ではありません。導入に乗り出したということは、チームが継続的に成長する機会が得られたということです。恐れることなく実験できるようになり、視野が広がります。従業員がリリースに向けて真夜中まで働き続けて燃え尽きてしまうことなく、または絶えずバラバラに崩れる建物を支えるような仕事でなく世界をより良くするために働けるようにすることを考えるなら、その価値は明白です。そう思いませんか?