Luck is what happens when preparation meets opportunity.

—Widely attributed to Seneca, Roman philosopher and playwright

イネーブラー

Definition: Enablers are backlog items that extend the architectural runway of the solution under development or improve the performance of the development value stream.

イネーブラーは、エピック、ケイパビリティ、フィーチャー、またはストーリーのタイプとしてバックログに記録されます。主に探索、アーキテクチャの実装、リファクタリング、インフラストラクチャの構築、そしてコンプライアンスへの対応のために使用されます。イネーブラーのタイプはユニークですが、顧客対応のバックログ項目と同様に管理されます。

詳細

イネーブラーは、将来のビジネス要件の効率的な開発とデリバリーをサポートするために必要なすべての仕事を可視化します。イネーブラーは、アイデアを探求し、アーキテクチャを改善し、インフラストラクチャを強化し、コンプライアンスを管理するために使用されます。イネーブラーは有形のアウトプットを生みだすため、イネーブラーは目に見える必要があります。それらは可視性、優先順位付け、インクリメンタルデリバリー、測定、そしてフィードバックの面で、他のすべてのバックログ項目と同様に扱われます。

イネーブラーの種類

イネーブラーは、予見可能なビジネスニーズを支えるバリューストリームを改善するあらゆるアクティビティを定義するために使用できます。これらのアクティビティは、一般的に以下の4つのカテゴリーのいずれかに分類されます。

探索 – 研究、プロトタイピング、および顧客のニーズを理解するために必要な他のアクティビティをサポートします。見込みのあるソリューションの探索や代替案の評価を含みます
アーキテクチャ – アーキテクチャランウェイを構築するために使用されます。これにより継続的デリバリーパイプライン（CDP）を通じてスムーズで速い開発が可能になります。
インフラストラクチャ – システムがソリューションを構築、検証、デプロイ、そして運用するために使用される開発環境とランタイム環境の作成と最適化をサポートします
コンプライアンス – 検証と妥当性確認（V&V）、監査と承認、およびポリシーの自動化を含む特定のコンプライアンスアクティビティの管理を容易にします

イネーブラーの作成と管理

イネーブラーはSAFe全体に存在し、それぞれの対応するエピック、フィーチャー、ケイパビリティ、ストーリーと同じルールに従って書かれ、優先順位を付けられます。

イネーブラーエピック - これらは「エピック仮説ステートメント」形式を使用して書かれ、ビジネスエピックと同じ方法で書かれます。イネーブラーエピックは、複数のアジャイルリリーストレイン（ART）とPIにまたがることができ、ポートフォリオバックログおよび関連するカンバンシステムを通じて管理されます。
イネーブラーフィーチャーとケイパビリティ - これらはARTとソリューショントレインによって定義され、短いフレーズ、ベネフィット仮説、受け入れ基準を含みます。それらは単一のPI内に収まるようにサイズ調整されなければなりません。
イネーブラーストーリー - どんなストーリーと同じように、イテレーション内に収まらなければなりません。ユーザーボイス形式を必要としないかもしれませんが、その受け入れ基準は要件を明確にし、テストをサポートします。

アーキテクトは、しばしばイネーブラーエピック、フィーチャー、ケイパビリティを定義し、手引きします。アーキテクトは、ポートフォリオをサポートするエンタープライズアーキテクト、ARTをサポートするシステムアーキテクト、またはソリューショントレインをサポートするソリューションアーキテクトかもしれません。アーキテクトは、適切なカンバンシステムとバックログを通じてイネーブラーを導き、コンセプトからデリバリーまでの実装を手引きします。アジャイルチームもイネーブラーを使用します。イネーブラーストーリーは、チームのニーズから局所的に浮かび上がり、チームバックログに記載されます。

以下の例は、アジャイルチームとアーキテクトが4つのイネーブラータイプを作成し管理する方法を示しています。

探索を有効にする

探索イネーブラーは、要件や設計の詳細を発見するためにチームが使用できる作業項目を提供します。ソリューションインテントの性質は、多くの要件が可変の意図から始まるということです。開発の初期段階では、顧客が何を必要としているのか、またそれをどのように実装するのかについてはほとんど知られていません。顧客自身が、自分たちが何を正確に必要としているのかをしばしば理解していません。継続的な探索を通じて、チームはソリューションインテントのどの側面を可変から固定に移行すべきかを徐々に学びます。

さらに広い視野で見ると、特定のビジネスニーズや機会を実装するための技術的な可能性は一般的に多数存在します。それらの代替案は分析され、モデリング、プロトタイピング、セットベースデザイン、またはリーンスタートアップサイクルを通じて評価されることがよくあります。探索イネーブラーは、これらのアクティビティを形式化し、仕事が可視化されることを保証し、ソリューションの開発が顧客とステークホルダーのニーズと密接に連携していることを確認するのに役立ちます。

アーキテクチャを有効にする

SAFeでは、アジャイルアーキテクチャのプラクティスがアーキテクチャランウェイを生み出し、それがアジャイルチームとARTが迅速にビジネスソリューションを提供するための基盤技術となります。しかし、ランウェイは常にビジネスのエピック、フィーチャー、ケイパビリティ、そしてストーリーによって消費されているため、新しい機能のために拡張される必要があります。アーキテクチャイネーブラーは、ランウェイを構築し、拡張し、維持するために使用されます。

アーキテクチャのイネーブラーは、デプロイされたソリューションの回復力に関する問題にも対処できます。実装後、これらのイネーブラーはしばしば将来のバックログ項目に課される非機能要件（NFR）を反映します。 NFRは、しばしばアーキテクチャのイネーブラーとして発生し、時間とともに組になって成長します（図1）。

図1 時間の経過とともにイネーブラーの結果として現れる多くの非機能要件

インフラストラクチャを有効にする

アジャイル開発は頻繁な統合を必要とします。アジャイルチームは、仕事を統合し、システムデモで動作するソリューションインクリメントを披露します。同様に、ソリューショントレインの一部であるARTは、ソリューションデモの準備として、PI中に可能な限り頻繁に自分たちの仕事を統合します。インフラストラクチャイネーブラーは、この積極的な統合ケイデンスを支える継続的な統合および継続的なデプロイメント技術を提供します。

システムチームは、開発環境を強化し、CDPを効率化するためのインフラストラクチャイネーブラーを定義し構築する上で不可欠です。シェアードサービス、運用チーム、およびサイト信頼性エンジニアリング（SRE）は、インフラストラクチャイネーブラーを活用してソリューションの開発とソリューションの拡張性を加速するクラウドサービスを提供します。

コンプライアンスを有効にする

一連のPIを通じてソリューションインテントで必要なアーティファクトをインクリメンタルに構築することで、SAFeは継続的な検証と妥当性確認を支援します。検証アクティビティは開発ワークフローの一部として行われ、しばしば完了の定義（DoD）によって強制されます。アーティファクトは開発の終わりに必要とされる客観的な証拠を満たしますが、ライフサイクル全体を通じて反復的に作成されます。妥当性確認は、プロダクトオーナー、顧客、エンドユーザーがARTプランニングとシステムデモに参加し、目的に適しているかの妥当性を確認する際に行われます。

これらのアクティビティをサポートするためにイネーブラーが使用されます。例えば、デザインのレビューを必要とする規制や、そのレビューから生じるすべてのアクションが完了した際に文書化されなければならないという規制を考えてみてください。「デザインレビューイネーブラー」のバックログ項目は、レビューの証拠を提供し、その完了の定義（DoD）は、アクションがリーン品質管理システム（QMS）に従って記録され、解決されることを保証します。必要であれば、アクティビティ自体がイネーブラーのストーリーとしてトラックされることもあります。

イネーブラーをインクリメンタルに実装する

イネーブラーは、基盤となる重要なテクノロジーとバリューストリームへの気付きを提供します。その結果、イネーブラーはポートフォリオの中で、予算編成やキャパシティの割り当てからデリバリー、そして継続的な改善まで、集中的な注意を必要とします。しかし、イネーブラーの実際の価値は将来のビジネス目標の実現に結び付いているため、イネーブラーを迅速かつ反復的に実装することに注意を払う必要があります。それ以外の場合、顧客へのバリューの提供は大幅に遅延する可能性があり、イネーブラーの基本的な目的を損なう可能性があります。

すべてのタイプのイネーブラーは、インクリメンタルに実装するべきです。しかし、アーキテクチャイネーブラーとインフラストラクチャイネーブラーは、ミッションクリティカルなソリューションのデリバリーと運用にしばしば影響を与えるため、ここでは特別に言及する価値があります。

アーキテクチャーとインフラストラクチャイネーブラーの仕事の規模と要求は圧倒的に大きくなることがあります。したがって、それらをフィーチャーとストーリーとに分割し、インクリメンタルに提供できるようにすることが重要であることを覚えておく必要があります。これは難しい場合があります。なぜなら、アーキテクチャーおよびインフラストラクチャの変更がその変更が完了するまで既存のシステムの動作を停止させる可能性があるからです。

イネーブラーが実装されている間もシステムが現在の環境で運用を続けられるように、仕事は優先順位を付ける必要があります。そうすることで、チームは仕事を続け、統合し、デモを行い、さらに新しい機能をリリースすることができます。

これに対するアプローチは3つあります[1]。

ケースA – イネーブラーは大きいですが、インクリメンタルに実装するアプローチがあります。システムは常に動作（運用）します。
ケースB - イネーブラーは大きく、インクリメンタルに実装することはできません。システムは、時々中断する必要があります。
ケースC – イネーブラーは本当に大きく、インクリメンタルに実装することはできません。必要な時にシステムは動作します。

[2]にもインクリメンタルなパターンの例が記述されており、そこではアセットキャプチャやイベントインターセプションなどの実証済みパターンを使用してレガシーサブシステムが時間とともに徐々に「抑圧されて」いきます。

ビジネス機能を提供するテクノロジープラットフォームを作成することにより、イネーブラーの経済性は向上します。しかし、革新的なプロダクト開発はリスクを取らなければ生じません。初期の技術関連の決定が常に正しいとは限りません。これが、リーンエンタープライズが時折コースを変更する準備をしなければならない理由です。これらのケースでは、サンクコストの原則[3]が重要な指針を提供します。すでに使ったお金は考慮しないでください。インクリメンタルに実装することで、投資が大きくなりすぎる前に是正措置を取ることができます。

ARTとバリューストリーム全体でイネーブラーを実装する

イネーブラーエピックとケイパビリティは、複数のバリューストリームまたはARTを横断することができます。適切なカンバンシステムの分析段階では、ART全体でイネーブラーを同時にまたはインクリメンタルに実装するかどうかを決定することが重要です（図2）。

図2 横断的なイネーブラーを実装するための2つのアプローチ

シナリオAでは、イネーブラーは最初にART 1で実装され、その後のPIでは他のARTによって実装されます。これはポートフォリオ全体にわたる変更の影響を軽減するかもしれませんが、完全に実装されたイネーブラーの全ベネフィットを遅延させる可能性があります。それに対してシナリオBでは、すべてのARTが同時にイネーブラーを実装することを求めています。これは、全体の実装を遅延させるコストが許容できないほど高い場合に適しています。

詳しく学ぶ

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional, 2010.

[2] Fowler, Martin. Strangler Fig Application. MartinFowler.com, June 29, 2004. Retrieved October 13, 2023, from http://martinfowler.com/bliki/StranglerApplication.html

[3] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

最終更新: 2023年10月13日