化学で不毛な土壌を解決できない。

—Joel Salatin

アーキテクチャーフィーチャーの概要

アーキテクチャーフィーチャーは、開発者がソリューション価値を納品するビジネスフィーチャーを実装できるための技術的システムサービスである。ビジネスフィーチャーと同様に、アーキテクチャーフィーチャーはプログラムバックログに維持され、そこで識別され、優先順位が付けられ、経済性に基づいて調整される。システムアーキテクトがこれらのフィーチャーの識別、分割と優先順位付けに責任を持つ。実装はアジャイルチームの責務であるが、アジャイルチーム、システムアーキテクト、システムチームとプロダクト管理層の連携の結果である。

詳細

すべてのシステムは、必要な新しいビジネス機能をサポートできるようにするために最終的に大幅なアーキテクチャーの変更を必要とする。したがって、システムアーキテクチャーは、変化するビジネス環境に反応するように常に進化しなければならない。そうしないと、開発のベロシティが急激に低下する。SAFeでは、アーキテクチャーフィーチャーと呼ばれる固有のプログラムバックログ項目の一種を介して、システムレベルのアーキテクチャーへの取り組みを促進する。新しいソリューションの機能を迅速に導入できるために欠かせないアーキテクチャー滑走路の構築では、アーキテクチャーフィーチャーが利用される。 典型的にアーキテクチャーフィーチャーは主に以下の3つから由来する。

  1. ポートフォリオレベルからビジネスアーキテクチャーエピックを分割する結果。例えば、「スイートにすべての製品に共通のインストールを実装する」というようなビジネスエピックは、「InstallShieldを使用するコーポレートチャットサービスを適応する」というアーキテクチャーエピックを駆動することがある。
  2. プログラムビジョンロードマップから。例えば、検索システムが「キーワードで検索する」、「トピックの自動要約を構築する」や「検索結果のフィルタリング」というような機能が必要かもしれない。初期の技術的な反応は「エンティティ抽出メカニズムを構築する」であるかもしれない。
  3. 現行のソリューションからの課題。例えば「パフォーマンスを向上させる」というニーズから「ユーザ画面を3秒以内で表示する」という非機能要求が生まれることがある。実際には、非機能要求の多くは、アーキテクチャーフィーチャーの結果として出現する。図1に示されているようにそれらは時間をかけて構築されることが多い。

図1. アーキテクチャーフィーチャーの結果として数多くの非機能要求が時間とともに実装される

アーキテクチャーフィーチャーはプログラムインクリメント(PI)の区切り内に収まるように、必要に応じて分割する必要がある。ソリューションのフィーチャーの取り扱いと同様に、アーキテクチャーフィーチャーを分割し、インクリメンタルに実装することは、技能であり、科学であり、また、プログラムや実際に企業スケールでの俊敏性を実現するために必要不可欠なスキルである。

アーキテクチャーフィーチャーの分析とモデリング

すべてのアーキテクチャーフィーチャーはシステムの転換として考えることができる。図2に示されているように、そこで、新しいシステムは新しい品質を取得する。

図2. アーキテクチャーフィーチャーはシステムを異なる状態に転換する

図2. アーキテクチャーフィーチャーはシステムを異なる状態に転換する

この転換を達成するために、システムモデル、内部システムロジックと非機能要求(NFR)は同様に変化する。例えば、「レスポンス時間が3秒以下」に達成するため、内部ロジック「select data from tables X, Y and Z…」は「create indexes for the required fields; select data from X, Y, and Z…」、「更新するまでデータセットをメモリに保持する」へ転換しなければならない。変化を通じて考えることが必要とされる分析のほんの一部である。分析は以下も含む:

  • ソリューションの影響範囲を分析する
  • フィーチャーを分割する
  • 受け入れ基準を識別する
  • 実装の工数を見積もりする
  • 影響とリスクを評価する

実装

実装では、プログラム内の様々な「役割」の努力を同期させることが必要である。

アジャイルチームはアーキテクチャーのためにコードを実装し、以下のことも行う:

  • テストシナリオを実装するプラクティスやアプローチに関する新しい知識を交流する
  • 関連するインターフェース、アルゴリズムとコンポーネントインタラクションを伝達する
  • システム全体のリファクタリングの結果として、依存関係や冗長性を管理する

システムアーキテクトが実装をサポートし、通常以下の責務を持つ:

  • フィーチャーに関する共通の理解を促進し、実装のための計画を理解する
  • 特定分野の専門家や利害関係者として、アジャイルチームの計画、バックログの手入れ、デモを参加する
  • プロダクトオーナーと一緒に作業をし、フィーチャーの受け入れ基準や技術ストーリーを定義する
  • 新しいシステムを統合し、テストするために必要なインフラの変化を理解し、システムチームと協力する
  • 重みづけされた最短作業から着手(WSJF)を利用し、アーキテクチャーフィーチャーの優先順位付けを行う

システムチームは以下のことを行う:

  • 統合とテストのインフラへの変更を実装する
  • アーキテクチャーフィーチャーに必要とされるシステム要件の検証を保証するために、新しいNFRのテストを作成する
  • 関連するNFRをテストするためのデータセットやテストケースをアジャイルチームに提供する

プロダクト管理は以下のことを行う:

  • プログラムバックログはビジネスとアーキテクチャーフィーチャーの適切なバランスで最適化されていることを保証する
  • アーキテクチャーフィーチャーは、ビジネスフィーチャーのフローを促進する順序で実装されていることを保証する
  • ビジネス機能とシステム品質間の相対的な影響と依存関係を理解するために、プロダクトオーナーと一緒に作業する

さらに知りたい場合

[1] 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.