アーキテクチャー滑走路

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

─アジャイル宣言

設計やシステム開発における創発は事実として認識しなければならないが、少し計画を立てることで多くの無駄が省けることがある。

─James Coplien and Gertrud Bjornvig, Lean Architecture: for Agile Software Development

アーキテクチャー滑走路の概要

アーキテクチャー滑走路は、SAFeがアジャイルアーキテクチャーの概念を実現する手段の1つである。アーキテクチャー滑走路が存在するといえるのは、企業のプラットフォームに十分な技術インフラが既に存在し、遅延につながる大きな再設計なしに当面のプログラムインクリメントに含まれる最も優先順位の高いフィーチャーの実装をサポートできる場合である。この滑走路は、ビジネスの取り組みを開発し、新しいフィーチャーやシステム能力を実装するために必要な、技術基盤となる。

滑走路は、ビジネスエピック、システム能力、フィーチャー、ストーリーによって常に消費される。滑走路を使って、必要な機能が作り上げられる。今後の機能をサポートできるよう、企業はイネイブラーを実装することで滑走路の拡張に投資し続けなければならない。これらのイネイブラーの一部は、パフォーマンスの向上などソリューションの既存の問題を修正するためのものだが、将来のシステム能力で使用する基本機能を実装するためのイネイブラーもある。

詳細

アジャイル開発では、ウォーターフォール的な考え方や事前の大量の設計(Big Upfront Design:BUFD)を避けて、代わりに「最良のアーキテクチャー、要求、設計は、自己組織的なチームから生み出される」(アジャイル宣言[3])というシンプルな考えを信じる。ここから創発的設計というプラクティスが生まれた。これは、機能の次のインクリメントを実装し検証するために必要なだけ、設計を発見し拡張するという、アジャイルアーキテクチャーの進化のプロセスである。

この新しいプラクティスは、ある程度までは非常にうまく機能する。しかし、アジャイルプラクティスが成熟し、より大規模なチームや複数のチームから構成されるチームによって採用されるようになると、どこかの時点で、創発的設計だけでは大規模システム開発の複雑さに十分に対応できなくなる。次のような問題が発生し始める。

  • 再設計や遅延が過剰に発生する。フローにボトルネックが生じる。
  • 異なるアーキテクチャー構成要素で同じシステム能力をサポートするため、保守コストが増加する。
  • チーム間の協調や同期が減少する。
  • ベロシティーが低下する。
  • システムの統合や検証が困難になる。
  • システム品質(非機能要求)が劣化する。
  • コンポーネントの再利用率が低下する。実装が冗長になる。

これらすべての結果として、ソリューションのパフォーマンスが低下し、経済性が悪化し、市場投入までの時間が長くなる。

意図的アーキテクチャーによる大きな全体像のサポート

自分たちの環境の外で起きる変化をすべてのチームが予想することや、システム全体を個々のチームが完全に理解して冗長だったり矛盾したりする設計や実装を防ぐことは、まったく不可能である。簡単に言えば、大企業の中の1つのチームが全体像を把握したり、やってくる変化(多くは自分たちの制御の利かない外部で発生する)の一部を十分に予想したりすることはできない。

そのため、チームには意図的アーキテクチャーが必要になる。これは、ソリューションの設計やパフォーマンスや使いやすさを向上し、チームをまたがって設計や実装を同期する際の指針となる、目的をもって計画されたアーキテクチャーの取り組みである。このようなイネイブラーによって、チームがビジネス価値をより早くより確実に納品するために必要なアーキテクチャー滑走路が作成される。

意図的アーキテクチャー創発的設計を併用することで、プログラムは大規模なソリューションを作成し保守することができる。創発的設計ではローカルの素早い制御が可能になるため、チームは、将来も使い続けられるシステムにしようと必要以上に努力しなくても、要求の変更に適切に対処することができる。意図的アーキテクチャーは、システム全体が概念的に整合が取れていて有効であることを保証するために必要な指針となる。創発的設計と意図的アーキテクチャーの適切なバランスを取ることによって、大規模システムを効果的に発展させることができる。

アーキテクチャーによってフローとアジャイルさを実現する

アーキテクチャー滑走路を拡張するためにイネイブラーが使われる。イネイブラーは、多くの場合、さまざまなレベルのアーキテクトやシステムエンジニアリングによって定義される。これは、ポートフォリオレベルではエンタープライズアーキテクト価値のストリームレベルプログラムレベルではシステムおよびソリューションアーキテクト/エンジニアリングである。イネイブラーを定義したアーキテクトは、そのイネイブラーをそれぞれのカンバンシステムに入れ、分析に必要な指針と見積もりや実装に必要な情報とを提供する。これによって、その影響を受けるサブシステム、コンポーネント、関数、プロトコル、内部システム関数などの要素は、ロードマップ上ですぐ先にあるフィーチャーやシステム能力をサポートするアーキテクチャーを手に入れられる。

ただし、「事前に大量に分岐させて後でマージする」というウォーターフォールのやり方はもう使われないため、イネイブラーエピック/システム能力/フィーチャーの実装は複雑になる。その代わりの方法として、企業はアーキテクチャーをインクリメンタルに実装することに力を注ぐ。そのためには、イネイブラーエピックをイネイブラーフィーチャー/システム能力に分割しなければならない。そしてそれらを最終的に個々のアジャイルリリース列車(ART)が実装する。システムが常に動作する(少なくともPI境界では動作する)よう、各イネイブラーフィーチャーは1つのプログラムインクリメント(PI)内で完成しなければならない。そのため、場合によっては新しいアーキテクチャーの取り組みを断片的に実装することになり、実装を行ったPIではユーザーに公開されないこともある。このようにすると、見えないところでアーキテクチャー滑走路の実装とテストを行うことができるため、その間も出荷を続け、新たなビジネスエピックとそれらをインスタンス化したプログラムレベルのフィーチャーの実装をサポートできるだけの十分なシステム能力が備わってから、ユーザーに公開することができる。

R&Dに特有のバラツキを管理するための主要なツールとして、SAFeでは計画策定と資産統合の両方にPIのリズムと同期を用いる。こうすると、ARTでは出荷可能な新しいプロダクトを常に提供できる状態になるので、企業は、主に外部的な要因に基づいて、その資産を出荷するかどうかを自由に判断することができる。これは、(少なくとも)PIの境界で、頑丈な高品質の配置可能なシステムレベルのソリューションを持つことが極めて大事であることを意味する。言い換えれば、PI計画セッションが始まる時点で、ある程度のアーキテクチャー滑走路が存在しなければならないということである。そうでなければ、アーキテクチャーの再作業が発生し、その後にその再作業に依存する新規フィーチャーの構築を行うことになって、プログラムに受け入れ難いリスクが生じる。

このリスクを低減するには、最も革新的な新規フィーチャーで必要なアーキテクチャーの土台が、PI計画策定の時点で既にシステム内に存在するよう、プログラムが配慮しなければならない。そのためには、いくらかの滑走路を構築し、その滑走路を使用し、拡張しなければならない。それについてこの後のセクションで説明する。

アーキテクチャー滑走路を構築する

新しいプラットフォームが特に革新的な場合や、まったく新しい(グリーンフィールド)開発の場合には、初期定義や滑走路の構築にシステムまたはソリューションアーキテクト/エンジニアが参加することが一般的である。その際、最初のいくつかの反復の間、通常は、新しいインフラを1つか2つだけのアジャイルチームに導入する。このとき、アーキテクト/エンジニアがプロダクトオーナーを務めることもある。その様子を図1に示す。

図1.  アーキテクチャー滑走路の初期導入

そのときのルールはシンプルでアジャイルである。

  1. これらのチームはプログラム内の他のアジャイルチームと同様に反復開発する。
  2. 成果は動くソリューションであり、モデルや設計ではない。
  3. 時間が最も重要である。新しいアーキテクチャーの実装と検証には2、3の反復しか費やすべきではない。

その後すぐに、いくつかのフィーチャーチームをプログラムに追加し、そこで初期の消費可能なフィーチャーを使って新しいアーキテクチャーをテストする(図2)。

図2.  新しい滑走路での新しいフィーチャーの実装

その間、チームはアーキテクチャー滑走路の追加部分を構築する(図3)。

図3.  アーキテクチャー滑走路の構築の進行

ベロシティーを安定させるには、アーキテクチャー滑走路を常に保守し拡張しなければならない。処理能力を割り当てて、イネイブラー(滑走路を拡張するための作業)に継続的に投資できるようにする。プロダクト/ソリューション管理とアーキテクト/エンジニアは、影響を受けるチームと協力して、アーキテクチャーの取り組みの多くを定義するが、それを実装するのはアジャイルリリース列車の責任である。アーキテクチャー滑走路によって、短期的に納品を成功させるために必要なものを提供しなければならないが、同時に、長期的な技術的確約をして開発に制約をかけすぎてはならない。「ちょうどいい量」のアーキテクチャー滑走路が必要である。多すぎると、アーキテクチャーがチームの過大な制約になったり現在のコンテキストから離れすぎてしまう。少なすぎると、チームが短期的な確約をしてそれを確実に実現するのが難しくなる。

使用する:システムアーキテクチャーの脆弱で一時的という性質

ここまではすべてがうまくいく。新しいアーキテクチャーが整い、それを使って価値のあるフィーチャーが既に配置されている。しかし、この初期の成功は一時的な場合がある。次のような自然な力によってアーキテクチャーはだんだんと消費されていくからである。

  1. アジャイルチームは素早い。比類のない集中と能力で新しいフィーチャーを提供するため、その過程で既存の滑走路が消費される。
  2. プロダクトオーナーとプロダクト/ソリューション管理はせっかちである。システム内部の機能に時間を投資してきたので、すぐにでもバックログの優先度をユーザーに売れるフィーチャーへと移動したがる。
  3. アーキテクチャー自体が脆弱であり、継続的に進化させる必要がある。技術は短い時間で変化する。モノは古くなる。
  4. 顧客も迅速な変化を求める。

アジャイルチームが本当に調子が良い場合を除いて、結果は図4のようになる。

図4.  アーキテクチャー滑走路を使い切る

 

拡張する

ふりだしに戻ってしまわないようにするにはチームはどうすればよいか。単純に言うと、アーキテクチャーへの投資を、一度きり、あるいは間欠的なイベントで済ますことはできない。何と言ってもこれはフローベースのシステムなのだ。その代わりに、チームはカンバンシステムを使用して、イネイブラーエピック/システム能力/フィーチャーの推敲、分析、実装を継続的に行うことを確約する。さらに、アーキテクト/エンジニアやアジャイルチームは、新たに身に付けたスキルで、イネイブラーエピックやイネイブラーフィーチャーを1つの反復やPIで実装できる小さい部分に分割し、結果として継続的に顧客に価値を納品する。(インクリメンタルな実装戦略については、「システムおよびソリューションアーキテクト/エンジニアリング」のページと、ASR[2]の第20章および第21章を参照のこと。)

注:メタファーの由来

アーキテクチャー滑走路という用語は、PIレベルのバーンダウンチャートを見ていたときに、例えとして使い始めた。よくあることだが、PIの開始時に十分なアーキテクチャーが存在していないと、新しいアーキテクチャーに依存するフィーチャーのリスクが高くなり、プログラムが「PIを着陸」させられる(PIの終わりにバーンダウンを0にできる)とは限らなくなる。そうすると、PI目標を達成できない。着陸するには「滑走路」が必要である。

SAFeでは、赤いアーキテクチャー滑走路の線で現状を示すが、これはときにより上下する。チームがいくらか構築し、いくらか消費し、構築し、消費し、ということを繰り返すからである。どの時点においてもちょうどいい量が存在しなければならない。さらに、このメタファーを少し拡張して言うと、飛行機(システム)が大きかったり、飛行速度(ベロシティー)が高かったりする場合には、安全にPIを着陸させるために必要な滑走路が長くなる。滑走路についてはアジャイルアーキテクチャーのページで詳しく説明する。


さらに知りたい場合

[1] Leffingwell, Dean.Scaling Software Agility:Best Practices for Large Enterprises.Addison-Wesley, 2007, 第16章 (邦訳:アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス、翔泳社、2010)

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

[3] アジャイルソフトウェア宣言:http://www.agilemanifesto.org.

Last update:18 September 2015