アジャイルソフトウェア開発宣言を読み解く
アジャイルを実践している人なら、1度は読んだことがある「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」。有名である一方で、そこに込められた想い、考え方や行動規範は20年経っていても、まだ正しく伝わっていません。
昨年、出版された『Clean Agile ー基本に立ち戻れ』をきっかけに、「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」の解説をまとめました。
アジャイルソフトウェア開発宣言 - 4つの価値
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも、個人との対話を
包括的なドキュメントよりも、動くソフトウェアを
契約交渉よりも、顧客との協調を
計画に従うことよりも、変化への対応を
価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
出典: https://agilemanifesto.org/iso/ja/manifesto.html
この4つの価値はアジャイルのマインドセットを表しています。難しい判断を求められるときや、普段の無意識の価値基準として、左記のことがらよりも右記のことがらを優先します。つまり価値の源泉は、右記のことがらにあると考えます。
多くの人が誤解していますが「プロセスやツール、ドキュメント、契約、計画」を疎かにしてもよいとは言ってません。最後にはっきりと「左記のことがらに価値がある」と明言しています。重要なのは「個人との対話、動くソフトウェア、顧客との協調、変化への対応」を阻害しない範囲で、「プロセスやツール、ドキュメント、契約、計画」を活用することです。
「自分たちはアジャイルなのか？」を確かめるには、まず何を優先し、何を価値基準にしているかを振り返りましょう。
1. プロセスやツールよりも、個人との対話を
価値のあるソフトウェアは、優れたチームから生まれます。よりよいチームを作るのは、メンバーの相互理解、個人との対話です。様々な課題を乗り越えるのは、チームです。
プロセスやツールは、あくまでもチームを支援するものです。プロセスやツールがチームを作るわけではありません。個人との対話の機会を奪ってしまうようなプロセスやツールの導入には慎重になりましょう。
2. 包括的なドキュメントよりも、動くソフトウェアを
顧客が最終的に欲しいものは動くソフトウェアであり、私たちは動くソフトウェアを評価しつづけることで、よりよいソフトウェアを作り上げます。また動くソフトウェアは、多くの仮説検証を可能にし、常にソフトウェアを価値のある状態にします。
包括的なドキュメントは成果ではなく、あくまでもツールです。ツールは成果を支援するものであり、よりよい成果を生み出す手段の1つです。ツールではなく成果に対してコストをかけ、ツールではなく成果を評価します。
3. 契約交渉よりも、顧客との協調を
お互いの立場を越境して協働することでWin-Winの関係を目指します。特にビジネス部門と開発部門の分断を防ぎ、よりよいソフトウェアを生み出すために最善を尽くします。
限られたコストを契約交渉に費やす必要がないように、お互いに協調し、よりよいソフトウェアを作ることに専念しましょう。
4. 計画に従うことよりも、変化への対応を
変化は、計画を狂わす脅威ではなく、ソフトウェアを価値のある状態にする機会です。価値のあるソフトウェアとは、事前に計画されたものではなく、最新の顧客ニーズやビジネス市場を反映されたものです。
ソフトウェアは変化に対応できるからこそ、"ソフト"なウェアです。ハードウェアとは違い、常に価値のある状態を維持する機会が与えられています。私たちはその機会を逃さず、よりよいソフトウェアを作り上げます。
アジャイル宣言の背後にある原則 - 12の原則
私たちは以下の原則に従う:
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
出典: https://agilemanifesto.org/iso/ja/principles.html
この12の原則は、アジャイルソフトウェア開発宣言の4つの価値を実現するために、従うことが望ましい原則、基本姿勢を示しています。
アジャイルな状態になるには、常に自分たちに合った方法を試す必要があり、そのたびに12の原則に立ち返ることが重要です。
失敗も成功も経験として捉えて、12の原則や4つの価値を体現しているかを振り返り、短いサイクルで改善を繰り返すのがアジャイルへの道です。
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
私たちの最も重要な活動は、顧客のビジネスを成功させ、満足させることです。そのためには価値のあるソフトウェアを素早く、継続的に提供します。
開発のトレードオフと言われるQCDは、重要な指標ですが、目的ではありません。ビジネスのゴールを明確にし、ビルドトラップを避けて、顧客価値とビジネス価値を実現することが大切です。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
ソフトウェアは変化に対応できるからこそ、"ソフト"なウェアです。ハードウェアとは違い、常に価値のある状態を維持する機会が与えられています。私たちはその機会を常に歓迎し、新しい価値を提供します。
一方で、これはすべての変更を受け入れるものではありません。ビジネス部門と開発部門は、変更がソフトウェアの価値を高めるかどうかを見極める活動を行い、必要な変更を判断します。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
私たちは、要求が不確実であり変化することを前提にしています。この変化の機会を捉えるには、動くソフトウェアが必要です。したがって、動くソフトウェアを短いサイクルでリリースすることで、仮説検証を可能にし、フィードバックを受け取ります。
また動くソフトウェアとは、中間成果物ではなく、ビジネス観点で評価できるものを指します。価値のあるソフトウェアかどうかを判断できるレベルでリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
私たちは、ビジネス部門と開発部門の分断を防ぎます。ビジネス部門と開発部門は、要求や都合を押し付け合う敵ではなく、共通の目標に対して活動するチームです。
不確実性の高い活動では、状況が刻々と変化するため、密な連携が求められます。したがって、関係者全員が一緒の場所で働くことを目指し、常にビジネスを成功に導くための目標と課題を共有します。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
顧客の価値創造のために、自らが考え、自らの行動と判断に責任を持つ、意欲的で前向きな人々でチームをつくります。ステークホルダーは、チームを信頼し、マイクロマネジメントを避け、自律的な行動を促します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
お互いの本音をフェイス・トゥ・フェイスで、直接対話することを大切にします。ドキュメント等を通した一方通行のコミュニケーションは避け、対面での双方向コミュニケーションを推進します。
目的、希望、不安など、正確に言葉で表現しにくく齟齬や誤解を生みやすい情報は、表情や雰囲気を通して伝えます。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
私たちの最も重要な活動は、顧客のビジネスを成功させ、満足させることです。その進捗を測るモノサシは、動くソフトウェアが最も重要です。ドキュメントの完成度や各種指標などで進捗を測ることは、ビルドトラップに陥る危険性があります。
動くソフトウェアを短いサイクルでリリースすることで、進捗を素早く把握します。また短サイクルで評価するために小さな受け入れ基準を用意します。
8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
無理のない一定の開発ペースを保ちます。チームは心身ともに余裕を持つことで、常に変更を受け入れること、創意工夫すること、改善活動をすることを可能にします。
また一定のペースを維持することで、未来を予測をするための信頼できるデータを提供します。小さく均一化されたタスクと一定のペースにより、優先順位付けを現実味のあるものにします。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
常に最新の技術を学び、ソフトウェアに適用します。品質とスピードがトレードオフではなく、比例関係であることを認めます。
ソースコードの状態を目視とツールによって、常に診断し、容易に変更可能で可読性の高い状態を維持します。ステークホルダーは、優れた技術と品質を推奨し、その結果としてスピードやアジリティを獲得します。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
シンプルさを維持することが、生産性を高めます。顧客のビジネスを成功させ、満足させることを忘れず、成果につながる活動にコストを投じます。
チームは価値を生まない活動をやめる勇気を持ちます。日々の活動の中から、顧客に価値をもたらさないプロセスやツール、ドキュメントや中間成果物、会議や報告を減らします。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
価値のあるソフトウェアは、優れたチームから生まれます。優れたチームは自分たちで規律やルールを決めます。また自ら率先して活動の改善や課題の解決に取り組みます。
チームの不得意な分野や領域は、たとえ自分がが不得意でもチャレンジして取り組み、チームのパフォーマンスを向上させます。互いに助け合い、不測の事態でもすぐにフォローしあえる状態を作ります。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
チームの状態を把握し、チームが成長し続けるために、定期的に振り返ります。私たちを取り巻く環境が変化を続ける限り、自分たちの活動を調整し続ける必要があります。
課題は、個人が所有し責任を負うものでありません。全ての問題はチームの責任であり、全員が問題の一部であることを認識し、チームで立ち向かいます。
参考文献
参考書籍
最後まで読んでいただき、ありがとうございました。もらったサポートは次の書籍代にあてます！