アジャイル開発とウォーターフォール開発の違い、向き不向きはある?

システム開発 開発手法

INDEX

昔からあるウォーターフォール開発と、比較的新しいアジャイル開発。

プロジェクトで、どちらを採用すべきか、迷いますよね。

プロジェクトの成功/失敗の方向性が決まる最初の大きな判断を、間違えたくないものです。

アジャイル開発とウォーターフォール開発の違いや、向き不向き、ハイブリッドの可能性、これらを知ることで

自信を持って最初の判断をできるようにしましょう。

アジャイル開発とは

まず、聞き慣れない人も多いかもしれませんので、アジャイル開発とはどういったものかについて、歴史、工程、特徴という観点で簡単に見ていきます。

 

アジャイル開発の歴史


アジャイル開発は、2001年に「アジャイル開発宣言」が発表されました。

もともと「走り」となるXP(エクストリーム・プログラミング)やスクラムなどがベースとしてあったものを総称し、「アジャイル開発」として定義しました。

 

アジャイル開発の工程


アジャイル開発は、開発を一定の期間(イテレーション)で区切り

その期間の中で【設計→開発→テスト→リリース】を小さく行い、これを繰り返す手法です。

 



イテレーション1 回目: 設計→開発→テスト→リリース→ふりかえり&次の計画

イテレーション2 回目: 設計→開発→テスト→リリース→ふりかえり&次の計画

イテレーション3 回目: 設計→開発→テスト→リリース→ふりかえり&次の計画

    :

    :

 

アジャイル開発の特徴


以下、箇条書きですが、アジャイル開発特徴です。

・開発中も顧客の要求に応えて仕様変更を行う。

・ドキュメントは最小限で、ワードやエクセルなどよりは、ツールやWikiのような形で残す事が多い。

・プロジェクトの中で、チームを成長させるしくみが多く、チームは並列で上下がない。

・イテレーションごとに動くソフトウェアをリリースするので、顧客もチームも安心感を持てる。

 

関連記事:アジャイル開発とは?簡単な解説と導入のメリットまで

ウォーターフォール開発とは

続いて同じウォーターフォール開発について簡単に説明します。

 

ウォーターフォール開発の歴史


ウォーターフォール開発の起源を辿ると、1970年代にW. W.ロイスによって発表された論文「Managing the Development of Large Software Systems」が元になったとされています。

 

ウォーターフォール開発の工程


ウォーターフォール開発は、【要件定義→設計→開発→テスト→リリース】という工程を、順に進めていきます。

要件定義が終わったら設計工程へ、設計が終わったら開発工程へ、というように各工程を積み上げていきます。

 

ウォーターフォール開発の特徴


・要件定義以降の仕様変更は基本的には行いません。行うとしても規模・内容によって別費用などを調整する。

・一般的に、納品物としてしっかりしたドキュメントを顧客から求められる事が多い。

・チームはピラミッド型で上下がある。

・工程が明確に分かれているので、リソース計画を立てやすい。

アジャイル開発とウォーターフォール開発、向き不向き

一般的に、

・銀行などの堅牢なシステムや大規模開発には「ウォーターフォール開発」

・比較的小規模な開発やニーズが変化する開発には「アジャイル開発」

が向く、と言われています。

 

しかし、この「向き不向き」も最近では崩れつつあります。

「エンタープライズアジャイル」など、大規模でもアジャイルを採用するプロジェクトもあります。

 

この背景には、現代の複雑かつスピード感の求められる開発に、ウォーターフォール開発では対応しきれない、という判断によるものと考えられます。

 

例えば、Eclipseの開発ではスクラム・オブ・スクラムズ(Scrum of Scrums)という形で大規模な開発が進められています。

参考:Eclipse Foundation Development Process


 

そして、エンタープライズアジャイルにも、フレームワークがあります。

・ディシプリンド・アジャイル・デリバリー(Disciplined Agile Delivery:DAD)

・スケールド・アジャイル・フレームワーク(Scaled Agile Framework:SAFe)

この2つのフレームワークが有名です。

アジャイル開発とウォーターフォール開発のメリット、デメリット

アジャイル開発とウォーターフォール開発、それぞれにメリット、デメリットはあります。

 

アジャイル開発のメリット


・常に動くソフトウェアをリリースしながら進めるので、問題の発見が早く、大炎上が発生しにくい。

・プロダクトとともに、チームも成長する。

・顧客のニーズに応えやすく、本当に必要とされるプロダクトを届けやすい。

・手戻りコストが低い。

・活発なコミュニケーションや短い期限による緊張感など、プロジェクトに動きが出て、仕事が楽しくなる。

 

アジャイル開発のデメリット


・アジャイルで進めるためのスキルが必要で、いきなり全てを導入するにはハードルが高い。

・発注先がアジャイル開発の採用をNGとする場合がある。

・仕様変更は優先順位付けや取捨選択が必須の前提条件としてあるが、機能追加がいつまでもできると誤った認識で変更が発生し続けるなどあるので、顧客側の教育も必要。

 

ウォーターフォール開発のメリット


・要件定義を最初に完了させてしまうので、比較的見積りやすく、人員も確定しやすい。

・工程をぶつ切りすれば良いので、スケジュールを立てやすい。

・順に工程を終わらせていくことができる。

 

ウォーターフォール開発のデメリット


・後工程のテストなどで問題が発生した場合、手戻りコストが大きい。

・全て決めようとするため要件定義に時間がかかりやすい。

・大きなスケジュールで動いているので、遅延が少しずつ蓄積し、取り返せずに大きな遅れに発展しやすい。

 

関連記事:システム開発における要件定義の重要性と進め方のコツ

 

各々のメリット、デメリットを考えると

よほど強力な理由がない限り、今ウォーターフォール開発を採用する利点は少ないのではないのでしょうか。

アジャイル開発とウォーターフォール開発のハイブリッドは可能?

併用が可能なのか、これはよく議論にあがる問いです。

ハイブリッドという中途半端なやり方をすると「失敗する」という意見もあり、賛否が分かれる問題のようです。

しかし、筆者の経験から言うと『可能』です。

なぜ可能なのか、

 

そもそも『プロジェクトの成功確率を上げられるのであれば、結局、手法は何でもよい。』からです。

 

何をもって、ハイブリッドとするのかしないのか。定義はありません。

アジャイルの一部要素を取り入れて、うまく進められるならそれで良いのです。

ウォーターフォールは○○だから△△すべき、とか、

○○をしていないからアジャイル開発ではない、というのは残念な発想で、手段と目的を取り違えています。

手法ばかりに囚われる必要はありません。

 

会社、部署、その他プロジェクトを進める上で、アジャイル開発の導入が許される状況ではないが、

ウォーターフォールでうまくいくイメージを持てていない。疑問を持っている。

ではどうすればうまくいくか。

今までのプロジェクトで、駄目だった所は何なのか、良かった所はどこなのか。

駄目だった所を解消する方法として、アジャイル開発のフレームワークのうち、課題を解決してくれそうなメソッドを取り入れる。

というように、要は、ハイブリッドをしたい理由、取り入れどころ、使いどころによって、成功/失敗が分かれるということです。

ハイブリッドをする場合は、理由を曖昧にせず、自問し、自分でも納得した上で自信を持って進めましょう。

まとめ

しばしば比較されがちなアジャイル開発と、ウォーターフォール開発について考えてみました。

プロマネ新人が「プロジェクトマネージャとは?」を学び、身につけるにはウォーターフォール開発は良い手法でもあります。

しかし、情報社会の今、スピード感やニーズ対応の柔軟性を考えるとアジャイル開発になるでしょう。

手法が何にせよ、やはり「あるべき価値の提供を正しくできる」プロジェクトの推進方法を採用したいものですね。
  • Twitter
  • Facebook
  • LINE

堂々の実績 Sackleのシステム開発

ユーザー体験をデザインし お客様のビジネスを成功へ導く

単なる機能ではなく、「人が使う」機能であることにSackleはこだわります。
孤高の設計力、提案力で予想以上のプロダクトを創出します。

SackleのWebシステム開発について詳しく見る

RECOMMEND

PICKUP

CATEGORY