アジャイル開発とはなにか？
概要・進め方・ウォーターフォール開発との違いを解説

目次

アジャイル開発の概要・特徴

アジャイル開発とは、ソフトウェアを開発する手法のひとつです。ソフトウェアを機能ごとに小さく分けて、小さな単位での設計、実装、テストという工程を反復しながらプロジェクトを進めていきます。

小さな単位で開発を進めることから、開発途中での仕様変更や機能追加にも柔軟に対応可能で、ある程度は見切り発車的に開発を進めることができます。ソフトウェアの短期開発にもつながる柔軟な考え方から、アジャイル（Agile：機敏）と名付けられました。

アジャイルソフトウェア開発宣言

アジャイル開発というと、スクラムなどの開発手法そのものに注目が行きがちですが、そもそもアジャイル開発とはより良い開発方法を求めてたどり着いた考え方を指す言葉です。その考え方については、2001年に17人の開発者が議論の末に公開したマニフェスト「アジャイルソフトウェア開発宣言」に示されています。

私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。

「アジャイルソフトウェア開発宣言」より引用。

このマニフェストを実現するために、スクラムといった開発手法が用いられています。

【関連記事】

アジャイル開発とウォーターフォール開発との違い

ソフトウェア開発の手法として古くから用いられているものに、ウォーターフォール開発 があります。開発の始まりを上流、終わりを下流に見立てて、滝（ウォーターフォール）の水が流れ落ちるように、一方向へ順に開発を進めていく開発手法です。

ウォーターフォール開発では、開発初期段階に行う要件定義や設計を重要視しており、詳細に至るまでの計画書をしっかり作り上げてから開発に移ります。計画書どおりに作業工程をこなしていけば完成へと向かっていくのが、ウォーターフォール開発です。

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

• 開発者がシステムの全体像をイメージしやすい。
• 決められた作業工程に沿って開発を進めるので、進捗状況を把握しやすい。
• 各工程の作業内容が明確なので、必要人員やコストの見積もりが容易。
• 最初に設計を固めてしまうので、システム全体に影響があるような仕様変更は、設計からやり直しをしなければいけないこともあり、対応が難しい。
• 想定外の仕様変更やトラブルを避けるためには、工程ごとに行う顧客との綿密な確認が重要で、そのぶん開発期間も長め。
• 想定外の修正や手戻りを防ぐのは難しく、開発期間が延びることも珍しくない。

アジャイル開発の特徴

• システムの重要な要件さえ定めれば、詳細な計画までは詰めず開発に入れるので、開発期間が短い。
• 小規模な開発サイクルで区切っているので、仕様変更やトラブルに短期間で対応できる。
• 開発メンバー同士や顧客とのコミュニケーションが重要。
• 事前の綿密な計画がないぶん、開発者には高いスキルと自己組織化が求められる。
• 小規模な開発の繰り返しでプロジェクトを進めるため、全体的なスケジュール管理が難しい。管理に失敗すると開発期間が延びる事態にも。
• 仕様変更を柔軟に受け入れられるぶん、コンセプトがブレやすいという問題が潜在している。

アジャイル開発に向いているプロジェクト

アジャイル開発は、次に挙げるようなプロジェクトに適しています。

• 要件定義の全体像が明確ではないプロジェクト
• 変化の激しい分野で仕様変更の可能性が高いプロジェクト
• 顧客との密接な連携を行うことができるプロジェクト

要件定義の全体像が明確ではないプロジェクトとは、主に既存経験のないソフトウェア新規開発が当てはまります。作りたいソフトウェアのイメージはあるけれど、どのような機能が必要か把握しきれていないようなケースです。そんな時は企画段階で詳細まで詰める必要がなく、把握している部分から開発を進めて徐々に機能を増やしていけるアジャイル開発が適しています。

変化の激しい分野とは、市場のニーズに左右されやすかったり、新技術が次々と登場したりする分野です。市場のニーズに左右されるのは、ビジネスにとっては当たり前のことと言えるかもしれません。このような場合もアジャイル開発が適しており、常に最新の状況を取り入れたソフトウェア開発が可能です。

顧客との密接な連携を行えるプロジェクトでは、顧客満足度の高いソフトウェアを開発できる可能性が高まります。アジャイル開発には顧客を開発プロセスに巻き込み、コミュニケーションを重ねながら、より顧客満足度の高いソフトウェアを開発していく手法が確立されています。

ウォーターフォール開発に向いているプロジェクト

ウォーターフォール開発は、次に挙げるようなプロジェクトに適しています。

• 要件定義がはっきりしているプロジェクト
• 仕様変更の発生する可能性が低いプロジェクト
• 安定性や信頼性が重要視されるプロジェクト
• 多くの開発者が携わる大規模なシステム開発のプロジェクト

要件定義がはっきりしているプロジェクトとは、既存システムのリプレースなど、ソフトウェアの機能をしっかり把握できる場合などが当てはまります。

仕様変更の発生する可能性が低いプロジェクトとは、ニーズ変化の激しい市場向けや、最新技術を扱うようなソフトウェアではなく、社内システムなど用途がほぼ固定され、仕様変更することが滅多にないケースを指します。

安定性や信頼性が重要視されるプロジェクトとは、金融システムやインフラシステムなど、誤作動が許されない分野を指します。このような分野では、時間と手間をかけてでも要件定義や設計を綿密に行い、確実に正しく動くシステムの開発が求められます。

多くの開発者が携わる大規模なシステム開発の場合は、仕事の割り振りや全体スケジュールの把握が容易なウォーターフォール開発が適しています。

ウォーターフォール開発はアジャイル開発と比べて古くて劣っているという印象を持つ人も多いかもしれませんが、ここで挙げたように仕様変更の可能性が低かったり、大規模なシステム開発といった場合はアジャイル開発よりもウォーターフォール開発が適していると言えます。

アジャイル開発の基本的な流れ

ここでは、アジャイル開発の基本的な流れを見ていきましょう。アジャイル開発は大きく2つの工程に分けられます。

1. リリース計画の作成
2. イテレーション

リリース計画とは、製品の目標やビジョンを掲げ、開発の方向性を示す製品管理手法です。特にアジャイル開発に合わせて製品の段階的なリリースを計画する製品管理手法を、アジャイルリリース計画とも言います。

イテレーションとは、反復と言う意味を持ち、一連の開発工程を短期間で繰り返す開発サイクルのことを指します。アジャイル開発では短期間のイテレーションを終えるごとに開発の評価や見直しを行うことで、仕様変更やトラブルへの高い順応性を実現しています。

では次に、それぞれの工程について、もう少し詳しく見ていきましょう。

リリース計画の作成

リリース計画の作成は、主に次のようなステップに沿って行われます。

1.目標を明確にする
製品がリリースされることで、どのような成果や利益を生み出すのかといった製品のビジョンを定義し、最終的にたどり着くプロダクトの目標（ゴール）を明確にします。この目標に到達するまで、ソフトウェアの開発が続けられることを意味します。

2.プロダクトバックログのランク付け
プロダクトバックログ（プロダクトを目標へ導くために必要となる機能）を確認し、各機能のストーリーポイント（難易度）を見積もったり、優先順位を決めます。

3.リリース計画会議
開発メンバーや関係者を集め、リリース計画を確認するためのミーティングを行います。リリースに向けていつまでに何を達成する必要があるのか、全員で共通認識を持っていることを確認します。

また、開発チームの実力に鑑みて、1回のイテレーションの長さ（通常1～4週間）や、開発チームのベロシティ（1イテレーションでどれだけの成果を出せるかという開発力を示す値）を算出し、機能の優先順位やストーリーポイントを参考に、開発チームへタスクを割り振っていきます。これで本格的な開発がスタートします。

4.リリース計画の更新
リリース計画は一度出したら終わりではなく、例えばイテレーション終了のタイミングで開発チームのベロシティを見直したり、機能の開発が間に合わなかった場合は開発の順番を組み替えるなど、状況が変わるたびに見直していくことが一般的です。

イテレーションの開発手順

イテレーションでは、手順に則ってプロダクトへ組み込む機能の開発を行います。

1.計画
プロジェクトの目標やスケジュールなどを定義し、考えられるリスクの洗い出しや対策を講じます。

2.設計
アーキテクチャ設計やプログラム設計を行います。

3.実装
設計に基づいてソフトウェアをプログラミングで開発します。

4.テスト
単体テストや結合テストを行い、開発したソフトウェアが仕様どおり動作することを確認します。

5.改善
テストで不具合が出たり改善の余地が見つかった場合は、2.設計の段階まで戻って改善を加えます。イテレーションの期間内であれば何回でも改善可能です。

6.リリース
成果物を本番のプロダクトへ組み込むためにリリースします。これで1つのイテレーションが完了です。次のイテレーションへ活かすために、チームで開発時のふりかえりを行ったりもします。

これら一連の工程を1～4週間の短いスパンで繰り返していくのが、アジャイル開発の基本的な流れとなります。

【関連記事】

アジャイル開発の主な3つの手法

アジャイル開発のイテレーションで実際に用いられる開発手法には、いくつかの種類があります。それぞれに異なる特徴を持ち、プロダクトの目標や開発チームの性質で使い分けられています。ここではよく使われている3つの手法を説明します。

スクラム

スクラムは代表的なアジャイル開発の手法です。選手が一丸となって突進するラグビーのスクラムが由来となっていて、開発メンバー同士のコミュニケーションが重要な開発手法です。事あるごとに開発メンバーでミーティングを行い、進捗状況や課題を共有して、一致団結でプロダクトに挑むことが求められます。

スクラムでは、チームを構成するメンバーに次のような役割があります。

• プロダクトオーナー
• スクラムマスター
• 開発メンバー

プロダクトオーナーは、プロダクトの価値を最大化する最高責任者です。プロダクトバックログの管理、顧客との折衝、開発チームの連携、その他マーケティングや予算管理など、さまざまな役割を担っています。

スクラムマスターは、スクラムのコーチ的な存在です。スクラムが正しく機能しているか逐一チェックし、開発メンバーへのアドバイスや指導も行います。

開発メンバーは、実際にコーディングを行うメンバーです。プログラミングスキルはもちろんのこと、スクラムにおいてはコミュニケーション能力も求められます。

アジャイル開発では、1つの開発チームの人数を10名以下とすることが推奨されており、スクラムの場合もチームは3～10人が理想的です。

スクラムでは1回の開発期間をスプリントと呼び、スプリントの期間は1～4週間が一般的です。短期間で成果を出しやすく、変化への柔軟な対応力や生産性向上にもつながっています。

スプリント期間中には、次の4つのイベントが行われます。

1.スプリントプランニング
スプリントプランニングはスプリントの最初に行うイベントで、チーム全体でスプリントの作業計画を立てます。スプリントで達成したいゴール（実装したい機能）を明確にしたり、ゴールに至るまでのタスクを1日分の作業量に分割したりします（スプリントバックログの作成）。

スプリントが始まると、途中での仕様変更などは基本的に認められないので、スプリントプランニングでは十分な検討を行う必要があります。

また、スクラムは仕様変更に対応できる開発手法ではあるものの、いったんスプリントが走ったらスプリントが終わるまでは変更を受け付けません。スプリント期間が長いと仕様変更への対応力が下がってしまう点には注意が必要です。

2.デイリースクラム
デイリースクラムとは、スクラムの特徴的なイベントの1つで、スプリント期間中に毎日行う短時間のミーティングのことを言います。昨日までの進捗や本日の目標、開発の課題などを発表し開発メンバーで共有する場です。

3.スプリントレビュー
スプリントレビューは、スプリントが終わった後に行うイベントです。今回のスプリントの成果や今後の流れを関係者に披露して共有します。

4.ふりかえり
ふりかえりはスプリントの最後に行うイベントで、今回のスプリントに対する評価や反省点を議論し、次回に向けた改善点を検討します。

【関連記事】

エクストリーム・プログラミング（XP, eXtreme Programing）

エクストリーム・プログラミングは、仕様変更やトラブルへの高い対応力といったアジャイル開発の特徴に加え、顧客の意見や要望を取り入れられる柔軟性の高さも持ち合わせられるようにするための方法論です。

開発手法自体はスクラムと同様に、短いイテレーションでの開発を基本とします。そこにエクストリーム・プログラミングの方法論を取り入れることで、継続的な開発チームの成長が期待できます。顧客満足度の高いソフトウェアを開発するための方法論です。

エクストリーム・プログラミングでは、開発で重視すべき5つの価値が示されています。

• コミュニケーション
• シンプル
• フィードバック
• 勇気
• 尊重

シンプルとは、本当に必要な機能を優先したシンプルな設計に重きをおくことを意味します。

フィードバックとは、顧客からの要望を意味します。シンプルな機能のみを実装したソフトウェアに、フィードバックを得て機能を追加していく工程を繰り返すことで、無駄のないソフトウェアができあがります。エクストリーム・プログラミングでは、顧客からのフィードバックを頻繁に取り入れます。

勇気とは、変化を受け入れる勇気を意味します。最初に綿密な計画を立てないエクストリーム・プログラミングでは、途中で大幅な仕様変更が起こることもあります。

尊重とは、開発者同士や顧客とのコミュニケーションにおいて、お互いの意見や姿勢を尊重することを意味します。心地良いコミュニケーションを行う上で、不可欠な心持ちです。

これら5つの価値を踏まえた上で、エクストリーム・プログラミングにはプラクティスと呼ばれる習慣や実践内容が示されています。プラクティスは対象者別に4つに大別し、それぞれのプラクティスには4～6個の実践内容が内包されています。プラクティスと実践内容の一覧は次のとおりです。

開発のプラクティス
• ペアプログラミング
• テスト駆動開発
• リファクタリング
• ソースコードの共同所有
• 継続的インテグレーション
• YAGNI（You Aren’t Going to Need It）

管理者のプラクティス
• 責任の受け入れ
• 援護
• ミラー
• 最適なベースの仕事中
• 四半期ごとの見直し

顧客のプラクティス
• ストーリーの作成
• リリース計画
• 受け入れテスト
• 短期リリース

共同のプラクティス
• 反復
• 共通の用語
• 開けた作業空間
• 回顧

これらの実践内容をソフトウェア開発に取り入れることが、エクストリーム・プログラミングを実践するということになります。

【関連記事】

ユーザー機能騒動開発（FDD, Feature Driven Development）

ユーザー機能駆動開発とは、ユーザー目線で価値のある機能を中心に開発を行うアジャイル開発手法です。顧客がプロジェクトに求めるものを正確に把握することで必要な機能を選定し、顧客が必要とする機能から優先的に開発を進めるというのが基本的な流れです。

そのため、顧客との入念なコミュニケーションが重要なのはもちろんのこと、開発者側もシステムの利用場面やビジネスモデルをしっかり把握しておく必要があります。

また、アジャイル開発と言えば反復開発ですが、ユーザー機能駆動開発の場合、実際に動作するシステムを短期間でリリースして反復する部分が特徴と言えます。 ユーザー機能駆動開発は、次に挙げる5つの基本活動をベースに作業が進められます。

1.全体モデル開発
ユーザー機能駆動開発は、モデル駆動型の短期反復を採用する開発方式です。この開発方式では、最初にモデル図と呼ばれる仕様に沿った全体モデルを開発します。まずはシステム全体の範囲と内容についての検討を行うことから始まり、次に部門ごとの専門的なモデルを制作していきます。こうしてできあがった特定分野ごとのモデルを結合したものが、全体モデルです。

2.フィーチャーリスト構築
全体モデル開発時に得られた知見をもとに、顧客の求める重要度で分類したフィーチャー（機能）をリストアップします。1つのフィーチャーは2週間程度の短期間で開発できる規模のものとし、それ以上に複雑だと考えられる場合は、さらに細かいフィーチャーに分割するなどの調整を加えます。

3.フィーチャーごとの計画
フィーチャーリストをもとに開発計画を立案します。開発チームの負荷状況や、フィーチャーの複雑さや優先度などに鑑みて、どの開発チームにどのフィーチャーを割り当てるかを決定します。開発チームでは、フィーチャーごとに責任を持つプログラマ（オーナー）を決めて分担させます。

4.フィーチャーごとの設計
フィーチャーのオーナーは、2週間で開発すべきフィーチャーを選択し設計を行います。その際、フィーチャーごとの詳細なシーケンス図を作成して、全体モデルの更新も行います。

5.フィーチャーごとの構築
設計が完了すると、コーディングでフィーチャーの実装を行います。

ユーザー機能駆動開発は、多くの開発チームにフィーチャーを割り当てて開発を進められるので、アジャイル開発の中でも大規模プロジェクトに対応しやすいという特徴を持ちます。

またユーザー機能駆動開発は、ソフトウェア工学に基づいたベストプラクティスを採用しているのも特徴です。代表的なベストプラクティスをいくつか次に挙げておきます。

• フィーチャーごとの開発
• クラスごとのオーナーシップ
• フィーチャーチーム
• 定期ビルド

フィーチャーごとの開発とは、2週間以内に実装できる小さな機能単位の開発です。バグの少ない実装が可能となり、システムの拡張や改善も容易になります。

クラスごとのオーナーシップとは、オーナーが各クラスの一貫性や性能などに責任を持つことを示しています。

フィーチャーチームとは、小規模で動的に結成されるチームです。個人や固定チームで陥りやすい独善を防ぎます。

定期ビルドとは、顧客に対して常に公開可能な最新システムを構築しておくことを意味します。ソースコード結合時の不具合を早期発見するのにも役立ちます。

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

アジャイル開発についてさまざまな開発方式を見てきましたが、ここであらためてアジャイル開発のメリットをまとめていきましょう。

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

• 開発スピードが速い
• 仕様変更やトラブルへの対応力が高い
• 顧客の要望を取り入れやすい

開発スピードの速さは、アジャイル開発の大きなメリットの1つです。開発の初期段階でしっかりとした設計や計画を詰めるのではなく、大まかに骨子ができた時点で重要な機能から開発に取り掛かることができ、素早く形にできる点が強みとなります。

また、イテレーションという短期間で納期を区切ることにより、長期開発でありがちな中弛みの余地を持たせないのも、開発スピードの速さにつながっていることでしょう。

仕様変更やトラブルへの対応力の高さも、アジャイル開発の大きなメリットです。これも、アジャイル開発のイテレーションという、短い開発スパンからもたらされるメリットになります。イテレーションという短期間で区切りながら開発を進めるアジャイル開発であれば、仕様変更に伴う損切りの量も最小限になり、今後の方針転換への対応も容易です。

顧客の要望を取り入れやすいのも、イテレーションからもたらされるメリットです。イテレーションが終了するたびに顧客と意見のすり合わせを行えるので、その際に要望を取り入れることができます。顧客と一緒にプロジェクトを完成させていくというスタイルも、アジャイル開発の特徴と言えるでしょう。

【関連記事】

【関連記事】

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

アジャイル開発には大きなメリットがある一方で、デメリットもいくつかあることを知っておきましょう。

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

• スケジュール管理や全体の把握が難しい
• 開発方針にブレが生じやすい
• 組織全体でアジャイル開発を理解しなければ成果を上げられない

スケジュール管理や全体の把握の難しさは、イテレーションによる柔軟性の高い開発の弊害です。ウォーターフォール開発のようにスケジュールを順番に埋めていくのではなく、変更や追加も頻繁に行われるため進捗状況が見えにくいのです。これは納期や予算に関わる問題になりかねず、開発チームが複数になるとさらに顕著となります。

開発方針にブレが生じやすいのも、変化への対応力の高さの裏の面と言えます。修正や追加を加えていった結果、最初の目標とは大きくかけ離れたものになってしまう恐れがあります。

組織全体でアジャイル開発を理解しなければ成果を上げられないという点も、デメリットと言えなくありません。アジャイル開発は単純にそのスタイルを真似ればOKというわけではなく、組織のトップから開発メンバーの1人1人に至るまでの意思統一が重要です。

管理者が目標に向かって適切な指示を出し、開発メンバーは自己組織化で十分な実力を出してイテレーションという短期間の開発に打ち込むことにより、アジャイル開発が本来の力を発揮します。

ウォーターフォール開発と適材適所で使い分けを

アジャイル開発について、代表的な開発手法を中心に説明してきました。

アジャイル開発はプロジェクトの骨子が大まかにできあがった段階で機能ごとの開発に取り掛かれるフットワークの軽さが魅力で、何と言っても開発スピードの速さと変化に対応する柔軟性の高さが利点です。

ただ、従来のウォーターフォール開発にも適した分野はあるので、盲目的にアジャイルオンリーとなるのではなく、適材適所で使い分けていけるのが理想的と言えます。

【関連記事】

【関連記事】