Program Level

システムが自らを管理することができないから、人がシステムを管理しなければならない。放置すると、システムの構成要素は、利己的になり、互いに競争し、別々のプロフィットセンターになり、かくしてシステムを破壊してしまう …秘訣は、組織の目的に向け構成要素間で協力を図ることである。

– エドワーズ・デミング

プログラムレベルの概要

プログラムレベルでは、開発チームやその他のリソースが、継続中の重要な開発の使命に充てられる。SAFeのプログラムレベルのチームや役割や作業は、アジャイルリリース列車(ART)というメタファーを中心として構成される。このアジャイルリリース列車は、価値を継続的なフローとしてインクリメンタルにリリースする、複数のアジャイルチームからなるチームである。アジャイルリリース列車とは、SAFeのリーン-アジャイルな原則およびプラクティスを実施することで、職務の境界を超え、不必要な引き継ぎや手順をなくし、より早く価値を納品することを目的に作られた、仮想の組織である。

プログラムレベルと呼ばれるものの、ARTは一般に、開始日と終了日を持ち一時的にリソースが割り当てられる従来の「プログラム」と比べると、非常に寿命が長く、そのため自己組織化や構造や使命がより持続的である。SAFeのポートフォリオが効果的なのは、長期的、フローベース、自己組織化というARTの性質のおかげである。

詳細

SAFeにおける価値は、寿命の長いアジャイルリリース列車によって納品される。それぞれの列車は価値のストリームの一部(場合によっては価値のストリーム全体)を実現する。アジャイルリリース列車は期間が8~12週間のプログラムインクリメント(PI)の中でインクリメンタルに価値を納品する。各PIは複数の反復からなる時間枠で、この時間枠の中でシステムの重要で価値のあるインクリメントが開発される。各ARTは、5~12のアジャイルチーム(人数は50~125人以上)から構成され、完全にテストの済んだシステムレベルの動くソフトウェアを納品するのに必要な役割とインフラを含む。多くのリリース列車は、仮想的であり、組織や地理の境界をまたいで存在する。事業ラインやプロダクトラインの管理報告系統に沿って作られることもある。

価値のフローの管理

プログラムレベルの第一の責任は、ビジネスがビジョンロードマップを実現するのに必要なフィーチャーイネイブラーを発見し、定義し、開発することである。この作業のフローを管理し、すべての利害関係者に対して可視化できるよう、SAFeではプログラムカンバンシステムを用意している。このシステムを使うことで、PI境界に達する前にフィーチャーの論理的な検討と分析が済んでいること、その後フィーチャーに適切な優先順位が付けられること、高精度の実装を行えるよう受け入れ基準が確立されていることを保証できる。

フィーチャーは、プログラムバックログの中に保管され、優先順位が付けられる。実装時には、各プログラムインクリメントで概念的に整合のとれた新しい機能を納品できるよう、PIに合わせてフィーチャーのサイズが調整される。フィーチャーは、1つの反復の間に1つのチームによって処理される ストーリーと、複数のARTにまたがることもある価値のストリームレベルのサービスを表すシステム能力との間に位置する。

主な役割

アジャイルリリース列車とは、計画や確約や実施を一緒に行う複数のアジャイルチームからなる、自己管理および自己組織化するチームである。ただし、列車が勝手に生まれたり進行するわけではない。チームが共有の使命に対して整合を取り、アーキテクチャーおよびユーザーエクスペリエンスのガイダンスに従って活動し、列車のチーフスクラムマスターであるリリース列車エンジニア(RTE)の助けを得て納品を行うことができるよう、各列車には指針と指示が必要である。図1に主要役割の「トロイカ」を示す。

Figure 1. Program Management, Content Management, and Architecture troika
図1. プログラム管理、内容管理、アーキテクチャーのトロイカ

この3つの主要職務は、プログラムレベルでビジョンとロードマップの取り組みを確実に成功させられるよう手助けする。

  • プログラムの実施– リリース列車エンジニアは、列車の乗務員のリーダーであり、チーフスクラムマスターである。RTEは、プログラムカンバン検査と適応のワークショップ、PI計画などのさまざまなメカニズムを使用して、プログラムを通して価値のフローを最適化できるよう手助けする。
  • 内容管理プロダクト管理は、顧客を代弁する社内の声であり、顧客やプロダクトオーナーと協力して彼らのニーズを理解/伝達し、システムのフィーチャーを定義し、妥当性検証に参加する。また、プログラムバックログに関する責任を持つ。
  • 技術– The システムアーキテクト/エンジニアリングは、本当の意味でシステム思考を適用できる個人または小規模の分野横断チームである。システムのアーキテクチャー全体を定義し、非機能要求の定義を手伝い、主な要素およびサブシステムを決定し、その間のインタフェースやコラボレーションの定義を手伝う。

規模の大きな価値のストリームでは、これらの役割はソリューションのPI計画前/後ミーティングにも参加する。

全域パレット

このレベルにはいくつかのアイコンが追加されていて、ビッグピクチャーの価値のストリームレベルとプログラムレベルの連結部分に置かれている。これは「全域パレット」と呼ばれるものである(図2を参照)。

Figure 2. Spanning palette
図2. 全域パレット

これらの成果物や役割は、それぞれがARTやプログラムレベルに貢献する。これは、ビジョンロードマップメトリックスマイルストーンリリースDevOpsシステムチームリリース管理共有サービス担当ユーザーエクスペリエンスの各ページで定義しているとおりである。これらの成果物や役割はレベルをまたがって使われる。成果物の多くは価値のストリームレベルでも役に立つからである。ビッグピクチャーの右側にある「折りたたみ」ボタンをクリックすると、価値のストリームレベルが非表示になり、パレットがポートフォリオレベルとプログラムレベルの間に表示されて、可能であればこれらの要素の一部またはすべてをポートフォリオレベルでも使用すると便利であることがわかる。これはフレームワークの設定可能性やモジュール性の本質部分である。これらの項目に関しては、SAFe企業 は必要なものだけを3つのどのレベルでも適用することができる。

価値のストリームとポートフォリオとの関係

プログラムは、価値のストリームやポートフォリオと双方向の関係にある。プログラムのビジョンやロードマップは、開発対象のソリューションやシステム能力のビューとなり、そこには顧客や利害関係者のニーズとそのニーズに対処するためのアプローチ案が反映される。

ただし、複数のARTが参加する価値のストリームにおいては、プログラムのビジョンやロードマップは単独で作成されるわけではない。互いに協調して作成し、通常はPI境界においてソリューションと同期しなければならない。各列車のプログラムポートフォリオ管理プロダクトおよびソリューション管理は、それぞれのロードマップやビジョンの作成を協調して行う。

従来のプログラムとARTとの混在

企業がSAFeに移行途中の場合やサプライヤーの開発プラクティスを企業が制御できない場合には、従来型の(ウォーターフォールの)プログラムがまだ存在する可能性がある。そのため、SAFeのプログラムポートフォリオ管理では、従来型のステージ-ゲート式のプログラムと一緒にARTを管理するときに適用できるガバナンスモデルを用意している。このように混在して運用する場合に指針となる記事をガイダンスのページで紹介している。(「Mixing Agile and Waterfall Development」(アジャイル開発とウォーターフォール開発との混在)の記事を参照。)


さらに知りたい場合

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

Last update: 21 September 2015