アジャイル手法とは

アジャイルとは、動作するソフトウェアを迅速なイテレーションで作成して継続的に提供することを目指す、ソフトウェア開発アプローチです。 

しかし、「アジャイル手法」という言葉は、「アジャイル」という単一のソフトウェア開発アプローチがあるという誤解を招く可能性があります。アジャイルは、「ソフトウェア開発はこうすべき」という手順を規定するものではありません。コラボレーションとワークフローについての考え方であり、何をどのように作るかを決める指針となる価値観の集合です。

実際的な言い方をするなら、アジャイルソフトウェア開発手法とは、顧客満足度を向上させるために、問題なく動作するソフトウェアの小片を迅速に提供することです。この手法では、適応性のあるアプローチとチームワークを活用して、継続的な改善に注力します。通常、アジャイルソフトウェア開発チームは自発的に集まった少人数のソフトウェア開発者チームとビジネス担当者チームで形成され、これらのチームは、ソフトウェアの開発ライフサイクルを通じて、定期的にミーティングを行います。アジャイルでは、ソフトウェアドキュメント作成作業の軽量化が重視され、ライフサイクルのあらゆる段階で変化を (敬遠するのではなく) 歓迎します。

現在のアジャイルの歴史は、2001 年に始まりました。ソフトウェアプロジェクトを一連の直線状のシーケンスとして編成するウォーターフォール型のプロジェクト開発への反論として、あるソフトウェア開発者グループが、アジャイルソフトウェア開発宣言を作成しました。この宣言は、プログラマーがソフトウェア開発に対する新しいアプローチを提案し、他の懸念事項よりも重視されるべきだと彼らが考えた 4 つの重要な考え方について述べるものでした。この宣言によると、アジャイルソフトウェア開発チームは次のことを重視する必要があります。

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

これを書いた人たちは、上述したすべての項目にそれぞれ固有の価値があることを明確に認めています。しかし、左側の項目に対して右側 (太字) の項目を重視することで、製品開発の成果は改善されると主張します。アジャイル宣言は、一連の手法を規定するものではなく、ソフトウェア開発についての新しい考え方の指針です。

アジャイル宣言の実務的な成果は、これまでに数多く生まれています。たとえば、ウォーターフォール手法では、ソフトウェアをあるフェーズから次のフェーズへと順番に開発することによって製品の品質を保証しますが、アジャイル手法は、開発とテストを並行および継続するプロセスとして進めます。別の言い方をすれば、ウォーターフォール型の開発では、次のフェーズに進む前に、現在作業中のフェーズ全体を完了する必要がありますが、アジャイル手法では、複数のシーケンスを並行して進めます。 

ウォーターフォール手法は、1913 年のヘンリー・フォードによる組立ラインの製造方法から派生し、後にソフトウェア開発に適用されたものです。その手法で見えてきた限界に対処するために考案されたのが、アジャイル手法の作業アプローチです。2001 年に登場して以来、アジャイル開発はソフトウェア業界とプロジェクト管理の分野で発展し、多様なバリエーションがあります。

アジャイルは、多くのソフトウェア開発者が、ウォーターフォール型の生産サイクルとコラボレーション手法が望ましい結果を生み出していないことに気づき始めたことで使われるようになりました。この問題は 1990 年代初頭には広く認知されるようになりました。この当時は、組織のビジネスニーズを認知してから、動作するアプリケーションが実際に提供されるまでに数年の遅れが生じることが当たり前でした。しかしビジネスの需要や市場は、その間にも変化します。時にはあまりに大きく変化したために、ソフトウェアプロジェクトの大部分がソフトウェアの提供前にキャンセルされることもありました。このような時間とリソースの無駄をなくそうと、多くのソフトウェア開発者が代替手段を探し求めました。

破壊的変革の脅威に直面している組織の多くは、加速するビジネスに追いつくために、デジタル・トランスフォーメーション戦略を導入するようになってきています。そこでしばしば活用されたのが、アジャイルソフトウェア開発です。

アジャイルは、現在使用されているデジタルワークフローの多くの基盤になっています。柔軟でスケーラブルな IT インフラストラクチャを備えたクラウド・コンピューティングは、アジャイルソフトウェア開発の需要と並行して成長しています。クラウドネイティブ開発では、ビジネスニーズに合わせて拡張する相互接続された一連のサービスとして、アジャイルのようなソフトウェアの概念を採用しています。

概念としての DevOps は、ソフトウェア開発と運用の間にある古い壁を打ち破るものです。SRE は DevOps 実践の一形態であり、ソフトウェアをツールとして使用してシステムを管理し、問題を解決し、運用タスクを自動化します。CI/CD 手法は、ソフトウェアが絶えず変化することを受け入れ、開発者による新しいコードのデプロイを加速するツールを提供します。

ここまでで、「アジャイル手法」という概念そのものがアジャイルな発想であり、時代の変化を通じて顧客 (つまり、ソフトウェア開発者) のニーズに応えていることをご理解いただけたのではないかと思います。このことに留意しつつ、名称が異なり、実装によって変わることも多い、さまざまなアジャイルフレームワークの概要を見ていきます。

スクラム、かんばん、エクストリーム・プログラミング (XP) といったソフトウェア開発用のアジャイルフレームワークは、DevOps や継続的インテグレーションおよび継続的デプロイメント (CI/CD) などの一般的なソフトウェア開発プロセスの基盤を形成します。

現在使用されているアジャイルフレームワークの中で最も一般的なものはおそらくスクラムですが、すべてのアジャイルがスクラムだというわけではなく、すべてのスクラムがアジャイルでもありません。スクラムは、5 - 9 人の小規模な部門横断型チーム向けに設計された作業管理フレームワークで、チームの作業は、スプリントと呼ばれる一定の期間内に完了できるアクションに分割されます。スクラムのチームは、チームメンバー、スクラムマスター、プロダクトオーナーで構成されます。通常、スクラムは、大きなプロジェクトを 2 - 4 週間のスプリントに分割できる場合に実装されます。スクラムの主眼は「レトロスペクティブ」と呼ばれる形式を通じたフィードバックループにあります。何かモットーを立てるとすれば、それは「検査と適応」となるでしょう。

かんばんをはじめとする他のアジャイルフレームワークは、アジャイル宣言以前からあるものです。しかし、アジャイル宣言で述べられている価値を促進するものなので、アジャイルとみなされています。アジャイルフレームワークとアジャイルなスケーリングへのアプローチは、ここですべてを挙げることができないほど多数存在します。