Release

動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔で納品する。
– アジャイル宣言

創造的なプロセスは、実際には3つの部分に分かれる。最初にひらめき、次に実行、最後にリリースである。
– Eddie Van Halen

リリースの概要

リーン開発の目的は、価値のある、完全にテストの済んだ、動くソリューションのインクリメントを頻繁に納品することである。これは、絶え間ない価値のリリースによって実現される。各リリースは、最終的な使用の有効性の検証と承認が済んでいて、適用を確実に成功させるために必要なドキュメントが付属したものである。この目的を達成するには、よりリーンなソフトウェアおよびエンジニアリングのプラクティスと、検証および妥当性確認の継続的なプロセスが必要である。さらに、本番環境へのリリースや、顧客の世界への直接のリリースを成功させるためには、最終的な出荷前の確認、ドキュメント、サポートの作業も必要である。

詳細

頻繁な価値のリリース

リリースを行うたびにより多くの価値が顧客に納品される。また、ソリューションの一部のアイデアや想定事項や側面は、顧客の環境にリリースするまでは完全に妥当性を確認できない。その場合、有効性や配置のしやすさや使いやすさについての本当に意味のあるフィードバックは、開発環境では部分的にしか評価できない。このような理由で、より頻繁にリリースすることがリーン-アジャイルな企業の目的の1つになっている。

多くの人は、リリースがどれも同じようなものだと思っている。ウィジェットであれば、製造工程や顧客の環境に1度のイベントでリリースできるかもしれない。しかし、複雑なソリューションはそもそも非常に複雑であり、その場合にはシステムのさまざまな要素をさまざまな時点でリリースすることになるかもしれない。価値の納品全体を最適化しようとすると、各要素が独自の納品リズムで動かなければならない可能性がある。

たとえばバハライドの例を考えてみる。プレーヤーポータルへのソフトウェアアップデートは、2週間ごと、毎日、またはオンデマンドなどの頻度で納品され、顧客やユーザーはそれによってインクリメンタルな素早い納品という恩恵を受けることができる。たとえば車両制御システムはときどき無線によるソフトウェアアップデートを受け取るが、配置前にオフラインでのエンドユーザーによる確認が必要になることも珍しくない。そのため、一括処理やテストが必要である。そのサブシステムのリリースは、リズミカルに行われることもあれば、信頼性を向上したりライド体験の一側面を改善したりできるよう、コンテキストや問題やチャンスに応じて臨機応変に行われることもある。そして、新しいモーションベースとそのファームウェアやハードウェアのアップデートがリリースされて車両にインストールされるのは、年に一度だけである。図1にこの例を示す。

Figure 1. Different elements of the solution may have different delivery rhythms
図1. ソリューションのそれぞれの要素が異なるリズムで納品されることがある

 

リズムに基づき開発する、随時リリースする

このような機会と制約を考えると、リリースは必ずしも開発のリズムに合わせて行う必要はない。「リズムに基づき開発する、随時リリースする」は、同期、連携、変動の管理、開発ベロシティーの予測という目的を支援するためのものである。納品は、ビジネスで必要なときにいつでも行うことができる。しかしそれでも、多くの企業では、ソリューションの一部または全部をプログラムインクリメント(PI)境界に合わせて納品すると都合がよいと判断している。その場合には、開発のリズムと納品のリズムが一致し、それによって多くの利点が生まれる。

リリースの構築

リリースの準備ができて使用に適した状態に大規模システムを構築する作業は、図2に示すように段階に分けると検討しやすい。

Figure 2. Building a releasable solution
図2. リリース可能なソリューションの構築

チームインクリメント

このプロセスの最初の(可能であれば継続的に行いたい)ステップでは、アジャイルリリース列車(ART)に乗っているそれぞれのアジャイルチームが、担当のストーリーやコンポーネントの動くインクリメントを確実に作成することに集中する。そのために次のことを行う。

  • チームのバックログ内のユーザーストーリーを完成し、それぞれがストーリーの(ローカルの)完了の定義を満たすことを確認する。
  • 継続的インテグレーションのプラクティスとテストの自動化を可能な限り適用して、進捗を監視し、確実に実施する。

システムインクリメント

チームは2週間ごとにシステムインクリメントを作成する。これは、新しい機能を集めて統合したもので、現在およびこれまでのすべての反復ですべてのリリース列車チームによって完成させられたすべてのチームバックログ項目の合計である。システムインクリメントはどれもシステムデモの対象となる。こうすることで、一度に1ストーリーずつ、新しいフィーチャーがインクリメンタルにシステムに追加される(通常はプログラムインクリメントごとに数フィーチャー)。

そのインクリメント内で完成するフィーチャーに関しては、フィーチャーの受け入れ基準が満たされていなければならない。ただし、フィーチャーの中にはまだ途中のものもあるかもしれず、その場合には現在のインクリメントにはその機能のすべてではなく一部だけが含まれる。機能全体に矛盾がないことを確認するために、列車では主要シナリオと非機能的側面に関して検証と妥当性確認を行う。このとき通常はシステムチームの助けを借りる。

それぞれのシステムインクリメントは複数のチームの作業の結果なので、上述のように統合が必要である。ただし、状況によっては、すべてのプログラム資産を完全に統合するには大きな処理コスト(集めて設定しテストするなど)が必要であり、これはソリューションのシステム能力にハードウェアコンポーネントが含まれている場合に顕著となる。そのような場合には、工数と頻度との適切なバランスを見つけることが重要である。システムインクリメントの完了の定義をときどき緩和して完全な統合をせずに素早いフィードバックを求めることは可能だが、それを、頻繁な統合とテストのプラクティスを放棄する言い訳にしてはならない。システムインクリメントはARTの最重要の進捗測定基準(それぞれが学習のマイルストーン)であり、一定の頻度でインクリメントを作成できなければ、チームがシステム開発のどの段階にいるかを知ることができない。

PIの境界において、各アジャイルリリース列車は検査と適応のワークショップで最終的なシステムデモを行い、PIの期間中に開発したフィーチャーを見せる。

ソリューションインクリメント

複数のARTが参加する価値のストリームでは、ARTは通常、ソリューションの一部だけを構築する(これはいくつかのサブシステムであったり、ソリューションシステム能力であったり、その混在であったりする)。そのため、ソリューション開発作業の本当の進捗を客観的に評価するには、複数のARTが協調して作成した、統合/検証/妥当性確認が済み、機能要求と非機能要求(NFR)を満たしたすべてのシステム能力から構成される、ソリューションインクリメントを使用するしかない。このソリューションインクリメントは、きわめて重要なソリューションデモの対象であり、ここですべてのインクリメントが動くシステムにまとめられる。

完全にシステムを統合するプロセスでは、おそらく、プログラムレベル及び価値のストリームレベルのシステムチームの助けが必要になる。実際のところ、これこそがシステムチームの主な存在理由である。SAFeでは、この作業の頻度はこのページで説明している他のものよりも低くし、PIの境界を重視するよう提案している。大規模システム、特にハードウェアコンポーネントとソフトウェアコンポーネントが混在するシステムでは、処理コストが非常に大きくなる可能性があるため、頻度を下げることが示唆されている。

時にはこの作業の大部分が革新と計画(IP)の反復で行われる。そうすると、この反復に割り当てられた人やサプライヤー、サブシステムやコンポーネント、特別なスキルや設備、その他のリソースを、この重要なタスクに充てることができる。ただし、常にそうできるとは限らない。PIにおける進捗を企業がよりよく理解したいと望めば、ソリューションインクリメントをもっと頻繁に作成することになるかもしれない。その場合、ソリューションレベルの統合作業を、IP反復にカプセル化するのではなく、PI内の複数の反復に分散して行うこともある。そのときには、システムデモでその時点までの進捗の確認を行う。

リリース

このように、ソリューション開発は、ストーリー、フィーチャー、システム能力、非機能要求を一度に1つずつ処理して進んでいき、最終的にリリースという目標に達する。ただし、新しい機能すべてを実際に顧客にリリースする前に、通常は、ソリューションの検証と妥当性確認、ドキュメント作成、その他の関連作業を行う必要がある。

リリースプロセスの一環として、別の事業部門(場合によっては顧客への実際の納品を担当する別の組織)にソリューション資産を引き渡すこともある。たとえば、システムを設計図の形で製造技術部門にリリースして、そこで実際の最終的な製造指示を作成するなどが考えられる。または、ソリューションはそのままでリリース可能だが、納品プロセスにかなりの工数がかかるため、独立した主要プロジェクトとして実施する場合もある(人工衛星を使える状態にするためには軌道へと送りこむ必要がある)。いずれの場合も、リリースプロセスにはたいてい大きなリスクが伴い、そのせいでプログラム全体が成功できないこともある(新しいモーションベースのコストが高すぎて製造できない、打ち上げ時に人工衛星に加わる振動が大きすぎる、など)。

リリースに関わる問題を回避する最善の方法は次の2つである。
a)「リリースのしやすさ」を念頭に置いてソリューションとプロセスを設計する
b)できるだけ早い段階から頻繁に、想定事項の妥当性を確認する

(a)を行うには、経済的枠組み価値のストリームのカンバンやその他の意思決定ツールに、リリースに関係する主要な事柄を反映させておく必要がある。システム自体も、非機能要求(ある程度リリースの制約が反映されているもの)を満たす必要がある。PI計画PI計画前/後ミーティングは、ソリューションのリリース面について論じることのできる人に参加してもらったり、リリースしやすいインクリメントを構築するには何が必要かを列車やチームによく理解してもらったりするための、非常によい機会である。

(b)を満たすには、頻繁に妥当性を確認してフィードバックするモデルが必要である。状況によっては、外部へのリリースの頻度を上げると非常に役立つことがある。頻繁なリリースが不可能であったりコストが高すぎたりその他の制約があったりする場合でも、この種類の妥当性確認を少なくともPIごとにソリューションインクリメントのレベルで行う必要があるが、そのときには、一部またはすべてをエミュレートしてリリースのしやすさを確認するための特別な手順やインフラが必要になるかもしれない。IP反復がそのための時間枠として役立つ可能性がある。

規模ごとの完了の定義

これらを踏まえて、システム機能の継続的な構築と、ソリューションの要素の継続的な検証と妥当性確認、そして最終的なソリューション自体を、規模ごとの完了の定義に反映することができる。表1に例を挙げる。

Table 1. Example SAFe scalable Definition of Done
表1. SAFeの規模ごとの完了の定義

 


Learn More

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

Last update: 28 December 2015