アーキテクチャーは基本的には何かの容器である。ティーカップを楽しむのではなく、みなさんにその中のお茶を楽しんで頂けたらと思う。

谷口 吉生

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

もし、企業のプラットフォームは 過度に遅延を誘発する再設計がなく、近い将来のプログラムインクリメント(PI)で最も優先順位の高いフィーチャーの実装をサポートするために十分な既存技術インフラ(コード)を持っている場合、アーキテクチャー滑走路が存在していると言えるだろう。滑走路をある程度実現するために、企業は継続的にリファクタリングや既存のプラットフォームの拡張に投資しなければならない。

「ビッグバン的な事前設計と、ブランチし、マージする」というウォーターフォールアプローチが捨てられることでアーキテクチャーエピックの実装が複雑になる。その代わりに、企業はアーキテクチャーエピックがメインコードラインにインクリメンタルに実装されることを確約する。そうすることで、アーキテクチャーエピックは、個々のリリース列車で実装されているアーキテクチャーフィーチャーに分割しなければならないことを意味する。システムが常に動作する、少なくともPIの区切りで動作するため、各アーキテクチャーフィーチャーはPI内に完了しなければならない。新しいアーキテクチャーの取り組みが少しずつ実装されるという場合もあり、これらが実装されているPIではユーザに見えないかもしれない。このように、常に出荷が可能な状態を保ちつつ、アーキテクチャー滑走路を舞台裏で実装し、テストすることができる。アーキテクチャー滑走路は、新たなビジネスエピックとそれらをインスタンス化したプログラムレベルのフィーチャーの実装をサポートするために十分な能力をそなえた時に、ユーザに公開される。

詳細

R&Dの固有のバラツキを管理するための主要なツールとして、SAFeは計画策定とソフトウェア資産の統合の両方にプログラムインクリメントのリズムと同期を用いている。このように、アジャイルリリース列車は潜在的な出荷のために新製品が常に提供可能な状態にいるので、企業はその資産を出荷するかどうかを自由に決定するが、それはほとんど外部の要因に基づいて行われる。これは、(少なくとも)PIの区切りで頑丈な、高品質の配置可能なシステムレベルのソリューションを持つことが極めて大事であることを意味する。
言い換えれば、一定量のアーキテクチャー滑走路がPI計画策定セッションに存在しなければならないことを意味する。そうでない場合には、相当なアーキテクチャーの手戻りリスクがある。アーキテクチャーの手戻りがそれらに依存する新しいフィーチャーを構築することをもたらし、プログラムに受け入れにくいリスクをもたらす。リスクを低減するために、プログラムは、PIを計画する際に、最も革新的な新しいフィーチャーのために必要なアーキテクチャーの基盤(コード!)が既にシステムに確実に存在するように配慮する必要がある。我々は次のセクションで説明するように、それは、いくつかの滑走路を構築し、滑走路を使用して、それを拡張することによって達成される。

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

アーキテクチャー滑走路の概念は「Scaling Soft Agility」(SSA、参考文献[1]16章)にて初めて紹介され、「Agile Software Requirements」(ASR、参考文献 [2])にて拡張された。新しいプラットフォームへ変更の場合にせよ、新規開発(グリーンフィールド)の場合にせよ、システムアーキテクトは初期定義で役割を果たし、滑走路を構築することが一般的である。また、初期に新しいインフラが1つまたは2つのアジャイルチームのみに置かれることも一般的である。図1に示すように、いくつかの反復を通じてアーキテクトがプロダクトオーナーとして務めることもある。

図1. アーキテクチャー滑走路の開始

図1. アーキテクチャー滑走路の開始

このようにするためのルールが単純で俊敏である。

  1. これらのチームはプログラムにおけるほかのアジャイルチームと同様に反復開発する
  2. 成果は動作するコードであり、モデルや設計ではない
  3. 時間が最重要な条件である。新しいアーキテクチャーを証明するために数回の反復以上要するべきではない

その後、プログラムは直ちにフィーチャーチームを追加することによって拡張される。図2に示されるように、フィーチャーチームは、初期の消費可能なフィーチャーで新しいアーキテクチャーをテストする。

図2.より多くの滑走路を構築する

図2.より多くの滑走路を構築する

図3に示すように、この方法でチームは迅速にアーキテクチャー滑走路を作り上げる。

図3.アーキテクチャー滑走路を構築する時の進捗

図3.アーキテクチャー滑走路を構築する時の進捗

 

利用する:システムアーキテクチャーの脆弱ではかない性質

この時点まですべてがよい。新しいアーキテクチャーが確立し、その上に価値のあるフィーチャーはすでに配置されている。一時的な初期の成功ができるが、いくつかの本質の力によって、アーキテクチャーが時間につれて消費される傾向がある。

  1. アジャイルチームは早い。彼らは、新しいフィーチャーを提供するために比類ない集中と能力を持っている。そのため、既存の滑走路を消費する
  2. プロダクトオーナーやプロダクト管理者は性急だ。彼らは、内部のシステム機能にいくつかの時間を投資してきて、すぐにバックログの優先順位をユーザが支払ってくれると思っているフィーチャーへ移動する
  3. アーキテクチャー自身が脆い。技術が非常に短い時間幅に変化する
  4. 顧客も迅速な変化が求める

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

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

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

 

拡張する

出発した、まさにその場所に立ち戻ってしまうことをチームがどうのように避けられるか?単純にアーキテクチャーへの投資を、一度きり、あるいは間欠的なイベントにすることはできない。その代わりに、チームは アーキテクチャーエピックカンバンシステムを使用して、アーキテクチャーエピックとフィーチャーに対し、継続的な洗練化、分析と実装に確約する。さらに、SAFeに記したように、システムアーキテクトとアジャイルチームは新たに発見したスキルを持ち、それを利用しアーキテクチャーエピックとフィーチャーを小さな薄切りに分解する。これらの小さな薄切りは各反復や各PIにて実装されることができ、そして、顧客に継続的に価値を提供する。(インクリメンタルな実装戦略についてシステムアーキテクトページとASR(参考文献2)の20-21章を参照。)

歴史ノート: メタファーの由来

PIレベルのバーンダウンチャートとの類似性に気が付いた時に、「アーキテクチャー滑走路」という用語が使い始めた。我々はよく見たことであるが、PIを始めた時、コードに既存のアーキテクチャーが足りない場合、新しいアーキテクチャーに依存するフィーチャーが高いリスクを持ち、プログラムはこのようなPIを常に「着陸」(PI終了した時点で、残作業が0になる状態)できないので、PI目標を達成できない。そのため、着陸するため、「滑走路」が必要となる。SAFeでは、滑走路が構築されたり、使われたりするので、時間軸上では上がったり、下がったりするように描かれている。ある時点では、正しい量の滑走路を持たなければならない。さらに、このメタファーを少し拡張するが、より大きな飛行機(システム)、またより速く飛行する(ベロシティ)場合、安全に着陸するために、より多くの滑走路が必要である。滑走路について、さらに知りたい場合、アジャイルアーキテクチャーの原則をご参照ください。

 


さらに知りたい場合

[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)

Last update: 22 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.