アジャイル開発運動は、2001年にユタ州で開催されたリトリートで、先進的な開発者17名が集まった際に生まれました。このリトリートで確立された哲学と原則は、アジャイル、そして彼らの初期の活動から発展したその後のアジャイル開発手法の基盤となりました。
原典「アジャイルソフトウェア開発宣言」の出版以来、アジャイル手法はソフトウェア開発のみならず、ほぼあらゆる分野の組織に深遠な変革をもたらしてきました。無駄のない製品開発、反復的な発見、変化重視の開発、そしてあらゆる企業や社会集団を横断した協働作業の価値は、世界中で新たな先進的なビジネスモデルや製品モデルの基盤を形成してきました。
このアジャイル手法ガイドは、アジャイルの中核原則を概観的に紹介するものです。まず、2001年の宣言で提唱されたアジャイル手法の定義から始め、アジャイルから派生した最もよく知られた手法をいくつか紹介します。最後に、最も人気のあるアジャイル手法とツールをいくつか紹介します。
アジャイルとは何ですか？
アジャイルとは、継続的な変更と改善への取り組みとして考えることができる作業（当初はソフトウェア開発）へのアプローチです。
アジャイルの価値
アジャイルは、2001 年にオリジナルのアジャイル宣言チームによって書かれた次の価値観に簡潔に説明されています。
- 個人との相互作用 プロセスとツールについて
- 働くソフトウェア 包括的な文書化
- 顧客とのコラボレーション 契約交渉について
- 変化への対応 計画に従うことよりも
これらの原則を見ると、アジャイルとは「何であるか」だけでなく「何でないか」によっても定義されることが容易に分かります。上記で示した4つの価値はすべて、固定された成果物よりも反復的な発見とコラボレーションを重視するという共通のテーマを持っています。これらの要素に焦点を当てることで、アジャイルチームは無駄を減らしながらより良い製品を生み出すだけでなく、機能リリースをスムーズに進めながら発見の余地を残すことができます。wing to 最終顧客。
アジャイル開発 vs. ウォーターフォール開発
アジャイルの創始者たちは、ソフトウェア業界の伝統的な作業方法からの大きな転換を提案しました。当時（2001年頃）、ソフトウェアは主に、数か月前に設定された特定の仕様に基づいてデジタル製品を開発する、単一のプロジェクトベースの取り組みとして開発されていました。製品のビジョンは、コンサルタント、経営幹部、そして管理者からなるグループによって決定され、彼らは経営陣に提示する要件リストを作成しました。経営陣は、要求されたソフトウェアのコーディング、コンパイル、テスト、そして構築といった作業を、定められた期間と予算内で実行するよう委託していました。
ソフトウェアの要件と成果物がすべて会社のトップから中核開発スタッフに指示されるため、開発者はこのシステムを「ウォーターフォール」方式と呼んでいました。
当初アジャイル開発に協力した人々は、いくつかの理由からこのソフトウェア開発形態を拒否しました。第一に、ウォーターフォールは柔軟性に欠け、開発中に変化する可能性のある顧客の要求に対応できませんでした。第二に、ウォーターフォール型の製品設計では、すべてのイノベーションはプロジェクト開始前に考案されなければなりませんでした。この硬直した枠組みでは、リリースが完了するまで新機能の可能性を発見する余地がほとんどありません。さらに、ソフトウェアは意図したとおりに動作しない可能性があり、ウォーターフォール型プロジェクトの開発途中でこのような問題が発見されると、多大な遅延を招きます。
アジャイルの創始者たちは、発見、革新、そして反復に開かれたソフトウェア開発手法を提案しました。特定の期日に機能完結型のソフトウェア全体をリリースすることを期待するのではなく、機能ビルドを段階的にリリースするのです。これにより市場投入までの時間が短縮され、開発予算を一括ではなく段階的に配分することが可能になります。
最も重要なことは、 アジャイル開発 当初構想された製品が、顧客や企業自体に期待されるレベルの価値を提供できない可能性があることを認めています。ビルドフェーズで作業することで、新しいアイデアを追加したり、製品戦略を変更したりすることができ、ウォーターフォールでは対応できない開発が可能になります。
アジャイルの原則
ウォーターフォールの欠点を克服するために、アジャイル哲学は社内のあらゆる場所からアイデアを集めることを推奨します。また、製品開発サイクルにおいて重要なのは、機能的なビルドを作成するのに数か月または数年かかる大規模な製品リリースではなく、反復的な変更を頻繁に提供することに重点を置くことです。
従来の「ウォーターフォール」管理主導の開発サイクルに代わって、このグループは当時としては革新的だった以下の作業方法を提案しました。
- 新しいソフトウェアを作成するときは、網羅的な成果物ではなく、シンプルな概念とアイデアから始めます。概念が顧客と社内の利害関係者に価値をもたらす可能性を示す実用的な概念実証プロトタイプを開発します。
- ビジネス担当者と開発者チームが協力して、実用的なプロトタイプをさらに強化し、改善し、進化させる方法を決定します。
- 進捗状況を把握し、製品を改善するための新たな機会を発見できるよう、個人とチームメンバーが直接話し合う時間と場所を毎日確保しましょう。これは、短時間のスタンドアップミーティングや、より長時間のスクラムミーティングといった形で行うことができます。
- ソフトウェアの新しい動作バージョンを頻繁に提供し、新しい変更を本番環境に継続的に統合・展開します。変更された各バージョンは、以前のバージョンを改良したものとなります。
- 各作業期間（「スプリント」）の結果を振り返り、学んだ教訓を活用してその後の開発を改善します。
- 製品を継続的に改善するために、直接的な調査または間接的なデータシグナルを通じて、プロセスにおいて顧客に意見を表明する。
アジャイルとリーン製造
アジャイルは、20世紀後半の高度工業化製造業の成長期に開拓された哲学であるリーン生産方式から多くの教訓を吸収しています。リーン生産方式は、製品製造における不要な工程を削減しながら、生産速度を向上させます。これらの手法は、日本の自動車メーカーであるトヨタによって活用され、トヨタ生産方式（TPS）を形成したことで有名です。
リーンから学んだアジャイルの主要な教訓は次のとおりです。
- 可能な限り最も効率的なプロセスを作成します。
- プロセスを統合し、より良い製品につながらないプロセスを削除することで、無駄 (ムダ) を排除します。
- 製品の品質と製造サイクルが一定になるように、結果を厳密に測定します。
- 従業員がプロセスの改善に貢献できるようにし、主要な人員に頼って品質、スピード、効率の目標を推進します。
- プロセスの中で遅延や品質低下につながるステップを特定し、これらの「フロー」の問題に対処して、スムーズで効率的なプロセスによって、信頼性の高い一貫した製品を作成できるようにします。
アジャイル手法とは何ですか?
アジャイル手法とは、2001年に初めて体系化されたアジャイルの理念を反映した一連の作業手法です。そのため、「アジャイル手法」という括りの下には、実際には複数の手法が含まれます。これらが最も人気のあるアジャイル手法を構成しており、それぞれについて以下で詳しく説明します。
アジャイル方法論は、次の特性によって定義されます。
- チームは、組織のさまざまな分野の専門家から構成されます (部門横断型チーム)。
- 部門横断型チームは、チーム自体、顧客からのフィードバック、製品戦略チームから得られた革新的なアイデアに基づいて、ソフトウェア/製品コンセプトのプロトタイプ バージョンを構築する責任を負います。
- その後、ソフトウェア製品は短い「スプリント」中に改訂され、より多くの機能、特徴、改善、修正が追加されます。
- 製品の変更や改善に関するアイデアは社内全体から寄せられ、これらの問題に関する議論が頻繁に行われます。
- 部門横断的なチームは、毎日の短い「スタンドアップ」ミーティングで、作業の進捗、課題、優先事項、新たな機会について話し合います。
- スプリントが完了すると、スプリント中に行われた変更が製品の現在のバージョンに組み込まれます。
- 定期的なテストや顧客からのフィードバックの反映など、プロセス全体を通して品質管理が導入されています。特定のリリースにおける問題は、新しいリリースの統合と提供前に発見され、（理想的には）対処されます。
- 各スプリントの終了時には、クロスファンクショナルチームは結果とプロセスの進捗状況を振り返る時間を取ります。得られた知見に基づいて、新たな目標とマイルストーンが設定されることが多いでしょう。
- 新しいスプリントは、部門横断的なチームが取り組むために編成され、新しい機能、改善、修正が追加されます。
アジャイル手法にはどのような種類がありますか?
アジャイルには、アジャイル宣言以前から存在するものの、その価値観を共有する手法だけでなく、多くの人気のあるバージョンや派生手法が存在します。スクラム、リーン、カンバン、エクストリームプログラミング（XP）、フィーチャー駆動開発（FDD）、動的システム開発手法（DSDM）、クリスタルなどがその例です。
スクラム
スクラム 積極的なスプリントを用いて反復的なアジャイル改善を完了することに重点を置いています。スクラムチームは、スプリントの過程で主要な作業を完了するために連携し、各スプリントは、リリースの品質と整合性を損なうことなく重要な作業を完了できるように計画されます。
スクラムは、「スクラムマスター」と「プロダクトオーナー」という役割を導入したことで知られています。どちらも、すべての小さなプロセスが望ましい結果につながるよう監督する役割を担っています。また、「プロダクトバックログ」という概念も重要です。これは、次のスプリントで導入すべき機能、改善、修正を示すものです。
スクラムメソッドは、800人以上の大規模組織における複数のチームに拡張できることが実証されています。その方法をご覧ください。 Digital.ai Agility（旧VersionOne）は、 スクラムスプリントプランニング 製品バックログの管理が容易になります。
リーン
上記で一部説明したリーン生産方式は、予測可能な作業フローを通じて継続的かつ一貫した価値を創造することを重視します。開発ワークフローのスピードと効率性を重視し、プログラマーと顧客間の迅速かつ信頼性の高いフィードバックを基盤としています。リーン生産方式では、顧客の要求によって成果物が「引き出される」という考え方を採用しています。階層的な制御フローよりも迅速かつ効率的であることが研究で示されているため、リーン生産方式では意思決定の権限と能力を個人や小規模チームに委ねています。
リーン開発は、チームリソースの効率性にも重点を置き、全員が可能な限り多くの時間を生産的に過ごせるように努めます。また、同時並行作業とチーム内ワークフローの依存関係を最小限に抑えることを重視します。さらに、リーン開発では、自動化されたユニットテストをコードの作成と同時に作成することを強く推奨しています。
かんばん
カンバンは、リーン生産方式の歴史と深く結びついた生産管理手法です。カンバン方式では主に「カンバンボード」を用いて、現在の作業項目の量と進捗状況を追跡します。カンバンボードでは、付箋（または仮想的な同等物）を用いて、プロセスの各段階における現在の作業項目の数を追跡します。作業項目が完了すると、付箋はプロセスの次の段階に移動します。
カンバンは、開発サイクルにおける現在の作業項目の量と進捗状況を視覚化することで、フローを重視します。多くの作業項目が1つのステージに集中している場合は、スプリントまたはタスクグループを完了に導くために、進行中の作業（WIP）の量にすぐに対処する必要があるサインです。WIPがなくなると、新たなキャパシティが確保されるため、バックログから新しい作業項目を「引き出す」合図にもなります。
エクストリームプログラミング（XP）
エクストリームプログラミング（XP）は、アジャイル宣言の協力者であるケント・ベックによって90年代後半に考案されました。アジャイルと同様に、顧客の積極的な関与、迅速なフィードバックループ、 継続的なテスト継続的な計画と緊密なチームワークにより、通常 1 ～ 3 週間ごとに非常に頻繁に実用的なソフトウェアを提供します。
XPのオリジナルのレシピは、シンプルさ、コミュニケーション、フィードバック、そして勇気という4つのシンプルな価値観に基づいています。また、12の重要なサポートプラクティスによっても機能します。
- 計画ゲーム
- 小規模リリース
- 顧客受け入れテスト
- シンプルなデザイン
- ペアプログラミング
- テスト駆動開発
- リファクタリング
- 継続的インテグレーション
- 共同コード所有権
- コーディング標準
- メタファー
- 持続可能なペース
機能駆動開発（FDD）
機能駆動開発（FDD） アジャイル手法の一種で、機能ごとに個別に完了する、非常に短い特定の作業フェーズを記述します。これには、ドメインウォークスルー、設計、設計検査、コーディング、コード検査、そしてビルドへのプロモーションが含まれます。
FDD の基本的な概念は、製品の意図された将来の状態をモデルを使用して表現でき、機能に取り組むことで「クライアントの目から見て有用」なものによって表現される総合的な製品モデルの構築に役立つというものです。
FDDは、「定期的なビルド」や「コンポーネント／クラスの所有権」といった特定のプログラマープラクティスを推奨しています。FDDの支持者は、FDDは他のアプローチよりも簡単にスケールし、大規模なチームに適していると主張しています。
動的システム開発手法 (DSDM)
DSDMは、1994年に初めて記述されたアジャイルのもう一つの初期の祖先です。DSDMの起源は、標準化を目指したラピッドアプリケーション開発（RAD）にあります。 ソフトウェア配信 フレームワーク。アジャイルの登場後、DSDMはさらに進化・成熟し、アジャイルプロセスと反復的なソフトウェア開発プロジェクトの計画、管理、実行、拡張のための包括的な基盤を提供するようになりました。
DSDMは、ビジネスニーズ／価値、積極的なユーザー関与、権限委譲されたチーム、頻繁なデリバリー、統合テスト、そしてステークホルダーとのコラボレーションを中心とした9つの主要原則に基づいています。DSDMは、システムのデリバリーと受入における主要な基準として「ビジネス目的への適合性」を特に重視し、システムの20%の時間で展開可能な、システムの有用な80%に焦点を当てています。
DSDM は、タイムボックス モデルを使用して特定の成果物を優先順位付けし、優先順位が低い項目は、タイムボックスの期限に間に合うように事前に選択されて脇に移動されます。
クリスタル
Crystalメソッドは、ソフトウェア開発における最も軽量で柔軟性の高いアプローチの一つです。Crystalメソッドの主要な信条には、チームワーク、コミュニケーション、シンプルさ、そしてプロセスを頻繁に調整・改善するためのリフレクション（振り返り）が含まれます。他のアジャイルプロセスメソッドと同様に、Crystalメソッドは、動作するソフトウェアの早期かつ頻繁なデリバリー、ユーザーの積極的な関与、適応性、そして官僚主義や煩雑な作業の排除を促進します。
Crystalは、実際にはクリスタルクリア、クリスタルイエロー、クリスタルオレンジといったアジャイル手法のファミリーから構成されており、それぞれの独自の特性は、チームの規模、システムの重要度、プロジェクトの優先度といった複数の要因によって決まります。このCrystalファミリーは、各プロジェクトの特性に合わせて、ポリシー、プラクティス、プロセスを少しずつ調整する必要があるという認識に基づいています。
アジャイル手法の利点
アジャイル手法はそれぞれ独自の長所と目的を持っていますが、次のような利点はすべての手法に共通する傾向があります。
- ソフトウェアの実用的なバージョンは比較的迅速かつ頻繁に配信される
- ビルドの品質と完全性はプロセスの早い段階で理解されます
- 依存関係と配信プロセスのボトルネックが最小限に抑えられます
- 製品は、顧客、競合他社、そして市場全体から示されるシグナルから理解される現在の需要の状態を反映しています。
- イノベーションは製品ライフサイクルのどの段階でも導入できる
- 最上位のアドバイザー/管理者/コンサルタントが下位のチームに指示を出すのではなく、すべてのチームから協力的な意見が出される。
- 機能ビルドを重視しない開発サイクルに比べてリスクが軽減されます
- 顧客満足度とチームの士気に重点が置かれており、どちらも満足していない場合は、製品とプロセスがニーズを満たしていないと理解されます。
- 業務はより管理しやすく予測可能になり、混乱や突然の戦略変更に対応できる柔軟性も導入されます。
アジャイル手法で使用するトップツール
アジャイル手法に最も推奨されるツールには次のようなものがあります。
- アジャイル計画ソフトウェア: 製品バックログ ポートフォリオの管理とスプリントの計画にカンバンやその他のツールを提供します。
- Release オーケストレーションソフトウェア: 作業項目の割り当てを可能にするとともに、リリースのオーケストレーションと自動化機能も提供します。
- Release Deployメントソフトウェア: クラウドやコンテナベースのものを含む、新しいリリースをオペレーティング環境に展開するプロセスを簡素化および自動化します。
- Continuous Testing ソフトウェア: 効率的かつ 自動テスト 開発プロセス全体を通じて、リスクとコストを削減しながら納品を迅速化します。
- ビジネスインテリジェンスと分析ソリューション: リリースのタイムライン、変更関連のリスク、リリースの品質と価値の提供を改善する機会に透明性を追加する単一の真実のソースを作成します。
