シミュレートのためのモデルを構築
ここまで、開発期間の比較に焦点を当てることにした背景を紹介しました。スクラムとウォーターフォールモデルという異なる開発手法を比較するため、抽象化、つまりモデル化が必要になります。まずは、どちらの開発手法でも開発期間に差が出ないように、スクラムとウォーターフォールモデルどちらにおいても、4.5カ月で完了する、100という規模のプロダクトを定義しました。この想定プロダクトを用いて、スクラムとウォーターフォールモデルそれぞれのシミュレーターを考案しました。これを「基準モデル」と呼ぶこととします。
スクラムの基準モデル
1スプリントの期間は2週間と定義し、100ストーリーポイントを4.5カ月で完成させる必要があるので9スプリント必要ということになります。したがって、1スプリントあたりに完成させる必要のあるストーリーポイントは12と定義しました。これを表したものが図1です。
ウォーターフォールモデルの基準モデル
ウォーターフォール開発において、100という規模のプロダクトの設計、製造、テストにそれぞれ100という作業量が必要になると定義しました。規模の100と設計、製造、テストの作業量100は別のものになります。ここで、規模や作業量の100というボリュームに対してあえて単位を設けないことが、スクラムとウォーターフォールモデルという全く異なる開発手法を比較する、今回のモデルのポイントとなります。
次に、各工程の作業期間を設定しました。ソフトウェア開発データ白書2016-2017（ソフトウェア開発データ白書2016-2017、pp.185、情報処理推進機構、2017）によると、各工程の期間割合は設計（基本設計＋詳細設計）が40.5％、製造が26.1％、テスト（結合テスト＋総合テスト）が33.4％です。このデータを参考にしつつウォーターフォールモデル経験者で検討した結果、4.5カ月の内訳は、設計が1.9カ月、製造が1.0カ月、テストが1.6カ月と設定しました。また、各工程に携わる人数について、ウォーターフォールモデルの経験に基づき、設計が3人、製造が10人、テストが6人と設定しました。
ここで、「人の能力」を定義しました。例えば設計であれば、「人」は1カ月あたり18の作業をこなすことができるものとすると、3人で1.9カ月をかけると100という設計が終わることになります。同様の考えで、「人」は、製造は1カ月あたり10の能力、テストは1カ月あたり11の能力を持つ、と定義しました。これらをまとめたものが図2です。
不具合考慮モデルの構築
図1、図2で示した基準モデルはソフトウェア開発の理想であり、現実には不具合（ここでの不具合とはソフトウェアの単純な不具合のほか、要件や設計の漏れ、誤りも含めます）の発生を考慮しなければなりません。本シミュレーターでは、不具合がW％混入した場合、開発期間にどのような影響が出るかシミュレートできるように、不具合混入割合をパラメータ化しました。
スクラムについては、各スプリントに必ず一定割合の不具合が入ると仮定したモデルを作りました。毎回12ストーリーポイント消化するのですが、W％の積み残しが発生するため開発に必要な期間が延びることになります。またウォーターフォールモデルについては、その不具合の発生工程を指定できるようにしました。手戻り作業量については必ずしも不具合の割合とは一致しないため、設計のやり直し、製造のやり直し、再テストの割合をそれぞれX％、Y％、Z％とパラメータ化しました。
以上を踏まえたモデルは図3、図4のような概念となります。
このように、モデル化をすることでスクラムとウォーターフォールモデルといった、一見比較不可能な対象を今回は「期間」という特定の視点において比較できるようになりました。何かを比較する際は、（1）抽象化する、（2）視点を絞る、ことにより比較対象をモデル化することで観察可能な状態になり、考察や議論ができるようになる、好例となったと思います。
