ウォーターフォール開発かアジャイル開発か、手法の違いを理解しよう

ウォーターフォール開発より小さい単位で開発を進めるアジャイル開発

小さい単位で開発を進めていくアジャイル開発

小さい単位で開発を進めていくアジャイル開発

アジャイル開発とは

アジャイル(Agile)は、機敏な、素早い、回転が速いなどの意味があります。アジャイル開発は、ソフトウェア開発やシステム開発におけるプロジェクト開発手法のひとつです。システムを大きな単位で区切るのではなく小さな単位で実装とテストをしながら開発を進めていきます。これまでの開発手法と比べて短い期間で開発ができるのでアジャイルと名前がつきました。
2001年に軽量のソフトウェア開発を提唱していたエンジニア17名がアメリカのユタ州に集まりました。彼らは開発手法の重要な部分を統合することについて議論し、それをまとめたのがアジャイルソフトウェア開発宣言です。アジャイルソフトウェア開発宣言は、ソフトウェア開発に基づく12の原則を定義したもので、現在もアジャイル開発の公文書として広く活用されています。
従来はウォーターフォール開発がソフトウェア開発の主流でした。ウォーターフォール開発は、システム全体の機能、設計、仕様を決定し、それに沿って開発、実装を進めていく手法です。製造業や造船業、システム開発などさまざまな業種で応用できる手法として活用されています。

アジャイル開発の流れ

アジャイル開発は、計画段階で厳密な仕様を決めずに大まかな仕様と要求だけを決めます。開発途中に仕様変更が発生するのは当たり前という前提で作られているのです。最初から仕様が決まっていないと実装段階で問題になりそうですが、逆に仕様が明確になっていないことで開発途中でも柔軟に変更できるため、クライアントのニーズに応えることができます。
アジャイル開発は、大まかな仕様と要求を決定したら、イテレーションというサイクルを繰り返して開発を進めていきます。イテレーションとは反復という意味です。小さな単位に区切られた開発を計画、設計、実装、テスト、というサイクルで繰り返し、リリースしていきます。通常は、ひとつのイテレーションは1~2週間で、イテレーションごとに機能追加をしていきます。数々のイテレーションを繰り返しながら細かく開発を進めていくのです。

アジャイル開発に向いているもの

開発の途中で仕様変更や機能追加が想定されるプロジェクトではアジャイル開発が有効です。モバイル分野などは日進月歩で進化しているので、そうした業界では開発の途中で機能追加や仕様変更が入ることは日常茶飯事です。アジャイル開発を活用すれば、計画段階では精密な仕様を決めないので、途中で変更が入ってもプロジェクトに与える影響を最小限に留めることができます。一方で、手作業でおこなっていたものをシステム化し、稼働中のシステムをリプレースするというような仕様が明確になっている場合は、アジャイル開発よりウォーターフォール開発の方が適していることもあります。

アジャイル開発についてさらに理解を深めたい人には次の本が参考になります。

おすすめ書籍【いちばんやさしいアジャイル開発の教本】

よく読まれている記事一覧

  • アジャイル開発手法の種類と特徴 アジャイル開発手法の種類と特徴

    アジャイル開発には、複数の開発手法があります。プロジェクトの進捗やスケジュールの流れをスムーズにすることに重点を置くもの、開発サイクルを繰り返す中で計画を決めて、仕様変更時のコスト削減を重視するものなど、それぞれが特性を有しています。アジャイル開発を使いこなしたいのなら、まずこうした開発手法の種類と特徴を知ることが欠かせません。ここでは代表的な開発手法を取り上げているので、ぜひ確認してみてください。

  • ウォーターフォール開発とアジャイル開発の案件はある? ウォーターフォール開発とアジャイル開発の案件はある?

    フリーランスエンジニアの案件には、ウォーターフォール開発とアジャイル開発、どちらもあります。ウォーターフォール開発案件に多いのは、金融機関のATMや携帯キャリアのシステムなど、品質担保が重視される大規模プロジェクトです。このようなプロジェクトには大人数のエンジニアが必要です。一方、アプリケーション開発などの案件はアジャイル開発が増えています。今後はアジャイル開発経験のあるエンジニア需要も増えていくといわれています。

  • 大規模開発向きのウォーターフォール開発 大規模開発向きのウォーターフォール開発

    要件定義からテストまでの開発工程においてひとつずつ段階を踏んで進めていくシンプルな開発手法がウォーターフォール開発です。ひとつの工程を完了させて次の工程へ進むため、前の工程へ戻ることは想定していません。開発途中の仕様変更や機能追加には対応できず、軌道修正には大幅なスケジュール変更が必要になってしまいます。しかし、全体のスケジュールやリソース確保がしやすく、確実に開発を進めることができるため、仕様変更を前提としない大規模開発に適しています。