…適切な設計をすれば、フィーチャーは安くなる。 このアプローチは難しいが、成功し続ける。

- デニス・リッチーe

システムアーキテクトの概要

アーキテクチャーの役割とそれに応じたソフトウェアアーキテクトの役割については、いくつかのアジャイルサークルでは依然やんわりと議論されている。スクラムとXPにおいて、この役割は特別に定義された役割でもないし、ほとんどのアジャイルの書籍ではこの話題について触れていない(時には軽蔑的である)。大規模なソフトウェア企業の世界では、我々はそれとは異なる見解をとっている。拡張されたプロダクトオーナー/プロダクト管理者/ポートフォリオ管理チームを介して、内容に関する権限(システムが何をするか)を適所に与えなければならないのと同様に、ポートフォリオやプログラムの技術的な決定を行うための設計に関する権限(システムがどのようにそれを行うか)は規模に応じ適所に与えなければならない。

このため、SAFeはソフトウェアアーキテクトについて以下の2つの具体的な役割を識別している。1)エンタープライズアーキテクトはポートフォリオレベルで表現され、複数のプログラムをまたがって働く。IT/ソフトウェア開発戦略や技術を企業の進化するビジネスニーズに確実に合わせられるように支援することは、この役割の責務である。2)システムアーキテクトはプログラム内で働く。対象システムが何を処理しなければならないかに関するユーザービジョンの高いレベルの理解を維持することが責務である。同時に、現在と今後のユーザーおよびビジネスニーズをサポートするために必要な実装フレームワークに関する理解を維持し、進化させることも責務である。

詳細

役割の概要説明

「最良の要求と設計は、自己組織的なチームから生み出される」(アジャイル宣言)が、一方、システムアーキテクトは複数のチームからなるアジャイルチーム、つまりアジャイルリリース列車で独自の役割を果たす。利害関係者のニーズを理解したり、チームの現在と今後のフィーチャーを担うために適した技術ソリューションの定義と実装を支援したり、進化する非機能要求に対応する。システムアーキテクトはアジャイルチームと日常的に協力しながら作業を行う。多くの場合、プログラムバックログ内で成熟しつつある将来のフィーチャーを支えるために今しなければならない設計上の決定に注力する。これらには、新しい アーキテクチャーエピックやフィーチャーだけでなく、標準のデータベース、プロトコル、Webサービス、およびパフォーマンス、スケーラビリティ、規制要件などの非機能要件のような、共通のガバナンスの項目が含まれる。ただし、以下で詳細に説明するように、システムアーキテクトの役割、責務、および責務を果たす方法は、真にリーンかつアジャイルなソフトウェア企業の創発を促進できるよう発展しなければならない。

責務

SAFeでは、システムアーキテクトは通常以下の主要な責務を果たす。

  • 顧客、利害関係者、プロダクト管理者プロダクトオーナーと一緒に作業し、システムの現在と今後の要求に関する高いレベルの認識を理解し、維持する。
  • システムの非機能要件を理解し伝達する。
  • 設計代替案を評価し、コスト利益分析を行う。
  • 推奨されたドメインとユースケースモデルなど、システムがその意図するところをどのように行うかを説明するために必要なあらゆるモデルやドキュメントを開発し維持する。
  • アーキテクチャーエピックを定義してフィーチャーに分割し、プログラムバックログに入れる。
  • リリース計画策定時にソリューションの技術的なビジョンを提示し、大規模システムの振る舞いを記述するドメインモデルと典型的なユースケースを提供する。また、計画策定プロセスに参加して積極的に対話する。
  • 実装中に、チームがシステムレベルとコンポーネントレベルの意思決定を適切に行えるように、1つのリソースとして支援する。
  • 今後のユーザーとビジネスのニーズを支援するために、ポートフォリオレベルエンタープライズアーキテクトと協力し、アーキテクチャー滑走路を確立する。

アジャイルでは何が違うか:アジャイルアーキテクチャーの原則

上記で定義された責務の多くは、従来のソフトウェア開発の責務と一致しているものの、それを果たす方法は異なっている。システムアーキテクトはアジャイルチームに設計を指示する権限を持っていない。そうでなければ、アジャイルプログラムの活動性の基礎となる権限委譲と責任能力が消えてしまう。代わりに、システムの状態、すなわち現在と短期の状態をサポートする設計判断ができるよう、アーキテクトはアドバイザやファシリテータとして、チームやプロダクトオーナーにメンタリングをしたり、コーチングをしたり、指導をしたり、協力しなければならない。以下は企業をアジャイルの道に導くためのアジャイルアーキテクチャーに関する7つの主要原則である(参考文献[1]から引用)

アーキテクチャーエピックとフィーチャーを実装する

ユーザーストーリーはインクリメンタルに実装できる小さな価値オブジェクトを表すが、アーキテクチャーエピックとフィーチャーはそれとほぼ同じように振る舞う。それらは定義され、優先順位が付けられ、独立してインクリメンタルに実装される。さらに、長い、ウォーターフォール式のブランチとマージ戦略でアーキテクチャー変更を行うのは過去のことなので、チームは継続的なプロダクト開発フローの世界で作業しなければならない。それには、今後の作業を可視化するために役に立つ新しい発想、ツールと戦略が必要である。また、それによって、プログラム実装境界に到達する前に、これらの項目の準備、優先順位付けと分析を行うことができる。これらはSAFeとASR[参考文献1]で説明されたアーキテクチャーのためのカンバンシステムを実装することでサポートできる。

インクリメンタルな実装のパターン

また、実際のシステムの実装では、システムが常に動く、少なくともプログラムインクリメントの区切りでは動くことを保証しなければならない。ASR[1]では、これを達成するための3つのアーキテクチャー変更実装パターンを紹介した。以下はその概要である。

大規模だが段階的、システムは常に稼働。理想的な純粋なアジャイルの場合、アーキテクチャー作業は付加価値のある小さな部分に分割され、反復期間内で実装される。それによって、これらの境界では(さらに理想を言えばその間の毎日)、システムを常に利用できることが保証される。

大規模だが完全に段階的ではなく、システムを時々止める必要がある。変更や経済の本質によっては1番目のアプローチを実行できないことがある。この場合、ブランチを作成したりアーキテクチャーの作業をさらに小さな部分に細分化するのではなく(こちらの方が好ましいが)、チームはPI中に主ブランチで主要なアーキテクチャー作業を行う。その期間はシステムが完全に機能しないかもしれないが、PIの終盤に更新されたシステムに新しい機能を追加する時には常に作業が完了している。

非常に大きくかつ段階的でなく、システムは必要な時に稼働、害を及ぼさない。それができなくても、本当に大きなアーキテクチャー作業は、やはりリアルタイムに主ブランチで完成しなければならない。しかし、チームはソリューションの完全性を達成するために必要な足場とスタブを利用する。この時システムはPIの区切りで動くが、全体の取り組みは未完成である。こうすれば、新しいアーキテクチャー要素を、既存および新規の回帰テストおよび性能テストによってテストできる。しかし、価値のフィーチャーや残りのアーキテクチャー土台は今後のPIで実装しなければならない。

アーキテクチャーバックログ項目の分割

どのパターンを選択した場合でも、スプリント内で完了するようにストーリーを分解するのと同様に、アーキテクチャーエピックやフィーチャーも小さな部分でインクリメンタルに価値を提供できるよう分割しなければならない。ASR[1]では、アーキテクチャーエピックとフィーチャーを分解するために考えられる8つの具体的なパターンを詳しく説明している。「サブシステム、コンポーネント、プロダクトによる分割」、「インクリメンタルなシステム品質の達成」、「インクリメンタルな機能の実装」、「足場の利用」、「主作業/副作業への分割」、「複雑な作業を最初に行う」、「データの種類で分割する」、「必要に応じスパイクを利用する」の8つである。

アジャイルモデリングのための推奨事項

典型的なアジャイルリリース列車は数多くのチームを含むことができる。これらのチームは協力し合い、大規模複雑な企業レベルのシステムを構築する。これをインクリンメンタルに行うのが大規模アジャイルの技能である。それには、継続的に価値項目(エピック、フィーチャー、ストーリー)をどんどん小さな独立したオブジェクトに分割してインクリメンタルに実装しなければならない。これはよいことであり、ある程度まではそれでうまくいく。しかし、1つの小さなストーリーが1つの反復にたどり着くまでに、システムのより大きな視点での理解が崩壊し始めている可能性がある。このため、アジャイルモデリング技術を使って文脈を作成し、理解を支援することを推奨する。特に、各主題システムのドメインモデルとユースケースモデルを開発し維持することを推奨する。これらのモデルの完全なスコープはSAFeのスコープから外れるが、深く理解するためのヒントとして以下で簡単に紹介する。

ドメインモデル。一時的に、フィーチャー駆動開発(参考文献[2]と[3]を参照) という1つのアジャイル方法論が流行っていた。その方法論の8つのベストプラクティスの中の1つは、システムアーキテクチャー概念の主要なコンテナであるドメインモデリングである。ドメインモデルは、システムがサポートしなければならない現実世界のオブジェクト(人、設備、他のシステム、他の実体)の観点からシステムを説明するものである。システムの振る舞いの動的および静的な要素や、システムにおける関連のあるオブジェクトを識別するために利用される。このように、ドメインモデルはシステム全体の「ビッグピクチャー」ビューを提供し、システムを実装するあらゆる人に重要な文脈を提供する。このため、多くのプログラムはドメインモデルの開発、維持、伝達がアジャイルプロセスの重要な要素であることに気付いている。

ユースケースモデル。ASR[1]と[2]では、ユースケースとユースケースモデルはシステムの振る舞い、ユーザーや設備、他のシステムとの相互作用に関する理解に大変有用なツールであることを述べている。Cockburn[4](アジャイル宣言の署名者の1人)はアジャイルの世界でユースケースを広く利用している。ASR[1]の第19章はこの話題だけに費やされている。ユースケースモデルは、個別に実装されるすべてのユーザーストーリーのための文脈を提供することだけではなく、システムのフィーチャーがユーザーの大きな目標をどのように達成するかについても詳しく述べる。また、システム設計のベースとなる要求モデルとしても機能する。個々のユースケースを使ってより大きなエンドツーエンドの振る舞いを記述することができる。また、メインと代替の成功シナリオはユーザーストーリーの発見と実装のための主要なメカニズムである。

我々の経験上、この2つのモデルに関する開発、維持、伝達はアジャイルプログラムに大いに役に立つ。これらのモデルがなければ、さまざまな隠された仮説から誤解が生じ、システム設計や振る舞いのエラーとして現れる可能性がある。これらのモデルをアジャイル原則に従って開発できるシステムアーキテクトは、すべてのアジャイルプログラムにとって真の資産である。彼らは、ソリューションに最終責任を持つチームによって歓迎される。


さらに知りたい場合

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

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

[3] Palmer, Steve, and John Felsing. A Practical Guide to Feature-Driven Development. Prentice-Hall, 2002. (邦訳:アジャイル開発手法FDD?ユーザ機能駆動によるアジャイル開発、ピアソンエデュケーション、2003)

[4] Cockburn, Alistair. Writing Effective Use Cases. Addison-Wesley, 2001. (邦訳:ユースケース実践ガイド―効果的なユースケースの書き方、翔泳社、2001)

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.