アジャイルソフトウェア開発宣言から２０年
今日、2021年2月13日はアジャイルソフトウェア開発宣言からちょうど20年になります。Manifesto for Agile Software Development（アジャイルソフトウェア開発宣言）を読み返してみます。
歴史を振り返る： アジャイル宣言
2001年2月11日から13日にかけて、ユタ州のワサッチ山脈にあるスノーバードスキーリゾートのザ・ロッジで、17人の人々が集まり、話をし、スキーをし、リラックスし、共通点を見つけようとした。そこで生まれたのが、アジャイルな「ソフトウェア開発」宣言だった。
History: The Agile Manifesto
アジャイルマニュフェストのホームページには、「マニュフェスト」「アジャイル宣言の背後にある原則」のほかに、「History: The Agile Manifesto」があります。公式に日本語訳がなかったので、マニュフェスト20周年となる今日を記念して、日本語訳とそのまとめをここでご紹介したいと思います。
歴史を振り返る： アジャイル宣言
2001年2月11日から13日にかけて、ユタ州のワサッチ山脈にあるスノーバードスキーリゾートのロッジで、17人の人々が集まり、話をし、スキーをし、リラックスし、共通点を見つけようとした。そこで生まれたのが、アジャイルな「ソフトウェア開発」宣言だった。エクストリームプログラミング、SCRUM、DSDM、適応型ソフトウェア開発（ASD）、Crystal、ユーザー機能駆動開発（FDD）、Pragmatic Programmingなどの代表者が集まり、ドキュメント駆動の重量級ソフトウェア開発プロセスに代わるものの必要性に共感した。
さて、組織的なアナキストのこのような大きな集まりは難しいでしょうから、この会議から出てきたものは象徴的なものでした-アジャイルソフトウェア開発のためのマニフェスト-すべての参加者によって署名されました。アジャイルという言葉に対する唯一の懸念は、マーティン・ファウラー(彼を知らない人のためにいうと、彼はイギリス人)が言い出したもので、彼は、ほとんどのアメリカ人が「アジャイル」という言葉の発音の仕方を知らないと思った。
アリスター・コックバーンの最初の懸念は、多くの参加者の初期の考えを反映していた。"私は個人的には、この特定のグループのアジリティが実質的な何かに同意するとは思っていなかった。" しかし、彼の会議後の感情はまた、共有されていた、 "私自身のために言えば、私は[マニフェストの]最終的なフレーズに喜んでいます。他の人たちも同じように喜んでいるように見えたのには驚きました。私たちは実質的な何かに同意したのですね。
自分たちを「The Agile Alliance」と名づけ、ソフトウェア開発についての独立した思想家のグループであり、ときにはお互いにライバルでもあるこのグループは、このWebサイトのタイトルページに表示されている「アジャイルソフトウェア開発宣言」に合意しました。
しかし、マニフェストにはいくつかの具体的なアイデアが示されていますが、アライアンスのメンバーの多くを、すべてではありませんが、確かに多くの人を突き動かす深いテーマがあります。日間の会議の終わりに、ボブ・マーティンは、今にも「ムズムズした」発言をしようとしていると冗談を言った。しかし、ユーモアを含みながらも、ボブの意見に反対する人はほとんどいませんでした。つまり、私たちは皆、互換性のある一連の価値観、お互いへの信頼と尊敬に基づいた一連の価値観、そして、人、コラボレーション、そして、私たちが働きたいと思うようなタイプの組織コミュニティの構築に基づいた組織モデルを推進している人々のグループと一緒に働くことが特権であると感じていたのです。アジャイルメソドロジストの核心は、「人が最も重要な資産である」という話以上に、あたかも人が最も重要であるかのように実際に「行動」し、「資産」という言葉を失うような環境で運営することで、良い製品を顧客に届けるという、本当に「ムズムズした」ものだと私は思っています。つまり、最終的には、アジャイルメソドロジーへの関心の急上昇と、ときにはアジャイルメソドロジーへの多大な批判は、価値観と文化の塊のようなものに関係しているのです。
例えば、究極的には、エクストリームプログラミングが使用され、関心を集めるようになったのは、ペアプログラミングやリファクタリングのためではなく、全体的に見て、ディルベルテスクな企業のお荷物から解放された開発者コミュニティを定義するプラクティスだからだと私は考えています。ケント・ベック氏は、2人で6週間のプログラミング作業を見積もっていた初期の仕事の話をしています。彼のマネージャーがプロジェクトの最初にもう一人のプログラマーをアサインし直した後、彼は12週間でプロジェクトを完成させたのですが、自分のことをひどく後悔しました。上司はもちろんのこと、2週間目の6週間はどれだけ遅かったかとケントを叱責しました。プログラマーとしての自分の「失敗」に落ち込んでいたKentは、当初の見積もっていた6週間という数字が2人の人間にとっては非常に正確であったこと、そして彼の「失敗」は本当にマネージャーの失敗だったことに気付きました。
この種の状況は毎日のように起こっています。マーケティング、経営陣、外部顧客、内部顧客、そしてそう、開発者でさえも、難しいトレードオフの決定をしたくないので、企業の権力構造の押し付けによって不合理な要求を押し付けています。これは単にソフトウェア開発に限った問題ではなく、ディルベルテスクな組織全体に言えることです。
新しいビジネスで成功し、eビジネス、電子商取引、Webの時代に積極的に移行するためには、企業は、ディルバート*のような「メイド・ワーク」や難解な政策の顕在化から脱却しなければなりません。企業生活の無意味さからのこの自由は、アジャイルメソドロジーの支持者を惹きつけ、伝統的な主義者を脅かす（専門家の論文では「クソ」という言葉を使うことはできない）。率直に言って、アジャイルアプローチは、企業の官僚を怖がらせます。少なくとも、「顧客」のために最善を尽くし、タイムリーで具体的なものを「約束通り」に提供しようとするのではなく、プロセスのためにプロセスを押し進めることに満足している人たちは、隠れる場所がなくなってしまうからです。
アジャイル運動は反メソドロジーではなく、実はメソドロジーという言葉の信憑性を回復させたいと思っている人が多いのです。私たちはバランスを回復したいのです。私たちはモデリングを受け入れますが、ほこりっぽい会社のリポジトリに図をファイルするためではありません。私たちは文書化を受け入れますが、何百ページものメンテナンスされておらず、ほとんど使われていない文書ではありません。私たちは計画を立てますが、激動する環境での計画の限界を認識しています。XPやSCRUMや他のアジャイルメソドロジーの支持者を「ハッカー」としてブランド化する人は、メソドロジーとハッカーという用語の元々の定義の両方に無知である。
スノーバードでの会議は、2000年の春にオレゴン州のローグリバーロッジでケント・ベック氏が主催したエクストリームプログラミングの推進者と数人の「部外者」が集まった初期の会議で生まれました。ローグリバーでの会議では、さまざまな「ライト」な方法論への支持が表明されましたが、 正式なものは何もありませんでした。2000年の間に、「軽量」または「軽量」プロセスのカテゴリーに言及した多くの記事が書かれました。これらの記事の中には、「Extreme Programming、Adaptive Software Development、Crystal、SCRUMなどの軽量な方法論」に言及したものも多くありました。会話の中では、誰も 「軽量」という名前を好んで使う人はいませんでしたが、当分の間はこの名前が定着しているようでした。
2000年9月、シカゴのObject Mentorのボブ・マーティンは、「2001年1月から2月にかけて、シカゴで小規模な（2日間の）カンファレンスを開催したいと思います。この会議の目的は、1つの部屋ですべての軽量メソッドのリーダーを取得することです。あなた方全員が招待されています。ボブはWikiサイトを立ち上げ、議論は激しさを増しました。
初期の頃、アリスター・コックバーンは「軽量」という言葉に対する一般的な不満を明らかにした手紙を残しています。"私は方法論が軽量と呼ばれるのは気にしませんが、軽量な方法論者の会議に出席している軽量と呼ばれたいとは思いません。それは何となく、やせ細った、気の弱い軽量な人々が何の日かを覚えようとしているように聞こえます"
最も熾烈な議論は場所の問題でした。冬のシカゴは寒くて何をするにも楽しいことがない、ユタ州のスノーバードは寒いが、少なくともマーティン・ファウラーが初日に試したように頭の上でスキーをする人にとっては楽しいことがある、カリブ海のアングィラは暖かくて楽しいが、行くのに時間がかかる。しかし、ロン・ジェフリーズのように、次回はもっと暖かい場所に行きたいと言う人もいます。
私たちは、アジャイルアライアンスとして一緒に仕事をすることで、私たちの専門職の他の人たちが、ソフトウェア開発、方法論、組織について、新しい、よりアジャイルな方法で考えるのに役立つことを願っています。そうすれば、私たちは目標を達成したことになります。
ジム・ハイスミス、アジャイルアライアンスのために
（ｃ）2001年 ジム・ハイスミス
*ディルバート(Dilbert)は、米国のコマ割り漫画。 ディルバートという技術者を主人公にした、事務系で、管理的な職場を皮肉ったユーモアで知られている。
アジャイルソフトウェア開発宣言
アジャイルを誤解をせず正しく理解し、成果を出すためには、IPAの「アジャイルソフトウェア開発宣言の読みとき方」がとてもよい入門になると思います。
「アジャイルソフトウェア開発宣言」に対する誤解と真意
「アジャイルソフトウェア開発宣言」のうち、価値について言及している文は「〜よりも」とあることから、一見すると左記のことがら「プロセスや
ツール、ドキュメント、契約、計画」は疎かにしてもよいと解釈されがちです。ここから、アジャイルソフトウェア開発ではドキュメントを作成しなく
てもよいとか、計画は考えなくてもよいなどの誤解が生じることが、よくあります。ですが、見落とされがちな「左記のことがらにも価値があること
を認めながらも」という一文にあるとおり、 「プロセスやツール、ドキュメント、契約、計画」にも価値があることを、明言しています。よってアジャイルソフトウェア開発でも“価値のある”必要なドキュメントは作成しますし、事前に計画を立てて作業を進めていくことは、言うまでもありませ
ん。また開発を効率的に進めるためには、有用なツールを活用することも重要です。
（IPAの「アジャイルソフトウェア開発宣言の読みとき方」）
アジャイル宣言の背後にある原則
アジャイルソフトウェアの12の原則ですが、IPAの「アジャイルソフトウェア開発宣言の読みとき方」が日本でアジャイルを始めるには理解しやすいと思います。１２の原則それぞれの解説スライドが用意されていますので参考にしてみてください。
May the Agile be with you
この記事が気に入ったらサポートをしてみませんか？