Develop on Cadence. Release on Demand.

—A SAFe mantra

リリースオンデマンド

リリースオンデマンドは、新機能を即時にまたはビジネスと顧客のニーズに基づいてインクリメンタルにリリースする、継続的デリバリーパイプラインの一側面です。

リリースオンデマンドは、継続的デリバリーパイプラインを構成する4つの側面、つまり継続的な探索（CE）、継続的な統合（CI）、継続的なデプロイメント、そしてリリースオンデマンド（図1）の最後の側面です。

図1 リリースオンデマンドは、継続的デリバリーパイプラインの最後の要素である

開発された明白なバリューは、エンドユーザーがその環境でソリューションを操作しているときにのみ発生するため、そのバリューを適切なタイミングでリリースすることは、エンタープライズがアジリティの真のベネフィットを得るために重要です。

何を、いつリリースするかの決定は、慎重な考慮を必要とする重要な経済的推進力となります。多くの人々にとって、「継続的デリバリー」は望ましい最終状態であり、新機能のデプロイメント直後にそのリリースができるようにします。しかし、より一般的には、リリースは特定のユーザー向けに、ユーザーが必要とするタイミングや、顧客とビジネスにとって最も経済的な意味を持つタイミングで行う、切り離された、オンデマンドのアクティビティです。

詳細

アジャイルプロダクトデリバリーのコンピテンシー記事は、「ケイデンスに基づく開発、リリースオンデマンド」の特性が、最適なタイミングと頻度で価値あるソリューションをエンドユーザーに提供する能力をどのように生み出すかを説明しています。それは、プロダクトマネジメントおよびソリューションマネジメントに対して次の三つの質問を提起します。

リリースはいつ行うべきか？
ソリューションのどの要素がリリースされるべきか？
どのエンドユーザーがリリースを受け取るべきか？

これらの質問に対するプロダクトマネジメントとソリューションマネジメントの回答は、顧客中心のマインドセットによって導かれます。

ロードマップ上の市場リズムと市場イベントは、リリースのタイミングを決定し、顧客のニーズと合わせることができる
プロダクトマネジメントは、特定の顧客セグメントに対してフィーチャーやシステム全体などのリリース要素をターゲットにする必要がある

リリースの分離は、特に外部の顧客を対象としたオペレーショナルバリューストリームに対して、ビジネスアジリティを促進する追加のベネフィットを提供します。例えば下記です。

プロダクトマーケティングは、特定の対象者に対してプロモーション活動をターゲットにすることができる
営業チームは、ソリューションのタイミングと機能性により確信を持って活動をスケジュールすることができる

リリースオンデマンドにおける4つのアクティビティ

図2は、オンデマンドでリリースする4つのプラクティスを示しています。

リリース - ソリューションをエンドユーザーに対し、一度にまたはインクリメンタルに提供するために必要なプラクティス
安定化と運用 - ソリューションが機能要件と非機能要件（NFR）の観点からうまく機能していることを確認する
測定 - 新たにリリースされた機能が意図したバリューを提供しているかをどのように定量化するか
学習 - フィードバックを収集し、次の継続的デリバリーパイプラインのループに備える

図2 リリースオンデマンドにおけるの4つのアクティビティ

顧客へのバリューのリリース

ソリューションが本番環境で検証されたら、それを顧客に利用可能にする時です。しかし、このバリューをリリースするタイミングは、早すぎるか遅すぎるかにより経済的に悪影響を及ぼす可能性があるため、重要なビジネス決定です。他のステークホルダーとのコラボレーションにより、プロダクトマネジメントはリリースプロセスを管理するポリシーを確立します。これには、品質が確認されたコードを自動的に顧客に即座に利用可能にするか、より正式なレビュープロセスを手動のゲートで維持するかが含まれます。システムが複雑になればなるほど、以前の重要な質問（何をリリースするか、誰に、いつ）の答えを決定するための手動のゲートが存在する可能性が高くなります。

以下のプラクティスはリリースする能力に貢献します。

ダークローンチ - ユーザーに機能をリリースせずに、本番環境へのデプロイメントを可能にする
フィーチャートグル - コードを「オン」または「オフ」にするためのメカニズムを提供し、追加のデプロイメントが不要になる
カナリアリリース - ソリューションを特定の顧客セグメントにリリースし、結果を測定してから、それをより多くの顧客にリリースするというプラクティス
切り離されたリリース要素 - このテクニックは、それぞれが独立してリリースできる特定のリリース要素を特定する。単純なソリューションでも、図3が示すように、それぞれが異なるリリース戦略で動作する複数のリリース要素が存在する

図3 ソリューションからリリース要素を切り離す

例えば、この記事をホストしているSAFeのウェブサイトには、複数のやや独立したリリースサイクルがあります。Scaled Agileは以下のことができます。

修正する - いつでも私たちのホスティングインフラストラクチャのセキュリティ問題（その場限り、迅速な、サービスのクラス）を修正する
更新する - いつでも任意の記事を更新し、ブログ投稿を通じて読者に通知（高頻度）
追加する- 新しいコンテンツをSAFe詳細ガイダンスに、利用可能なときはいつでも追加する（中頻度）
作成する- 新しいビッグピクチャーを含む、フレームワークへの重要な更新を作成する。これは、顧客が新しいバージョンを消費する能力と私たちの開発努力をバランスさせる頻度で行う（低頻度）

これらの別々のフロー -「バリューの小ストリーム」 - は、それぞれが自身のニーズとペースに応じてバリューを提供するように管理されるバリューストリーム内の完全なエンドツーエンドのバリューフローを表し続けます。ストリームレットを識別することは、リリースオンデマンドを可能にするために重要であり、それらはソリューションの異なる要素を別々のケイデンスで独立してリリースすることを可能にします。彼らはまた、チームとARTが自立してリリースオンデマンドできるように、組織の気づきを提供します。

安定化と運用

新たに検証され、デプロイされたソリューションに顧客がアクセスできるようになると、予期しない問題が発生します。使用量の増加や予期しない使用パターンがこれらの問題を引き起こす可能性があります。チームは、彼らのサービスレベル契約（SLA）内でインシデントとセキュリティ脅威を迅速に解決しなければなりません。ソリューションの運用を支援するいくつかのプラクティスは下記です。

サイト信頼性エンジニアリング（SRE） - 現代的で、デジタルを活用したソリューションは、しばしば世界中に広がるユーザー集団にサービスを提供する相互に関連する複雑なシステムのエコシステムで構成されている。サイト信頼性エンジニアリングは、ソフトウェアベースのツールを使用して運用活動を自動化することにより、これらのシステムの信頼性とスケーラビリティを向上させる。
フェイルオーバー / 障害復旧 - 障害は発生する。フェイルオーバーメカニズムを開発することは、サービスを迅速に再開させるため、またはサービスの中断を避けるために重要である。障害復旧は、計画され、サービスに組み込まれ、練習されなければならない。
継続的なセキュリティ監視 - コード化されたセキュリティおよびペネトレーションテストは、既知の脆弱性が本番環境に現れるのを防ぐことに焦点を当てている。しかし、新たに発見され報告された脆弱性に対してサービスを継続的にテストすること、そしてサービスとインフラストラクチャへの侵入や攻撃を検出することもまた、不可欠である。
運用のためのアーキテクトする - 企業は運用のニーズを考慮しなければならない。高負荷、セキュリティ攻撃、そしてインシデントへの対応は、サービスのダウングレードや削除からキャパシティの追加まで、さまざまな選択肢を促す。遠隔測定とログのケイパビリティは、組織が自身のアーキテクチャを理解し、改善し、進化する使用パターンに合わせて調整することを可能にする。
非機能要件（NFR）を監視する - サービスの中断を避けるために、チームは信頼性、パフォーマンス、スケーラビリティなどのシステム属性を継続的に監視する必要がある。

ビジネスバリューを測定する

継続的な探索の最初のアクティビティは、仮説作成 - そしてアプリケーションの遠隔測定を使用して、仮説が証明され、ビジネスバリューが提供されたかどうかを測定することです。この取り組みを支える2つのプラクティスがあります。

アプリケーションの遠隔測定 - アプリケーションの遠隔測定は、仮説に対するデータ使用量をトラックし、測定する主要なメカニズムである。
イノベーション会計 - 仮説の評価には、最終状態の機能するソリューションを測定するために使用されるメトリクスとは異なるメトリクスが必要である。イノベーション会計は、初期のインクリメンタルソリューション開発と実用最小限のプロダクト（MVP）の評価中に、アイデアの中間的で予測的なビジネスの成果を測定する。 (イノベーション会計の記事を参照。)

学習と応答

リリースから収集された情報は、継続的デリバリーパイプラインのループを閉じるために使用されます。プロダクトマネジメントは、このフィードバックを使用して、フィーチャーやエピックについての投資選択を行います。学習プロセスの一部は、バリューフローがどのように改善されるかについての情報を分析し、継続的デリバリーパイプラインを改善することです。フローの高速化とバリューの向上を達成するための3つのプラクティスがあります。

リーンスタートアップの考え方 - MVPとMMFのベネフィット仮説が評価される。証明されない場合、組織は開発の努力を続けるべきか、停止するべきか、または新しいアイデアに方針転換して、戦略を達成するための異なるアプローチを試すかを決定する。
バリューストリームマッピング - パイプライン全体でのバリューフローを改善するための重要なツールはバリューストリームマッピングである。このツールは、フローに対するボトルネックや問題領域を特定し、未来の状態を設計し、パイプラインを改善するためのイネーブラーを作成するために必要な可視性を提供する。
たゆまぬ改善 - ARTは、バリューフローを継続的に改善することができる。このマインドセットはSAFeコアバリューの一部であり、結果を達成するためには不可欠である。

顧客は、フィーチャーが手元にあるときだけバリューを把握します。このバリューが測定されると、新たな知識が進行中の探索努力に情報を提供し、サイクルが新たに始まります。 1つのフィーチャーにとって、これがパイプラインの終わりです。しかし、別の観点からは、これは始まりであり、継続的デリバリープロセスがユーザーに新たなバリューを、組織に新たな学びをもたらします。迅速なフィードバックを得ることはプロセスに組み込まれており、チームが市場のニーズに対応することを可能にします。

リリースガバナンス

リリースガバナンスは、ソリューションのリリースをプランニング、管理、そしてガバナンスするプロセスであり、これによりバリューストリームがビジネスの目標に向かってガイドされます。これは、一部の企業、特に重要な規制とコンプライアンス基準を持つ企業における、リリースがすべての関連ビジネス基準を満たすことを確認する中央集権的なポートフォリオ構成のSAFeチームまたは機能（「リリースマネジメント」は一般的な用語）です。

他の状況では、ARTとソリューショントレインのリーダーシップ、開発業務、品質、営業からのステークホルダー、および他のステークホルダーが、一部のリリースマネジメントとガバナンスの責任を引き受けます。

どちらの場合でも、リリースガバナンスは、内部および外部のステークホルダーが新しいソリューションを受け取り、デプロイするのを助け、ARTがデプロイメント前に重要なガバナンス品質要素を満たしていることを確認します。これには、内部および外部のセキュリティ、規制、およびその他のコンプライアンスの懸念が含まれます。

ARTはPIプランニング中にリリースをプランします。それが簡単です。難しさは、PIの複数のイテレーションにわたるフィーチャーの実装を調整することにあります。この課題は、新たな問題、障壁、依存関係、そしてビジョンとバックログのギャップが生じたときに特にあてはまります。これらの課題のため、各リリースのスコープは継続的に管理、再検証、そして伝達されなければなりません。主な考慮事項は下記です。

組織のリリースガバナンスが理解され、遵守されることを確認する
内部および外部のステークホルダーにリリースの状況を伝える
適切なデプロイメントプランが整っていることを確認する
マーケティングと連携し、内部および外部のコミュニケーションについてプロダクトとソリューションマネジメントと協力する
ソリューションが関連するソリューション品質とコンプライアンス基準を満たしていることを検証する
リリースプロセス、バリューストリームの生産性、およびソリューションの品質を向上させるために、インスペクト＆アダプト（I＆A）に参加する
リリースの最終承認を提供する
適切に、Lean Portfolio Management (LPM)との連絡役として行動する
最終リリースアクティビティへの参加と監督

多くの企業は、以下の質問に対処するために、定期的なケイデンスでリリースガバナンスの会議を開催します。

ビジョンはまだ理解されているか、そしてトレインとチームは最適に整列しているか？
自分たちが何を構築するのか理解しているか？そして、そのバリューストリームの目的と現在の戦略テーマとのベクトルは合っているか？
トレインは希望のリリース日に向けてトラッキングしているか？
そのソリューションには適切な作り込み品質が行われているか？
進捗状況をファシリテートするために、何の阻害要因を解決しなければならないのか？

PO（プロダクトオーナー）またはARTシンクは、シニアマネジメントに定期的にリリースの進捗状況を見せています。それはまた、リリースを確実にするために必要なスコープ、タイミング、人々、またはリソースの調整を承認する場所でもあります。より継続的デリバリー環境では、参加者はARTカンバンのリリースセクションを密接に監視します。彼らは、必要なときに正しい顧客セグメントにアイテムがリリースされることを確認し、カナリアとダークリリースを管理し、仮説を評価し、本番環境での検証後のフィーチャートグルの削除を確認します。

DevOpsでリリースオンデマンドを可能にする

このCDPの側面は、すべての上流の努力の累積バリューを明らかにし、継続的な探索で始まった学習ループを閉じます。すべての活動は、迅速でリスクが低く、ビジネスの成果に合わせて、迅速で正確なフィードバックのために最適化されていなければなりません。 DevOpsのプラクティスとツールは、デリバリーパイプラインの「最後のマイル」で非常に重要な反応性を可能にします。

図4は、SAFeのCALMRアプローチをDevOps（中央）といくつかのプラクティス分野（内側のリング）がリリースオンデマンドを可能にする方法を示しています。 4つの活動（緑色）のそれぞれは、ビジネスバリューを最大化し、学習を検証するために、複数の分野からのDevOpsの専門知識を活用する共同作業です。

図4 DevOpsはリリースオンデマンドを可能にする

「リリース」は、例えば、バージョン管理で保存されたインフラストラクチャのコンフィグレーションを使用してデプロイされたソリューションを即時に活性化すること、ソリューションの健康状態、セキュリティ、バリューについて運用チームに通知する積極的な監視、そしてSLAで指定された本番の問題からの迅速なリカバリーを必要とします。

DevOpsは、技術的なプラクティスとツールの異なる組み合わせを用いて、リリースオンデマンドの全4つの活動を可能にします。それがCDPをどのように権限を与えるかについての詳細なガイダンスについては、DevOpsの記事シリーズをご覧ください。継続的デリバリーパイプラインを実装し、DevOpsを適用しても、組織はまだ遅延に苦しむ可能性があり、ビジネスのニーズが求めるときに顧客にバリューを提供することが阻害されるかもしれません。詳細については、ARTフローの記事をご覧ください。そこでは、「途切れることのないバリューフローを実現する（原則＃6）」について説明しています。

詳しく学ぶ

Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Random House, Inc, 2011.

Womack, Jim. Gemba Walks Expanded 2nd Edition. Lean Enterprise Institute, Inc, 2019.

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series). Pearson Education, 2011.

Gothelf, Jeff, and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media, 2016.

最終更新： 2023年1月9日