ウォーターフォールとアジャイルとプロトタイプの違い図解

社内向けの勉強会の資料を公開しています。画像を含めご自由にお使いください。

ウォーターフォールとアジャイルの違いについて図解してみました。そして最後にプロトタイプとアジャイルの違いについても説明してます。

ウォーターフォールとアジャイルの違い

時間軸からみた違い

上の図をみてください。縦軸と横軸はなにか明記されてませんが、機能の集合があるというふうに考えてください。そして図の○で示した部分が、顧客が要求している機能の集合です。いわばシステム開発におけるゴールですね。システム開発ではここを目指します。青い矢印はイテレーション(作業の繰り返し)を示しており、矢印の長さがかかった時間に対応します。

ウォーターフォールでは一気に矢印がゴールでまで伸びております。一方でアジャイルでは、ふらふらと迷いながらゴールまでたどり着いています。

２つのかかった時間の合計を見てみましょう。

ウォーターフォールのほうが合計時間は短いですね。つまりリソース的にもかなり効率がよいといえます。

ここでもし顧客が要求していた機能郡が実は違っていたというシナリオを考えてみましょう。システムが開発完了間近になって、顧客からじつはこっちの機能のほうが必要だとわかったと言われたのです。

このときウォーターフォールの対応はつぎの２つが考えられます。

対応１のように、そこから素直に次の機能郡に移行できればいいのですが、実際は対応２のように、戻れるまで戻ってそこから修正というふうなものが多いです。だから、SIerは最初の要件定義でどれだけ顧客の要求を正確に表現できるか真剣なのです。

アジャイルの対応は次です。

繰り返し成果物をみせることにより早めに顧客が当初の要求が違うことに気づきます。また開発を細かく刻んでリリースを繰り返しているので、変更にも対応しやすいです。

ただし、顧客が当初要求していた機能郡と顧客が本当に要求したかった機能群があまりにかけ離れていると、アジャイルでも変更にかなりの時間がかかります。

結果として、２つのかかった時間の合計を見てみましょう。

このように、ウォーターフォールのほうがより多くの時間がかかってしまっていることがわかります。

作りたい機能があらかじめはっきりしていて変わりにくいのであればウォーターフォールのほうがおすすめです。逆に、曖昧さが強いものを作るのであればアジャイルのほうがおすすめです。

以上、かなり抽象化と単純化しましたがウォーターフォールとアジャイルの違いでした。

スコープからみた違い

スコープとは機能の数を指します。例えば以下の図ではこのシステムは機能A~機能Dをスコープにもつ事がわかります。開発の締切が迫っており間に合わないときに、機能Dを切り捨ててスコープを小さくすることで間に合わせるみたいな使い方をします。

ウォーターフォールではこれらのスコープを一気に作り上げていきます。アジャイルでは各機能ごとに作り上げていきます。

プロトタイプとは

まずはこの図をみてください。

スコープの図に似てますが、「忠実度」という言葉が出てきます。これはどれだけ実際のプロダクトに似せるのかという意味で忠実度が100%であればそれはもう実際にシステムを作っています。忠実度が0%にちかければ紙ベースで作っている感じです。実際にはプロトタイプを作るときには、100%の忠実度のものを作ることはありません。というのは、プロトタイプとはそもそも労力をかけずのその機能の効果を知りたいから行うものだからです。忠実度が高ければ高いほど労力がかかるため、あるいていど再現しつつも実際にはプログラミングをしない程度の忠実度で行われることが理想です。

プロトタイプの種類

プロトタイプには水平プロトタイプと垂直プロトタイプがあります。

水平プロトタイプとはペーパープロトタイプなど忠実度の低いものですべての機能を眺めるものです。垂直プロトタイプとは特定の機能にしぼりツールプロトタイプなど忠実度の高いものでその機能の効果を確認するものです。

一般的には、水平プロトタイプで浅く -> 各機能ごとに垂直プロトタイプで深くという流れをとります。

プロトタイプとアジャイルの違い

プロトタイプとアジャイルはよく混同されますが同じものではありません。ウォーターフォールに対比されるアジャイルは作り方に目的があり、プロトタイプは作る前に少ない労力で効果を知ることに目的があります。もしあなたのチームがUXチームと開発チームに分かれている場合、プロトタイプを行うのがUXチームでアジャイルに開発を行うのが開発チームである、というイメージですね。

何を作るのかとどう作るのか

ですね。

コラム

プロトタイプで作ったものは捨てることが大前提と言われています。なぜ捨てたほうがいいのかは、ネットにたくさん記事が転がっているのでそちらに譲ることにします。逆に捨てずにそのまま少しずつ機能を確かめていくアプローチの仕方もあり、そちらのほうは曳光弾(えいこうだん)のアプローチと言われています(達人プログラマより)。

[おまけ] スコープの２つの側面

スコープは機能の数という説明をしましたが、正しいものを正しくつくる　プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先についてという本においては、スコープを２つの側面に分けています。それは、スコープの広さと深さです。

スコープの広さとは、機能の範囲です。どの機能までをリリースに含めるのかという考え方です。スコープの深さとはその機能を実現するプランを複数考えてどのプランを選ぶのかということです。一番簡単に実装できるけど、保守性や変更容易性が低い。手間が結構かかるけど、今後のビジネスの展開てきに理想な構成。など３つほどのプランを考えて(例えば上中下や松竹梅などの名前をつけ)リリースに間に合わないから機能Dは梅プランで行くか、などの選択ができるようになります。