誰がリーダーで、誰がフォロワーか、イノベーションではっきりとさせる。

- スティーブ・ジョブズ

アーキテクチャーエピックの概要

アーキテクチャーエピックは、通常、現在と将来のビジネスニーズをサポートできるよう、ポートフォリオソリューションを発展させるために必要な、横断的かつ技術的な大きな取り組みである。承認されたアーキテクチャーエピックはアーキテクチャーエピックカンバンシステムのアウトプットであるポートフォリオバックログに保管され、管理される。カンバンシステムでは、アーキテクチャーエピックは成熟度のいくつかの状態を通して処理され、最終的に捨てられるか実装に移される。このプロセスにおいて、エピックの裏にあるビジネスと技術駆動力、技術的な影響、インクリメンタルな実装の戦略に関する合理的な経済性分析が行われる。

詳細

カンバンシステムを通過するエピックフロー

アーキテクチャーエピックは、まずアーキテクチャーエピックカンバンシステムに取り込まれ、仕掛かり作業(WIP)制限下で、このシステムを通っていく。 エピックオーナーはこの重要な活動を管理する。WIP制限があることで、責任のある分析を行うのに必要な時間が作業を行う人に与えられることを保証できる。同様に重要なのは、カンバンシステムが、新しい技術取り組みを実装するための適切なスコープと時間枠への期待を管理できることである。各エピックを実際に実装するかどうかの最終判断は、プログラムポートフォリオ管理チームが行う。そして、通常、バックログには常に複数の分析済みのエピックが実装待ちの状態になっているため、リソースが提供できる場合、意思決定者は一定数量の可能なビジネス機会から選択することができる。

分析

エピックはプログラムポートフォリオの主要な経済駆動力であるため、実装すると確約する前に、慎重に分析しなければならない。分析の待ち行列に空きができると、レビュー段階から最も価値のあるエピックが分析に引き渡される。分析では、工数と経済的影響をより詳細に定義し、重みづけされた最短作業から着手(WSJF)するという優先順位付け方法を適用し、コストの見積もりを確立し、軽量のビジネス企画を作成する。分析では以下のような作業を行う。

  • ビジネスの利害関係者と一緒にワークショップを行い、技術的なエピックに関するビジネス上のメリットを理解し、説明する
  • システムアーキテクトやアジャイルチームリーダーと一緒にワークショップを行い、実装の工数と既存システムへの影響を理解する
  • 具体例を作成し、曖昧さの問題を解決する(実例仕様)
  • エピックの成功基準を定義する

この分析の主要な目的はリスクを識別することである。特に複数のシステムにまたがるアーキテクチャーエピックにとって、これは特に重要である。図2に示すように、リスク分析はエピックの実装計画に影響を与える可能性がある(その一部は遅延コストが理由である)。

図2.複数のプロダクトにまたがる大きなエピックの実装に関する2つのシナリオ

分析段階の成果物は軽量のビジネス企画であり、それによって利害関係者であるスポンサー、販売と流通への影響、開発の工数、WSJF評価などを明示する。その後、適切な責任者がビジネス企画を使用して、エピックのゴーかストップかに関する意思決定を行う。

成功基準

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

通常ポートフォリオエピックは複数のアジャイルリリース列車リリースにまたがるので、フィーチャーの開発に関して進捗があるかを評価するのは難しい。そのため、SAFeではエピックの進捗を測るために使用できる一連の ポートフォリオメトリックスを用意している。

インクリメンタルな実装

エピックは、承認された後、1つまたは複数のリリース列車で実装のための空きができるまで、ポートフォリオバックログに保持パターンで保管される。その後、エピックオーナーは責任を持って、プロダクト管理者システムアーキテクトと一緒に作業し、エピックをプログラムエピックや新しいアーキテクチャーフィーチャーに分割し、プログラムバックログを作成する。

従来のやり方では、システムの全般的なアーキテクチャー変更を実装することは概念的には簡単だった。つまり、新しいブランチを作成し、新規開発を開始して、どこかでベースラインにマージする、というものである。しかしアジャイルの場合は、そのように行わない。その代わりに、システムを継続的に再設計すると確約する。非常に短い期間であっても、滅多にブランチを作らない。これは複数のインクリメンタルな実装パスによって実現する。

インクリメンタルな実装のための戦略

システムアーキテクトのページと参考文献[1]で説明したように、以下の3つの可能性がある。

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

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

アーキテクチャーエピックはビジネス機能を提供するための技術プラットフォームを有効にすることによって、経済性がより良くなる。しかし、リスクを取らずに革新的なプロダクト開発を行うことはできず、初期の技術関連の決定が常に正しいとは限らない。したがって、アジャイル企業は、時折方向転換ができるよう、準備しておく必要がある。プロダクト開発フローの「サンクコストを無視する」の原則(参考文献[3]、第17原則)は、「既に費やした金額を考慮してはならない」という重要な指針となる。投資が大きくなりすぎない間に是正措置を取れるので、インクリメンタルな開発が役に立つ。スパイクを利用して調査を行うことも、方向修正のもう1つのアプローチである。インクリメンタルな実装を行うには、アーキテクチャーエピックをより小さなプログラムエピックアーキテクチャーフィーチャーに分割しなければならない。アーキテクチャーエピックとビジネスエピックの分割方法は別のページで説明する。


さらに知りたい場合

[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: 25 July 2014

This information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.