イノベーションは顧客ではなく、製作者から生み出す。
W・エドワーズ・デミング

フィーチャーとコンポーネントの概要

SAFeのチームレベルでは、テキストアイコン「フィーチャーとコンポーネント」はわれわれがソフトウェアシステムを構築するために利用する2つの重要な概念を具体化する。

  • フィーチャー は、ユーザーのニーズを直接的に満たすためのシステムの振る舞いである
  • コンポーネント は、識別できるシステムの一部であり、フィーチャーを実装するために必要な共通機能を提供し、カプセル化する。

アジャイルの価値提供はフィーチャー(とその構成要素となるストーリー)に重点を置く。フィーチャーはユーザーのニーズに応え、ソリューションを差別化する。しかしながら、弾力性のある大規模システムはコンポーネントによって構築される。コンポーネントは関心事の分離、ロジック再利用の促進、テスト容易性の改善を図る。これらは迅速なシステム進化のための土台を提供する。

フィーチャーとコンポーネントの概念の存在は広く知られているだろう。特に企業の俊敏さに関しては、フィーチャー、コンポーネントあるいは両者の混合を巡り、チームをどのように組むのかについて興味深い議論があるかもしれない。組織を適切なものにすることはスケーラブルシステムにおけるイノベーションを促進し、このシステムは知識の成長とともに達成される。組織を不適切なものにした場合には以下のどちらかの結果に至る。

  • 保守不能、急速に陳腐化する脆弱なシステム(すべてのフィーチャーでいつも)、あるいは
  • 企業の競争力を維持するために固有の将来のユーザー価値を持つ、見事に設計されたシステム(すべてのコンポーネントでいつも)

この文章は大規模アジャイルシステム開発の文脈において、これらの概念を説明したものである。また、ベロシティーの向上、価値提供の加速のため、アジャイル組織の継続的な進化に関する組織的なガイダンスを提供している。

詳細

コンポーネントとフィーチャー

ソフトウェアシステムのアーキテクチャーは部分的に「コンポーネント構造」や「フィーチャー」によって記述できる。フィーチャーを構成する一貫したユーザー向けの振る舞いを提供するために、コンポーネントは相互に作用し合う。拡張性、柔軟性、共通機能の再利用、保守性を提供するため、チームはこれらのコンポーネントを通じシステムを構築する。

以下の動機で、特定のコンポーネントの作成を促進できる:

  • 特定の技術の実装/分離(例:PHPベースのUI、Javaベースのビジネスロジック)
  • ロジックの再利用(例:トランザクション処理モジュール)
  • セキュリティ、コンプライアンス、安全性などを制御する目的に対する保護隔離
  • 予測された素早い要求の変更に対処するため(例えば:ブリッジ/アダプターモジュール、プロキシオブジェクトなど)

「コンポーネント」という言葉には広い意味がある。SAFeでは、以下の意味を持たせることができる:

  • システムレイヤ(UI、アプリケーションやデータレイヤ)
  • ソフトウェアモジュールやパッケージ
  • アプリケーションのライブラリ
  • サブシステム

コンポーネントチーム

コンポーネントチームは1つの「定義-構築-テスト」チームである。このチームの関心事はシステムの特定コンポーネントやコンポーネント集に限定されている。これによって、チームバックログは技術ストーリーユーザーストーリーの反対側として)はもちろん、リファクタリング作業やスパイクによって通常構成される。コンポーネントが以下に当てはまる場合、コンポーネントチームの構築が理にかない得る:

  • 他のエンティティ、ビジネスユニットやサブシステムによって利用できる場合
  • コンポーネントにまとめられなければ、コードベースの多くの箇所に現れ、保守性とテスト容易性が繁雑になる場合
  • コンプライアンス、安全性、セキュリティや条例に関する特定の機能の責務を持つ場合
  • ユニーク、あるいはレガシー技術を含む場合
  • 特定の深い技術や論理的で専門知識に基づいたアルゴリズムやロジックを提供する場合
  • 大規模データセット上で操作し、非常に多くの計算を実行し、また高い可用性や高い負荷等の重要な非機能要求を満足しなければならない場合

アジャイル以前に、多くの大規模システム開発プログラムはすでにコンポーネントやサブシステムによって編成された(古いお題目:組織はアーキテクチャーに従う)。従って、アジャイルへ移行時に、最も簡単な第1歩は、既存のコンポーネントベースの組織パターンに従って、アジャイルチームを編成することである。図1に示す。

図1. コンポーネントチームからなるアジャイルプログラム

図1. コンポーネントチームからなるアジャイルプログラム

フィーチャーチーム

上記の欠点は明らかである:数多くの新しいフィーチャーは、チーム間の協業が必要となる相互依存性を作ってしまう。チームはエンドユーザー向けの価値提供よりも、むしろ、多くの時間をかけて、チーム間の依存性を議論し、コンポーネントにわたる振る舞いをテストするので、これはベロシティーを継続的に低下させるものである。以下の場合には、コンポーネントやコンポーネントチームは当然必要ないだろう。

  • 数多くの新規ユーザーストーリーがコードベースにおける特定部分に対して、ユニークな変更を求める場合
  • 関心のあるコードがシステム上の他のコンポーネントと比べ、より高い重要性を持っていない場合
  • コードがユニーク、稀少なあるいは異なるスキルや技術を必要としない場合
  • コードが他のコードやコンポーネントやシステムにそれほど使われない場合

これらの場合、ユーザー視点で機能を中心として編成されるフィーチャーチームを作成するのが最もよい。図2に示したように、各チーム、あるいはチーム内小チームは、エンドツーエンドでユーザー価値の提供ができる。フィーチャーチームは主にユーザーストーリー、リファクタリング作業とスパイクを取り扱う。しかしながら、彼らのバックログに、たまに技術ストーリーも現れることがある。

図2. フィーチャーチームの例

図2. フィーチャーチームの例

しかし、フィーチャーチームと呼ばれても、このチームが常に単独でフィーチャーを完成できるということではない。フィーチャーが大きすぎて1つのアジャイルチームで消化できない際は、複数のユーザーストーリーに分解する。そして、これらのユーザーストーリーは順番に他のフィーチャーチームによって実装される。さらに、多くの有効なチームはフィーチャーまたコンポーネントの両方の責務を持つため、フィーチャーまたコンポーネントチームの概念は単純に割り切れず、以下のようにまとめられる。

最高のフィーチャーの処理能力を確保するために、SAFeは、一般的に、おそらく75-80%のフィーチャーチームと20-25%のコンポーネントチームの混合をお勧めする。

混合がもっとも適切であろうとすると、混合を促す2つの主要な要因がある。

  • 求められる専門性に対する現実的な制約の程度
  • 潜在的な再利用の経済性

図3は、どちらの選択肢が良いかを判断するために利用できるこれらのパラメーターとカーブを示す。

図3. フィーチャーとコンポーネントチームの判断カーブ

図3. フィーチャーとコンポーネントチームの判断カーブ

この「混合モデル」はプログラムベロシティーを向上させるために求められる他の能力を強調する。

  • システムレベル、継続的インテグレーション(CI)インフラ:フィーチャーチームは、任意の望ましいポイントでシステム全体を統合することができるようにしなければならない。
  • テスト自動化:広く、自動化された回帰テストスイートは構築され、利用可能にする必要がある。
  • 特殊なチーム、すなわちシステムチームは、フィーチャーとコンポーネントチームによって利用されるCIシステムとプロセスの積極的な改善と支援を務める。
  • フィーチャーチーム間で、コンポーネント関連の知識を共有するために、実践コミュニティを編成することができる。
  • 当然ながら、リファクタリング技術と共にローカルのコード品質を強く重視することは、スケーリングのために必須である。

まとめ

このページでは、フィーチャーチーム対コンポーネントチームを中心にアジャイルプログラムを編成することに関する些細な難問を説明している。フィーチャーチーム寄りの混合チームへの進化は、大規模アジャイル開発の高いベロシティーと効果を生み出すように見える。単純に、フィーチャーチームによって、依存性がより少なくなり、管理がよりしやすくなり、価値の創出力がより高くなる。それにしでも、これらの言葉はともに抽象な概念であり、ある人のフィーチャーが他の人にとってはコンポーネントかもしれない。そのため、アジャイルプログラムは継続的に検査と適応を行わなければならない。また、市場を駆動する価値に従うために、必要に応じ実際に再編成を行わなければならない。


さらに知りたい場合

参考文献

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

Last update: January 15, 2013

 © 2010-2013 Leffingwell, LLC. All rights reserved.