SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

トップエスイーからのアウトカム ~ ソフトウェア工学の現場から

スクラムとウォーターフォールの違いはどこにあるのか? シミュレート可能なモデルを構築して検証する

トップエスイーからのアウトカム ~ ソフトウェア工学の現場から 第11回


  • X ポスト
  • このエントリーをはてなブックマークに追加

シミュレートのためのモデルを構築

 ここまで、開発期間の比較に焦点を当てることにした背景を紹介しました。スクラムとウォーターフォールモデルという異なる開発手法を比較するため、抽象化、つまりモデル化が必要になります。まずは、どちらの開発手法でも開発期間に差が出ないように、スクラムとウォーターフォールモデルどちらにおいても、4.5カ月で完了する、100という規模のプロダクトを定義しました。この想定プロダクトを用いて、スクラムとウォーターフォールモデルそれぞれのシミュレーターを考案しました。これを「基準モデル」と呼ぶこととします。

スクラムの基準モデル

 1スプリントの期間は2週間と定義し、100ストーリーポイントを4.5カ月で完成させる必要があるので9スプリント必要ということになります。したがって、1スプリントあたりに完成させる必要のあるストーリーポイントは12と定義しました。これを表したものが図1です。

図1 スクラムの基準モデル
図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です。

図2 ウォーターフォールモデルの基準モデル
図2 ウォーターフォールモデルの基準モデル

不具合考慮モデルの構築

 図1、図2で示した基準モデルはソフトウェア開発の理想であり、現実には不具合(ここでの不具合とはソフトウェアの単純な不具合のほか、要件や設計の漏れ、誤りも含めます)の発生を考慮しなければなりません。本シミュレーターでは、不具合がW%混入した場合、開発期間にどのような影響が出るかシミュレートできるように、不具合混入割合をパラメータ化しました。

 スクラムについては、各スプリントに必ず一定割合の不具合が入ると仮定したモデルを作りました。毎回12ストーリーポイント消化するのですが、W%の積み残しが発生するため開発に必要な期間が延びることになります。またウォーターフォールモデルについては、その不具合の発生工程を指定できるようにしました。手戻り作業量については必ずしも不具合の割合とは一致しないため、設計のやり直し、製造のやり直し、再テストの割合をそれぞれX%、Y%、Z%とパラメータ化しました。

 以上を踏まえたモデルは図3、図4のような概念となります。

 このように、モデル化をすることでスクラムとウォーターフォールモデルといった、一見比較不可能な対象を今回は「期間」という特定の視点において比較できるようになりました。何かを比較する際は、(1)抽象化する、(2)視点を絞る、ことにより比較対象をモデル化することで観察可能な状態になり、考察や議論ができるようになる、好例となったと思います。

図3 スクラムの不具合考慮モデル
図3 スクラムの不具合考慮モデル
図4 ウォーターフォールモデルの不具合考慮モデル
図4 ウォーターフォールモデルの不具合考慮モデル

次のページ
シミュレート結果

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
トップエスイーからのアウトカム ~ ソフトウェア工学の現場から連載記事一覧

もっと読む

この記事の著者

宗田 知子(freee株式会社)(ソウダ トモコ)

 2017年度第12期生としてトップエスイーを受講。認定スクラムプロフェッショナル。freee株式会社所属。Webアプリケーション開発に従事。自身のエンジニアとしての生い立ちが影響し開発現場の改善に強く興味を持っており、日々奮闘している。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

関根 浩二(日本電子計算株式会社)(セキネ コウジ)

 2017年度第12期生としてトップエスイーを受講。日本電子計算株式会社公共事業部開発統括部所属。地方公共団体向け総合行政情報システム「WizLIFE」の開発業務に従事。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

原田 知拡(富士通株式会社)(ハラダ トモヒロ)

 2017年度第12期生としてトップエスイーを受講。富士通株式会社 共通ソフトウェア開発技術本部 ソフトウェア検証統括部 第二ソフトウェア品質検証部 所属。ミドルウェア、ならびにクラウドサービスの品質検証の中で、スクラムやウォーターフォールモデルを経験。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11049 2018/09/20 10:52

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング