アジャイルとは

アジャイルは、段階的なデリバリー、チームのコラボレーション、継続的な計画、継続的な学習を重視したソフトウェア開発のアプローチを表す用語です。 アジャイルという用語は、2001 年の アジャイル宣言で作られました。 このマニフェストは、ソフトウェア開発に対するより良いアプローチを導くための原則を確立することを目的としています。 マニフェストの中核では、アジャイル運動の基礎を表す 4 つの価値観を宣言しています。 マニフェストには次のように書かれています。

私たちは次のことを重視するようになりました。

• 個人および対話 (プロセスやツールよりも)。
• 包括的なドキュメントよりも動作するソフトウェア。
• 契約交渉よりも顧客とのコラボレーション。
• 変化への対応 (計画に従うことよりも)。

マニフェストは、これらの声明の右側にある項目が重要ではない、または必要ではないことを示唆するものではありません。 むしろ、左側のアイテムの方が単純に価値が高くなります。

アジャイルな手法と実践

アジャイルはものではないことを理解することが重要です。 アジャイルを実行しません。 むしろ、アジャイルはソフトウェア開発へのアプローチを推進する考え方です。 すべての状況に有効な単一のアプローチはないため、アジャイルという用語は、マニフェストの価値観に沿ったさまざまな方法や実践を表すようになりました。

アジャイル手法はフレームワークと呼ばれることが多く、DevOps ライフサイクルの各段階 (計画、開発、提供、運用) に対する包括的なアプローチです。 彼らは、明確な指針と原則に基づいて、仕事を遂行するための方法を規定します。

Scrum は最も一般的なアジャイル フレームワークであり、ほとんどの人が最初に使用するフレームワークです。 一方、アジャイル実践は、ソフトウェア開発ライフサイクルの各段階で適用される手法です。

• プランニング ポーカーは、チーム メンバーが 完了 の意味について理解を共有できるように設計された、共同見積もりの実践です。 多くの人がこのプロセスを楽しいと感じており、チームワークの促進とより良い見積もりの促進に役立つことが証明されています。
• 継続的インテグレーション (CI) は、コード変更をメイン ブランチに頻繁に統合する一般的なアジャイル エンジニアリング手法です。 自動ビルドにより変更が検証されます。 その結果、統合負債が削減され、メインブランチを継続的に出荷できるようになります。

これらのプラクティスは、すべてのアジャイル プラクティスと同様、アジャイル マニフェストの原則と一致しているため、アジャイル というラベルが付けられています。

アジャイルではないもの

アジャイルの人気が高まるにつれ、多くの固定観念や誤解がその有効性にマイナスの影を落としてきました。 説明責任なしに「はい、私たちはアジャイルをやっています」と言うのは簡単です。 この点を念頭に置き、アジャイルにはない点をいくつか考えてみましょう。

• アジャイルはカウボーイ コーディングではありません。 アジャイルを、ソフトウェア開発に対する「やっていくうちに解決する」アプローチと混同すべきではありません。 そのような考えは真実からかけ離れたものではありません。 アジャイルには、完了の定義と、スプリントごとに顧客に提供される明示的な価値の両方が必要です。 アジャイルは個人とチームの自律性を重視しますが、自律性の向上がより高い価値を生み出すように調整された自律性を重視します。
• アジャイルには厳密さと計画が欠かせません。 それどころか、アジャイルの方法論と実践では、通常、計画における規律が重視されます。 重要なのは、事前に計画を立てるだけではなく、プロジェクト全体を通じて継続的に計画を立てることです。 継続的に計画を立てることで、チームは実行した作業から確実に学ぶことができます。 このアプローチを通じて、計画の投資収益率 (ROI) を最大化します。

「計画には価値がないが、計画こそがすべてだ。」 — ドワイト・D・アイゼンハワー

• アジャイルはロードマップがないことの言い訳にはなりません。 この誤解はおそらくアジャイル運動全体に最も大きな害を与えています。 アジャイル アプローチに従う組織やチームは、自分たちがどこに向かっているのか、そして達成したい結果を完全に理解しています。 変化をプロセスの一部として認識することは、毎週、スプリント、または月ごとに新しい方向にピボットすることとは異なります。
• アジャイルは仕様のない開発ではありません。 どのようなプロジェクトでも、なぜ、どのように作業が行われるかについてチームの意見を一致させておくことが必要です。 仕様に対するアジャイル アプローチには、仕様が適切なサイズであること、およびチームが作業をどのように順序付けして実行するかを適切に反映していることを保証することが含まれます。
• アジャイルは計画外の作業やその他の中断に対応できないわけではありません。 スプリントをスケジュールどおりに完了することが重要です。 ただし、開発を妨げる問題が発生したからといって、スプリントが失敗する必要があるわけではありません。 チームは、問題や予期せぬ問題に備えてリソースを事前に指定することで、中断に備えた計画を立てることができます。 そうすれば、それらの問題に対処しながら開発を順調に進めることができます。
• アジャイルは大規模な組織には不適切ではありません。 よくある不満は、アジャイル手法の重要な要素であるコラボレーションが大規模なチームでは難しいということです。 もう 1 つの不満は、アジャイルへのスケーラブルなアプローチが柔軟性を損なう構造と手法を導入していることです。 こうした誤解にもかかわらず、アジャイル原則をうまく拡張することは可能です。 これらの問題を克服する方法については、アジャイルを大規模チームに拡張するを参照してください。
• アジャイルは非効率ではありません。 顧客の変化するニーズに適応するために、開発者は反復ごとに時間を投資して、実際に動作する製品を実証し、フィードバックを収集します。 こうした取り組みにより、開発に費やす時間が短縮されるのは事実です。 ただし、顧客のリクエストを早い段階で反映することで、後の時間を大幅に節約できます。 機能が顧客のビジョンと一致していれば、開発者は将来の大規模な見直しを回避できます。
• アジャイルは、データ ストリーミングを中心とすることが多い今日のアプリケーションにはあまり適していません。 このようなプロジェクトには通常、ユーザー インターフェイスよりも多くのデータ モデリングと抽出、変換、読み込み (ETL) ワークロードが含まれます。 このため、一貫した厳しいスケジュールで使用可能なソフトウェアをデモンストレーションすることが困難になります。 ただし、目標を調整することで、開発者は引き続きアジャイル アプローチを使用できます。 開発者は、反復ごとにタスクを達成するために働く代わりに、データ実験の実行に集中できます。 実用的な製品を数週間ごとに提示する代わりに、データをより深く理解することを目指すことができます。

なぜアジャイルなのか?

では、なぜアジャイル アプローチを検討するのでしょうか? ソフトウェアの構築に関する関与ルールがここ 10 ～ 15 年で根本的に変化したことは明らかです。 アクティビティの多くは似ていますが、それを適用する風景や環境は著しく異なります。

• 現在のソフトウェアの購入が 2000 年代初頭とどのようなものかを比較してください。 ビジネス ソフトウェアを購入するために、どのくらいの頻度で車で店に行きますか?
• 製品に関する顧客からのフィードバックをどのように収集するかを考えてみましょう。 ソーシャル メディアが登場する前、チームは人々が自分たちのソフトウェアについてどう考えているかをどのように理解していましたか?
• チームが提供するソフトウェアをどのくらいの頻度で更新および改善したいかを検討してください。 毎年の更新は、現代の競争に対抗するにはもはや不可能です。

Forrester の Diego Lo Guidice 氏は、自身のブログ アプリケーション配信の変革 (2020 年 10 月) で最もよく述べています。

「すべてが劇的に変わりました。 持続可能性とは、グリーンでクリーンであることに加えて、今日構築したものを明日は簡単かつ迅速に変更する必要があることを意味します。 戦略計画は短期的なものであり、計画と変更は継続的に行われます。」 — Diego Lo Guidice、Forrester

ルールが変更され、世界中の組織がそれに応じてソフトウェア開発へのアプローチを適応させています。 アジャイルの手法やプラクティスは、すべての問題を解決するとは限りません。 しかし、彼らは、コラボレーション、継続的な計画と学習、そして高品質のソフトウェアをより頻繁に出荷したいという願望を通じてソリューションが生まれる文化と環境を確立することを約束しています。

次のステップ

ソフトウェア開発にアジャイルの道を選択すると、DevOps プロセスを強化するための興味深い機会が得られる可能性があります。 重要な考慮事項の 1 つは、アジャイル開発 が組織の現在のアプローチとどのように比較対照されるかに焦点を当てています。