アジャイルソフトウェア開発宣言の読み解き方｜アジャイル宣言
「アジャイル」における公式の定義と言われているアジャイルソフトウェア開発宣言を読み解きます。これは4つの価値観で成り立っており、総称として「アジャイル（俊敏型）」と呼ばれています。しかし、名付けの段階では「アダプティブ（適応型）」や「ライトウェイト（軽量級）」などの候補がありました。そして、どれもいまいちだったがその中では最良ということで「アジャイル」が選ばれたようです。つまり、「アジャイル/Agile」という英単語だけで理解しようとするとミスリードすることになります。ちなみに、宣言の中の4つの価値観を何度読み返してみても、私にはアジャイルよりアダプティブの方が合っているように思えます。
※「アジャイル」という言葉が生まれた背景は下記の「Clean Agile（クリーン アジャイル）」に詳しく記載されています。
https://amzn.to/2P9FlNqアジャイルソフトウェア開発宣言の原文
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick
© 2001, 上記の著者たち この宣言は、この注意書きも含めた形で全文を含めることを条件に 自由にコピーしてよい。
アジャイルソフトウェア開発宣言
アジャイル宣言（アジャイルマニフェスト）はいつから
この宣言は2001年に、よりよい開発方法を模索していた「軽量プロセス方法論者」と呼ばれていた17名の有識者が集まって作成して署名した、共通項となる価値観です。この価値観が『アジャイル』と名付けられました。XP（エクストリーム・プログラミング）やScrum（スクラム）の提唱者等のそうそうたるメンバーにて作られており、本宣言による価値観と別記事として後述するアジャイル宣言の背後にある原則にて成り立っています。そして、「共通項となる価値観」と記載している通りに、それぞれの有識者がよりよいと考えている方法論は大規模向けの開発を含めてたくさんあります。その中で最小公約数的な共通項を見つけたら、結果としてこの価値観が残ったということです。この価値観を大事にしつつ、様々な方法論を個々のプロダクトの特性に合わせて適用していくことになります。
「アジャイルソフトウェア開発宣言」はアジャイル開発を始めるにあたって、一番最初に読んで理解したいものです。しかしながら、アジャイル開発をしている人の中でも読んだことがない人、誤った理解をされている人、読んだけどもう忘れた人、などのケースが見受けられます。この本質的なところでつまずかないように、丁寧に読み解いていきたいと思います。きっと、読んだことがある人にも振り返りとなります。
本宣言を読み解くにあたって特に大事なポイントが３つ抜き出します。
- よりよい開発方法を見つけだそうとしている
- 左記のことがらに価値がある
- 右記のことがらにより価値をおく
よりよい開発方法を見つけだそうとしている
アジャイルソフトウェア開発宣言より引用
We are uncovering better ways of developing software by doing it and helping others do it.
Manifesto for Agile Software Development
プロダクト開発において「これをやったら絶対うまくいく」という銀の弾や魔法の杖はありません。「よりよいものを見つけだそうとしている」、というところから「アジャイル開発」というものは進化（改善）し続けなければならないことが分かります。
VUCA時代と言われている通りに、常に社会、ビジネス、システム、人々を取り巻く環境は変わり続けて複雑になっているため、前例にただ習うのではなく、よりよく改善していくことが重要です。
例えば、下記のようなことが「意識、判断、行動」として現場で起きてはいませんでしょうか。
- 前回の開発でうまくいったから同じようにやる
- 隣りのチームでうまくいっているから真似をする
- 前例に沿えば問題ない
- みんなやってるからこうしている
- なぜか分からないが今までやってきたからやっている
- よくないやり方だと感じているが特にアクションを起こさずに続けている
- 正しくないやり方に対して、正しくない、ということに気づいていない
これらはよりよい開発方法を見つけだそうとしていないため、「アジャイル」ではないということになります。二つとして同じプロダクトは存在しません。よく検討した結果として同じやり方をする、というのは問題ありません。むしろ、そういったものをどんどん取り入れていったほうが効率的です。大事なのはその都度ゼロベースで検討し、本当にそのやり方がそのプロダクトに適しているかを見極めて、必要があればカスタマイズして適用することです。そして、適用して終わりではなく、その効果を振り返り、良ければ継続し、改善点があれば調整し、うまくいかなければ止めるという判断を、適切なタイミングでするといったサイクルを反復的に実施することが大事になります。何も考えずに真似して試すのが「アジャイル」ではないのです。
左記のことがらに価値がある
アジャイルソフトウェア開発宣言より引用
we value the items on the left more.
Manifesto for Agile Software Development
「プロセスやツール」「包括的なドキュメント」「契約交渉」「計画に従うこと」に価値があると書かれています。つまり、これらも当然のように必要なもの、価値があるものとと捉えられているということです。軽く考えて良いものではありません。
たまに、「アジャイルはドキュメントを作らなくていい」「アジャイルは計画を立てない」と言う人がいますが大きな間違いです。もちろん、価値を生まないドキュメント（報告のためだけの資料、誰も見ない資料、メンテされずに使われない資料、納品のためだけの資料、等）は作る必要はありませんし、無駄な計画に時間をかけて立てること（結局立てた計画が役に立たない）も必要はありません。また、テスト駆動開発（TDD）を導入し、テストコードを書くことでテスト仕様書作成（およびテストの打鍵）を省略すること等はどんどん進めるべきです。ただ、本当に必要なドキュメントは従来の開発と同様に必要です。例えば、外部システムとの連携が必要な場合は正確なIF（インタフェース）定義書を作りますし、複数画面の開発であれば画面遷移図（サイトマップ）を作ります。外部の人、チームメンバー内、今後新たにプロジェクトに参加される人たちとのコミュニケーションに必要なドキュメントは作る必要があります。経験上、ここは特に誤解の多いポイントです。
また、日進月歩で技術は飛躍的に進化しています。その技術からの価値を享受するために、様々な「プロセスやツール」をウォッチし、必要に応じて取り入れていくことは欠かせないものと捉えています。それを怠ってしまうと世界からどんどん取り残されてしまいます。
右記のことがらにより価値をおく
アジャイルソフトウェア開発宣言より引用
That is, while there is value in the items on the right,
Manifesto for Agile Software Development
この文が端的に「アジャイル」を表しています。
「個人と対話」「動くソフトウェア」「顧客との協調」「変化への対応」により価値をおく、とあります。この言葉をよくご覧ください。何も特別なことがかかれていないことに気づきます。つまり、「アジャイル」は私たちにとって、何も特別ではないのです。
プロセスやツールよりも個人と対話を、
アジャイルソフトウェア開発宣言
Individuals and interactions over processes and tools
Manifesto for Agile Software Development
コミュニケーションの手段としてFace to Faceの対話が最上位であることは疑いようがありません。
今はメールやチャットツール、SNSなどの便利なツールがたくさんあります。それはどんどん活用して構わないのですが（むしろ活用すべきです）、しっかりと認識、目線を合わせるためには対話がどうしても大切になります。
これをおざなりにしてしまうと「認識齟齬」というリスクがどんどん溜まっていきます。例えば、メールを使って部下に重要な指示を出す上司がいるとします。それで部下が動かなかった場合にその部下を叱るケースがありますが、これは上司が仕事をしていない、と捉えています。
メールというコミュニケーション手段は基本的に相手がいつ読むか分からない、読んだとして理解するのか分からない、理解した上で行動するかどうか分からない心許ないものです。よって、メールを送信した時点では正式に仕事の依頼をした、という状態にはなく、ボールは自分が持ったままです。メールの返信があればよいですが、そうではない場合は口頭（対話）や電話等の他のコミュニケーションを使う必要があります。
もっと言いますと、口頭（対話）や電話等の双方向のコミュニケーションをした上で、補足として、エビデンスとして、他の関係者への周知としてメールを使う、という意識の方が良いです。仕事で使用することも多くなっているLINE等のSNSやSlack等のチャットツールも同様です。メッセージを送信して「既読」になったとしても、それを開いたというだけで本当に読んでいるのか、誤解なく理解しているのか分かりません。
仕事は依頼して、相手からの返事があって初めて渡せた、という状態になります。一方で、各種のツールはコミュニケーションのコストが小さいというとても大きなメリットがありますので、ツールの特性を理解して適切に使い分けをしたいものです。
また、書籍によっては「個人との対話を」の部分を「人と人との交流を」を訳しています。私はこちらの方が好きです。優れたプロセスやツールを使う普通の人々より、普通のプロセスやツールを使う優れた人々の方が良い結果を出します。
従来型の開発ではよいプロセスやよいツールを使うことで、誰がやっても一定の品質のものが開発できるようにしたがります。しかし、それでうまくいっているでしょうか。
アジャイルのプロセスは一人ひとりが異なる強みと弱みを持つことを認め、その多様性を活かします。誰でも同じ仕事ができるようにするプロセスと対照的です。
結局は「ひと」なのです。
アジャイル宣言：動くソフトウェア
包括的なドキュメントよりも動くソフトウェアを、
アジャイルソフトウェア開発宣言
Working software over comprehensive documentation
Manifesto for Agile Software Development
最終的にユーザーに届けられて価値を産むのは動くソフトウェアであり、ドキュメントでも社内報告でもありません。
通常、ユーザーとしては目の前で使うソフトウェアに対して価値を感じて対価としてお金を払うのであり、どのような過程でそれらが作られたのか、裏で何が動いているかを意識しません。何のために仕事を、プロダクト開発をしているかを考えれば、動くソフトウェアを開発するための時間が最も大切であるかがお分かりいただけるはずです。
また、どんなに綺麗な進捗報告資料を作って説明をしたとしても、動くソフトウェアより進捗（事実）を正しく伝えることはできないのです。「問題ない」「オンスケ」「できている」という報告を真に受けて、蓋を開けてみたら「全然できていなかった」ということを経験をされたことはありませんか。
アジャイルではドキュメントの代わりに「動くソフトウェア」を定期的に見せます。少なくとも顧客に対して見せ、可能であればユーザーにも見せることで、より質の高いフィードバックを受けます。
そのフィードバックを次に開発するソフトウェアに反映していくことで、ユーザーに価値を提供し、期待に応えることができます。
この「価値の積み上げ」が何よりも進捗を正しく表しています。
アジャイル宣言：顧客との協調
契約交渉よりも顧客との協調を、
アジャイルソフトウェア開発宣言
Customer collaboration over contract negotiation
Manifesto for Agile Software Development
顧客（発注者）とシステム開発者（受注者）の間が契約とドキュメントで大きな隔たりが起きているケースがとても多くあります。
しかしながら、プロダクト開発の目的は共通であるはずです。契約やドキュメント（スコープの定義）が明確にあるため、その範囲内を満たすことだけに注力しがちで、そうすると、そのプロダクト開発で成し遂げたかったことがおざなりになり、システムを開発することが目的化してしまって結果的にうまくいきません。
顧客とシステム開発者が協調し、プロダクト開発の目的に真っ直ぐ進みたいものです。お互いのコミュニケーションが希薄になってしまうと、自分達に不利になることを隠すようになり、あとで表面化して大問題になります。こうなってしまうと互いに疑心暗鬼となり信頼関係も崩壊します。
これではプロダクト開発の成功は叶いませんし、誰も幸せになりません。人生の中で多くの時間を割くことになる仕事というものを、誰もが良いものとしたいはずです。
「協調」という言葉をより具体的に深掘りすると、「チーム」になるということです。
開発者と顧客が共通の目的を持つチームになることで、ユーザーに対してより大きな価値を届けることができるようになります。両者のゴールは同じはずです。
アジャイルチームにおける「開発者」は手を動かしてソフトウェア開発に取り組む人のことを指します。システムエンジニアもプログラマーもデザイナーも役割ではなく開発者となります。もちろん、自己組織化したチームとしては多様なスキルが必要ですが、責任は全て個人ではなくチームが持ちます。
よって、下記のようにチームが起点となるように、意識と行動様式を変える必要があります。
◯：チームの一員として、プログラミングをします。
◯：チームの一員として、デザインをします。
×：プログラマーとして、チームに貢献します。
×：デザイナーとして、チームに貢献します。
例えば、開発するにあたって「ユーザーリサーチ（ニーズの検証）」が最重要課題になっているとしたら、それをUXデザイナーだけに任せるのではなく、プログラマーも担って良いのです。
アジャイル宣言：変化への対応
計画に従うことよりも変化への対応を、
アジャイルソフトウェア開発宣言
Responding to change over following a plan
Manifesto for Agile Software Development
社会もビジネスも常に動いていますので、システム開発当初にロンチ（リリース）時の姿を正確に予測し、それを前提に完璧な要求・要件定義をすることはとても難しいです。
それにも関わらず、当初に結んだ契約の内容、立てた計画通りに開発をしないと納品・検収にいたらないため、無駄だと分かっていてもやらざるを得ないという現状があります。
ウォーターフォールという真っ直ぐに水が流れる開発手法と言っても、往々にして仕様変更が発生するため、完全なウォーターフォールにはなりません。もともと最初に完璧な計画を立てるということに無理があるため必然とも言えます。
それは、計画時には想定できなかったという内側の論理と、ニーズの変化や競合他社の動向などの外側の論理の両方があります。「アジャイル」では変化するということを前向きに受け入れ（むしろチャンスと捉える）、それを前提として変化する社会やビジネスに合わせて、システム開発を柔軟に適応させることがより大事であるという価値観となっています。
もちろん、いつでも「やるべきことはやれることより多い」ため、やるべきことに対して優先順位をつけて新たに追加して作業するものが増えた場合には、結果的に優先順位の低いものをやらないということになります。
人と時間とコストは有限なのです。これを誤解して「アジャイルだからいつでも仕様変更できる」と解釈してしまうと、やれるスコープをオーバーしてデスマーチ真っしぐらとなります。
また、「変化への対応を」の部分を「変化に適応することを」と訳す場合もあります。
こちらの方が変化に追随するイメージが伝わりやすいかと思います。
上記の文を読み「計画を軽視しているのではないか」と誤解されるケースがありますので補足いたいます。
アジャイルも必ず計画を立てます。プロダクト開発の開始当初は情報が少ないため、その情報で可能な範囲で計画を立てます。全体的には曖昧で、直近は具体的でしょう。
その後、開発を進めることで、環境が変化したりし、新たなユーザーのニーズが分かったり、優先順位が高いと思われたものが実はあまり重要ではないということが分かったりします。そのような学習した気づき、現実に合わせて再計画します。それを定期的にするのです。それを「アジャイルな計画づくり」と言います。
アジャイルでは、ある時点のスナップショットである「計画」より、常に「計画をつくっていく」ことを重視します。「計画をつくっていく」ことこそが「変化への適応」となります。
「計画」とは数多ある未来の可能性のうちの、ひとつの見解でしかありません。
※アジャイルな見積りや計画づくりについては下記の本がとってもおすすめです。
https://amzn.to/3vJRolaまとめ
ここまで読んでいただきありがとうございます。いかがでしたでしょうか。
アジャイルソフトウェア開発宣言は平易な文章で書かれているため、さっと読んで分かった気になります。しかしながら、もうお分かりの通りに意外と奥が深いものとなっています。原文は英語となっており、日本語を含む各国の言葉で翻訳されております。翻訳の過程でどうしてもニュアンスが異なってしまいますので、興味がある方は、ぜひ英語の原文を読んでみてください。もしかすると、違う気づきが得られるかもしれません。
もしよろしければ、いつものチームメンバーでそれぞれアジャイルソフトウェア開発宣言を読み、その後集まって、この宣言をどのように解釈し、それを今の開発現場にどう生かすことができるのかをディスカッションしてみてはいかがでしょうか。
ともすると、「アジャイルをする（Do Agile）」「アジャイルになる（Be Agile）」という言葉は、システム開発に限らず、あらゆる業務に適用できるのでは、と思います。
なんとなくで構いませんので「アジャイルって良いものかも」と思っていただけましたら嬉しいです。
あとがき
みなさん、◯◯◯よりも◯◯◯に価値を置く、という表現が日本語の文章として特殊だと思いませんか。
ウォーターフォール開発に代表される従来の開発手法を否定していません。ウォーターフォール対アジャイル、従来開発対新しい開発、というわけではないのです。これまで最重要とされてきた価値観は大事であると認めています。その上で新たな価値観を取り入れていきたいという趣旨です。
新しいことを始めようとすると、それに反発する抵抗勢力が生まれます。逆に言いますと、反発されないものは従来の価値観で理解できるものであるため、新しくはないということです。
反対意見に耳を傾けることでより洗練されていくというメリットはありますが、あまりに反発が強いと前に進まなくなります。そのため、新しいことを始める時には反対意見を持つ方にも寄り添い、理解を示し、敵ではないというスタンスを持ち、協力者になっていただくことを目指す振る舞いが必要です。
何かを変えたいときは「優しさ」が必須です。
内心ではすべてアジャイルにすればいい、と思っていたとしてもそれを前面に全面に出してしまうと前に進むことができません。「アジャイル信者になってはいけない」という言葉はこういったところから生まれていると考えています。
最後に、アジャイルソフトウェア開発宣言を引用するための条件として以下の記載があります。
© 2001, 上記の著者たち
アジャイルソフトウェア開発宣言
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。
これはどういうことかと言いますと、一部分だけ切り出して引用されると誤解を招くからです。
例えば、「包括的なドキュメントより動くソフトウェアを」の部分だけがひとり歩きすると、「ドキュメントは作らなくていい。コーディングさえすればいいんだ。」という解釈がなされてしまう恐れから、上記の引用条件になったのかと思います。
※アジャイルソフトウェア開発宣言は英文が「Manifesto for Agile Software Development」であることから、「アジャイルマニフェスト」とも呼ばれます。
アジャイル （Agile）の原点（トヨタ生産方式）は日本ですが、アジャイル 開発が方法論として確立され、拡大したのは米国発信であるため、アジャイル に関する情報（Webサイト、書籍、SNS等）の圧倒的な量は英語となります。そして、グローバルで多様性の時代は国籍や人種に関係なくONE-Teamになることが当たり前になってきます。
さて、次は原則（アジャイル宣言の背後にある原則（前半）｜本質を読み解く）に進んでいただけますと幸いです。
IPA｜アジャイルソフトウェア開発宣言の読み解き方
IPA（情報処理推進機構）からも、アジャイル宣言に対する読み解き方の資料が公開されています。
考え方や行動規範がたくさん載っているため参考になるでしょう。