Scrumチームを編成する際の必読記事２点

昨日のエントリー（QA versus Testing! Antagonism or Symbiosis? - Always All Ways）でQA/テストからの視点でチーム編成に少し関連することを書きましたが、一般的に、Scrumにおけるチーム編成を行う上でポイントとなることが２点あります。それは、

チーム分けの切り口（フィーチャーチームvs.コンポーネントチーム）
メンバーの多能工化の進め方

私自身も過去に複数チームで一つのシステムを開発するような組織へのScrum導入・展開を推進したときにメンバーからよく聞かれました。その時に自分自身で繰り返し参照したり、メンバーに読むことを進めたりした文献がありますので、少し前の文献になりますが改めてここで紹介しておきたいと思います。（「こんなのあるから、一度読んでみて！それから、うちの会社でどうすればいいか一緒に考えよう！」みたいな感じでディスカッションねたとして使うのがオススメです。）

Feature Team Primer

まずひとつめは、Craig Larman and Bas Voddeの"Feature Team Primer"という小冊子です。これは、以下のサイトにあるリンクからpdf形式でダウンロード可能です。
http://www.featureteamprimer.org/
江端さん（@ebacky）による日本語訳もあります。
10ページ足らずの文書でさらっと書かれていますが、実際の現場で何をどう変えていくかとかフィーチャーチームにすることによる弊害・デメリットをどう極小化していくかなど考えるととても奥が深いテーマです。

Specialization and Generalization in Teams

もう一つが、同じくBas VoddeがScrum Allianceのサイトに投稿した記事です。
Scrum Alliance - Specialization and Generalization in Teams
一般的にScrumチームでは多能工が求められると言われています。果たして、全てのメンバーがジェネラリストとして全てのタスクを担当できるようにならなければいけないのでしょうか？そんなの難しいですよね。この記事の一つのメッセージは以下の文章に集約されているように思います。

A mismatch between skills and requirements does not mean that everyone in the team needs to be able to do everything. That type of binary thinking leads people to think there are only two choices: specialist or generalist.

要するに、SpecializationとGeneralizationのバランスが大事ということですね。では、そのバランスは、どうやって生まれるのでしょうか？それは、メンバーが例えばそのスプリントでやるべきタスクの全てについて責任をシェアできた時に生まれます。そのために、各メンバーは一つのことのスペシャリストであることから少し離れ、複数の専門を持つこと、あるいは隣接領域にまで専門を広げる努力をすることが求められます。そして、そのバランスが取れたとき生まれる組織のダイナミクスは以下の通りです。

Specialization is used when it's the fastest way to generate value.

There is an opportunity for team members to have multiple specializations.

There is an opportunity for team members to focus on their specialization as long as it generates value.

A mismatch between available and needed skills automatically creates learning in the team

共通すること

この２つに共通することはいくつかありますが、最も重要なのは「学習」だと思います。フィーチャーチームを作ったり、またコンポーネントチームからフィーチャーチームに移行したりするときも、チーム内におけるSpecializatiionとGeneralizationのバランスを取ったりするときも、そこではある意味個人としてあるいは組織としての「学習」が要求されます。その意味では、Scrumは改善のフレームワークであるとともに、組織の学習を強制するフレームワークとも言えるかもしれません。