アジャイルとは、ソフトウェア開発へのアプローチを表す用語で、最終段階で一括納品しようとするのではなく、段階的な成果物の提供、チームの協働、継続的な計画立案、継続的な学習を重視する考え方です。
アジャイルは、プロセスをスリムに保ち、複数のイテレーションを経て完成に至る最小限の実用的なプロダクト（MVP）を作成することに重点を置いています。フィードバックは継続的に収集・反映され、全員が一つの目標に向かって協力し合う、非常にダイナミックなプロセスです。
アジャイルソフトウェア開発とは
スクラムとその他の主要なアジャイル手法
アジャイルとはマインドセットであり、価値観と原則の集合体です。アジャイルは思考と行動の在り方です。アジャイルは、短いサイクル、反復的・段階的な成果物の提供、早期の失敗と学習、フィードバックの取得、ビジネス価値の早期提供、そして人・協働・インタラクションを重視します。アジャイルとは、透明性・検査・適応を核とするマインドセットです。ただし、アジャイル自体は特定のロール、イベント、アーティファクトを定義するものではありません。あくまでもマインドセットです。例えば、スクラムはアジャイルの傘下で広く使われているフレームワークの一つで、アジャイルな開発を実践する助けとなりますが、カンバン、XP、クリスタルなど、アジャイルにはさらに多くのフレームワークが存在します（下図参照）。
アジャイル手法
スクラム：
スクラムは、複雑な適応的課題に取り組みながら、最高の価値を持つプロダクトを生産的かつ創造的に提供するためのフレームワークです。ソフトウェアプロジェクトやプロダクト・アプリケーション開発の管理に活用されています。2〜4週間のサイクル（スプリント）内で共通の目標に向かって機能横断的なチームが一体となって動く、適応型プロダクト開発戦略に焦点を当てています。価値観、アーティファクト、ロール、セレモニー、ルール、ベストプラクティスの集合体で構成されています。
リーン：
リーンはトヨタ生産方式（TPS）に端を発し、1950〜60年代以降の製造業に革命をもたらしました。現在も製造業での地位を保ちつつ、ナレッジワークにも応用が広がっており、あらゆる業界の企業が無駄の排除、プロセス改善、イノベーション促進に活用しています。ソフトウェア開発はリーン手法の自然な応用先です。製造業と同様に一定のプロセスと受け入れ条件が存在し、具体的な価値を提供するという共通点があるためです。すべてのリーン実践を導く中心概念（リーンの柱）は以下のとおりです：
- 継続的改善
- 人間尊重
- 軽量なリーダーシップ
カンバン：
カンバンは、リーンチームの間で広く普及している視覚的なワークフロー管理手法です。実際、リーンを実践するチームの83%がカンバンを活用し、継続的な成果物の提供を重視しながら開発チームに過度な負荷をかけずにプロダクト作成を可視化・管理しています。スクラムと同様、カンバンはチームがより効果的に協働できるよう設計されたプロセスです。
カンバンは3つの基本原則に基づいています：
- 本日の作業を可視化する（ワークフロー）：各アイテムを相互の文脈の中で把握することで、重要なインサイトが得られます
- 進行中の作業量（WIP）を制限する：フロー型アプローチのバランスを保ち、チームが一度に多くの作業を抱えすぎないようにします
- フローを改善する：タスクが完了したら、バックログの中で最優先のアイテムを次に引き上げます
カンバンは継続的なコラボレーションを促進し、チームの最適なワークフローを定義することで、積極的・継続的な学習と改善を後押しします。
動的システム開発手法（DSDM）：
DSDMは、8つの原則、ライフサイクルと成果物、ロールと責任、そして複数のベストプラクティス技法で構成されるフレームワークです。これらは、組織が最良の投資対効果（ROI）を得られるよう、戦略的に整合したビジネス上の成果をできるだけ早期に提供するという哲学を支え、支援するものです。
DSDMは、機能よりもスケジュールと品質を優先する方法論で、プロジェクト開始時にコスト・品質・期間を固定し、要件をMoSCoW法で次の4種類に分類します：
- 必須要件（M）
- あるべき要件（S）
- あれば良い要件（C）
- 今回は対象外の要件（W）
DSDM Atern[13]を支える8つの原則があります。これらの原則は、チームが一貫した成果を出すために取るべき姿勢とマインドセットを示しています。
- ビジネスニーズに集中する
- 期限を守って納品する
- 協働する
- 品質を妥協しない
- 確固たる基盤から段階的に構築する
- 反復的に開発する
- 継続的かつ明確に情報を伝達する
- コントロールを実証する
エクストリームプログラミング：
エクストリームプログラミング（XP）は、ケント・ベックによって考案され、最も人気があると同時に議論を呼んだアジャイル手法の一つとして台頭しました。XPは、高品質なソフトウェアを迅速かつ継続的に提供するための規律ある手法です。変化する顧客要件に対応するためにソフトウェアの品質と応答性を高めることを目的とし、高い顧客関与、迅速なフィードバックループ、継続的なテスト、継続的な計画立案、密接なチームワークを推進しながら、通常1〜3週間という高頻度でプロダクトを提供します。
この手法は、従来のソフトウェアエンジニアリングにおける有益な実践を「極限（エクストリーム）」レベルまで高めるという考えに基づいています。例えば、コードレビューは有益な実践とされていますが、それを極限まで推し進めると、ペアプログラミングによってコードを継続的にレビューすることになります。
XPの原型は、シンプルさ・コミュニケーション・フィードバック・勇気という4つのシンプルな価値観に基づいています。
また、12のサポート実践があります：
- プランニングゲーム
- スモールリリース
- 顧客受け入れテスト
- シンプルな設計
- ペアプログラミング
- テスト駆動開発
- リファクタリング
- 継続的インテグレーション
- コードの集合的所有
- コーディング標準
- メタファー
- 持続可能なペース
エクストリームプログラミング
フィーチャー駆動開発（FDD）：
フィーチャー駆動開発（FDD）は、シンガポールの大手銀行でのソフトウェア開発プロジェクトに携わっていたジェフ・デ・ルカによって1997年に考案されました。反復的・段階的なソフトウェア開発プロセスであり、アジャイルな開発手法の一つです。FDDは業界で認められた複数のベストプラクティスを一つの整合したアプローチに統合しており、クライアントが価値を感じる機能（フィーチャー）を中心に据えています。主な目的は、実用的で動作するソフトウェアを適時かつ継続的に提供することです。FDDの強みは、「必要最小限の初期設計（JEDI）」という概念により大規模チームにも対応できるスケーラビリティにあります。また、フィーチャー中心のプロセスにより、アジャイルで段階的かつ本質的に複雑なプロジェクトを管理するための優れたソリューションです。5つの基本的な活動で構成されています：
- 全体モデルの構築
- フィーチャーリストの作成
- フィーチャーによる計画立案
- フィーチャーによる設計
- フィーチャーによる実装
フィーチャー駆動開発（FDD）
プロジェクトごとに独自のモデルが作成され、そこからフィーチャーリストが生成されます。最後の3つの活動は短い反復プロセスであり、一つのフィーチャーの構築に2週間以上かかることはありません。2週間を超える場合は、より小さなフィーチャーに分解する必要があります。
クリスタル：
クリスタル手法は、アリスター・コクバーンが1990年代半ばに開発した一連の方法論（クリスタルファミリー）です。コクバーンが長年にわたりチームを調査・インタビューした成果として生まれました。調査によると、インタビューしたチームは正式な方法論に従っていなかったにもかかわらず、プロジェクトを成功させていました。クリスタルファミリーは、それらのチームが成功の要因としていた実践を体系化したものです。クリスタル手法が重視するのは以下の点です：
- 人
- インタラクション
- コミュニティ
- スキル
- タレント
- コミュニケーション
アジャイルマニフェスト
「アジャイル」という用語は、2001年に発表されたアジャイルマニフェストで生まれました。このマニフェストは、より良いソフトウェア開発アプローチを導く原則を確立することを目的としています。アジャイルマニフェストは4つの重要な価値観で構成されています。マニフェストの読み方として重要なのは、右側の項目が価値を持たないのではなく、アジャイルの考え方では左側の項目をより重視するということです。
アジャイルマニフェスト
アジャイルマニフェストの最初の一節を見てみましょう。この一節では、あらゆる広範なプロセスやツールを整備することよりも、人・インタラクション・コミュニケーション・コラボレーションを重視すると述べています。もちろんプロセスやツールに価値がないわけではありませんが、人々が協力して優れたプロダクトを提供することを本当に支援できるとき、その価値はさらに高まります。多くの組織では、プロセスやツールが目的化しがちです。アジャイルの観点では、プロセスやツールはあくまでも人々の協働と顧客への価値提供を支援するための手段であるべきです。
アジャイルマニフェストの原則
アジャイルマニフェストを補完するものとして、アジャイルアライアンスは12の基本原則も定義しており、マニフェストに対する指針と詳細な解説を提供しています：
アジャイルマニフェストの原則
アジャイルマニフェストの原則：
- 顧客満足を最優先とし、価値あるソフトウェアの早期かつ継続的な提供を行います。
- 要件の変更を歓迎します。たとえ開発の後期であっても。アジャイルプロセスは変化を顧客の競争上の優位性として活用します。
- 動作するソフトウェアを数週間から数ヶ月の間隔で頻繁に提供します。できるだけ短い期間を優先します。
- ビジネス担当者と開発者は、プロジェクト全期間を通じて日々協働しなければなりません。
- 意欲ある個人を中心にプロジェクトを構築します。必要な環境とサポートを整え、仕事をやり遂げることを信頼することが重要です。
- 開発チームへの、およびチーム内での情報伝達で最も効率的かつ効果的な方法は、対面での会話です。
- 動作するソフトウェアが進捗の主要な尺度です。
- アジャイルプロセスは持続可能な開発を促進します。
- スポンサー・開発者・ユーザーは、一定のペースを無期限に維持できるべきです。
- 技術的卓越性と優れた設計への継続的な注意がアジリティを高めます。
- シンプルさ——行わない作業の量を最大化する技術——が本質的です。
- 最良のアーキテクチャ・要件・設計は、自己組織化チームから生まれます。チームは定期的に、どうすればより効果的になれるかを振り返り、それに従って行動を調整します。
まとめ
アジャイル開発は、ソフトウェア開発業界で広く普及した重要なコンセプトであり、ソフトウェア開発プロジェクトの管理における新しいアプローチを示しています。特定の開発手法ではなく、アジャイルマニフェストに表明された価値観と原則に基づく一連の手法・実践を総称するものです。ソリューションは、自己組織化された機能横断的なチームの協働を通じて、各チームの状況に合った実践を活用しながら進化していきます。
出典: https://www.visual-paradigm.com/scrum/what-is-agile-software-development/
