今日、多くのシステム開発現場では「アジャイル開発」という手法が用いられています。しかし、アジャイル開発とは何でしょうか。そして、システム開発においてどのように実践すべきなのでしょうか。本記事ではアジャイル開発の流れや、従来の開発手法との違い、失敗しないためのポイントなどについて解説します。
アジャイル開発とは
「アジャイル開発」とは、プロジェクト管理も含めたシステム開発の進め方、または考え方のひとつです。その大きな特徴は、2週間から2ヶ月ほどの短いサイクルで開発とリリースを繰り返しながら、システムを構築していくことにあります。この手法では、システムを小単位ごとに区切って、「企画」→「計画」→「設計」→「実装」→「試験」からなる開発フローを小刻みに繰り返すことで、実際にシステムを動かしながら顧客（ユーザー）からのフィードバックを得て、システムを構築・改善していきます。
アジャイル開発の始まり「アジャイルソフトウェア開発宣言」とは
アジャイル開発という概念は、17人のシステム開発の専門家が発表した「アジャイルソフトウェア開発宣言」という声明に由来します。この宣言では、彼ら専門家が開発において共通して重要と考えていることを、以下の12の原則に基づき示しています。
【アジャイル宣言の背後にある12の原則】
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更は、たとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを2～3週間から2～3ヶ月という、できるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え、仕事が無事終わるまで彼らを信頼します。
- 情報を伝える最も効率的で効果的な方法は、フェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
これらの原則では単なる技術的な方法論を超え、顧客満足度を最優先にする開発姿勢や、顧客と開発者の適切なコミュニケーションの取り方、部門横断的なチームワークの重要性など、事業を成功に導くための本質的なマインドセット（心構え）が説かれています。
アジャイル開発とウォーターフォール開発の違い
アジャイル開発の特徴は、これまで主流であった「ウォーターフォール開発」と比較することで、より明瞭に理解できます。
まずウォーターフォール開発とは、最初に緻密な要件定義や計画書の作成を行い、それに沿って開発を長期的に行っていく手法です。その性質上、銀行システムのような不具合を許されないものや、多くの人員確保を要する大規模な事業を行う場合に適しています。
しかし、その緻密さゆえの弊害として、この手法は途中で顧客から仕様変更などの希望が出た場合、根底から計画全体を見直さなければならないリスクも抱えています。また、システムの一部に不具合などがあった場合も、大きな手戻りが発生する可能性があるなど、その硬直性が課題です。
対してアジャイル開発は、システムを機能ごとに区切り、開発とリリースを反復する中で、顧客の要望を都度反映しつつ開発を進めていきます。もちろん、ここにおいても事前の要件定義や計画は重要ですが、実際に開発と実装を行っていく中で、「当初の計画よりもこっちのほうがよいのでは？」という発見は往々にして起こりうるものです。
それゆえアジャイル開発では、途中の変更は当然起こりうるものと仮定し、重要な機能から段階的にリリースしていきます。これにより、各変更がシステム全体に与える影響や、それに対する顧客やユーザーのフィードバックを収集し、柔軟にシステムを構築していくことが可能になるのです。そのため、頻繁なシステム更新が要求されるクラウドサービスなどに適した手法といえるでしょう。
【ウォーターフォール開発の特徴】
- 事前の緻密な計画に基づいて長期的に開発を進める
- 完成された大規模なシステムを構築するのに適している
【アジャイル開発の特徴】
- 実際にシステムを動かしながら短期サイクルで開発を進める
- 頻繁な更新が要求される柔軟なシステムを構築するのに適している
アジャイル開発の手法
プロジェクトで何を重視したいかによって、アジャイル開発の在り方は変わってきます。以下では、3つの主な手法についてご紹介します。
スクラム
「スクラム」とは、チームが協力してプロジェクトを進めていくことを重視した手法です。語源通り、ラグビーチームが試合を目指して練習に取り組むように、チームが一丸となって問題解決に取り組みながら、細かく開発サイクルを回していきます。チームマネジメントという性質が色濃いこの手法は、ソフトウェア開発に限らず、あらゆる種類のチームワークに適用できます。また、後述の2手法と組み合わせて運用することも可能です。
XP（エクストリーム・プログラミング）
「XP」は、技術面に重きを置いたプログラマー中心の開発手法です。事前計画よりも、仕様や要件の途中変更に対応できる柔軟性を重んじ、極限（エクストリーム）レベルまでベストプラクティスを追求したフレームワークに従って開発を進めます。この手法は、少人数のプログラマーチームが難易度の高いプロジェクトに取り組む際に有効です。
ユーザー機能駆動開発（FDD）
「FDD（Feature Driven Development）」とは、顧客が本当に必要とする機能を洗い出し、それを実現することに大きな価値を置く手法です。必要なときに必要な機能を提供することが重んじられており、通常その開発サイクルは2週間程度と短く設定されます。スケーラブルに開発を進めたい場合に有効な手法です。
アジャイル開発のメリット・デメリット
続いては、アジャイル開発のメリット・デメリットをご紹介します。
アジャイル開発のメリット
アジャイル開発の大きな強みは、顧客からの要件・仕様変更などの要求にも臨機応変に対応でき、柔軟かつ迅速な修正や変更が可能なことです。これにより開発チームは、顧客のニーズを最大限反映したシステムを開発できます。
アジャイル開発のデメリット
他方、デメリットとしては、柔軟でスケーラブルな開発を重んじる反動として、全体のスケジュール感や進捗状況の管理が難しくなることが挙げられます。また、繰り返される変更の中で、全体の整合性を取るのに失敗してしまうリスクも抱えています。
アジャイル開発を失敗させないための注意点
上記のように、アジャイル開発にも欠点はあり、運用を間違えてしまうと開発が失敗に終わってしまう場合もあります。そこで最後に、開発を進める際の注意点について解説します。
クライアントの経営層やユーザーのアジャイル型開発への理解を深める
先述したようにアジャイル開発では、ごく短いサイクルで顧客からの要望を都度反映した開発を繰り返していきます。それゆえ非常にタイトなスケジュールになりやすく、顧客から要望を十分に聞けていなくても、現場のチームとしては見切り発車で開発を進めなければならない状況になりがちです。プロジェクトを成功させるためには、顧客側もこうした特性を十分に理解し、開発チームとのコミュニケーション機会を多く設けることが大切です。
組織の特性やリスクに応じたプラクティスを取り入れる
アジャイル開発と一口にいっても、実際にはいくつもの手法があります。プロジェクトを成功させるには、それぞれの手法の違いを理解したうえで、組織の実態や想定されるリスクに対し、合理的に応じられるベストプラクティスを採用することが重要です。場合によっては、ウォーターフォール開発のほうが向いていることもあるでしょう。
アジャイル開発にも設計書やドキュメントの必要性を考える
アジャイル開発に関して間違った認識のひとつに、「設計書やドキュメントがいらない」という誤解があります。たしかに無駄な設計書は不要ですが、かといって設計書そのものの価値を認めていないわけではありません。むしろ繰り返される変更の中でも、システム全体の一貫性や整合性を見失わないようにするための大きな指針として、設計書が役立つことは大いにあります。一概に設計書や仕様書を否定するのではなく、何のためにそういったドキュメントが必要になるのかを改めて考えることが大切です。
まとめ
アジャイル開発とは、システムを小さな機能単位ごとに短期サイクルで開発していく手法です。柔軟性が高く、顧客のニーズを細やかに汲み取り開発できるのが特徴です。Microsoftでは、アジャイル開発を促進するプラットフォーム「Azure DevOps」を提供しています。アジャイル開発に取り組む際は、ぜひご活用ください。
