アジャイルソフトウェア開発宣言

重要ポイント

• アジャイル マニフェストは、適応性があり顧客重視のソフトウェア開発の価値と原則を概説した基盤となる文書です。

• 厳格なプロセスよりも、個人、動作するソリューション、コラボレーション、変化への対応力を重視しています。

• マニフェストは今でも有効であり、チームが価値と継続的改善を優先するよう導いています。

• アジャイル マニフェストを定期的に見直して、チームのプラクティスをその中核となっている価値観に合わせ、アジリティの文化を育成します。

技術革命の真っただ中にいる私たちは、継続的な革新によって定義される世界に移行しつつある今もなお、アジャイル マニフェストが指針となるかどうか疑問に思っています。この短くも革新的なドキュメントは、船上貨物で製品を発送する世界から、ドローンで即日配送する世界に私たちを導きました。

しかし今日、私たちはパイオニアというよりは、絶え間のない改善の海にいる探検家のようです。そして、そろそろマニフェストも改善すべきなのかという疑問をお持ちのことでしょう。

アジャイル マニフェストの経緯

2001 年初頭、ユタ州スノーバードのワサッチ山脈をバックにして、ソフトウェア開発の将来について議論するために 17 人が集まりました。現状の改善方法について彼らの意見は食い違っていましたが、グループのメンバーは誰もが開発の現状に不満を抱いていました。

問題は、企業がソフトウェア開発サイクルの計画と文書化に集中し過ぎているために、顧客を喜ばせるという、本当に重要なことを見失っていることでした。

企業は「卓越性」や「誠実さ」などの企業価値を宣伝していたかもしれませんが、これらの価値が人々を、特にソフトウェア開発者をより良い方法に導くために役立ったことはほとんどありませんでした。変えなければならないのは、そこだったのです。Snowbird 17 の多くは、ソフトウェア開発の新しい時代を先導する方法についてのアイデアをすでに持っていました。

ワサッチ山脈への旅は、そのようなアイデアを詳細に議論する機会になりました。

この長い週末のおかげで、わずか 68 ワードのアジャイル マニフェストが生まれました。そして、この簡潔で要領を得たドキュメントがソフトウェア開発を永久に変えたのです。作成されてからの 20 年近くで、これらの言葉 (およびそれに続く 12 の原則) は、数え切れないほどの個人、チーム、企業によって (程度の差こそあれ) 受け入れられてきました。

アジャイルマニフェストの 12 の原則: 文化、定義

今日のアジャイルの世界は、アジャイルの理想を現実世界で実現させることを約束する方法論であふれかえっているように見えるかもしれません。しかし、今日見られるような方法論の乱立は、決して新しいものではありません。

マニフェスト自体は、スクラム、エクストリーム プログラミング、クリスタル クリア、その他のフレームワーク間の共通点を見つける必要性から生まれました。

「自分たちが実践しているものに共通項があることに人々は気付き始めていました。しかし当時、彼らは競合する企業同士であり、少なくとも競合他社として意識されていました。」と、Atlassian の DevOps 部門プリンシパル ソリューション エンジニアである Ian Buchanan は述べています。「このような状況を考慮すると、彼らがなにがしかの合意点に達したという事実は、深い意味を持つと言えます。」

Snowbird 17 は、異なる分野の代表者たちが合意できるものがあるかどうかを判断したいと考えていました。そして驚いたことに、彼らは合意したのです。それは文化を定義する一連の価値でした。

それは次のようなものでした。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践あるいは実践の手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値にたどり着いた。

プロセスやツールよりも個人と対話を

包括的なドキュメントよりも動くソフトウェアを

契約交渉よりも顧客との協調を

計画に従うよりも変化への対応を

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

アジャイル ソフトウェアの 12 の原則 (Snowbird サミットの成果) では、価値を構成するいくつかの文章でさらに詳しく説明されています。

それを達成その後、アジャイルマニフェストのサイトに加えられた変更は、仮にあった場合でも、最小限のものです。しかし、アジャイルを取り巻く世界は大きく変わりました。

アジャイルに関する有意義な話し合い

Snowbird 17 は、いくつかのコアとなる原則の下で、異なる視点を統一することに成功しましたが、議論はそこで終わりませんでした。ある意味、そのテーブルに着いた先見の明のある人たちが考えた以上に、アジャイルはより多くの運用方法へと細分化されました。あらゆる人がアジャイルを取り入れたようにも感じられるほどです。

今では、SAFe があり、LeSS があります。マニフェストの冒頭には「ソフトウェア開発の実践あるいは実践の手助けをする活動を通じて、よりよい開発方法を見つけ出そうとしている」と述べられていますが、ソフトウェア開発とは関係のない分野にもアジャイルが応用されています。

さまざまな組織に出向いてアジャイル プラクティスを観察した、Scrum.org の CEO である Dave West 氏は、ウイルスを使用した遺伝的失明の治療法を開発するためにアジャイルを使用する研究チームを挙げています。

事実、アジャイルの導入はソフトウェアの領域外にも普及しましたが、これは、必ずしもマニフェストの創始者が意図したものではありませんでした。

「解釈できないわけではありませんが、アイデアを忠実に翻訳するには、より深い理解が必要です」と、Buchanan は述べています。

そのような深い理解は、ソフトウェア開発の範囲内であっても常にできるとは限りません。

アジャイルコンビナート

「偽のアジャイル」 (別名「ダーク アジャイル」) は、アジャイル教育とコンサルティングの収益化によってさらに悪化すると多くの人が主張しています。この収益化の背後にある組織を「アジャイル コンビナート」と呼んでいる人さえいます。

「正しいことを行い、正しいことを述べているが、基本原則は理解されていないカード カルト アジャイルがありますが、それでは成果は得られないでしょう」と Buchanan は述べています。

アトラシアンのツールがスクラムやカンバンなどのアジャイル フレームワークを活用していることから、アトラシアンが根本原因であると述べている人も少なからずいます。しかし、私たちは、アジャイルは文化的価値であり、チームには各々が最適と考える方法で作業する能力が与えられるべきであるという信念を持っています。アジャイル フレームワークは文化的価値と歩みを揃えることで機能しますが、文化的な素地がなければ、何をやっても最初から使えないものとなってしまうことでしょう。

アジャイルを台無しにするこれらの「フェイク」、「ダーク」、「カーゴ カルト」アジャイルは、たとえ実務担当者が証明書を持っていたとしても、マニフェストの意図を無視して機能する状況 (マイクロマネジメント、燃え尽き症候群に陥るペース、成果の欠如、原則を無視したプロセスの最も悪質とされる順守など) を導くことがよくあります。残念ながら、これらのダーク アジャイルを経験することにより、アジャイルは絶対に使用しないと表明する (または、ダーク アジャイルによる実務経験を反映させてマニフェストを書き換える) 人もいます。

Snowbird 17 の 1 人である Ron Jeffries 氏は、次のような認証を用いて、このような異常事態に対処しようとしています。

「この文章や他の文章では、『アジャイル』とは自称していますが、アジャイル マニフェストに記載されているアジャイル ソフトウェア開発の内容や精神に必ずしも準じていないインスタンス、アプローチ、プロセスの多くを "アジャイル" という単語を使用して表しています。強調するために『フェイク アジャイル』と呼んだり、実際に状況を悪化させた "アジャイル" アプローチを『ダーク アジャイル』と呼んだりすることもあります。『マニフェスト アジャイル』と呼ぶ場合は、マニフェストの核となるアイデアを示しており、私は今でもその価値を信じています」

ときには方向性が誤ってはいるものの、アジャイルが広く採用されていることを考慮すると、アジャイルマニフェストはいまでも参照する価値があるのでしょうか?

マニフェストはいまだに有効か?

ソーシャル メディアでマニフェストについて読むのに費やした膨大な時間は言うまでもなく、何百人ものアトラシアンのお客様、社内外のアジャイル コーチ、愛好家、熱心な実践者と話をした私としては、自信を持って「はい」と答えることができます。マニフェストは今でも、そしておそらくこれまでにないほど重要です。

同僚の上級エンタープライズ アジャイル コーチの Dan Radigan、日々顧客とやり取りしている Ian Buchanan はともに、新しい顧客には定期的にマニフェストについて強調していることを認めています。

LinkedIn のアジャイル コーチ兼上級テクニカル プログラム マネージャーである Tanner Wortham 氏は、マニフェストをよく引用していると述べています。海兵隊で 10 年間過ごした Wortham 氏は、アジャイルの名前を知る前からアジャイルの実践を始めていたと言っています。彼はそれを単に「一流海兵隊員」と呼んでいましたが、Wortham 氏にしてみれば、名付けること自体が取り組みを始めるための大きなステップになっていました。

「名付けるまでは、何をしてよいのかがわかりません。マニフェストの意味はまさにそこにあったのだと思います。マニフェストによって名付けられ、アジャイルと呼ばれるようになりました。何らかのことはすでになされていたのでしょうが、名付けられたことによって、識別しやすくなったのだと思います」

Scrum.org の CEO である West 氏は、アジャイルの原則はまったく新しいものではないと指摘しています。単に異なる方法で適用されているだけであると。

West 氏は次のように述べています。「マニフェストの背後にある理念を見るとわかりますが、これらは私たちが発明したものではありません。これらは科学的方法が持つ理念です。ガリレオやアルキメデスが使用していたものなのです」

おそらく、アジャイルマニフェストの最大の功績は、ソフトウェア開発にこれまで使用されていなかった考え方を成文化したことで、かなりの功績です。

これは何を意味するのでしょうか?

つまり、アジャイルの原則はアジャイル マニフェストより前から存在していました。その原則がソフトウェア開発に適用され、その価値がアジャイル マニフェストに取り込まれたのです。その後、人々はマニフェストの原則を採用し、自分の仕事にそれを適用し始めました。すべてのアイデアがリサイクルされている今、アジャイル マニフェストを更新すべきでしょうか?

必ずしもその必要はありません。

マニフェストと同じくらい文化的な重要性を持つものが現れたのであれば、マニフェストを再解釈できるかもしれませんが、オリジナルに匹敵するようなものはまったく現れていません。そのため、公式に更新しようとするよりも、個人、チーム、組織への適用方法を探す方が得策であると言えます。

Wortham 氏は次のように述べています。「多くの点で、マニフェストが会話の基礎になっています。私はこのように解釈しますが、あなたはどのように解釈しますか?では、仕事のやり方を一緒に考えましょう」

そういった流れで見ると、おそらく重要なのは、誰もが同意できるありがたい文書ではなく、人々のグループ (チームから組織全体まで) がマニフェストのアイデアを、その精神を見失うことなく、特定の状況に適用できるかどうかです。それがうまくいけば、可能性は無限になります。

West 氏はこう続けます。「正しく行えば、世界は驚くべき場所になると思います。がんを解決でき、私の子供たちはおそらく 150 歳から 175 歳まで生きるでしょう。私たちにはそれが可能であるし、また、そうするでしょう」

この記事についてのインサイトと専門知識を共有してくれた、Amanda O'Callaghan 氏、Ian Buchanan、Dan Radigan、David West 氏、Tanner Wortham 氏に深く感謝の意を表します。

アジャイル原則に関するよくある質問

アジャイルの 12 の原則

アジャイルの 12 の原則とは、アジャイル マニフェストの価値を拡張した一連の指針となる概念であり、顧客満足、変化の受け入れ、頻繁なデリバリー、コラボレーション、意欲的なチーム、対面での会話、動作するソフトウェア、持続可能なペース、技術的卓越性、シンプルさ、自己組織化チーム、改善のための定期的な振り返りに焦点を当てています。こうした原則は、チームがより良いソフトウェアを提供して、プロセスを継続的に改善するのに役立ちます。

アジャイルの 12 の原則を覚える方法

アジャイルの 12 の原則を覚えるには、その中核となるテーマに注目しましょう。これには、顧客重視、適応性、頻繁なデリバリー、チームワーク、コミュニケーション、品質、継続的改善があります。類似した原則をグループ化して、ニーモニック デバイスや要約を使用することで、より簡単に思い出せるようになります。

アジャイルの 4 つの価値

アジャイルの 4 つの価値では、プロセスやツールよりも個人や対話を、包括的なドキュメントよりも動作するソフトウェアを、契約交渉よりも顧客とのコラボレーションを、計画の遵守よりも変化への対応を重視しています。これらの価値は、ソフトウェア開発において、人、コラボレーション、適応性を優先します。

アジャイル、スクラム、カンバン、XP の違い

アジャイルはソフトウェア開発における価値観と原則の集合体ですが、一方のスクラム、カンバン、XP (エクストリーム プログラミング) は、アジャイルの原則を実装する具体的なフレームワークです。スクラムは時間制限のあるスプリントと定義された役割を使用し、カンバンは作業の可視化と進行中の作業の制限に焦点を当て、XP は技術的な卓越性と頻繁なリリースを重視します。