短い反復で動くソフトウェアを素早く繰り返し作る開発の考え方。
アジャイル開発とは、短い反復(イテレーション)で動くソフトウェアを素早く繰り返し作っていく開発の考え方のことです。アジャイル(agile)は「俊敏な・素早い」という意味で、変化にすばやく対応することを目指します。
身近な例で考えると、料理を少しずつ味見しながら作るのに似ています。完璧なレシピを最初に決めきるのではなく、作っては味見し、相手の反応を見て調整する──このようにこまめに作って確かめ、変化に合わせて直していくのがアジャイルです。
上の図解のように、数週間程度の短い反復を繰り返し、各反復の終わりに動くソフトをリリースします。利用者の意見を取り入れながら、製品を少しずつ育てていきます。
アジャイルの考え方は「アジャイルソフトウェア開発宣言」という文書にまとめられています。そこでは次の4つの価値が示されており、いずれも「左より右をより重視する」という形になっています(左側にも価値はあります)。
| 左(の価値)より | 右(の価値)を重視 |
|---|---|
| プロセスやツール | 個人と対話 |
| 包括的なドキュメント | 動くソフトウェア |
| 契約交渉 | 顧客との協調 |
| 計画に従うこと | 変化への対応 |
それぞれの価値の意味は次のとおりです。
・個人と対話:決まった手順より、人どうしの会話で素早く問題を解決する
・動くソフトウェア:分厚い資料より、実際に動くソフトで価値を示す
・顧客との協調:契約の文言より、顧客と一緒に良いものを作る
・変化への対応:当初の計画に縛られず、変化を歓迎して取り込む
| 項目 | アジャイル | ウォーターフォール |
|---|---|---|
| 進め方 | 短い反復を繰り返す | 工程を一度だけ流す |
| 仕様変更 | 歓迎して取り込む | 対応しにくい |
| 動くソフト | 各反復で出る | 終盤まで出ない |
| 向く開発 | 変化が多い開発 | 要件が固い開発 |
ウォーターフォールが工程を上流から下流へ一度だけ進めるのに対し、アジャイルは短い反復を何度も繰り返し、仕様変更を歓迎して柔軟に対応します。
そのため、要件が変わりやすい開発や、利用者の反応を見ながら育てたいサービスに向いています。なお、アジャイルを実践する代表的な手法に「スクラム」や「XP(エクストリームプログラミング)」があります。
なぜアジャイルが生まれたのか。それは、ウォーターフォールでは「完成してみると要件が変わっていた」という問題が繰り返し起きたからです。システム開発は、料理のレシピを決めてから全部作るのと違い、作る途中で「やっぱりこうしたい」が次々と出てきます。
ウォーターフォールでは工程を一度だけ流すため、動くソフトが完成するのはプロジェクトの終盤です。そこで「思っていたのと違う」と気づいても、最初からやり直す莫大なコストがかかります。
・問題の発見が遅い:完成まで動くものが見えないため、ズレに気づくのが遅くなる
・変化への対応コストが高い:後工程ほど変更のやり直しが大きくなる
アジャイルはこの反省から生まれました。短い反復で早めに動くものを出して確かめることで、「ズレ」を小さいうちに直せます。建物全体を一気に建ててから「窓の位置が違う」と発見するより、間取り図→模型→1フロアと段階的に確認しながら建てるほうが手直しが少なくて済む、という考え方です。
1回の反復(イテレーション)は、ミニチュアのプロジェクト全体のようなものです。計画・開発・確認・改善の4ステップを、数週間という短い期間にギュッと詰め込み、終わりに動くソフトを1つ出すのが目標です。
各ステップの役割は次のとおりです。
・計画:この反復で何を作るかをチームで決める(やることを絞り込む)
・開発:実際に設計・実装・テストを行う(作る)
・確認:利用者や顧客に動くものを見せてフィードバックをもらう(合っているか確かめる)
・改善:チームの進め方をふり返り、次の反復に向けて直す(やり方を磨く)
この短いサイクルを何度も積み重ねることで、「ちょっとずつ動くものを増やしながら、育てていく」のがアジャイルの本質です。毎回の確認で早めにズレを見つけられるため、大きな手直しが起きにくくなります。