ブロックボールゲームの結果

　5つのチームを作り、別々の部屋に分かれてゲームを行った。それぞれのグループ構成は以下の Diagram のとおりである。Team A (Table 48)、Team D (Table 51)は、全員会社員でありながら、かつ、MBAに通っている学生たちのグループ、Team B (Table 49) は、全員会社員である。Team C (Table 50) は全員が営業職で、Team E (Table 52)は、全員がシステム開発に携わっている者で構成されている。また、全員が、ブロックボールゲームの経験はない。Team A は、全員がシステム開発に関わっていないビジネスパーソンたちであり、Team Bは、全員が何らかの形でシステム開発に携わっているビジネスパーソンである。ブロックボールゲームをそれぞれに初めて作ってもらった結果を各 Diagram の一番下に記した。それぞれの人のブロックボールゲームに対する親和性、言い換えれば、能力の差として見ることが可能である。

　以下の Table 53が5チームで行ったゲーム (プロジェクト) の結果のテーブルである。Figure 47 が、それぞれのチームのアジャイル型とウォーターフォール型でかかった時間の合計時間の比較であり、Figure 48が、それぞれのチームのアジャイル型とウォーターフォール型の時間の比較である。第4節の総括でこれらの結果を元に考察を議論する。

ブロックボールゲーム実験総括

これらの結果(Table 55、Figure 46、Figure 47)から言えることは、以下である。
1） 全ゲームの全チームが アジャイル型よりも ウォーターフォール型の方が速度が速かった。 また、トータルのかかった時間でもアジャイル型よりもウォーターフォール型に掛かった時間が少なかった。このことから、どのような状況でも、開発速度だけを見ると アジャイル型よりも ウォーターフォール型の方が効率的な開発であると言える。

2） 全体を通して、一番時間がかかったのは、多くのチームでゴールを変えた際の アジャイル型であり、特に Team A、Team B、Team Eでは、ゴールを変えた場合にアジャイル型とウォーターフォール型のゲームにかかる時間差が大きかった。アジャイル型よりも ウォーターフォール型が優れているという 1）の考察と共に、ゴールを変える際には、特にアジャイル型は適切とは言えず、ウォーターフォール型を採用すべきである。このことから、“ゴールやシステム要件が変わる要件リスクが高いプロジェクトでは、最初から全てを決めるウォーターフォール型よりも柔軟なアジャイル型を選択すべき”という帰無仮説は成り立たず、棄却されることを示唆している。

3） 2）の次に時間がかかったのは、アジャイル型で説明書を見せて行うゲームであった。分割してパーツが渡されるのに説明書がある場合に、チームによっては混乱が見えた。これは、アジャイル型ではある程度の自由を与えて開発をさせる方が向いており、完全に作るものを決めてしまうとやりにくさを感じる特性があるようである。

4） ランダムに各ゲームを行ったが、最後になればなるほど、時間が早くなっていった。つまり、ゴール、要件、説明書などの“あり無し”よりも、Skill Risk （作成の慣れ）が物を言う事が多く、これは実際のシステム開発では、Developer のレベルが高ければ全体の速度も品質も高くなることがあるという事が言えよう。

5） 8回のゲームは、実際の開発プロジェクトのように各参加者にストレスを与えた。つまり8回のゲームは少々長く、最後の2回は人によっては疲れを見せた。また、目的意識を持つ人にとってはチームメートの貢献に不満を持つこともあった。そのストレスをどう対処するかでゲームの結果が変わった。怒りを露わにし文句を言うチームは悪影響を与え、気持ちを露わにせず冷静なチームやムードメーカーがいるチームは最後までペースが変わらず安定した結果が表れた。

6） ゴールを変える、要件を変えるという行動は参加者に大きなストレスを与えた。結果にも表れているが、それ以上にゲームのやる気をなくしたり不平を言う方もいた。ゴールや要件が変わること自体への不平もあったがどのように変えたら良いか分からないチームはさらに参加者にストレスを与え結果を悪くした。

7） ウォーターフォール型よりも、アジャイル型の方が Fail 数が多かった。これは、チームの性格にもよる。例えば、Team Aがテストを入念に何回も行ってから完成するというチームの性格で、Team Bは、テストは一回だけ行い、一回成功すれば、完成というチームであるというチームの特性にもその要因はある。しかし、アジャイル型の場合、完成形までが分散されるため、全体としてのテストが行いにくく、それぞれを別々に作成していくため、途中で全体の整合性を確認するというステップが入る。また、そのステップは確認するのが難しくなるという事も観察された。

8） 一人でもブロックの作り方を理解している人間がチーム内にいると全体的に早くなる。例えば、Team B には、参加者番号6 (Table 51) がおり、その者が PMの役割をして全体を引っ張っていた。 このことから、実際のシステム開発においても、一人でもレベルが高い、もしくは経験が多い人がいるとチーム全体のレベルが向上し、結果も向上すると言える。

　次回、最後の回として、全体総括をしてこの長い連載を終わろうと思います。