開発フェーズを重複させる

開発フェーズを重複させることで、メンバーは専門分野を超えてプロジェクト全体に責任感をもつようになる。

オリジナルでは...

自己組織化されたチームは独自のリズムを作り出す。開発と製造では、もともとスケジュールの考え方が異なっているのに、それが一体となって全体のゴールを目指すことになる。Type Aのように行程を逐次通過する手法（リレーアプローチ）では、前工程の要求事項がすべて満たされて始めて次の工程に移る。次行程へと移るチェックポイント毎にゲートを設けてリスクをコントロールする仕組みだ。しかし、この手法は上流で全体の自由度を過度に奪ってしまい、決定が後戻りができない欠点がある。また、ある行程で障害に出会うと流れが止まってしまい、そこがボトルネックになって全体の進行を阻んでしまうこともある。

一方、行程が重なり合ったType BやType Cのような手法（ラグビーアプローチ）では、発生する障害を全員でなんとか解決しようとする。さまざまな知見を持つメンバーが、チーム全体として問題解決に取り組み、ラグビーのようにボールを前に押し進めようとするのだ。

富士ゼロックスの例では、米国の親会社から継承したType Aの手法を改良し、行程を6つから4つに縮めるとともにサプライヤもチームに巻き込んで情報をオープンにしながら開発した。また、ホンダの新製品開発の例では、プロジェクトの中心メンバーはプロジェクトの最初から最後までずっとチームに残留し、すべての工程に責任を持つという。このように、Type Aで問題になる成果物の引継ぎ（リレーで言うバトンパス）を、文書で行わずに、人が行うことでスムーズにしている。文書ではなく、人が、情報を運んでいるのだ。

さらに、ラグビーアプローチでは開発期間短縮という「ハード」なメリットのほかにも人材育成に関わる「ソフト」なメリットもある。責任を共有しながら他のメンバーと協調すること、自分から積極的にプロジェクトに参加すること、さらに問題解決思考、専門外スキルやリーダーシップの育成、市場に関する知見の獲得、といった人材開発の要素がそこには多く含まれている。

逆に、デメリットとしてはプロジェクト全体を通して膨大なコミュニケーションが必要になること、また、異種の分野から集まった参加者の考え方の違いで、チーム内に衝突が多く起こることがあげられる。

アジャイル開発では...

アジャイル開発のスクラムでも、分析、設計、実装、テスト、という開発のフェーズが重なりあっている。さらに、メンバーは分析者、設計者、実装者、テスター、という専門部隊の垣根を取り払って１つのチームとなる。分析が終わったら設計、設計が終わったら実装、という流れではなく、一体となって、全員で開発に取り組むのだ。

アジャイル開発では、「スプリント」という１週間から１ヶ月の短い固定期間を区切るが、これが１つのリズムを形成する。このスプリントは、新製品開発のオリジナルスクラムにはない考え方の１つだ。スプリントによってチームは内部で、そして外部とも同期をとりつつ開発を進めることになる。

また、情報をオープンに保つ仕組みも、アジャイル開発に積極的に取り入れられている。チームの状況はバーンダウンチャート、バックログ、タスクかんばん、等々によって顧客にまで透明に共有される。

「仕様書」という厚い文書を壁越しに投げることで情報を伝達していたウォーターフォールから、壁を取り払って１つのプロジェクトを作り、対面のコミュニケーションを基本に情報を伝達し合いながら問題解決する、というのがアジャイル開発の中心にある。これは、オリジナルのスクラムからまっすぐに継承されている考え方の１つだと言える。

プロジェクトチームは自ら組織化する

チームは不安定な環境から自己組織化し、対話の中で自律状態を作り出す。

オリジナルでは...

不安定な環境から、チームの動的な秩序が生まれる。チームが自ら組織化を始めるのだ。自己組織化されたチームの状態には、(1)チームが自律しており、(2)常に自分たちの限界を越えようとし、(3)異種知識の交流が起こる、という特性がある。

マネジメントができるだけ口を出さないようにすることで、スタートアップ企業のような危機感と活気が同居したムードがチームに起こり、チーム自身が最初に設定された目標を超えて新しいゴールを設定するようになる。開発だけでなく生産や営業の人間をチームに交えることで、境界を越えて交流が起こるようになる。
例えば富士ゼロックスでは、FX-3500の開発チーム作る際に企画、設計、製造、販売、流通、品質保証のそれぞれのグループからメンバーを集め、多機能チームとして全員を１つの場所に集めた。いわゆる大部屋だ。こうすることで、自然に情報が共有化され会話が起こる。しばらくすると、自分一人の立ち居地だけでなくチーム全体としてのベストな決定は何か、という視点で考えるようになる。全員が他人の立場を理解することで、それぞれが他人の主張に耳を傾けるようになる。

アジャイル開発では...

同様に、アジャイル開発のスクラムでは、スプリント期間内に部外者からの指示を遮断し、「プロダクトオーナー」を通してのみ要求が入ってくるようにすることが基本のルールになっている。チームは自律してスプリント内のバックログの完成に注力する。と同時に、「スクラムマスター」はメンバーに指示を与えるのではなく、チームが自分たちで決定できる環境を支援するのが役割となっている。スクラムマスターは、チームに立ちはだかる障害物をどけて回るのが主な仕事だ。つまり、スクラムはあくまで自律性を尊重したチームづくりなのだ。

さらに、チームは１つの部屋に集まることが基本とされている。ウォーターフォールのソフトウェア開発では分業化が進んでしまった要求分析者、設計者、実装者、テスターという枠組みをはずしてチームを組むことで、異種知識の交流が起こり、自分の専門外の役割にも貢献できるような仕組みになっている。

スクラムではこの「自己組織化」(self-organization)という言葉が頻繁に使われる。このコンセプトのオリジナルは、ここであると同時に、複雑適応系の理論であろう。