統合ポイントの本質は、それによってプロダクト開発が制御されることである。統合ポイントはシステムを改善するためのレバレッジポイントとなる。統合ポイントのタイミングがずれこむのは、プロジェクトに問題が生じていることを意味する。

─Dantar Oosterwal, The Lean Machine

 

継続的インテグレーション

継続的インテグレーション(Continuous Integration:CI)は、ARTや価値のストリームにとっておそらくはもっとも重要な技術プラクティスであり、リスクを軽減し持続可能で高速な開発を定着させる、品質のための鼓動である。チームがフィーチャーやコンポーネントの開発のみに集中していると、想定が積み重なったりシステム内で意図しない相互作用が起きたりして無駄が発生し、それが遅延や納品のバラツキとして現れる。しかし、早い段階から頻繁にCIを行っていると、チームはシステム的なものの見方をするようになり、それによって開発プロセスを制御下に置き、予測性を高めることができる。

しかし、異機種環境の複雑なシステム、つまり、機械サブシステム、ソフトウェア、電気/電子サブシステム、サプライヤーから入手した部品を含むようなシステムを、継続的に統合することは困難である。リーンなシステム構築を行うには、チームが品質を作り込み、統合済みのインクリメントから素早くフィードバックを受け取ることができる、バランスの取れたアプローチが必要である。そのために、たいていは、統合/テストの頻度と範囲の間で経済的なトレードオフを検討することになる。適切なインフラを整備し、CIのプラクティスを継続的に改善し、自動化手法とテスト容易化設計を取り入れていくと、フィードバックを素早く得ることができ、ARTのベロシティーがこれまでになく向上する。

詳細

大規模ソリューションが複雑になる主な原因は、コンポーネント間の相互依存、ソリューションのシステム能力の横断的な性質、ソリューション要素間での意図しない相互作用である。このような振る舞いの可能性を事前にすべて予想するなどできるわけがない。そのような依存関係を積極的に特定し管理する必要はあるが、協調して動作するコンポーネントをソリューションとしてまとめて統合しテストすることが、ソリューションを完全に検証する唯一の現実的な方法である。

フィーチャー/コンポーネントレベルの継続的インテグレーション

アジャイルチームで価値が生みだされるのは、チームメンバーがそれぞれの作業の成果を頻繁に統合してテストしたときだけである。頻繁に統合を行わなければ、チームのさまざまな役割や職務が矛盾のない成果(チームインクリメント)を実際に作成できていると裏付けることはできない。そのため、SAFeでは、アジャイルチームのメンバーが少なくとも反復ごとに一度、できればもっと頻繁なリズムで、作業を統合することが強く推奨されている。

この統合とテストの作業は、それぞれの反復の一部であり、きちんと計画するべきである。そのために、ストーリーの見積もりの一部にその工数を含めるか(ストーリーの完了の定義に含める)、統合とテストの作業を独立したバックログ項目として反復のバックログに追加する。どちらの方法で行うにしても、この作業はチームのベロシティーの計算に含めるべきである。そうでなければ、大規模な開発の予測性を高めるためのもっとも基本的な前提条件である持続可能なペースを維持することはできない。

ARTレベルの統合

ローカルでの統合とテストは非常に重要だが、それだけでは不十分である。「テスト済み」のコンポーネントに対するちょっとした変更ですら意図しない結果を生み、それがシステムの残りの部分に波及することがある(図1を参照)。

図1.  ローカルでの統合とテストは必要だがそれだけでは不十分である

さらに大きな問題は、システムが実際に動いているという間違った安心感(「希望的観測」。リーンにおける主なムダの1つ)を持たせてしまうことである。システム全体を見渡していなければ、検証されていない作業の上にどんどんと多くの機能が構築され、重要な問題が瞬く間に積み重なって、問題が指数関数的に増加しかねない。

頻繁な(少なくとも反復ごとに一度の)統合とテストは、進捗を評価し、修正しやすい間に問題を発見するのになくてはならない手段である。これによってシステムインクリメント(統合されて機能する一連のフィーチャーとコンポーネント。システムデモの対象)が作成され、チーム自体やプロダクトオーナーなどの主要利害関係者によってレビューできるようになる。さらに重要なのは、それによってインクリメントの目に見える実際の価値が明らかになることである。

ソリューションレベルの統合

大規模なソリューションでは、学習したり、価値のストリーム内の複数のリリース列車にまたがったソリューションの進捗を理解したりするためには、もう1つのレベルの統合が必要である。ソリューションデモというイベントでは、複数のアジャイルリリース列車のすべての開発作業(サプライヤーや他の価値のストリームの関係者の貢献分も含む)の結果が、顧客やその他の利害関係者に対して明らかにされる。これは完全に統合の済んだソリューションレベルのデモを行う非常に重要な時間であり、ここで客観的な評価と利害関係者や顧客のフィードバックが得られる。

ソリューションレベルの統合とデモは、下の図2に示すように、ARTや価値のストリームレベルのシステムチームの共同責任である。このような大規模システムは統合が困難な場合がある。ソリューションインクリメントのデモを定期的に行うには、一般的に、チームは統合とテストとそれを支えるインフラに投資しなければならない。それを行ったとしても統合やテストの対象範囲が100%に満たないこともあり、早期のうちは統合ポイントごとに対象を変える必要があるかもしれない(図2)。

その助けとなるよう、チームでは、可視化、環境のエミュレーション、モック、スタブ、無駄なものを省いたテストスイートなどを利用することができる。また、統合とデモの工数やサポート環境に費やす時間を、PI計画前ミーティングで明示的に割り当てる必要があるかもしれない。

図2.  ソリューションレベルの統合

サプライヤーおよびソリューションコンテキストとの同期

独自のシステム能力やソリューションを持つサプライヤーは、SAFeにおいて重要な役割を果たす。サプライヤーはリードタイムや価値納品に大きく影響する。両方の組織が最適な結果を得るには、緊密な協力と信頼が必要であるが、それは次に示す推奨プラクティスによって向上させることができる。

  • 統合ポイントを計画する。
  • 適宜、リズムを導入する。動くソリューションの客観的な評価に基づいてマイルストーンを設定する。
  • 親システムやサプライヤーARTのシステムチームと協力する。
  • 一貫性のある統合とテストのインフラを構築し保守する。
  • PI計画前/後ミーティングとシステムデモに参加する。サプライヤーを招待して出席してもらう。
  • あらゆるレベルのアーキテクチャー/システムエンジニアリングの間で協調と同期を行えるようにする。
  • ソリューションとソリューションコンテキストを同期させ、現状のソリューションが配置環境でうまく動作するかを確認する。

課題とトレードオフ

アジャイルリリース列車の目標は、反復ごとに、すべてのチームをまたがってフィーチャーを完全に統合することである。しかし、ソリューションが複雑である、複数のプラットフォームに対応しなければならない、専門技術を持ったテスト担当者や研究室や設備やサードパーティコンポーネントが手に入らないなどの理由で、それが困難な場合がある。そのため、反復ごとにそのゴールを統合するのは実際的ではないとチームが感じてしまうことがある(特に初期には)。しかしそれは、サイクル後半になっても統合とテストを継続的に行わないままでいることの言い訳にはならない。

このトレードオフが必要になった場合、チームは適宜にプラクティスを調整する必要があるが、それでも、信頼性の高い素早いフィードバックメカニズムを得られるようにしなければならない。図3は、チームが自分のコンテキストにおけるCIの最適なスコープと範囲を検討する際に役立つ、トレードオフ曲線である。

図3.  統合とテストのトレードオフ曲線

このトレードオフを行えるのは、ソリューションのさまざまな部分ごとに結合度が異なり、システム能力ごとにさまざまなシステム要素に対する影響の程度が異なるためである。また、コンポーネントによって、統合とテストのコスト全体に占める割合が異なり、他よりも統合とテストがしやすいものがある。完全に素早くCIを行うことが今すぐには現実的でない場合でも利点の多くを手に入れるための方法を、以下にいくつか紹介する。

  • さまざまな側面をさまざまな頻度で統合する。たとえば、バハライドの制御システムチームは、ソフトウェアを反復ごとに複数回、場合によっては毎日統合する。しかし、車両の完全な統合を行えるのは、2、3週間に一度だけ、またはプログラムインクリメントの境界だけである。
  • すべての資産を統合するが、古いテストを実行する。すべての回帰テストの実行を含む完全な検証を行うには時間やコストがかかりすぎるかもしれないが、これまでの実例に照らすと、通常、問題のほとんどは少数の「縦の」テストで見つかると判断することができる。完全な回帰テストスイートは、もっと長い間隔で実施するよう、取っておく。
  • エミュレーション環境やスタブやモックを使用する。コンポーネントや設備やサードパーティのサブシステムの中には、簡単に手に入らず、実際の環境で頻繁にテストに使用できないものがあるかもしれない。その代わりに、エミュレーターやモックやスタブを構築し、システム環境の残りの部分をシミュレートする。

また、リーンな手法に移行してきたばかりのグループにとっては、頻繁な統合が特に難しい課題であると知っておくことも大切である。これまでにやったこともなければ、必要なインフラもまだ構築していないからである。しかし、目標は明確であり、現在の状態は統合のスコープや範囲を狭めるための言い訳にならない。課題の多くは近い将来には解消しているはずだが、それはチームが今すぐとりかかることが前提である。

継続的インテグレーションの実現

リーンかつアジャイルな方法で複雑なソリューションを構築するのは旅に似ている。主に継続的インテグレーション機能によって関門が設けられた旅である。この後のセクションでは、速く前に進むための方法をいくつか提案する。

共通のリズム

すべてのチームが同じ一定のリズムで動いていると、統合ポイントを設けるのは簡単である。この理由で、すべての反復は同じPI境界に合わせて揃えられる。反復の終了時点を過ぎたところに統合/テスト作業を少しずらす必要が生じるかもしれないが、できるだけ近い方が望ましい。反復の中で完全なCIを行えない場合には、短期的に妥協することも可能だが、その間に技術やインフラの改善を続ける。

インフラ

効果的に継続的インテグレーションを行えるかどうかは、実行環境や、CI/テストツールや、モックやエミュレーターなどが手に入るかどうかにかかっている。インフラの一部はシステムチームが構築とサポートを行う。他の部分はチーム自身で管理し、常に素早くシステムのパフォーマンスを理解できるようにしておく方が効率が良い。

もちろんインフラは投資なので、予想される利益と比較して評価しなければならない。品質の作り込みというリーンの文化をまだ備えていない組織は、インフラの拡張が今後によい影響を及ぼすことを理解しにくいかもしれない。そのため、開発時間や設備に新たに投資をすることは、費用や遅延の原因であるとみなされる可能性がある。しかし、リーン-アジャイルなリーダーは、もっと長い目で見て現在必要な投資を行い、今後の長期的なベロシティーを向上する。

CIを行うためのエンジニアリング手法

次のような事柄を踏まえてシステムを設計すると、継続的インテグレーションを実現しやすくなる。テスト容易化設計(ハードウェア開発から始まった手法)では、より高度なモジュール性、関心の分離、主要インタフェースや物理テストポイントの使用が必要となる。セットベースの設計も、柔軟性を保ちながらもテスト用に固定することが可能な一部のソリューション要素を、(インタフェースやプロトコルによって)明確に分離するのに役立つ。

統合とテストの頻度は、品質を決める重要な要素である。しかし、そのための費用が問題になることもある。特に作業の多くが手動で行われる場合はそうである。プロセスやその一部を自動化すると、費用が抑えられ、生産性が向上する。上述の手法のいくつかと自動化を併用すると、図1のトレードオフ曲線の形を大きく変えることが可能である。

システムチームのサポート

この責任の多くはシステムチームが負う。しかし、ARTインクリメントの品質を担うのはシステムチームだけではないし、システムチームだけが責任を負うわけでもない。つまり、統合とテストは役割間の協調であり、ARTと価値のストリームの中で常に知識がやり取りされる。

アジャイルチームを統合の輪から外すと、彼らは一貫性のないインクリメントを納品し続けることになる。同様に、変化し続けるソリューションコンテキストの情報をアジャイルチームがシステムチームに知らせなければ、期待する事柄がすぐに乖離し始め、環境や構成に食い違いが生じる。

CIは文化である

継続的インテグレーションの議論の多くはツールを中心に展開されるし、ツールは重要な要素である。しかし、継続的インテグレーションは文化の変化であり、あらゆるレベルで新しい責任が必要になる新しい考え方である。以下は、CIの文化の導入を成功させるための3つの提案である。

  1. 頻繁に統合する。チームが頻繁に統合を行うほど、早く問題が見つかる。困難であればあるほど、頻繁に行って、その過程で障害を取り除き自動化を進める必要がある。その結果として学習サイクルが短くなって再作業が減る。
  2. 統合の結果を可視化する。統合プロセスが中断した時には、どのような理由でどのように中断したかを全員が知るべきである。修正された時には、何によって修正したかを知るべきである。
  3. 統合の失敗を修正することは最優先である。統合作業が失敗しているのにもかかわらずチームが仕事を続けていると、利益が打ち消され、統合作業への無関心を生むことにもつながりかねない。これを強調するために、多くのチームではビルドが失敗したときに光を点滅させて知らせたり、システムが失敗した時間の割合をよく見えるように示したりしている。そうすることで、新しい機能を追加するより先に問題を修正するようすぐに注意が向き、学習スピードが上がって、根本的な問題の影響を低減できる。

 


最終更新日:2015年11月18日