Part7では,数あるアジャイル型プロセスの中でも,最も取り決めが緩い「クリスタル・ファミリー」について紹介する。最大の特徴は,プロジェクトを実施する過程で,開発プロセスの内容そのものをチューニングしていくことにある。

 本講座ではこれまで,開発者個人の生産性向上に焦点を当てた「プロダクト重視型」プロセスとしてXP(eXtreme Programming)を,チームの生産性向上に焦点を当てた「マネジメント重視型」プロセスとしてスクラムを取り上げ,各々の基礎と,実践の勘所を解説してきた。Part7ではプロダクト重視型とマネジメント重視型の中間に位置するプロセス,いわば「中庸型」のプロセスとして,「クリスタル・ファミリー」を取り上げる。

 一般にアジャイル型プロセスは,メンバー個人の自主性を尊重する傾向が強く,ウォーターフォールやRUP(Rational Unified Process)といった“重量級”プロセスに比べて決まったルールや手順が少ない。そんなアジャイル型プロセスの中にあっても,クリスタル・ファミリーは特に決まり事が少なく,抽象的とも思える言い回しも多い。以下ではクリスタル・ファミリーの背景にある思想や,基本的な開発スタイルを解説する。

規模と影響度を考慮

 クリスタルは,ソフトウエア・プロジェクト管理の専門家として知られるアリスター・コーバーン氏が,様々なプロジェクトを調査・分析した結果を基に,1997年に考案した開発プロセス群の総称である。同氏は多くのプロジェクトを調査して,1つのことに気付いた。それは,「すべてのプロジェクトを包含できる統一的な方法論を決めることはできない」ということである。一見当然のことのようだが,これを素直に認め,プロジェクトの特質によって開発プロセスに変化をもたせるべきと実際に提唱したのは,コーバーン氏が初めてだろう。

 通常のアジャイル型プロセスでは,メンバーの人数,すなわちプロジェクトの規模を基に,そのプロセスの向き/不向きを判断する。コーバーン氏の考え方が特徴的なのは,こうした従来の判断基準だけでなく,プロジェクトの成否が引き起こす「トラブルの影響度」も考慮している点である。

 プロジェクトは,その目的によって,問題が発生したときのインパクトに大きな違いがある。例えば医療現場のシステムや衛星軌道監視システムなどは,システムの不具合が場合によっては人命や,あるいは国家的な問題に直結する。商業目的のシステムでも,金融機関の勘定系システムなどは,システムの不具合による社会的影響が大きく,その企業の存続を脅かしかねない。

 コーバーン氏は,こういった深刻な影響を及ぼすシステムの開発プロジェクトと,トラブルの影響が比較的軽微なWebシステムなどのプロジェクトを,同種のチーム体制,同一の開発プロセスで実施することがそもそも誤りであると指摘している。この観点から,コーバーン氏はプロジェクトの規模や影響度に応じて,必要となるメンバーの役割や作成すべき成果物を分類・定義した。クリスタル・ファミリーは,文字通りそれらの“結晶”である。

プロジェクトに合わせて色分け

 図1に,コーバーン氏が調査・分類したプロジェクトの特性と,クリスタル・ファミリーの対応関係を示す。基本的な考え方は,規模が小さく(メンバーの人数が少なく),失敗した場合に社会・会社に及ぼす影響が比較的軽微なプロジェクトほど,“軽量”でコンパクトな開発プロセスが適しており,規模や影響度が大きくなるほど,開発プロセスそのものも“重量級”になっていく,というものだ。

図1●クリスタル・ファミリーの分類
図1●クリスタル・ファミリーの分類
著名なプログラマであるアリスター・コーバーン氏は,プロジェクトの規模(メンバー数)と,トラブルを起こした場合の影響度に応じて,プロジェクトを分類。各プロジェクトに適した開発プロセス群である「クリスタル・ファミリー」を考案した。クリスタル・クリアからクリスタル・レッドと規模が大きくなるに従い,メンバーの役割分担が厳格になり,成果物も増える

 クリスタル・ファミリーの中でも,最も軽量なものが「クリスタル・クリア」である。メンバーの人数が3~6人,トラブルの影響度が「快適さを失う」,または「自由裁量の資金を失う」の範囲に収まる程度のプロジェクトに対応している。イメージとしては,部門クラスの文書共有システムやイントラネットの経費精算システム,社外向けのWebアンケート・システムなどの開発プロジェクトだ。

 次に大きいプロジェクトに対応するのが「クリスタル・イエロー」である。メンバーの数が20人程度,トラブルの影響度が「会社の存続に関わる,非常に重要な資金を失う」ようなプロジェクトが対象になる。クリスタル・クリアに比べて,メンバーの役割や作成すべき成果物が,詳細に決められている(詳しくは後述)。中堅企業の受発注管理システムや顧客管理システム,生産管理システムなどをイメージするとよいだろう。以降,オレンジ,レッドという具合に,同じクリスタル・ファミリーでも,名称に入っている色が濃くなるほど,内容も重量級になっていく。

チューニングの「ルール集」

 クリスタル・ファミリーの最大の特徴は,開発プロセス自体をチューニングするのが大前提となっていることだ。そのためにクリスタル・ファミリーでは,開発プロセスの内容をチューニングする方針やルールを定めている。

  一般に開発プロセスでは,ソフトウエアの開発方法や各種の管理方法を定めている。アジャイル型プロセスで言えば,XPにはPart3で紹介したように,実践すべき項目として19のプラクティスを定めている。マネジメントを重視し,決まり事の比較的少ないスクラムでも,プロジェクトの節目で作成すべき成果物や,実施すべきミーティングを,明確に定義している。

 これに対してクリスタル・ファミリーでは,プロセスをどのようにカスタマイズすればよいか」が定められている。クリスタルでは「このようにせよ」という決まったやり方があるわけではない。むしろプロジェクトの過程で見つけていくものであるという考えかたを採っている。実際コーバーン氏は,「クリスタルは,アジャイル型プロセスを構築するルールを集めたものだ」と述べている。

 クリスタルではプロジェクトの立ち上げ時に,クリスタル・クリアからクリスタル・レッドのうち,どれをベースにするかを決める。そしてプロジェクトの途中で,選択したプロセスが適切かどうかを常に見直し,必要であればクリスタル・クリアからクリスタル・イエローに切り替えるといった具合に,プロセス自体を見直すことができる。つまり,プロジェクトにあわせたプロセスを,プロジェクトを実施しながら作り上げていくことができるのである。他の開発プロセスにもチューニングの余地がないわけではないが,ベースとなるプロセス自体を変えることは,他に例を見ない。