「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

大雑把過ぎる上に誤解を招きそうな言い方になってしまうのですが、無理やり一言で説明すると

システム開発のやり方のひとつで、作りながら考えるやり方

が「アジャイル」です。

もともと、システム開発というのは

１．きっちりヒアリングして～
２．きっちり設計して～
３．きっちり作って～
４．きっちりテストして～
５．完成＼（－－）／

な流れでやるのが一般的でした。
基本的には工程の後戻りをしない（実際には、よくあるけど）やり方が主流だったのです。

このようなシステム開発のやり方を「ウォーターフォール型」と言います。
水が高いところから低いところに流れ落ちるように、最初の工程から最後の工程に向かって1つずつ順番に終わらせていく やり方です。



ウォーターフォール型はウォーターフォール型で良い面もあります。
ただし、弱点もありました。
それは「予定通りに進まないと困る」という点です。

ウォーターフォール型は工程の後戻りを想定していません。
極端な言い方をすると、完璧な設計をやり、その完璧な設計に従って完璧に作り上げ、その完璧に作り上げたものを完璧にテストして完成させるやり方です。

とはいえ、実際には、作っている最中で「あれ？この設計だとマズくない？」と気付くこともありますよね。
そうなると困ります。
工程の後戻りを想定していないために予定が崩れるからです。

そこで「予定通りに進むことなんて、あるわけないじゃん？」と開き直った人が

１．お客さまの要望を、ある程度ヒアリングして～
２．何となく作ってテストして～
３．お客さまに見せて～
４．１に戻る
５．１～４を繰り返して、それっぽくなったら完成＼（－－）／

なやり方を考えたのです、多分。
それがアジャイルな開発手法です。

アジャイルは大雑把に言えば「作りながら考える」やり方です。

イメージとしては、そうですね。

旅行をするときに何時何分の電車に乗って～どこで乗り換えて～と事前に調べてから動くのがウォーターフォール型です。



方向さえ合っていれば取りあえず来た電車に飛び乗るのがアジャイルです。



かなり乱暴な例えですが、そんなイメージです。

アジャイルのメリットは

１．できた物を実際に見てあれこれ判断できる
　（作ってなんぼのアジャイル開発）

２．方向転換や軌道修正が比較的容易
　（出たとこ勝負のアジャイル開発）

３．上手くやれば開発コストを減らせる
　（いらない物は作らないアジャイル開発）

です。
一方のデメリットは

１．工数が見積りにくい
　　（いつ終わるから分からないアジャイル開発）

２．上手くやらないと収拾がつかなくなる
　　（つぎはぎしていくアジャイル開発）

３．人員の入替が大変かもしれない
　　（やりながら歴史を積み上げていくアジャイル開発）

でしょうか。

ウォーターフォール型とアジャイルは比較されがちですが、どちらが優れているということは ありません。
何を重視しているかが違うだけです。

どちらも一長一短があるやり方です。
目的や状況に合わせて選ぶ必要があります。

なお、アジャイルの定義は人によって微妙に違ったりします。
さらに、プロトタイプモデルやスパイラルモデルといった、アジャイルと似て非なる？やり方もあります。

アジャイルとプロトタイプモデルやスパイラルモデルの違いは私も知りません。
いろいろ調べたのですが、人によって定義が違ったりして何が正しいのか分かりませんでした。

「アジャイルとは何ぞや？」の具体的な定義を求めると深みにはまりそうです。
素直に

作りながら考えるやり方

程度で解釈しておくのが無難だと思います。