nav_Enabler

幸運とは準備と機会があったときに起こるものである。

– セネカ

 

イネイブラーの概要

イネイブラーとは、ビジネスの取り組みの開発を可能にし支えるための技術的取り組みである。イネイブラー(ビッグピクチャーで赤で示されているもの)は、SAFeの4つのレベルすべてに存在する。つまり、ポートフォリオレベルのイネイブラーエピック、価値のストリームレベルのイネイブラーシステム能力、プログラムレベルのイネイブラーフィーチャー、チームレベルのイネイブラーストーリーである。イネイブラーは、今後のビジネスフィーチャーを支えるために必要などのような作業にも使用できるが、概して次の3つに分類できる。

  1. 調査: 調査イネイブラーは、顧客が何を必要としているかを理解し、作成するソリューションを理解し、代替案を評価するために使われる。
  2. アーキテクチャー: アーキテクチャーイネイブラーは、開発をすばやくスムーズに行うためのアーキテクチャー滑走路を構築するために使われる。
  3. インフラ: インフライネイブラーは、開発およびテスト(ときには配置も)用の環境を構築/増強して、開発速度とテスト品質を向上するために使われる。

詳細

イネイブラーとは、今後のビジネスフィーチャーを効率的に開発および納品するために必要なすべての作業を記述して可視化した作業項目である。主に、調査、システムとソリューションのアーキテクチャーの進化、開発およびテスト環境の増強のために使われる(後のセクションを参照)。これは実際の(ときには多量の)作業を反映したものなので、隠すことはできない。付加価値のある他のすべての開発作業と同様に扱われるため、見積もり、可視化/追跡、WIP制限、フィードバック、最終的には結果発表の対象となる。

イネイブラーの種類

イネイブラーはフレームワーク内のすべてのレベルに存在する(赤色で示されているもの)。以下に示すように、対応する種類の作業の属性を継承する。

  • イネイブラーエピックは、一種のエピックなので、エピック用に定義されたエピック価値記述の書式を使って記述される。複数の価値のストリームやPIにまたがることが多い。実装をサポートするための軽量のビジネス企画を含まなければならず、ポートフォリオカンバンシステムを通じて特定および追跡される。
  • イネイブラーシステム能力およびイネイブラーフィーチャーは、価値のストリームレベルおよびプログラムレベルに現れ、その種類の作業として表現される。これは一種のフィーチャーまたはシステム能力なので、利点の記述や受け入れ基準など同じ属性を共有し、1つのPIに収まるようスケジュールしなければならない。
  • イネイブラーストーリーは、一種のストーリーなので、反復に収まる必要がある。ユーザーの声の書式は必要ないかもしれないが、要求を明らかにしテストをしやすくするための受け入れ基準を持つ。

イネイブラーは、対応するエピック、システム能力、フィーチャー、またはストーリーと同じ規則に従って記述し、優先順位を付ける。たとえば、フィーチャーとイネイブラーフィーチャーはどちらも、フィーチャーと利点のマトリックスを使って記述し、受け入れ基準を持ち、ストーリーポイントで見積もりし、WSJFで優先順位を付ける。

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

ほとんどのイネイブラーは、ビジネスの取り組みがさまざまなカンバンシステムを通り抜けるときに必要に応じて作成される。つまり、ニーズやソリューションを検証するために調査イネイブラーが、滑走路を整備するためにアーキテクチャーイネイブラーが、取り組みの開発やテストや統合のおぜん立てをするためにインフライネイブラーが作成される。

イネイブラーは、多くの場合、さまざまなレベルのアーキテクトやシステムエンジニアによって作成される。これは、ポートフォリオレベルではエンタープライズアーキテクト価値のストリームレベルプログラムレベルではソリューションおよびシステムアーキテクト/エンジニアリングである。イネイブラーを作成したアーキテクトは、そのイネイブラーをカンバンシステムに入れ、分析に必要な指針と見積もりおよび実装に必要な情報とを提供する。

イネイブラーの中には、既存ソリューションを改善したいというアジャイルチームやARTや価値のストリームのニーズの中から現れるものもある。カンバンシステムを通るイネイブラーは、ソリューションを先に進めることとアーキテクチャー滑走路を延長することのいずれかが軽んじられることがないよう、プログラムおよび価値のストリームのバックログにおける処理能力の割り当ての対象となる。処理能力の割り当ては、イネイブラーの作業全体を対象とすることも、イネイブラーの種類ごとに変えることも可能である。

イネイブラーの使用

調査

調査でイネイブラーを利用すると、開発チームは要求や設計の詳細を具体化することができる。ソリューションの意図では、多くの要求が最初は変動であるのが普通である。開発の開始時には、顧客が正確に何を必要としているかやそれをどう実装するかについて、ほとんど分かっていないためである。多くの場合、顧客自身が自分が何を欲しているかを正確には理解しておらず、反復的なプロダクト開発やデモを行ってはじめて実際に必要なものが理解されていく。

ソリューション側から考えると、ビジネスのニーズを実装する方法には多くの技術的選択肢がある。それらの選択肢を分析し、ときにはモデルやプロトタイプを作成したり、場合によっては複数のソリューション候補を同時に開発したりして(セットベースエンジニアリング)評価しなければならない。

アーキテクチャー

アーキテクチャー滑走路は、SAFeがアジャイルアーキテクチャーの概念を実現する手段の1つである。この滑走路は、適切な技術基盤の上でビジネスの取り組みをすばやく開発するための基礎となる。しかし、滑走路はビジネスのエピックや、フィーチャー、システム能力、ストーリーによって常に使われるため、絶えず保守しなければならない。イネイブラーは滑走路を拡張するためのバックログ項目となる。

このアーキテクチャーイネイブラーの一部は、たとえばパフォーマンスを向上しなければならないなど、ソリューションの既存の問題を解決するためのものである。これらのイネイブラーは、まずバックログに入れられるが、実装を行った後で非機能要求(NFR)になることがある。実際に、NFRの多くはアーキテクチャーイネイブラーの結果として発生する。これらは、図1に示すように、徐々に構築されることが多い。

Figure 1. Many nonfunctional requirements appear over time as a result of enablers
図1. 非機能要求の多くはイネイブラーの結果として徐々に現れる

インフラ

アジャイル開発は頻繁に統合しながら行われる。アジャイルチームは、反復ごとのシステムデモで、同じアジャイルリリース列車(ART)上の他のチームと作業を統合する。列車は、ソリューションデモ用に、プログラムインクリメント(PI)ごとに統合を行う。多くの企業では、さらに継続的インテグレーションを行って、ソリューションが常に動作することを確認し、統合ポイントでのリスクを低減している。

このように頻繁または継続的な統合と構成要素のテストを行うには、チームレベルプログラムレベル、および価値のストリームレベルでインフラを開発する必要がある。顧客リリースする速度を上げるために、新しいインフラが必要になることもある。アジャイルチームは、システムチームと協力して、このインフラを構築し保守する責任がある。インフライネイブラーをバックログ項目として使って、この作業を進め、継続的に増強する。これは、新しいシナリオをサポートするために行う場合でも、企業のアジャイルさを向上するために行う場合でも同じである。

アーキテクチャーイネイブラーのインクリメンタルな実装

アーキテクチャーイネイブラーの作業は大規模になりがちである。反復に収まる小さなイネイブラーストーリーに分解する必要があることを忘れてはならない。アーキテクチャーやインフラの変更が原因で、新しいアーキテクチャーやインフラが整うまで既存システムの動作が止まる可能性があるため、この作業は困難な場合がある。イネイブラーの作業の計画を立てるときには、ほとんどの時間はシステムが古いアーキテクチャーまたはインフラで動作できるよう、準備する必要がある。そうしておけば、イネイブラーの作業が行われている間も、チームは作業を継続し、統合やデモや、リリースまでも行うことができる。

システムおよびソリューションアーキテクト/エンジニアリングのページや参考文献[1]で説明されているように、3つの状況が考えられる。

  • ケースA:イネイブラーは大規模だが、インクリメンタルに実装する方法がある。システムは常に稼働している。
  • ケースB:イネイブラーは大規模で、完全にインクリメンタルには実装できない。システムをときどき止める必要がある。
  • ケースC:イネイブラーが非常に大きく、インクリメンタルに実装することは不可能である。システムは必要なときに稼働する。害を及ぼさない。

インクリメンタルなパターンの例は参考文献[2]の第2章でも紹介されている。そこでは、アセットをキャプチャーする、イベントを遮断するというような検証されたパターンを利用し、徐々にレガシーサブシステムを「潰していく」。

イネイブラーによりビジネス機能を納品するための技術プラットフォームを作成することで、経済性がより良くなる。しかし、リスクを取らずに革新的なプロダクト開発を行うことはできないため、初期の技術関連の意思決定が常に正しいとは限らない。したがって、アジャイル企業は、ときおり方向転換ができるよう、準備しておく必要がある。プロダクト開発フローの「サンクコストを無視する」の原則(参考文献[3]、E17原則)は、「既に費やした金額を考慮してはならない」という重要な指針となる。投資が大きくなりすぎない間に是正措置を取れるので、インクリメンタルな実装が役に立つ。

複数のARTや価値のストリームにまたがるイネイブラーの計画

イネイブラーエピックおよびイネイブラーシステム能力は、複数の価値のストリームやARTにまたがる可能性がある。カンバンシステムの分析フェーズで行わなければならない重要な意思決定の1つに、イネイブラーをすべての価値のストリーム/ARTで同時に実装するか、インクリメンタルに実装するかの判断がある。これは、ソリューションまたはシステムを一度に1つずつ実装してリスクを低減することと、完全なイネイブラーがないために生じる遅延コストとの、トレードオフである。その様子を図2に示す。

Figure 2. Two scenarios for implementing large enablers spanning multiple ARTs or VSs
図2. 複数のART/価値のストリームにまたがる大規模なイネイブラーを実装するための2つのシナリオ

さらに知りたい場合

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] Fowler, Martin. Strangler Application. http://martinfowler.com/bliki/StranglerApplication.html.

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

Last update: 10 December 2015