nav_Epics

システムは管理されなければならない。システムの目標にすべての構成要素の努力を傾けるようにすることは、管理者の仕事である。

– W. Edwards Deming

エピックの概要

エピックは、重要な取り組みのためのコンテナであり、ポートフォリオの大きな狙いに向けて価値のストリームを導く役割をする。その過程で、企業にとっての経済的価値の多くが推進される。エピックは、規模が大きく、通常は横断的で、複数の価値のストリームやアジャイルリリース列車(ART)にまたがって実施される。集約的投資であり、その影響は広範囲にわたる。コスト、影響、機会の明確化と分析は重要な問題である。こういったことを考慮すると、エピックを実装する前に、軽量のビジネス企画を作成し財務承認を得る必要がある。エピックにはビジネスエピックとイネイブラーエピックの2種類があり、ポートフォリオ、価値のストリーム、プログラムの各レベルで使用される。

このページの大部分は、ポートフォリオエピックの定義、表現、実装についての説明にあてられている。規模も影響もポートフォリオエピックが最も大きいためである。ポートフォリオエピックは、ポートフォリオカンバンを通って作成、管理される。ポートフォリオカンバンの中でさまざまな成熟状態を通って処理され、最終的に拒否または承認される。承認されるとポートフォリオバックログに入れられて、そこで実装を待つ。このプロセスでは、エピックの背後にあるビジネス要因、技術的影響、インクリメンタルな実装の戦略について、合理的な経済性分析が行われていることを前提としている。

価値のストリームエピックとプログラムエピックについても同様に扱う必要がある。これらについてもこのページで説明する。

詳細

ポートフォリオエピック

規模の最も大きいエピック、つまりポートフォリオのビジネスエピックとイネイブラーエピックでは、ポートフォリオ内で発生する最大規模の横断的取り組みについて記述する。ビジネスエピックは直接的にビジネス価値を納品するものであり、イネイブラーエピックは今後のビジネスエピックを支えるアーキテクチャー滑走路を進化させるためのものである。

これらのエピックは、最初、ポートフォリオカンバンに保存され、仕掛かり作業(WIP)制限のもとでこのカンバンシステムを通り抜ける。こうすることで、作業の担当者は、責任を持って分析をするのに必要な時間を得ることができる。また、同じように重要な点として、カンバンシステムは新しいビジネス上の思い付きを実装するための妥当なスコープおよび時間枠の見込みを管理するのに役立つ。各エピックを実際に実装するかどうかの最終判断は、プログラムポートフォリオ管理(PPM)の権限に委ねられる。リソースに空きが出ると、意思決定者は、いくつかの潜在的ビジネス機会の中から最善のものを選ぶことができる。通常は、常に複数の分析済みエピックがバックログに含まれているためである。承認されたエピックはポートフォリオバックログに進み、そこで実装のための処理能力に空きが出るのを待つ。

図1はエピック価値記述のテンプレートである。これを使って、エピックに関する主要情報を記述し、整理し、伝えることができる。この記述はカンバンのレビュー状態で作成するが、その意図は、提案された取り組みについて有意義な話し合いをするのにちょうど良い量の情報を提供することである。

Figure 1. Epic Value Statement template format
図1. エピック価値記述のテンプレート

分析

エピックはポートフォリオ内で最も重要な取り組みであるため、実装を確約する前に、慎重に分析しなければならない。この重要な作業の責任を負うのはエピックオーナーだが、ビジネスエピックの技術面をサポートするイネイブラーエピックはエンタープライズアーキテクトが主導する。分析の待ち行列に空きができると、バックログから最も価値のあるエピックが分析に引き渡される。分析では、工数と経済的影響をより詳細に定義し、WSJFの優先順位付けを練り直し、コストの見積もりを確立し、軽量のビジネス企画を作成する。分析では以下のような作業を行う。

  • ビジネス利害関係者と一緒にワークショップを行い、ビジネスエピックに関するビジネス上の利点を理解し、記述する。
  • 価値のストリームおよびプログラムレベルアーキテクトやシステムエンジニアアジャイルチームと一緒にワークショップを行い、実装の工数と現在のソリューションへの影響を理解する。他にも関連するSMEが参加することもある。
  • チームはスパイクの実装や研究/調査作業を行う。
  • 具体例を作成し、曖昧な点を解決する(実例仕様)。)
  • エピックの成功基準を定義する。

分析段階の成果物は、概要(検討し直したもの)、成功基準、実装の時間および費用の見積もり、プログラムの影響などを含む分析結果を記述した、軽量のビジネス企画である。この書式の例を図2に示す。その後、適切な権限を持つ人がこのビジネス企画を使って、エピックを進めるか止めるかの判断をする。

Figure 2. Epic lightweight business case
図2. エピックの軽量ビジネス企画

[wpdm_file id=104]

成功基準

エピック価値記述と軽量ビジネス企画のどちらにもエピックの成功基準が含まれていて、実装が完了して成功しているかどうかの検証に使用することができる。ポートフォリオエピックは本質的に大きくて抽象的になりがちなので、成功基準を定義することは重要である。これによって、ビジネスにとってこのエピックは実際にどのような意味があるかに関する共通認識が利害関係者の間にできあがる。

抽象的な成功基準に注意

ただしエピックは、システム能力やフィーチャーと違って、エピックを完成させる必要がないことが多く、そのため成功基準については注意が必要である。スコープや影響が大きいことから、エピックのすべてではなく一部を実装することで経済的価値の大部分を達成できる場合もあり、WSJFで考えると、予定通りにエピックを完成させるよりも別のものに投資した方が経済的利益が大きくなるポイントが存在する可能性がある。
たとえば、我々の経験では、「すべてのアプリケーションをJBoss Webサーバーを使うように移行する」というエピックは、「寿命が近付いてきているアプリケーションを除くすべてのアプリケーションをJBoss Webサーバーに移行する」とした方がよい。

進捗の測定

エピックは通常、複数の価値のストリームやプログラムインクリメントにまたがって実施されるため、そのシステム能力やフィーチャーの開発がどの程度進捗しているかを判断するのが困難な場合がある。そのためSAFeでは、エピックの進捗を測定するのに使用できる一連のポートフォリオメトリックスを用意している。

インクリメンタルな実装

承認されたエピックは、1つまたは複数の価値のストリームで実装の処理能力に空きができるまで、ポートフォリオバックログにとどまる。その後、エピックオーナーやエンタープライズアーキテクトは責任を持って、プロダクト管理者やアーキテクト/システムエンジニアと協力してエピックを価値のストリームレベルやプログラムレベルのエピックに分割する。あるいはシステム能力やフィーチャーというバックログ項目に直接分割することもある。

エピックの分割

インクリメンタルに実装するには、エピックをインクリメンタルな価値を表す小さな部分に分割しなければならない。表1に、エピックを分割するために推奨している9つの方法と、それぞれの例を示す。

1. ソリューション/サブシステム/コンポーネント– エピックは、複数のソリューションやサブシステムや大規模コンポーネントに影響することが多い。その場合、該当する側面を分割することで、効率的に実装することができる。
複数のユーザープロファイル … opt-out Webサイトでの複数のユーザープロファイル
…adminシステムでの複数のユーザープロファイル
2. 成功基準– エピックの成功基準には、期待されるビジネス価値をインクリメンタルに達成する方法のヒントが示されていることが多い。
検索結果に新しい成果物を含めるよう実装する:場所の成功基準
a) あいまいさを解消するための他の方法が役に立たないときに、追加のフィルタリング手段として住所を使用できる。
b) 人の詳細な住所を提供する。
検索結果に州の情報を提供する (州だけでもすでにフィルタリングが提供されているので、「成功基準「a」は部分的に満たされる)
住所の複数部分の実装:主と市(これで成功基準全体が満たされる)
3. 主作業を最初に行う エピックを複数の部分に分けたときに、ほとんどの作業が最初の部分の実装に費やされる場合がある。
スイート内のすべてのプロダクトで共通するシングルサインオンを実装する PINGIDプロトコルサーバをインストールし、モックアイデンティティプロバイダでテストする
もっとも単純なプロダクトにSSO管理機能を実装する
もっとも複雑なプロダクトにSSO管理機能を実装する
バックログの処理能力が許す限り迅速に広げていく
4. 単純/複雑 – 最も単純なものを独立したエピックとし、すべてのバリエーションや複雑なものに対応するためのプログラムエピック群を追加する。
5. データのバリエーション – データのバリエーションやデータソースも、スコープ、複雑さ、実装管理に影響を与える。
すべてのエンドユーザー画面を国際化する … スペイン語
… 日本語
… 他はその時点での市場シェアに応じた優先順位で対応する
6. 市場セグメント/顧客/ユーザー種別 – 市場や顧客ベースでエピックを分割することもできる。ビジネス上の影響が大きいものから先に行う。
opt-in機能を実装する … 現在のパートナー向け
… すべての主要市場向け
7. ソリューション品質(NFR)を後回しにする – 場合によっては、初期の実装はそれほど難しくなく、労力の大半は速度、信頼性、正確性、拡張性などの向上に費やされる。そのため、ソリューション品質(非機能要求)をインクリメンタルに達成することを検討するとよい。
8. リスク低減/機会強化 – エピックはスコープが広いため本質的にリスクが高いことがある。リスク分析を行って、最もリスクの高い部分から先に行う。
複雑なユーザー定義の式で検索結果をフィルタリングする機能を実装する … 否定のフィルタリングを実装する
… すべての論理演算を使用できる複雑なフィルタリング式を実装する
9. ユースケースシナリオ – アジャイルでは、ユーザー対ソリューションまたはソリューション対ソリューションの複雑なやり取りを記述するために、ユースケース[1]を使用できる。ユースケースの具体的なシナリオユーザー目的ごとに分割する。
人のつながりを検索する機能 (目的1~)Find connection to a person
(目的2~)会社との結び付きを検索する
(目的3~)結び付きの強弱を区別する

表1. エピックの分割方法

エピックへの投資の承認

SAFeを構成するシステムにおいて、エピックにはもう1つ重要な役割がある。具体的に言うと、エピックはそもそもの定義からして、ポートフォリオ利害関係者の財務承認が必要である。これは価値のストリームの予算が承認されている場合でも同じである。そもそもリーン-アジャイルな予算編成(価値のストリームに財源を直接割り当てて、その中の取り組みに支出を割り当てる権限を価値のストリームの利害関係者に委譲する)を行えるかどうかも、システム内の抑制と均衡にかかっている。その1つとして、大きな支出項目は、価値のストリームの予算内で対処できるとしても、やはり目に見えるように承認する必要がある。その過程でエピックは重要な役割を果たす。エピックは相当な量のリソースを消費するし、技術戦略またはビジネス戦略の変更を伴うことも珍しくないためである。そのような大規模な支出項目を協調して承認するのは、権限委譲をする方もされる方も含めた全員の義務である。詳細は予算のページを参照のこと。

プログラムエピックと価値のストリームエピック

ここまでの説明では、もっとも影響の大きい種類のエピックであるポートフォリオエピックについて取り上げた。ポートフォリオエピックの多くから、価値のストリームエピックと、さらにそれに対応するプログラムエピックが作成される。また、大規模な取り組み(エピック)の多くは、価値のストリームやプログラムのレベルで局所的に生じる。大部分は局所的な問題だが、それが財務、人、その他のリソースに及ぼす影響は範囲が広く、軽量ビジネス企画を作成して議論し、PPMの財務承認を得るだけの理由となる。それがエピックをエピックたらしめる理由である。しかし、価値のストリームエピックおよびプログラムエピックの場合、分割、実装、管理のプラクティスは、主に局所的な問題である。これらのレベルでエピックを管理する手法については、プログラムと価値のストリームのカンバンシステムのページで説明する。


さらに知りたい場合

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

Last Update: 4 November 2015