プロジェクトマネージメント特性比較 Part2（全体総論）

アジャイル型とウォーターフォール型を比較してみた

　実際の論文では、この前にアジャイル型の定義、ウォーターフォール型の定義なんて話をしているが、ここでは割愛する。　

　前回説明したように、この記事の全体像は上記であるが、今回は、この一番外枠の実際の開発データによる回帰分析について記述する。
　実際のシステム開発の プロジェクト データを用いて アジャイル型と ウォーターフォール型の開発効率、開発速度効率の比較を行い、その差が生じる原因について、回帰分析モデルを用いて分析する。回帰分析による考察は [Nonaka, 2008] [佐藤, ソフトウェア開発プロジェクトの生産性評価に関する事例 ──真の価値と工数削減効果を計測する手法, 2016]を参考とした。

　分析対象のデータとして、 [Nonaka, 2008]や米国や諸外国の論文で使用されている ISBSG のデータを使用した。一定の条件（詳細は末尾の“条件”を参照）で抽出し全体で9552 プロジェクトから アジャイル型と ウォーターフォール型に分けた結果、アジャイル型は、142 プロジェクト、ウォーターフォール型は、124 プロジェクトを得た。
　
　”比較すると言っても、何と何を比べるんだ？”という話であるが、今回は次の三つの観点で比較を行った。
１．Project Elapsed Time （総開発時間）から計算される開発速度
２．Work Effort (労働時間) から計算される Productivity (生産性)
３．Defect Density （欠陥が出る比率、バグ比率）の比較

　開発尺度は、FP （ファンクショナルポイント）を採用している。このファンクショナルポイントとは、簡単に言うと機能の数である。
システム開発の結果としてユーザーがどれだけ機能を享受できるかという観点をデータとして表現しているのがファンクショナルポイントであるため、これをこの論文では採用した。

　まず、全体としての相対的な アジャイル型と ウォーターフォール型の比較を行った。
　下記テーブルは、目的関数の平均を使用して比較した結果である。各項目の内容についてはさておき、注目すべきは、全ての目的関数において アジャイル型よりもウォーターフォール型が優れていたことだ。
　開発速度は、ウォーターフォール型の平均数値が アジャイル型を上回り、次に生産性においても ウォーターフォール型の数値が アジャイル型の数値を上回り、さらには、欠陥が生じる比率においても ウォーターフォール型の数値が アジャイル型の数値を下回った（つまりウォータフォール型が優れている）。開発速度においては ウォーターフォール型が、アジャイル型より平均で 1.52 倍速く、生産性においては ウォーターフォール型が アジャイル型より 3.07倍 効率が良く、欠陥が出る比率においても、ウォーターフォール型が、アジャイル型の 2.01 倍低く出た。

　それぞれの比較について、細かく説明したいところだが、ちょっと長くなるので、一旦今回はここまで。

　あわてな～い、あわてない。一休み一休み。

プロジェクトマネージメント特性比較 Part3

データ背景
1． 過去の10年間のデータに絞るため、2009年から2019年のデータとする
2． Development Methodologies に、Agile、Waterfall と書かれているプロジェクトに限る。アジャイル型には、Agile Development、Agile Development; Extreme Programming、Agile Development; Personal Software Process、Agile Development; Scrum Agile Development; Unified Process のすべてを含む。
3． Functional Point (以降 FP) の Count Approach もしくは、FP Standardが、NESMA、IFPUG、COSMIC、EFP、FP のどれかであること。
4． Project Activity Scope が、Design、Build、Test、implement と一通りのシステム開発となっている事。Planning、Specificationまで含まれている物もターゲットのプロジェクトとする。逆に言うと、Build、Test のみのプロジェクト、Build、Test、Implement のみのプロジェクトは除外した。

（注）
1. ISBSG https://www.isbsg.org　プロジェクト の Research、コンサルタント会社であり、多くのソフトウェア開発会社が自分たちの開発の効率性や改善点を測るために開発データを提出している。今回は、2009年から2020年までのデータを会社名やプロジェクト名は秘匿された物を購入し使用している。
2.  Speed of Delivery (開発速度)：1時間当たりの FP 数であり、FP数 / Project Elapsed Time で計算される。数値が大きい程開発速度が速いと言える。
3.  Productivity （生産性）：１FP当りに掛かる Work Effort（労働時間）であり、Work Effort / FP 数で計算される。数値が小さい程に 1 FP 当りに掛かる労働時間が少なくなり、生産性が高いと言える。
4.  Defect Density （欠陥比率、バグ比率）: 1 FP 当りから出た欠陥数であり、総欠陥＊1000 / FP 数で計算される。数値が少ない程欠陥が出にくいと言える。
5.  Man Power Delivery (総工数生産性) ： FP Size をWork Effort と時間を掛けたものであり、FP 数 / （Project Elapsed Time * Work Effort） で計算される。数値が大きい程開発が効率的に行われていると言える。