1. はじめに
新しいプロジェクトチームでスクラムを採用することになったため、スクラムを基礎から学んでみることにしました。
まずはスクラムの前にアジャイルについてまとめていきます。
2. そもそもアジャイルとは？
アジャイルとは概念・考え方です。
「アジャイル開発」という具体的な開発手法がある訳ではなく、「スクラム」や「XP（eXtream Programming）」などの開発手法を総称した考え方として「アジャイル開発」と呼ばれることが多いです。
つまり、「アジャイル開発」と一口に言っても、その実体はスクラムだったりXPだったりと状況によってさまざまかと思います。
「アジャイル」という言葉はそれ自体が具体的な開発手法だと思われていたり、言葉の解釈が人によって多少異なることが多いように思います。
このようなことが起きるのは、そもそものアジャイルの成り立ちが関係しているかもしれません。
3. アジャイルの成り立ち
参考書籍『正しいものを正しくつくる』ではアジャイルがどのようにして生まれたのかが紹介されていました。
ざっくりまとめると以下の通りです。
- もともとはXP、適応型ソフトウェア開発（ASD）、スクラム、DSDM、FDDなど先人たちによって考案された手法が先にあった
- こうした先人たち17人が2001年ユタ州に集まり会議を開いた
- そこでそれぞれの考え方や手法について、共通点や相違点について話した
- その結果、変化に対応することの必要性、重視する4つの価値、それらの価値を具現化するための12の原則について同意した
- この会議でお互いが同意した方向性に「アジャイル」という言葉が選択された
この会議では「変化への対応」「4つの価値」「12の原則」に同意した他、「不同意の同意」というものがあったそうです。
不同意の同意
プロダクトづくりを行うための詳細なやり方はそれぞれで異なっていて同意できないということを同意しました。
XPにはXPのやり方があり、スクラムにはスクラムのやり方があり、それらを具体的なやり方のレベルで統一しようとはしなかったということです。
あくまでそれぞれの開発手法における考え方や大切にするポイントを抽出するに留めることで、アジャイルには多様な進化を期待していたのかもしれません。
4. アジャイルソフトウェア開発宣言
上記の会議を経て作成されたのが『アジャイルソフトウェア開発宣言』です。
ここではアジャイル開発における「4つの価値」が記載されています。
（アジャイルソフトウェア開発宣言の全文を引用）
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
※ この宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。
左のことを蔑ろにするというものではなく、これらの価値も認めた上でアジャイル開発においてはより右のことを大切にしています。
プロセスやツールより個人と対話
良いプロダクトを開発するためにより良い開発プロセスや便利なツールを探すのはもちろん良いことだと思います。
しかし、開発プロセスやツールに銀の弾丸は存在しません。
だからこそ、プロセスやツールに踊らされるのではなく、環境やチーム状況に応じてお互いにコミュニーケーションを取りながら開発を進めていきましょうね、ということなんだと思います。
包括的なドキュメントより動くソフトウェア
網羅的なドキュメントを作ることよりも動作するソフトウェアが作られることを重視しています。
プロダクトづくりの進捗を測ったり、状況を判断する材料となるのは動くソフトウェアであり、ドキュメントだけで全てを判断するのは難しいです。
ただし、「アジャイル = ドキュメントを書かない」ということではありません。
ドキュメントはコミュニケーションの補助として使ったり、事実を記録したりと必要に応じて作ります。
契約交渉より顧客との協調
プロダクト開発はお金も時間もかかります。
だからこそ相手より優位に立てるよう契約交渉に力を入れるということもわからなくはないです。
しかし、交渉に時間やパワーを使うくらいなら、互いに協調してより良いプロダクトをつくりましょうということなんだと思います。
「より良いプロダクトをつくる」という共通の目的のもと、ステークホルダーが協調して開発を進められたら良いですよね。
計画に従うことより変化への対応
事前に決めた計画の通りに物事が進むことは滅多にありません。
たいていの場合、計画と違うことが起こります。
そんな時に「でも計画ではこう決まっているから...」と無理やり計画に合わせようとしてもどこかで無理が生じます。
だからこそ、計画には不確定要素が含まれることを理解して、計画と違うことが起きた時にその変化に対応できるだけの柔軟性を持つことが大切です。
5. アジャイル宣言の背後にある原則
『アジャイルソフトウェア開発宣言』の中に『アジャイル宣言の背後にある原則』へのリンクがあります。
ここではアジャイルの「12の原則」がまとめられています。
（アジャイル宣言の背後にある原則の全文を引用）
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、
それに基づいて自分たちのやり方を最適に調整します。
6. おわりに
今回アジャイルについていろいろ調べてみて、思ったよりも自分の理解が曖昧だったと気づきました。
アジャイルが大切にする「4つの価値」や「12の原則」は定期的に読み返したいと思います。
最後に改めて「アジャイルとは？」という問いを考えてみると、
- 全員が協調して
- より良いプロダクトを作るために
- できるだけ短い期間を繰り返しながら
- 振り返りと改善を続けていく
という開発における考え方のことである、というのがしっくりきます。
以上です。
最後まで読んでいただきありがとうございました。