開発手法の選択はなぜ難しいのか？
システム開発を進めるための手段には多種多様なものがあり、その選択には頭を悩ますことになります。「手段」といえば「移動手段」にもいろいろな種類がありますが、自転車と飛行機、どちらが優れているかという議論はあまり聞いたことがありません。なぜしないかは明確で、どちらが優れているかを一般的に決めることに意味がないからです。自転車の方が適していることもあれば、飛行機の方が適していることもあります。
乗り物については判断材料が単純明快なので、議論されることは皆無です。ところが、開発の進め方となると話は違ってきます。開発対象のドメインについての知識やそれを実際に作る人、はたまたどの手法が適切なのかを判断をしようとしているあなた自身の経験などが絡み合います。結果的には、総合的に判断する必要があるという点が大きな違いです。
この悩みには実際に開発現場でも向き合うことがありました。「この開発手法でやった方が明らかに向いているが誰もが理解できる言葉で言語化できない」といった経験談や、「ステークホルダーの理解を得られない」といった経験談を聞いたこともあります。そこで、何としても開発手法を客観的に比較でき、その結果を判断材料のひとつとして活用できるものを作りたいと考えました。
当初、比較対象を絞ることなく比較しようとしたため、期待していたような比較結果を導き出すことができませんでした。そこで、「ウォーターフォールモデル」と、「アジャイル開発」のメソドロジーのひとつである「スクラム開発」とを比較することにポイントを絞りました。その結果、客観的に比較ができるようになりました。
比較可能なモデル作成のアプローチはどのようにしたか
スクラムとウォーターフォールモデル、これらの異なる開発アプローチを客観的に比較するために、「なにか共通項目を挙げることができないか」といった点から検討を行いました。それらを比較する上で、まずスクラムとウォータフォールモデルで開発対象をどのようにモデル化するかを考えました。
ウォータフォールモデルについては、開発対象をソースコードの規模で捉えることがよく行われます。一方スクラムでは、プロダクトを実現すべきユーザーストーリー（実装する機能など、ユーザーがどのように対象のプロダクトを使うかという目線に立って表現したもの）に分割できると考えました。そして、各ストーリーに対する規模を相対的に見積もったものである、ストーリーポイントの総和を全体的な規模として捉えました。
モデル化するにあたり、「作るものの規模」といったどのようなプロセスを用いても変わらない普遍的なものが共通して存在すると考え、その概念に近いと考えられるストーリーポイントを基準にして、作る対象の規模として捉えることにしました。
次に、比較対象としてQCD（生産管理の3要素である「Quality（開発品質）」「Cost（開発コスト）」「Delivery（開発期間）」の頭文字を取ったもの）に着目しました。ウォータフォールモデルを用いた開発では、QCDの観点で評価する手法が長年行われてノウハウが培われてきています。一方のスクラムでQCDを測定する場合、どのようにそれらを捉えたかを表1に示します。
| 開発品質（Q） | 一定の期間内にエンドユーザーに提供できたストーリーポイント |
|---|---|
| 開発コスト（C） |
必要なスプリント数 （1スプリントで完成可能なストーリーポイントの平均を算出） |
| 開発期間（D） | 提供までにかけたスプリント数と1スプリントの日数をかけ合わせたもの |
スクラムとウォータフォールモデルの違いを論じるために、開発期間の違いを求めます。そのために、開発期間を算出するためのシミュレート用モデル（次節で説明）を構築し、それを元に開発期間を見積もります。なお、開発に要した期間の算出は次に示す式の通りです。
- スクラム：リリースまでに要したスプリント数×スプリント期間
- ウォータフォールモデル：設計期間＋開発期間＋テスト期間（＋手戻り期間）
