フィーチャーチーム入門
by Craig Larman and Bas Vodde
Version 1.2
フィーチャーチームと要求領域は、リーン＆アジャイル開発を大規模開発で実践するためにとても重要です。この２つに関しては、"Scaling Lean & Agile Development" のフィーチャーチームと要求領域の章で、大規模で実践する際のスクラムの考え方と組織的なツール等を徹底的に分析しています。このフィーチャーチーム入門には、いくつかの重要な考え方を集約しました。また、より詳細な内容は"Practices for Scaling Lean & Agile Development: Large, Multisite, and Ofshore ProductDevelopment with Large-Scale Scrum" に記載しました。

フィーチャーチーム概論
図１に示したフィーチャーチームは、”組織の既存の枠やコンポーネント等にとらわれず、多くの顧客のフィーチャーを１つずつ完成させる長寿命のチーム” （１）です。

図１ フィーチャーチーム

(1)．フィーチャーチームは長期に渡り、常に協働し、共に多くのフィーチャーを実装します。

www.featureteamprimer.org
Copyright (c) 2010 Craig Larman and Bas Vodde
All Rights Reserved1フィーチャーチーム

フィーチャーチームの特徴は以下の通りです。

フィーチャーチームを採用する場合、最新のエンジニアリング技法（特に継続的インテグレーション）を用いることが不可欠です。継続的インテグレーションは、コードの共同所有を容易にし、複数のチームが同時に同じコンポーネントを実装するためには必要不可欠です。

”フィーチャーチームの全てのメンバーが、システム全体を把握する必要がある” という一般的な誤解がありますが、その必要はありません。なぜなら


全ての顧客のフィーチャーを実装するために、個人ではなくチーム全体でテスト、設計、プロ

フィーチャーは、やみくもにフィーチャーチームに配分されません。どのチームが、どのフィーチャーに着手するのかは、チームの現在の知識と技術により決定します。

グラミング等の実用的な技術とコンポーネントに関する知識等が必要であり、多種多様な分野で協働する事が望ましい。しかし、多くのチームは未だに...

フィーチャーチーム内では、専門作業を任せると作業と同時に、専門作業の学習を始めます。

www.featureteamprimer.org
Copyright (c) 2010 Craig Larman and Bas Vodde
All Rights Reserved2フィーチャーチーム

表１と図２は、フィーチャーチームと従来のコンポーネントチームとの差異を示します。
表１ フィーチャーチーム VS コンポーネントチーム(a) 異なる観点で最適化されたフィーチャーチームは、しばしば局所視点から遅く感じられます。
(b) フィーチャーチームは、比較的 "最新" の大規模開発で長期の実績があります。
Microsoft や Ericsson がその好例です。

(c) Mel Conway は、1968 年にこの望ましくない構造に気付き、推薦しませんでした。
実際、多くの点でフィーチャーチームと正反対です。
(d) 計画が追加される度に行われるリリース会議、もしくはリリースまでの経緯に、より多くの管理コストがかかる事は明らかです。

www.featureteamprimer.org
Copyright (c) 2010 Craig Larman and Bas Vodde
All Rights Reserved3フィーチャーチーム

図２ フィーチャーチーム VS コンポーネントチーム

以下の表は、フィーチャーチームと従来のプロジェクトもしくはフィーチャーグループの差異を示します。

表２ フィーチャーチーム VS フィーチャープロジェクト

コンポーネントチームの多くの欠点を Scaling Lean & Agile Development の "フィーチャーチーム"の章にまとめました。図 3 に、これらを示します。

www.featureteamprimer.org
Copyright (c) 2010 Craig Larman and Bas Vodde
All Rights Reserved4

フィーチャーチーム

図３ コンポーネントチームの欠点

コンポーネントチームでは作業量に差があり、WIP（Work In Progress）の高レベル、多くの引き継ぎ作業を要し、掛け持ち作業も増加する。これにより部分的な作業配分等になり、ウォーターフォールや V モデルの様な逐次的開発になる場合がある。

コンポーネントチームか、フィーチャーチームか？
純粋なフィーチャーチームは、価値の提供と組織への適応性の観点から理想的です。価値と適応性は組織の唯一の評価基準ではありませんが、多くの組織は、コンポーネントチームからフィーチャーチームに移行する間は、平行運用します。多くの企業がこの方法を採用したハイブリッド組織になった理由はコンポーネントチームが従来から継続的に行ってきた作業（インフラ構築、再利用可能なコンポーネント構築、もしくは、コードの整理等）の調整が必要だからです。しかし、コンポーネントチームを

www.featureteamprimer.org
Copyright (c) 2010 Craig Larman and Bas Vodde
All Rights Reserved5

フィーチャーチーム

作らず、純粋なフィーチャーチームだけで、この調整作業を行うことは可能です。どのように行えばよいのでしょうか。それは、顧客のフィーチャーに関連する "インフラ構築、再利用可能なコンポーネン
ト構築、もしくは、コードの整理等" があれば加え、プロダクトバックログにも追加します。フィー

チャーチームは当面（プロダクトオーナーが望む期間）、上記のような仕事を行い、終えたら顧客中心のフィーチャーの実装に戻ります。

フィーチャーチームへ移行
コンポーネントチームからフィーチャーチームへ移行する時、各企業ごとに戦略や計画が必要になります。私達は多くの経験から様々な戦略を持っていますが、異なる前提条件や異なる背景でそれを共有しても失敗します。時間はかかりますが比較的安全な戦略は、既存のコンポーネントチームの中から、１つのフィーチャーチームを設けることです。このチームが活躍した後に、第２のフィーチャーチームを設けます。これは、企業が満足する速度で漸進します。これを図４に示します。

図４ コンポーネントチームからフィーチャーチームへの段階的移行

www.featureteamprimer.org
Copyright (c) 2010 Craig Larman and Bas Vodde
All Rights Reserved6

フィーチャーチーム

要件領域概論
フィーチャーチームは上手く規模拡大しますが、１０チームを超え、１００人以上になった場合、組織の状態に合わせて構造を修正する必要があります。要件領域に適切に対応するためには構造修正が必要となりフィーチャーチームが、そのコンセプトを実現します。要件領域は、プロダクトバックログとは異なる分野の要件です。

プロダクトオーナーは、要件領域内の特定の要件に関する全てのプロダクトバックログ項目を集約します。次に、プロダクトオーナーは様々な観点から、総合的なプロダクトバックログ（エリアバックログ）へ意見を追加します。エリアバックログは、顧客視点から製品価値を把握できる専門家である "エリアプロダクトオーナー" によって優先順位付けされます。各要求領域は、エリアバックログに様々なフィーチャーを持っています。例を図５に示します。

図５ 要求領域

要求領域は、フィーチャーチームを大規模に適応したものです。製品構造に従い、チームを構造化することによって大規模に適応します。これは開発領域と言われます。表３に要求領域と開発領域の差異を示します。

www.featureteamprimer.org
Copyright (c) 2010 Craig Larman and Bas Vodde
All Rights Reserved7フィーチャーチーム
表３ 要求領域 VS 開発領域

最終的に、エリアプロダクトオーナーは、特定ではない複数のプロダクトオーナーをサポートしながら、全プロダクトオーナーを調整するよう働きます。エリアプロダクトオーナーは、プロダクトオーナーとは異なる事柄に焦点を合わせ、異なる責任を持ちます。故に、特定の１プロダクトではなく複数のチーム（少なくとも４チーム以上）と共に協働します。こうすることにより、１プロダクトチームによる組織の部分最適化を避けます。

結論
フィーチャーチームは、完全な顧客のフィーチャーを実装する安定したチームです。フィーチャーチームは、コンポーネントチームが引き起こした部分最適化と無駄なオーバーヘッドを解決します。しかし、フィーチャーチームは自ら知識、技術等の探求へ挑戦し続けなければなりません。

要件領域は、総合的な顧客のフィーチャーを用いてエリアプロダクトバックログを作ることで、フィーチャーチームのコンセプトを拡大します。その結果、フィーチャーチームは、どのような規模にも拡大しても（組織等を）構造化できます。

翻訳者よりフィーチャー入門をお読み頂き、ありがとうございます。ご意見、フィードバック、お気付きの点等がございましたら、私（Kazumasa EBATA : ebacky）ebacky AT odd-e.com までご連絡下さい。また、日本には “すくすくスクラム (http://www.sukusuku-scrum.jp/)” というスクラムのコミュニティがあります。よろしければ、一度、ご参加下さい。
最後に、本資料が何かの形で、皆様のお役に立てれば幸いです。

www.featureteamprimer.org
Copyright (c) 2010 Craig Larman and Bas Vodde
All Rights Reserved8フィーチャーチーム

参考文献

www.featureteamprimer.org
Copyright (c) 2010 Craig Larman and Bas Vodde
All Rights Reserved

9