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

フィーチャーチームの定義

そのチームがフィーチャーチームかどうかは以下で判断できる。
・そのチームだけで最終出荷製品が作れるかどうか。

リーン思考では、手渡し作業、待ち状態、仕掛り作業の制限、情報散財、未活用の人々、これらは致命的となる。
クロスファンクショナル、クロスコンポーネントフィーチャチームはそれらの無駄を減らすためのパワフルな解決策となる。

理想的なフィーチャーチーム

長期間存続。
クロスファンクショナルでありクロスコンポーネントである。
一緒に同じ場所で働く。
要求分析、デザイン、プログラミング、テスト・・・顧客中心の機能をすべてのコンポーネントにまたがって実現する
多能工で構成される
スクラムにおいては、7±2人で構成される。

フィーチャーチームのメリット

価値のスループットが増加する

顧客もしくは市場にプロダクトを届けることに焦点をあてる。

学びの増加

個人とチームの学びは、広い責任と様々なエリアのスペシャリストが集まり協働することによって増加する。

よりシンプルな計画をすることになる

組織的に計画がより簡単になる。例えば、コンポーネントチームが複数あった場合、それぞれのコンポーネントチームと調整が必要になるが、
フィーチャーチームの場合、このフィーチャーチームだけで調整は閉じている。

手渡し作業の無駄を減らせる

要求分析、デザイン、プログラミング、テスト・・・などのすべての作業において手渡し作業の無駄を減らせる。

待ち時間の無駄を減らせる

複数のコンポーネントチームでの協働の場合、そのコンポーネントができるまで自チームに待ちが発生する。その無駄を減らせる。

自己組織化、効率的にコストを改善できる

フィーチャーチームはプロジェクトマネージャまたはフィーチャーを市場または顧客の届けるためのマトリックスマネジメントを必要としない。
なぜなら、フィーチャーチームにすると、調整はささいなことになるかである。チームは顧客に届ける価値を自分達自身で調整し、彼らの仕事を仕上げる責任がある。
データはマネージャーの数と開発生産性に逆の相関があること、また、内部と外部の両方に焦点を当てたチームが成功する可能性が高いことをも示している。[AB07]
フィーチャーチームは出費を抑え、プロジェクトマネージャのようなオーバーヘッドを必要としない。

コードとデザインの品質がより良くなる

複数のフィーチャーチームで開発をすると、シェアすべきコンポーネントは、否が応でもクリーンなコードにせざるを得ないプレッシャーにさらされる。複数のフィーチャーチームで扱うのだから
コードフォーマットは標準化され、維持される。コンスタントにリファクタされ、たくさんのユニットテストで囲まれる。そうでなければ、仕事をすることが不可能になるからだ。
一方で、コンポーネントチームが長い間維持されると、彼らはそのコンポーネントに対する理解しか持たなくなり、似たようなスキルの人で固まり、よりコードをわかりやすくするという必要性に迫られない。

モチベーションをより維持できる

フィーチャーチームは、顧客と直接対話し、必要なものを作っているという実感を得られるとモチベーションが高まるという研究結果がでている[HO80, Hackman02]。
仕事満足度もあがる。これは、生産性と成功に重要なファクターとなる。

変更がより簡単になる

要求やデザイン、設計の変更により柔軟に対応できる。マルチコンポーネントチームとの相談や調整が不要になるし、コードがクリーンだから当然だ。

コンポーネントチームのデメリット

順次開発サイクルとマインドセットを助長する
同じコンポーネントを長期間開発し人々の学習を制限する
最も価値のある仕事よりも、簡単にできる仕事をすることを助長してしまう
人工的な仕事（仕事のための仕事）を助長してしまう
手渡し作業の無駄と長い待ち時間による大きな遅延の原因となる
コードの重複を助長する
増え続ける開発者を不必要に促進する（どんどん人を増やす原因となり、遅れが遅れを呼ぶ）
チーム間の計画と同期を複雑にする
ボトルネックを増加させる -あるコンポーネントチームが単一障害点となる-
より貧弱なコード・設計を育成することになる

よくある質問

例えば、デザイナーや要求仕様をまとめる人(Analyst)がフィーチャーチームでチームに加わっていたとして、その人の作業が終わるまでプログラマは作業ができないのではないか？

なぜプログラマはその人の作業が終わるまで待っているのですか？同じチームなのに。デザインが必要ならば、一緒にデザインをすればいい。要求分析が必要なら、一緒にやればいいのです。
忘れないでください。あなたたちはチームであり、共通の目的を持っている。そして短いイテレーションの中でその目的を達成し続ける必要があります。
プログラマがデザインの仕事を一緒にやることによって、より効率的な方法が見つかるかも知れません。逆のことも考えられます。
デザイナーやアナリストもプログラムを一緒に書きましょう。チームの一員なのです。これの繰り返しにより、メンバー全員のスキルが多能工になっていきます。よりよい世界が見れますよ。きっと。

営業やマーケティングもフィーチャーチームに加わるべきでしょうか？

原則はリーン思考になります。リーン思考を考えると、Time to Market。つまり、いかに迅速に市場や顧客にプロダクトを提供できるか、提供後に学び続けられるかが重要になります。
営業やマーケティングのメンバーがチームに加わることで、それが達成できますか？答えがYesなら、そうすべきですし、Noであれば、そうすべきではないでしょう。
必ず加わらなければならないということではありません。結局は、Time to Marketがより迅速になるかどうかだけです。フィーチャーチームになることが目的ではありません。
コンテキストに依存するので、一概にYesとは言い切れない場合もあるでしょう。

意欲に満ちていない人々を集めてフィーチャーチームはできますか？

アジャイルの12原則に少し違反しているようですね（笑
意欲は非常に重要です。ただ、フィーチャーチームはより顧客に近いところで仕事をすることになります。
人間は社会性を持つ動物ですので、他者の役に立ちたいと思う動機は、どのような人であり、多少はあるようなのです。
フィーチャーチームは、その動機を刺激することはできると思います。
でも、刺激をしたからといって、本当に人と接したくない方もいらっしゃるでしょう。
無理強いはよくないですので、それでも、もしモチベーションが全然上がらない方、それが２ヶ月以上続いたら、フィーチャーチームから『優しい言葉』をかけて去っていってもらうようにしましょう。