SHOEISHA iD

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

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

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

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

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


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

 社会人エンジニア向けの教育プログラム「トップエスイー」から、エンジニアの皆さんに対して有用な情報をお届けするコーナーです。ソフトウェアを開発するにあたり「ウォーターフォールモデル」と「アジャイル開発」は比較対象として取り上げられ、どちらが優れているのか、あるいはどちらが正しいのかという議論がよく見られますが、果たして比較可能な対象でしょうか。これらに限らず、さまざまな開発手法の違いを客観的に比較することができないだろうか、といった疑問を持ちました。客観的な基準があれば、何を採用するのかといった議論もスムーズに行えるはずです。任意の開発手法に対する比較は困難ですが、「ウォーターフォールモデル」と「アジャイル開発」に絞ったモデルを作成することで、それぞれの違いを比較できるところまで示すことができました。

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

開発手法の選択はなぜ難しいのか?

 システム開発を進めるための手段には多種多様なものがあり、その選択には頭を悩ますことになります。「手段」といえば「移動手段」にもいろいろな種類がありますが、自転車と飛行機、どちらが優れているかという議論はあまり聞いたことがありません。なぜしないかは明確で、どちらが優れているかを一般的に決めることに意味がないからです。自転車の方が適していることもあれば、飛行機の方が適していることもあります。

 乗り物については判断材料が単純明快なので、議論されることは皆無です。ところが、開発の進め方となると話は違ってきます。開発対象のドメインについての知識やそれを実際に作る人、はたまたどの手法が適切なのかを判断をしようとしているあなた自身の経験などが絡み合います。結果的には、総合的に判断する必要があるという点が大きな違いです。

 この悩みには実際に開発現場でも向き合うことがありました。「この開発手法でやった方が明らかに向いているが誰もが理解できる言葉で言語化できない」といった経験談や、「ステークホルダーの理解を得られない」といった経験談を聞いたこともあります。そこで、何としても開発手法を客観的に比較でき、その結果を判断材料のひとつとして活用できるものを作りたいと考えました。

 当初、比較対象を絞ることなく比較しようとしたため、期待していたような比較結果を導き出すことができませんでした。そこで、「ウォーターフォールモデル」と、「アジャイル開発」のメソドロジーのひとつである「スクラム開発」とを比較することにポイントを絞りました。その結果、客観的に比較ができるようになりました。

比較可能なモデル作成のアプローチはどのようにしたか

 スクラムとウォーターフォールモデル、これらの異なる開発アプローチを客観的に比較するために、「なにか共通項目を挙げることができないか」といった点から検討を行いました。それらを比較する上で、まずスクラムとウォータフォールモデルで開発対象をどのようにモデル化するかを考えました。

 ウォータフォールモデルについては、開発対象をソースコードの規模で捉えることがよく行われます。一方スクラムでは、プロダクトを実現すべきユーザーストーリー(実装する機能など、ユーザーがどのように対象のプロダクトを使うかという目線に立って表現したもの)に分割できると考えました。そして、各ストーリーに対する規模を相対的に見積もったものである、ストーリーポイントの総和を全体的な規模として捉えました。

 モデル化するにあたり、「作るものの規模」といったどのようなプロセスを用いても変わらない普遍的なものが共通して存在すると考え、その概念に近いと考えられるストーリーポイントを基準にして、作る対象の規模として捉えることにしました。

 次に、比較対象としてQCD(生産管理の3要素である「Quality(開発品質)」「Cost(開発コスト)」「Delivery(開発期間)」の頭文字を取ったもの)に着目しました。ウォータフォールモデルを用いた開発では、QCDの観点で評価する手法が長年行われてノウハウが培われてきています。一方のスクラムでQCDを測定する場合、どのようにそれらを捉えたかを表1に示します。

表1 スクラム開発でのQCDの定義
開発品質(Q) 一定の期間内にエンドユーザーに提供できたストーリーポイント
開発コスト(C) 必要なスプリント数
(1スプリントで完成可能なストーリーポイントの平均を算出)
開発期間(D) 提供までにかけたスプリント数と1スプリントの日数をかけ合わせたもの

 スクラムとウォータフォールモデルの違いを論じるために、開発期間の違いを求めます。そのために、開発期間を算出するためのシミュレート用モデル(次節で説明)を構築し、それを元に開発期間を見積もります。なお、開発に要した期間の算出は次に示す式の通りです。

  • スクラム:リリースまでに要したスプリント数×スプリント期間
  • ウォータフォールモデル:設計期間+開発期間+テスト期間(+手戻り期間)

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

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

  • 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」など、さまざまなカンファレンスを企画・運営しています。

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

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

メールバックナンバー

アクセスランキング

アクセスランキング