アジャイルソフトウェア開発宣言を読み解く
アジャイルプロジェクト管理は、ウォーターフォール手法に代わる人気のある手法として、皆さんも耳にしたことがあるのではないでしょうか。既に、実践されているかもしれません。しかし、多くの専門家も、アジャイル手法の意味するものや生み出された背景、そしてこのムーブメントのきっかけとなったアジャイルソフトウェア開発宣言（アジャイルマニフェスト）についてしっかりと把握できていません。
アジャイルソフトウェア開発宣言は、ソフトウェア開発におけるアジャイル手法の価値と原則を確立したものです。この記事では、アジャイルソフトウェア開発宣言がどのように生み出されて、何を定義しているのかと、企業がアジャイル手法を導入する方法について解説します。
主な内容：
- アジャイルソフトウェア開発宣言とは？
- アジャイルソフトウェア開発宣言の背景
- アジャイルソフトウェア開発宣言の4つの価値
- アジャイルソフトウェア開発宣言の12の原則
- アジャイル手法の妥当性
- アジャイル手法への取り組み方
アジャイルソフトウェア開発宣言とは？
ソフトウェア開発のためのアジャイルマニフェストは、スクラム、エクストリームプログラミング、ユーザー機能駆動開発（FDD）などのフレームワークを統一する概念を宣言したものです。アジャイルソフトウェア開発宣言は、それまで広く使われていたウォーターフォール型のプロジェクト管理手法とは大きく異なっています。
「アジャイルソフトウェア開発宣言（Manifesto for Agile Software Development）」には次のように記述されています
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値にたどり着いた。
- プロセスやツールよりも 個人と対話を、
- 包括的なドキュメントよりも 動くソフトウェアを、
- 契約交渉よりも 顧客との協調を、
- 計画に従うことよりも 変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
アジャイルソリューションは、自己組織化された部門横断的なアジャイルチームが、状況に適した手法を採用することで実現します。しかし、とはいっても、管理者なしで運営できるわけではありません。
管理者は、次のような目的で必要です。
- チームが成功するための環境を整える
- チームメンバーのスキルセットが適切か確認する
- チームが自分たちで問題を解決できないときに指導する
- 必要に応じて、障害を取り除き、外部リソースを確保する
アジャイルソフトウェア開発宣言の背景
アジャイルソフトウェア開発宣言は、ソフトウェア開発者がより優れた、反応の速い作業の進め方を望んでいたことから生まれました。アジャイルソフトウェア開発宣言が生まれる以前、開発者はアジャイル開発に関する新旧の考え方を組み合わせて、作業方法に対する最善の方法を見つけようとしていました。
2001年、米国ユタ州スノーバードに17名の専門家が集まり、ソフトウェア開発の将来について討論しました。17名には、エクストリームプログラミング、スクラム、動的システム開発手法（DSDM）、適応型ソフトウェア開発、Crystal、FDD、プラグマティックプログラミングなどを支持する専門家が含まれており、「文書主導の重厚なソフトウェア開発プロセス」に代わるものを築きました。
その方法論は、次のことに重点を置いています。
- 開発チームとビジネス関係者との密接な協力関係
- ビジネス価値の頻繁な提供
- 緊密で自己組織化されたチーム
- コードの作成、確認、配信をよりスマートに行う方法
会議では、既存のアプローチに共通するものを探し、合意できないものは切り捨てるという方法をとりました。そして、残ったものを成文化して価値観を示すとともに「アジャイルソフトウェア開発」という言葉を生み出しました。
アジャイルアライアンス（Agile Alliance）は、ソフトウェア開発者がアイデアを探求し、経験を共有する場として、2001年末に結成されました。アジャイル手法を最初に採用したのは開発チームですが、その後、他のチーム、特に最初に明確なスコープや要件がないプロジェクト実行チームでも採用されました。
アジャイル手法がより広く採用されるようになると、アジャイルソフトウェア開発をおこなう人々や、コンサルテーション、トレーニング、フレームワーク、ツールなどを通じて開発者を支援する人々のエコシステムが発展しました。
アジャイルソフトウェア開発宣言の4つの価値
アジャイルソフトウェア開発宣言では、次の4つの事柄に価値を置くと述べられています。
1.プロセスやツールよりも個人と対話
開発プロセスを推進し、ビジネスニーズに臨機応変に対応するのは人間であるため、プロセスやツールよりも優先されます。ツール主導で開発を進めると、チームの対応力が低下し、顧客のニーズに応えられなくなります。
2.包括的なドキュメントよりも動くソフトウェア
アジャイルマニフェストでは、プロセスドキュメント作成の重要度が下げられています。従来、これには伝統的に膨大な時間を要し、頻繁にチーム作業を停滞させていました。アジャイルでは、重要ではないことを避けることで、チームが注力するのをプロセスそのものから、プロセスの成果である実際に動くソフトウェアへとシフトします。
3.契約交渉よりも顧客との協調
従来のプロジェクト管理手法では、顧客は作業開始前に製品要件について詳細に交渉し、通常は、プロジェクトの最初と最後にしか関与しません。アジャイル手法では、顧客は開発プロセスを通じて重要な協力者となります。これにより顧客の意見が反映され、顧客のニーズに応えることができます。
4.計画に従うことよりも変化への対応
従来のソフトウェア開発プロセスでは、継続的な適応の手法が組み込まれていないため、変更のための費用が高額になり頭痛の種でした。アジャイル手法では、継続的に評価および調整できる実行可能な最低限の製品をリリースすることに重点を置き、変化を進んで利用します。
アジャイルマニフェストの12原則
アジャイルマニフェストでは、4つの価値に加えて、それらの価値が実際にはどのようなものであるのかと、アジャイルの概念を適用していることを確認するのに役立つ12の原則が示されています。
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します： 顧客は、リリースとリリースの間に長い時間を待つことを望んではいません。顧客に状況を隠すのではなく、機能するソフトウェアを早期に頻繁に提供することが最善です。製品の動作版を頻繁に提出し、フィードバックを集め、必要に応じて変更し、性能を向上させます
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます： 機能要求の変更で進捗が遅れることのないようにし、変化を有利に利用します。アジャイルでは、大規模なアップデートを達成可能な小さなタスクに分割し、それをチーム内で分担します。これにより、変化を進んで利用できるだけでなく、ボトルネックを防ぐこともができます
- 動くソフトウェアを、2～3週間から2～3カ月というできるだけ短い時間間隔でリリースします： 定期的にソフトウェアをリリースすることで、反復サイクルを早め、プロジェクトを継続的に改善することができます。アジャイルチームはスプリントで作業するため、動作するソフトウェアを定期的に提供することは容易です
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません： リーダーは、ビジネス目標と開発の整合性を保つために、チームが取り組んでいることを把握する必要があります。アジャイルは、従来、ビジネスリーダーと開発者の間にあった壁を崩します
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します： アジャイルプロジェクトマネージャーの主な役割は、チームのモチベーションを維持することです。チームメンバーが自信を持って自由に意見を言い合える環境を築くことが、モチベーションを維持し、プロジェクトの品質を向上させる最良の方法です
- 情報を伝える最も効率的で効果的な方法はフェイストゥフェイスで話をすることです： コミュニケーションはアジャイル手法の大きな部分を占めています。メールやインスタントメッセージでのコミュニケーションには心惹かれますが、アジャイルでは、高い効果と効率性を維持するために、対面でのコラボレーションを推奨しています。たとえば、チームが遠隔地で作業している場合は、メールではなくビデオ通話でチャットするのが最良です
- 動くソフトウェアこそが進捗の最も重要な尺度です： アジャイルチームにとって最も重要な問いかけは、「機能するか？」です。機能は他の何よりも重要です
- アジャイルプロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません： アジャイルチームは迅速に作業しますが、そのペースが燃え尽き症候群の原因になってはいけません。チームが疲弊することなく、ソフトウェアを繰り返し提供できるような、一貫したペースであるべきです
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます： 顧客体験を向上させるために、チームにはさまざまなスキルセットが必要です。アジャイルモデルでは、顧客要件に確実に対応するために、チームのスキルを徐々に向上させる必要があります
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です： 開発しすぎてはいけません。ただ目の前のタスクに注力し、現在の課題を解決します
- 最良のアーキテクチャ、要求、設計は、自己組織的なチームから生み出されます： プロジェクトマネージャーがアジャイルチームメンバーを支配してはいけません。チームは、グループとして意思決定力を持つべきです
- チームがもっと効率を高めることができるかを定期的に振り返り、それにもとづいて自分たちのやり方を最適に調整します： 反復はアジャイルソフトウェア開発宣言の大きな部分を占めています。今後のプロジェクトをより優れたものにするために、グループとしてプロセス、スキル、テクニックを振り返ることが重要です
アジャイル手法の妥当性
アジャイルソフトウェア開発宣言がおこなわれて以降、この製品開発アプローチは広く採用され、多くの成功を収めてきました。また、SAFe（Scaled Agile Framework）やLeSS（Large-Scale Scrum）といった大規模なアジャイル開発プロセスも生まれ、アジャイル手法をソフトウェア開発の場から企業内の他の部門に移植するのに役立っています。
Zippiaによると、少なくとも71％の企業が、次のような主要部門において、アジャイル手法を何らかの形で利用しています。
- 研究および開発
- 生産および運用
- カスタマーサービスおよびサポート
- マーケティングおよびコミュニケーション
- 営業
- 人事、財務、総務
アジャイル手法は、生産性に革命をもたらしましたが、そのプロセスは20年以上も前に構築されたものです。アジャイル手法が、今日のソフトウェア開発チームの運営においても妥当性を維持しているかどうか疑問に思う人もいるかもしれません。
アジャイル手法は今でも妥当性を維持していますが、万能の手法が存在するわけではありません。アジャイル手法は、チームが最善の仕事を成し遂げるためのフレームワークを提供する貴重な情報源です。それは、業務に対する考え方の問題であり、独断的で杓子定規な管理方法ではありません。
チームに自主性を認めず、アジャイル手法を押し付けることはできません。また、生産性や品質の課題に対する対抗策であると考えるべきではありません。結局のところ、アジャイル手法は価値あるものですが、その適用には微妙な差異や状況に合わせたカスタマイズが必要であることを理解することが重要です。
アジャイル手法への取り組み方
アジャイルソフトウェア開発宣言は、それまでのソフトウェア開発を変えました。既に新しい方法論ではありませんが、アジャイルの概念は2001年当時と同様に今日でも重要です。しかし、企業がアジャイル手法から最大の価値を得るためには、そのアプローチを自社独自の状況に合わせてカスタマイズする必要があります。
アジャイル手法に取り組む際は、次のことを検討する必要があります。
- アジャイルチーム： アジャイルチームのメンバーをリストアップして、真に機能横断的なワークグループを形成します
- アジャイル手法： チームのキックオフの際に、スクラムとカンバンのどちらかを選びます
- スプリントサイクル： スクラムを利用する場合、イテレーション完了期間を決めます
- チームキャパシティ： スプリント期間中にチームが現実的に完了できる作業量を決めます
アジャイル手法に関心があるようであれば、アジャイル手法が開発チームにどのような利点をもたらすかをご確認ください。
ゼロから始める必要はありません。アドビがお手伝いします。Adobe Workfrontは、チームが共同作業によりプロジェクトで最善の成果を達成できるように支援する作業管理ソリューションです。組織全体の人、データ、プロセス、テクノロジーをつなぎ合わせ、チームのアジャイルな取り組みをサポートします。
Adobe Workfrontの詳細は、製品ツアーまたは概要動画でご確認ください。