スクラムの原典を読み解く(4)

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

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

オリジナルでは...

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

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

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

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

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

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

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

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

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

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