第1部でご覧いただいたとおり, スクラムとはいかにも不思議なソフトウェア・プロセスである. マネジメントに関するプロセスは詳細に記述されているが, エンジニアリングに関する具体的な記述は一切ないのである. スクラム・マスタ以外のスクラム・チーム・メンバが1ヶ月間することは「スプリント・バックログを解消すること」であってそれ以外の何ものでもない(日次スクラム・ミーティングに出席することを除いて). 「どうやって」スプリント・バックログを解消するかは「スクラム・チームの自律性」に任されている. つまりそれはスクラムのスコープには含まれていない. 多分ソフトウェア開発以外のプロジェクトにさえスクラムは適用可能だろう(筆者は経験したことはないが:-). スクラムが提供しているのは「スクラム・チームの自律性」を最大限に高めるための環境を作ることだけなのである.
もちろん優秀なスクラム・マスタを含む優秀なスクラム・チームはすぐにも高い自律性を発揮し, 大きな成果を挙げることができるだろう. しかし, 正直に言ってどんなチームでもすぐにそれができるとは限らない. 特にメンタやコンサルタントもなく, 見よう見まねでスクラムを始めたチームには何回かのスプリントでの試行錯誤が待っていると考えた方がよい. とすると, そのようなチームにとってはとりあえず「高い自律性を発揮して行われるであろう」エンジニアリング・プロセスの出発点があれば, 少なくともある程度の不安を解消することができる. そこで世間ではスクラムのマネージメント・プロセスを補完するエンジニアリング・プロセスとして, XPなどを併用して利用することがよく行われている.
第2部ではスクラムと他のプロセスの組み合わせや対応関係について見てみることにする.
スクラムを補完するアジャイル・プロセスとしてすぐ頭に思い浮かぶのはやはりXP(エクストリーム・プログラミング)だろう. XPはスクラムとは逆にほとんどがエンジニアリング・プロセスから構成されており, マネジメント・プロセスはあまり詳細に記述されていない. ただし注意すべきことは, XPの表面的なプラクティス(12個の初期プラクティス)としてはマネジメント・プロセスに関するものはほとんど含まれていないとは言え, XP自身はマネジメント・プロセスを軽視しているわけではないことである. XPにはXPなりのマネジメント・プロセスがあり, しかもそれが非常に重要な位置を占めていることは, Kent Beck始めXP提案者たちの著作, あるいはXP実施体験者たちの著作を見れば一目瞭然だと思う. XPの黎明期には既にスクラムは(少なくともオブジェクト業界では)よく知られており, XPもスクラムの強い影響下に誕生したものである.
スクラムとXPを組み合わせたソフトウェア・プロセスは広く行われている. 名前が付いてよく知られているものにはXBreed(http://www.xbreed.net/), XP@Scrum(http://www.controlchaos.com/xpScrum.htm)があるが, それ以外にも現場では普通に行われていると考えてよい. では具体的にスクラムとXPをどのように組み合わせればいいだろうか.
スクラムは以下のプラクティスを持っている.
これらのプラクティスは, スクラムの本質でもありどれをとっても切り離すことができないものである. すべてのプラクティスを取り入れてよいだろう.
一方XPのプラクティスは以下の通りである(ここに挙げているのは, あくまで「古典的な」XPのプラクティスである).
この中から例えば, メタファ, シンプルな設計, テスト, リファクタリング, ペア・プログラミング, 共同所有, 継続した結合, コーディング規約の8つのXPのプラクティスを, 先の9つのスクラムのプラクティスと組み合わせることができる.
<表にした方がいいかも>
XPの計画ゲームというプラクティスはスクラムのスプリント計画ミーティングというプラクティスで置き換えられる. スプリント計画ミーティングはスプリント・バックログをプロダクト・オーナとチームで決定するものである. 一方計画ゲームでは顧客のチームと開発チームがゲームに参加する. バックログ(ストーリ)の顧客側の責任者を一人に絞っているところがスクラムのXPとの差異である. これはチームの自律性を高くするために外部からの雑音を減らすためのアイデアと考えていいだろう.
よく考えてみると, このポイントはXPとスクラムの本質的な違いを物語っている. スクラムでは1ヶ月というスプリント期間に限ってではあるが開発チームを外部雑音から遮蔽して, できる限り閉じた環境を作り出す. 一方XPではある程度の外部雑音を許すことによって, 開発チームに揺らぎをもたらし, それによってチームの応答性を高めていく. これを後に述べる「複雑系」という観点からみると興味深いだろう.
XPの短期リリースというプラクティスはスクラムのスプリントというプラクティスで置き換えている. XPの短期リリースは数週間程度の期間を想定しているのに対して, スプリントの期間は1ヶ月間である. 必要があれば30日間というスプリント期間を2~5週間程度に調整してもよいだろう(スクラムの提案者たちは「まず30日でやってみろ. 変えるならそれからにしろ」といっているが). また最初あるいは最後どちらかのスプリントの期間の長さを顧客の都合に合わせて変更する場合もある. ただし, 少なくともそれ以外のスプリントに関しては同じ期間の長さにした方がいいと感じている. 開発にリズムができるからである.
XPの40時間労働というプラクティスは採用しない. スクラムではチームの自律性を重要視するので, 働く必要があれば残業でも休日出勤でもするのである. 残業や休日出勤がバックログの解消にかえって障害になる(欠陥を増やしてしまうとか)とチームが考えれば, 残業や休日出勤は止めるだけの話だ.
XPのオンサイト顧客というプラクティスは, スクラムの製品オーナというプラクティスで置き換える. XPは「常に」顧客とコミュニケーションし, できる限り変更を受け入れるが, スクラムではスプリント期間中は顧客からの変更要求は一切受け入れない.
このようにしてXPとスクラムのプラクティスを組み合わせて作ったプロセスは, マネジメント・プロセスとしてはスクラムをベースとし, それにXPのエンジニアリング・プロセスを組み合わせたものになっている. XPから見ればよりチームの自律性を強化し, スクラムから見ればスプリント期間中のチームのエンジニアリング・プロセスを具体化していると言っていいだろう.
ここで見たようなXPとスクラムの組み合わせで興味深いのは, 複数の時間スケールにわたる繰り返しが重層化していることである. つまりXPのテスト - コード - リファクタリング - 統合の数時間単位の繰り返し, 日次スクラム・ミーティングの1日単位の繰り返し, スプリントの30日単位の繰り返しが重なり合っている(注1)のである. この重層的で定期的な繰り返しのチームへの定着が, チームの生産性向上(注2)に大きく貢献していると筆者は考えている. ただしこれらの繰り返しは単純な繰り返しではなく, 必ず検証と計画が伴い, かつ外部とのコミュニケーションを前提としていることが重要である.
ここで検証とはそれぞれ
を指している.
また計画とはそれぞれ
を指している.
外部とのコミュニケーションとはそれぞれ
を指している.
<表にした方がいいかも>
こう考えると, 週(数日)単位の繰り返しがないのが不思議に思われてくる. 「時間」のサイクルを数回繰り返すことで「日」のサイクルが構成されのに対し, 「日」のサイクルは20回以上繰り返さないと「月」のリズムは構成されない. 仕事のリズムにとって「週」というのはそれほど自然なものではないのだろうか? あるいは平日と週末からなる社会的な1週間というサイクルの存在によって補完されているのだろうか? また国民の祝日のような非定常的な休日の存在はプロジェクトにどのような影響を与えているのだろうか?
生産性とはなんだろうか? 特にアジャイル開発プロセスにとって.
同じようにスクラムのマネジメント・プロセスと他のソフトウェア・プロセスのエンジニアリング・プロセスの組み合わせを考えることもできそうだ. 例えばフィーチャ駆動型開発(FDD)は, XPに較べると古典的な繰り返し的開発手法で, UMLを用いたモデリングをベースとしている. スクラムのマネジメント・プロセスとFDDのエンジニアリング・プロセスを組み合わせることはできるだろうか? またその組み合わせは強い効果を発揮するだろうか?
FDDは古典的なソフトウェア・プロセスに近いので, プラクティス以外にも役割や手順などが詳細に記述されている. それらをすべてここで説明するわけにはいかないので, 主要なプラクティスを中心にFDDの概略を[A Practical Guide to Feature-Driven Development, Stephen R. Palmer and John M. Felsing, 2002, Prentice-Hall]に従って見てみることにする.
ドメインのエキスパート, チーフ・プログラマ, チーフ・アーキテクトなどからなる複数のモデリング・チームを作り, 問題領域のウォークスルー, 調査, モデリングを行う. 作成するのは問題領域のクラス図とシーケンス図などである. ドメイン・オブジェクト・モデリングを行う理由は問題領域をよく理解し, それを元にフィーチャを発見するためである.
フィーチャとはユーザ機能のことである. ドメイン・モデルに基づいて, 主要フィーチャ・セット, フィーチャ・セット, フィーチャの3階層にリスト化する. 各フィーチャをフィーチャ・チームに割り当て, チームごとに設計/構築を2週間単位で繰り返す.
クラス担当者は, フィーチャの中の主要なクラスごとに決められ, そのクラスに関する責任を負う. 基本的にクラス担当者以外がそのクラスに関して干渉することはない.
フィーチャ・チームには一人のチーフ・プログラマがおり, (通常複数の)フィーチャを割り当てられている. フィーチャ・チームのメンバは割り当てられているフィーチャにに関するクラスの担当者である. したがって一人のメンバが複数のフィーチャ・チームに属することもある. フィーチャ・チームの主導権はチーフ・プログラマが握っている.
設計と構築の最後にはフィーチャ・チームで設計やコードに対するインスペクションを行う. インスペクションとは非常にフォーマルなウォークスルーと考えるとよいだろう.
コードは常にビルドされている.
構成管理ツールを用いて, 成果物(モデル, コードなど)を構成管理する.
フィーチャごとに進捗をチェックする. これによって, 進捗の度合いはかなり明瞭に把握される.
これらのプラクティスを組み合わせたFDD全体のプロセスは以下のようなものである.
<図がいいか>
ではFDDとスクラムをどのように組み合わせることができるだろうか? まずFDDでいうフィーチャとスクラムのバックログはほぼ同じものを表していると考えてよい. すると1~3のプロセスがスクラムのスプリント計画ミーティング(と製品全体の計画を立てるプロダクト計画ミーティング)に相当する. スクラムではスプリント計画ミーティング(プロダクト計画ミーティング)でどのようのバックログを決定するかについて何も述べていないので, これはスクラムのエンジニアリング・プロセスを補完するだろう.
同じように考えれば, FDDの4,5(フィーチャごとの設計/開発)がスクラムのスプリントに相当する. スクラムのスプリントは30日間だが, FDDではフィーチャの設計/開発のイテレーション期間を2週間としている. これはFDDがイテレーション内のアクティビティについてかなり明確で詳細に定義しており, チーフ・プログラマという中心的存在があるために比較的短いイテレーション期間が適しているものと考えられる. 逆にスクラムのようなチームの自律性に任せるような方法論では2週間という期間は短くて, 十分な自律性を発揮するに足りない.
この点がFDDとスクラムの本質的な相違点を示唆しているように思われる. つまり, スクラムではチームの自律性を最大限に尊重することによってアジリティ(迅速さ, 機敏さ)を獲得しようとしているのに対して, FDDは権限を集中(チーフ・プログラマ)したり, 責任をあらかじめ決められた個人に負わせたり(クラス担当者)することによってプロセスを明確化しているのである. そもそもスクラムはプロジェクトの目標が非常に困難であったり, 不明確であったりする場合に有効であるのに対して, FDDはプロジェクトの目標や技術的内容が比較的明確である場合に有効な方法論であると言えよう.
したがってスクラムとFDDを組み合わせようとするときには次の二つの戦略があり得ることになる. ひとつはチームの自律性を確保しつつ, エンジニアリング・プロセスを導入するFDD的スクラム, もう一つはプロセスの明確さを優先しつつ, スクラムのプラクティスを導入するスクラム的FDDである.
FDD的スクラムでは以下のようなプロセスを考えることができる.
FDD的スクラムは, バックログを決定するのにモデリング的手法を利用したい場合に有用である. それ以外はチームは自律的に活動し, チーフ・プログラマのような存在は考慮しない.
スクラム的FDDでは以下のようなプロセスを考えることができる.
スクラム的FDDは, 最初のドメイン・オブジェクト・モデリングでは理解できない範囲のチャレンジングな課題を持つような場合に有用である. FDDにスクラム・マスタと日次スクラム・ミーティングを組み合わせたものになっている.
同じようにスクラムと他のアジャイル・プロセスとの組み合わせ, スクラムと古典的プロセスとの組み合わせ, スクラム以外のプロセス同士の組み合わせを考えることができるだろう. その中にはアジャイル・プロセスを自分たちのソフトウェア組織や自分たちが持つカスタム・プロセスに適合させる場合も含まれる.
いずれにしろ重要なのは
ということを明確に認識できている必要がある. そうでなければプロジェクトはうまくいかないだろう.
プロセスの組み合わせという考え方は本質的には「プロセス・チューニング」のひとつの手法であり, 既に存在するプラクティスを組み合わせればいいと考えれば容易に思えるかも知れない. しかし本来異なるプロセスを組み合わせるために, それらのプロセスの負の側面同士があらわになったり(劣性遺伝), プロセスとプロセスが干渉して衝突を起こしたり(移植不適合)するリスクがつきまとっている. それらのリスクが不適切である場合には, あるひとつのプロセスを出発点にしてチューニングしていくような方法をとるべきだろう.