【開発手法モデル】アジャイルとは？ウォータフォール型との違いは？

こんにちは。iQeda [@iQeeeda] です。

最近どこの現場も「猫も杓子もアジャイル開発」な感じです。
僕もウォータフォール型の開発現場で苦い思いをしたので気持ちは分かります…

駆け出しエンジニアの頃、その言葉の意味をよくわかっていませんでした。
難しい言葉を難しい言葉で説明しないでほしいなぁと。

そもそもソフトウェア・システム開発手法ってなに？

ソフトウェア・システム開発手法とは、開発工程のフレームワークです。

それぞれ長所・短所があるので、
プロジェクトの性質や状況に応じて最適な開発手法を選択する必要があります。

ウォーターフォールとは？

アジャイルが登場する以前の開発手法「ウォータフォール」についてまず触れておきます。

従来型の「ウォーターフォール」の問題点

このプロセスに数ヶ月 〜 数年かけて、後戻りせず突き進むことをウォータフォールと言います。

時間をかける慎重な開発手法なのですが、
現実は下流工程でも突然に要件が変わったり、新しい要件が見つかります。
これを仕様変更と言います。

仕様変更が起きると一体どうなるのか

実装がすでに始まっている場合、仕様変更にうまく対応できないことがあります。
これがウォータフォールの一番の問題でした。というか 2020 年現在も問題になっています。

エンジニアはそれまで作り上げたものを捨てて後退するか、
断固たる態度で変更を拒否するしかありません。

アジャイルとは？

仕様を無視することは大問題ですが、
近年「要件はプロジェクトの終盤に入るまでわからないもの」という考えが出てきました。

ここでアジャイルという考えが登場します。

アジャイルとは「仕様変更を受け入れる」こと

これがアジャイルのキモです。

アジャイル採用している現場にいながら、
「仕様変更うぜー！」みたいなこと言う人がいますが、アジャイルとはそういうものです。

アジャイル宣言 – アジャイルで大切にすること

ユタ州のスノーバードというスキーリゾート地にて、
業界リーダーやエンジニアが集まり、アジャイルに関する議論をしました。

そこで生まれたのがアジャイル宣言。アジャイルの原理原則です。その内容を要約します。

アジャイルでは、左側より右側の項目が重要である！…と宣言しています。

あくまで優先順位の話

勘違いしてはいけないのが、左側の項目を軽視するわけではありません。
アジャイル宣言はあくまで優先順位について言っているのです。

例えば「ドキュメント」を軽視するわけではありません。
これがないと新しくジョインする開発者が困りますし、引き継ぎもスムーズにいきませんね。

アジャイル 12 の原則 (マニフェスト)

先程のアジャイル宣言は、以下の 12 の原則が元になっています。
大事なところを赤文字にしました。

乱暴な言い方をすると、

…って感じでしょうか。
技術を重要視する一方で、コミュニケーションの重要性も説いているのがいいですね。

絵に書いた餅になることは多い

ここまで「アジャイル、めっちゃいいじゃん！」って感じがします。

しかし、チームでモチベーションを高く維持して、
短い開発期間を遵守しながらリリースし続けるのは大変なことです。

そんなことはないですか？アジャイルでは日々のタスク管理が重要です。
細切れになったタスクを「毎日淡々とこなす」ストイックさが必要です。

アジャイル採用する場合「持続的に開発しづづける困難さ」をイメージしておきましょう。

アジャイルは「手法」じゃなくて「概念」

ここまでウォーターフォールとアジャイルの説明をしてきましたが…

ウォータフォールは「手法」ですが、アジャイルは「手法」じゃなくて「概念」です。
アジャイルを具体的な手法に落とし込む必要があります。

アジャイルを使った手法

下記のものがアジャイルを使った代表的な手法です。

アジャイル採用している現場ではこのどれかを使うことが多いです。
これら開発手法については別の記事で解説します。

関連記事