この連載は、登場して20年が過ぎ、成熟期を迎えつつある「アジャイル開発」を解説します。アジャイル開発については、世の中にたくさんの書籍や情報があふれていますが、アジャイルコーチとして10年以上の現場経験をもとに、あらためて学び直したい情報を中心にまとめていきます。
第2回目のテーマは、「アジャイルマニフェスト」です。
この内容はUdemyで公開しているオンラインコース「現役アジャイルコーチが教える！半日で理解できるアジャイル開発とスクラム 入門編」の内容を元にしています。
- アジャイルマニフェスト
- アジャイルソフトウェアの12の原則
- 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します
- 2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます
- 3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします
- 4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません
- 5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します
- 6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです
- 7. 動くソフトウェアこそが進捗の最も重要な尺度です
- 8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません
- 9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
- 10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- 12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
- アジャイルマニフェスト、12の原則の意味
アジャイルマニフェスト
アジャイルマニフェストは、わずか10行のWebページです。アジャイル開発やそれに関連するプロセスを学んだり、実践していくと、マニフェストの内容をたびたびふりかえるケースが増えます。それぐらいアジャイル開発の本質をついた内容になっています。特に重要とされる部分は、2段落目にある4つの価値観です。これを読みやすく書き直すと以下になります。
プロセスやツールよりも個人と対話に価値をおきましょう。
包括的なドキュメントよりも動くソフトウェアに価値をおきましょう。
契約交渉よりも顧客との協調に価値をおきましょう。
計画に従うことよりも変化への対応に価値をおきましょう。
よく「アジャイル開発はドキュメントを重要視しない」と解釈している人がいますが、それは間違いです。ここで伝えたいことは、上記文章の通り、「〜よりも〜に価値をおきましょう」なので、どっちも重要。ただし、しいていうなら後者に価値をおいていきましょうということになります。
次に、太字の部分を抜き出してみましょう。
- 個人との対話
- 動くソフトウェア
- 顧客との協調
- 変化への対応
アジャイル開発に取り組んでいく場合、ふりかえりなどのタイミングでこの4点に価値をおけているか？を確認するといいでしょう。そうすることで、アジャイル開発が向かおうとしている方向を確認するコンパスのように使えるはずです。
アジャイルソフトウェアの12の原則
アジャイルマニフェストの4つの価値の下には、『アジャイルソフトウェアの12の原則』と書かれたリンクがあります。アジャイルマニフェストは4つの価値が目立ちますが、このアジャイルソフトウェアの12の原則も重要な内容になっています。
4つの価値は、17人の開発方法論者が合意できた価値観でしかありませんが、原則は、価値よりも具体的な内容が書かれているため、指針になります。では、その内容を見ていきましょう。
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します
アジャイルチームは価値の最大化を常に考えています。さらに、顧客満足を優先した意思決定を行っていきます。
なにか判断が必要なときに、顧客満足を最優先にできているか？ アジャイルコーチであれば、価値あるソフトウェアを早く継続的に提供できているか？ チームに問いかけていきます。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます
4つ目の価値である「変化への対応」に紐付いた原則です。アジャイル開発は変化への対応を重視した方法なので、変化に弱くなっている場合は、自分たちのやり方を根本的に見直さなければなりません。
とはいえ、何でも変化に対応できるわけではありません。開発の後期で変化を受け入れるなら、それに伴い再計画が必要になったりします。何かを受け入れるなら、何かを捨てなければならなくなるというシンプルな考え方です。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします
「開発の速さ」に関する原則です。アジャイル開発は長期的な開発なのですが、小さく期間を区切って、リリースを繰り返しながら積み上げていく開発になります。
もし、仕事を小さくするのが難しい場合は、アジャイル開発に適したシステムではないかもしれません。アジャイル開発に取り組む前に、リアーキテクチャのような仕事を小さくする方法を検討するといいかもしれません。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません
アジャイルチームを組成する場合、もっとも難易度が高いのがこの原則かもしれません。とくにビジネスと開発が組織的に分かれている場合は、なかなか対策を打ちにくい部分でもあります。
ただ、ビジネスでも開発でも、同じゴールを目指すのであれば、この原則はなんとか実現したいものです。はじめは難しくとも、
- まずはMTG時間を使ってコミュニケーションの場を作る
- 開発チームのにビジネスの出張席を作る（もしくはその逆）
- 同じ場所で働く
- 専用の部屋で働く・・・
と徐々にやれることをやっていく形にするといいと思います。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します
よく、「アジャイル開発は優秀な人じゃないとできないのではないか？」と質問されますが、自分なら「意欲に満ちた人が必要」と答えます。
もちろん優秀な人に集まって欲しいとは思いますが、必須条件ではないと考えているからです。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです
4つの価値にある「個人との対話」に紐づく原則です。
最近はオンラインでの仕事が広まり、ツールも便利になったので、オンラインのコミュニケーションがやりやすくなってきました。少し前、筆者は久しぶりにオフラインでMTGをやったのですが、オンラインと比べて、ダントツにコミュニケーションが取りやすく感じました。
いくらツールが発達したとしても、そのツールをうまく活用したとしても、オフラインのコミュニケーションにまさるものはないのかもしれません。
7. 動くソフトウェアこそが進捗の最も重要な尺度です
4つの価値にある「動くソフトウェア」に紐づく原則です。アジャイルチームの成果は、動くソフトウェアで測られます。
整備されたドキュメントやテスト結果をまとめたレポートも重要ですが、動くソフトウェアほどシンプルに成果を確認できる手段はありません。
8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません
この文のポイントは、「持続可能な開発」です。つまり、アジャイルチームはムリ・ムダ・ムラを避けていかなければなりません。
そうしなければ、どこかでムリがたたり、持続可能な開発ができなくなるでしょう。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
読み取るのが難しい文章です。原文をDeepLで訳してみましょう。
Continuous attention to technical excellence and good design enhances agility.
優れた技術と優れたデザインへの継続的な配慮が、アジリティを高めています。
アジャイル開発はすばやく開発する方法ではありますが、技術やデザイン（設計）を放置しているわけではありません。優れた技術やツールがアジリティ（俊敏性）を生み出すのは当然ですし、よい設計もアジリティを上げるために必要な要素になります。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
これはトヨタの考え方が現れた原則です。スクラムを見ると、まさにこの原則に従っているように感じます。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
この原則も読み取りにくい内容です。そういうときは原文をDeepLに通してみましょう。
The best architectures, requirements, and designs emerge from self-organizing teams.
最適なアーキテクチャ、要件、設計 は、自己組織化したチームから生まれる。
興味深いのは、アーキテクチャを考えるのは「だれか」ではなく、「チーム」であることだと思います。チームを重要視するアジャイル開発らしい原則です。
日本語では「生まれる」となっていますが、原文はemerge （【自動】 表面に出てくる、現れる、出現する、浮かび出る）なので、ベストなアーキテクチャはチームから自然に生まれてくる・・・というニュアンスになります。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
最後はふりかえりの重要性です。「アジャイル開発ができない場合でも、ふりかえりは絶対やったほうがいい」と思います。
アジャイルマニフェスト、12の原則の意味
以上が、アジャイルマニフェスト、アジャイルソフトウェアの12の原則の解説です。
4つの価値については、若干ふんわりした表現になっていますが、原則を一緒に読み解いていくと、具体的にどうあるべきかが見えてきます。
世の中にはたくさんのアジャイル開発にまつわる本や記事がありますが、それらが行き着く先はアジャイルマニフェストや12の原則です（この記事もそうだと思います）。
アジャイルに正しさを求めると、原理主義的になり弊害が生まれやすいのですが、アジャイルチームの人であれば、自分たちの現状を、価値や原則に照らしあわせることで、自分たちの現在位置や、理想の状態がわかるようになるはずです。
連載一覧
第1回：アジャイル開発の過去、現在、未来を知ろう！
第2回：声に出して読みたいアジャイルマニフェスト
第3回：従来型開発とアジャイル開発の違い その１
第4回：従来型開発とアジャイル開発の違い その２
第5回：アジャイル開発のよくある誤解を解いていこう！
第6回：世界中で大人気の秘密に迫る！スクラムを使ったソフトウェア開発
第7回：わかるようでわかりにくいスクラムチームの責任
第8回：スクラムイベントの実践方法
第9回：エクストリーム・プログラミングとその価値
第10回：エクストリーム・プログラミングの原則と基礎プラクティス
第11回：エクストリーム・プログラミングの応用プラクティス
第12回：リーンソフトウェア開発
第13回：ソフトウェア開発における「かんばん」
第14回：さまざまな方法論 − リーンスタートアップ・DevOps
