アジャイルなチームとは

スティーブ・ジョブズはピクサーの映画作品の成功の裏には、どれだけ予定外の協調作業があったかについて語っている。
「トイ・ストーリー2」の公開後、ピクサーは手を広げ過ぎてしまいお互いの連携が疎かになっていることに気づき、カリフォルニアのエメリービルに20エーカー（東京ドーム2つ分程度）もの土地を取得し、社員全員を１つ屋根の下に集めた。
その成果はすぐに現れ、社員同士のコミュニケーションが改善され、お互いに協調して作業するようになった。
結果、ピクサーは長編作品を毎年公開する計画を立てられる力がついた。

社員同士のコミュニケーションや協調というのは20エーカーの土地を取得するほどに重要であることをジョブズは知っていた。いや、ピクサー「トイ・ストーリー2」での制作状況から感じ取り実行したのだ。
コミュニケーション能力というのはアジャイルのようなチームで課題に対処していく取り組みにおいては「高度なプログラミングが書ける」ということ以上に重要である。
メンバー同士がシナジーを生むことでしかアジャイルの真価は発揮されないからだ。
アジャイルにおいて、スペシャリストではなく、ゼネラリストこそアジャイルなチームには必要とされる。
それはアジャイルが職能横断型であることを考えれば必然である。

ここでアジャイル開発の原則として3つ重要な概念を紹介しておく。
・自己組織化
・成果責任と権限委譲
・職能横断型チーム

自己組織化というのは、目標に対してそれをどうやって達成するかを一歩引いた視点からみんなで客観的に考えることができるようになるために図られるものである。
自らのエゴを押し出し過ぎないように気をつけながら、チームで力を合わせ、「どう振る舞うことがお客様に対し最善の成果を届けることができるのか？」ということを考え抜く。
だから、自己組織化されたチームでの会話はこんな風になる。
「・・・もちろん、ボビーが得意なのはコードを短くすることだと思う。でもそれだけではなく彼はデザインへの造詣も深いから、ちょっとしたモックアップを作るのも手伝ってもらおう。」や「確かにスージーは最高のテスターだけれど、彼女が本当に活躍するのは、お客様の期待をマネジメントすることだよ。彼女はやり方も心得ているし、それをするのが好きだ。」といった具合である。

チームビルディングをうまくやるためには役割に人を合わせるのではなく、人に合わせて役割分担を決めることにあるということだ。
自分たちで計画を立て、見積もりをし、当事者意識を持つ。
肩書きや役割など気にせず、テスト済みのちゃんと動くソフトウェアを提供し続けることに心を砕く。
自分から動ける人を探す。他の誰かの指示を待つような人はアジャイルチームには相応しくない。

当然、こうしたことをやり遂げるためには「成果責任と権限が委譲」されていなければあらゆる面で許可を求めなければならず、チームが個人が主体的に動くことができなくなり、自己組織化を図ることができなくなってしまう。
良いチームというのは、自分たちがお客様から頼りにされているということをよく理解しているし、初日から成果を上げていかねばならないという責任を正面から受け止める。
「権限委譲された、成果責任を果たせるチーム」を作っていくためには、適切に権限が委譲されていることは当たり前だが、実際にどのようにして成果責任を果たしていけば良いのか？という問題に直面する。
ただこうした委譲されることに対し抵抗感を抱く者もいる。ただ職場に来て着席し、「刺身にタンポポを添えるだけの仕事」をこなした後に上から言われたことを粛々とこなしているだけの方がよっぽど楽なのにどうしてわざわざそんな面倒なことをしなければならないのか？と考えるのだろう。

実際に成果責任を果たすことに自信がないとしても現在実装しているソフトウェアをお客様にデモをすることで案外すぐに解決することができる。
そうすることでチームは自分たちの果たすべき成果責任に対してもっと自覚的になれるからだ。
自分たちのソフトウェアに期待している人たちが存在することに気づき、利用者は人間で解決すべき課題は現実のものだ。お客様は僕らが開発したソフトウェアを使ってそれをなんとかしたいと思っている。こんな風に実感できることの効果は大きい。

最後に職能横断型のチームとは顧客の要望に最初から最後まで答えられるチームのことである。
これを実現させるために開発チームに適切なスキルと専門知識が備わっていて、顧客が必要とするあらゆるフューチャ（※1）をきちんと届けられる必要がある。
開発チームに参加するメンバーを探す際には、幅広い作業をこなすことのできるゼネラリストが望ましく、プログラマで言えば技術全般に明るい人材。（フロントエンド、バックエンドのどちらかに偏っていない）が候補となる。
また、テスターやアナリストならばテストと要求分析を同じようにこなせる人物が良い。スペシャリストが必要になるのは、発生した事態に対処するスキルが開発チームに備わっていない場合である。基本的に開発チームは、プロジェクトの期間中は同じメンバーで協力し合い、一丸となって仕事をこなしていく。

職能横断型の真骨頂というのは物事をこなしていくスピードにある。他部門との余計な手続きが必要ない。だから初日から成果を上げることに集中できるのだ。誰にも邪魔されることはない。

（※1フィーチャとは、ソフトウェアの機能、特製や特徴、性能目標、見た目や使い勝手など、いわゆる「売り文句」などを総称する言葉。要求仕様、機能要件、大機能、ユースケースといった言葉がさすものとよく似ているが、決定的な違いは、ソフトウェアを使う側の視点から記述している点である。
フィーチャはユーザーにとっての価値であり、性能目標やセキュリティなど非機能要件も含まれる。）