シミュレート結果
こうして作成したモデルを用いてシミュレーションを行ってみました。シミュレーションの条件（パラメータ）は、「開発手法」「不具合の割合」「不具合混入工程」「発見工程」「手戻りが必要な工程」「手戻り割合」とし、表2の条件でシミュレーションを行いました。シミュレーション結果は図5となりました。
それぞれのモデルが示す結果について
この結果から見えることを考察してみましょう。スクラムモデル（ケース1、2）について、ケース2はケース1（不具合が全く存在しない場合）に比べて33％期間が延びています。各スプリント中で出た不具合はそのスプリント内で解決するため、解決に要した時間分期間が長くなります。その分は次のスプリントに積み残されるため、結果として全体の期間が延びます。
一方ウォーターフォールモデル（ケース3～12）について、不具合が全く存在しないケース（ケース3）が最も短い期間で完成させることができるという結果が出たのは当然ですが、全般的に設計の不具合が発見される工程が後になるほど、期間が長くなるというシミュレーション結果が示されました（ケース4、6、11の比較）。
ウォーターフォールモデル開発では、本シミュレーターの想定のように開発工程を「設計」「製造」「テスト」等に分けるV字モデル開発手法がよく用いられます。V字モデル開発は各工程の成果物が明確になること、工程単位で外部委託しやすいなどのメリットもありますが、「要求・設計の不具合発見が後工程になりやすい」という弊害も指摘されています。筆者自身も経験がありますが、システムがある程度動くようになってから初めて設計の矛盾に気づき、相当な手戻りを余儀なくされたという苦い経験をした方も多いのではないでしょうか。今回のシミュレーション結果は、上流工程の不具合は早く見つけることが必要ということを示しているといえます。
スクラムとウォータフォールの比較結果
次に今回の記事の主題である、スクラムとウォーターフォールモデルで比較してみましょう。ウォーターフォールモデル（ケース7～12）はテスト工程で不具合が発見された場合を想定していますが、テストの考え方が異なります。ケース7、9、11は手戻りのテストがいずれも25％であり、不具合の割合と同程度の再テストを行うことを想定したものです。ケース8、10、12は手戻りのテストがいずれも100％であり、不具合修正によるデグレーション確認のため、システム全体を再テストすることを想定したものです。これらのケースとスクラムケース2について比較してみます。
ウォーターフォールモデルで再テストを最低限とした場合（ケース7、9、11）ではスクラムで開発を行った場合よりも開発期間が短くなるという結果が出ました。またウォーターフォールモデルで全テストをやり直した場合（ケース8、10、12）ではスクラムで開発を行った場合よりも開発期間が長くなるという結果が出ました。これは期間と品質のトレードオフ関係を表しているとともに、手戻り時に最低限のテストのみを行う方針の場合はウォーターフォールモデルを選択し、品質を重視してテストを多く実施する方針の場合はスクラムを選択したほうが期間にとって有利であることを表しています。
今回は簡素なモデルでスクラムチームの成長を考慮していないため、スクラム側にやや不利な結果が出ています。今回のシミュレーターをさらに改良し成長率を加味できるようにすれば、スクラムが有利になるケースのシミュレートも可能と考えられます。また、変化への対応力を考慮するとスクラムの方が変化への対応を行うきっかけが多くあり、例えば顧客がエンドユーザーからのフィードバックを受けプロダクトに反映させることも可能になります。このようなことを加味して、例えば「顧客満足度」などの視点を加えるとスクラムの方に軍配が上がる結果が得られるかもしれません。
実際の開発経験で得られた知見との比較
さて、今回の結果と実業務での結果を照らし合わせてみると、驚くことにかなり一致しています。例えば、スクラム開発において、4人で構成される開発チームの場合「1スプリントで12ポイント完成できる」といった仮定は現実的な数字だと感じています。筆者自身それほど多くのチームを経験したわけではないですが、現実に12ポイント付近を維持していたチームの存在を、最近の業務でも見ています。
さらに不具合や改善系の対応を、スプリントの10～20％くらいを使って対応するやり方も過去に何度か実際にやったことがあり、現実的な数字であると感じています。
一方ウォーターフォール開発では、テスト工程、特に受入工程で設計不具合が検出された場合、設計→実装→テスト全てやり直しとなるため開発期間が一番長くなることは、ウォーターフォール開発を経験したことがあれば、経験したことがあると思います。
以上の結果と実務経験を考慮すると、変更の可能性がある場合はスクラムの方が向いており、変更の入る余地がないプロダクトほど、ウォーターフォールモデルの方が向いていると結論できます。
なぜこのテーマを取り上げたか
プロダクトをエンドユーザーに届けることにより喜びや豊かさ、進歩を何らかの形でもたらしたい、といった思い自体はソフトウェアを開発している誰もが多かれ少なかれ持っているのではないでしょうか。
その思いがありながら、やったことがない手法である、あるいは所属組織が推奨するやり方ではないからといった理由でそのプロダクトに寄り添った開発がなされていないとしたら、その状態を改善したいという思いが強くなるばかりです。そこで、少しでも開発の進め方に興味と関心を持ってもらいたいという思いをきっかけに、この記事で紹介したテーマを考えました。
明日から現場のプロダクト開発を、あなたはどのように改善していきますか？ 私たちが今回紹介した内容は、開発手法を選定するにあたってひとつのアプローチと考えています。本記事をご覧になった方にとって、開発現場の中でより良い手法を選択し、エンドユーザーに最速で価値を提供できるヒントとなることを願っています。さらに、今後のプロダクト開発の改善につなげることができれば幸いです。
トップエスイーについて
「トップエスイー」は、国立情報学研究所で実施している、社会人エンジニア向けのソフトウェア工学に関する教育プログラムです。トップエスイーでは講義や制作課題を通して、最先端の研究成果や現場で得られた知見が蓄積されてきました。その「アウトカム」、つまり成果やそこに至る過程を紹介し、現場のエンジニアの方々に活用いただける記事を連載しています。2017年度より、「ソフトウェア開発実践演習」がトップエスイーコースの受講生全員が履修する科目として加わりました。従来の修了制作は個人でテーマ設定して進めるのが基本でしたが、それだけでなく、講師が課題設定する場合や、グループで取り組むなど、より多彩な履修形態を用意しています。今回のウォーターフォールとスクラムの比較は、受講生がテーマを設定し、講師の指導の下、3人のグループで問題解決に向けて演習を進めました。各自が真剣に取り組んだことに加え、スクラムに詳しい受講生や、ウォータフォールの経験が豊富な受講生が含むグループだからこそ出せた結論であるといえます。
