開発プロセスとソフトウェア開発モデル
ウォータフォールとアジャイルの違いを、決める時期と直しやすさという観点から比べ、どちらが向く場面かを説明できるようになります。
ねらい
システムを作る進め方の型を学びます。このレッスンを終えると、代表的な開発モデルの違いをいつ決めるかという観点で比べられるようになり、それぞれが向く場面を説明できるようになります。
進め方には型があります
同じ工程を通るとしても、どういう順序と単位で回すかには型があります。型が違うと、うまくいく条件も変わります。
ウォータフォールモデル — 前へ戻らない前提で進む
ウォータフォールモデルは、要件定義から順に工程を進め、前の工程へは戻らないことを前提にした型です。滝の水が上から下へ落ちるように進むので、この名前があります。
- 長所… 工程の区切りがはっきりしており、進み具合を測りやすい。大人数でも分担しやすい。
- 短所… 最初に要件を固めきる必要がある。後から変えると、その工程以降をやり直すことになります。動くものが見えるのが遅く、利用者が実物を見て「違った」と気づくのは終盤になります。
向くのは、要件がはっきり決まっている場合です。法令で処理の内容が決まっている業務や、既存システムの置き換えなどが当てはまります。
アジャイル開発 — 小さく作って、確かめて、また作る
アジャイル開発は、短い期間(1〜4週間程度)で計画から動くものまでを一巡し、それを繰り返す型です。
- 長所… 早い段階から動くものを見せられる。要件の変更を受け入れやすい。
- 短所… 全体の完成時期と総額を最初に確定しにくい。利用者側にも継続的な関与が求められます。
向くのは、要件が動く場合です。新しいサービスのように、作ってみないと正解が分からないものが当てはまります。
代表的な進め方にスクラムがあります。数週間の反復をスプリントと呼び、期間中の作業を朝の短い会(デイリースクラム)で共有します。2人1組で1つのプログラムを書くやり方をペアプログラミング、動くものより先にテストを書くやり方をテスト駆動開発といいます。
ポイント
アジャイルは「決めない」進め方ではありません。決める時期を、必要になるまで遅らせる進め方です。変わるかもしれないことを早く決めると、決め直す費用がかかるからです。
そのほかの開発モデル
- プロトタイピングモデル… 早い段階で試作品を作り、利用者に触ってもらって要件を固めます。「見ないと分からない」を解消します。
- スパイラルモデル… システムを部分に分け、部分ごとに設計から製造までを繰り返し、少しずつ育てます。
- リバースエンジニアリング… 既存のシステムを解析して、仕様や設計を取り出すこと。設計書が残っていない古いシステムを作り直すときに使います。
- DevOps… 開発(Development)と運用(Operations)が協力して、速く安全に届け続ける取り組みです。
作業の進め方を共通の言葉で表した枠組みを共通フレームといいます。発注側と受注側で用語や作業範囲の理解を合わせるために使われます。
まとめ
開発モデルの違いは、いつ決めるかにあります。ウォータフォールは最初に決めきり、アジャイルは小さく回しながら決めていきます。要件がはっきりしているならウォータフォール、要件が動くならアジャイルが向きます。プロトタイピングは「見ないと分からない」を解消し、リバースエンジニアリングは設計書の無いシステムから仕様を取り出します。
理解の確認
これまでに前例のない新しい会員向けサービスを立ち上げることになり、利用者の反応を見ながら機能を決めていきたいと考えています。ウォータフォールモデルとアジャイル開発のどちらが向いており、それはなぜでしょうか。
答え: アジャイル開発が向いています。ウォータフォールモデルは最初に要件を固めきることを前提とし、後の工程で要件が変われば、その工程以降をやり直すことになります。前例のないサービスでは、作ってみて利用者に触ってもらうまで正解が分からないため、最初に固めた要件が後で変わる可能性が高く、やり直しの費用が繰り返し発生します。アジャイル開発なら短い期間で動くものを作って反応を確かめ、その結果を次の反復に反映できるため、要件が動くことを前提に進められます。ただし全体の完成時期と総額を最初に確定しにくい点は、あらかじめ関係者と合意しておく必要があります。
分からなかった点・気になった点
読み込み中です。