アジャイルソフトウェア開発宣言について
アジャイルソフトウェア開発宣言とは
こんにちは。ライトパスの建守です。
アジャイル開発をおススメする弊社にとって、「アジャイルソフトウェア開発宣言」は避けて通れない話題。
耳タコだよ、とおっしゃる方も多いかもしれませんが、どうぞお付き合いください。
「アジャイルソフトウェア開発宣言」（長いので、以下「アジャイル宣言」と略します）は、アジャイル開発手法を採用して開発する人たちが持つべき価値観をまとめたものです。
公式日本語訳を抜粋すると、
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
大事にします、ということになります。
一口に「アジャイル開発手法」といっても、そこにはいくつもの方法論が存在します。有名どころでは「スクラム」や「XP（eXtreme Programming）」、歴史の古さでいえば「Ctystal」や「FDD（Feature Driven Development）」、日本人になじみの深い名前でいえば「Kanban」などもその一つです。
これらの開発方法論は、その適用領域や推奨するプラクティス（こういうことをやりなさいね、というお勧め）に違いがあります。ですが、「自分たちのやり方はアジャイルである」と言うからには絶対に忘れてはいけないこと、それが「アジャイル宣言」で謳われている価値観なのです。
以下、それぞれの価値について詳しく見ていきます。
プロセルやツールよりも個人と対話を
偉そうなことを言えば、この日本語訳はちょっと誤解を招くのでは？と思っています。後半部分を「個人と対話すること」と読んじゃいませんかね？（私だけですか、そうですか・・・）
原文では「Individuals and interactions over processes and tools」となっているので、「プロセス」や「ツール」よりは「関係者個々人」と彼らとの「意思の疎通」のほうがより大事、というのが宣言を書いた人たちの意図するところだと思います。
従来のシステム開発プロジェクト、特に大規模なプロジェクトでは、製造業や建築業由来の作業プロセスを適用し、効率化のためと称して扱いにくいツールの使用を定めて運営するのが基本でした。
ですが、これが行き過ぎた結果、とにかく決められたプロセスに従わなきゃダメ、このツールを使わなきゃダメ、と硬直化したプロジェクト運営になり、無理・無駄は必要悪とばかりに容認される結果となり、それがやがて費用の増大とプロジェクトの長期化、関係者のやる気の低下へとつながっていきました。
ここに切り込んだのがアジャイル開発手法の提唱者たち。プロセスやツールありきじゃなく、まずはそれぞれの関係者の意思や感情、スキルを尊重し、関係者間でのコミュニケーションを密にすることがプロジェクトの成功につながるはずだ、ということをアジャイル宣言の最初に盛り込みました。
包括的なドキュメントよりも動くソフトウェアを
「包括的」ってお役所言葉というか、あまり自分では使わない言葉なので、これまた理解の難しい文章に感じます（私だけですよね、そうですよね・・・）
原文では「Working software over comprehensive documentation」となっています。「comprehensive」も私の語彙にはなかったので、いずれにしてもわかりにくい（泣）
「包括的」「comprehensive」というと、「すべてをひっくるめた」「総合的な」という感じの意味になります。要は、納品に必要だからという理由で作るフルセットの文書よりも、実際に使ってみることのできるソフトウェアのほうが大事だ、という意思を示した文章なのです。
アジャイル開発手法では、とかく「顧客にとっての価値」が問われます。システム開発プロジェクトは、狭い意味ではシステムを開発し稼働させることを目的としています。しかしその背後には、そのシステムがプロジェクトオーナー（発注企業、部署）のビジネスに何らかの価値をもたらすであろうという期待があります。この期待に応えること、ビジネス上の価値を生み出すことを最優先して考えた場合に、プロセス上で定義されているからという理由で作る文書に意味があるでしょうか？
ビジネスに価値をもたらすのはあくまで最重要成果物であるソフトウェアであってドキュメントではない、このことを忘れて無価値なドキュメント作成に没頭するようなことはしない、という決意表明が、この2つ目の宣言です。
契約交渉よりも顧客との協調を
ここにきてようやく、私にもすんなり理解できる分かりやすい訳文になりました（笑）。原文もシンプルに、「Customer collaboration over contract negotiation」となっています。
従来の開発手法（ウォーターフォールをはじめとした重量級の開発手法）では、発注者側と開発者側との間で「請負契約」を結ぶことがほとんどでした。請負契約とは、受託者側が契約で定められた期間内に定められた作業を完成させて納品し、それに対して発注者側が定められた費用を支払う、というものです。
一つのシステムを完成させるためには、長い時間を要します。小さなシステムでも数か月、場合によっては数年かけて構築することもあります。開発者側が数か月～数年かけて作った「包括的なドキュメント」と「動くソフトウェア」が当初のお約束（契約）どおりになっているかを確認し、OKだったらお金を支払う、というのがおおよその流れです。
では、数か月～数年のプロジェクトの期間中に、システムに求められるものが変わってしまったらどうなるでしょう？例えば、法改正があって必要な機能が増えた、社内の組織変更があって機能要件が変化した、新しいアイデアが出てきたので採用したい、などなど。
従来の開発手法は変化を嫌がります。請負契約なので、変化を拒む大義名分もあります（契約書にはそんなこと書いてないから対応できません、と言える）。でも、発注側としてはどうしても仕様を変えたい、となれば、契約交渉です。影響範囲を詳細に分析し、変更の受け入れが可能だと判断されれば、契約変更をおこないます。システム開発プロジェクトにおいてはQCD＋S（品質、コスト、納期＋スコープ）がトレードオフの関係にあります。変更要求がスコープ（機能要求）の追加であれば、ほかの要素（主にはコストと納期）の変更も併せて協議されます。
しかしこの流れ、とっても無駄ではないでしょうか。アジャイル開発では「顧客にとっての価値」を常に最優先事項として考えます。仕様の変更が顧客にとっての価値の増大につながることを発注者側がきちんと説明し、開発者側が納得できたのなら、やるのやらないのという交渉に時間を費やす前に、さっさと対応しましょうよ、というのが、アジャイル宣言の3つ目で述べられている内容です。
計画に従うことよりも変化への対応を
最後のこれがもっともアジャイル的な価値感だな、と個人的には感じています。原文では「Responding to change over following a plan」となっている部分です。
従来の開発手法は「計画駆動型」です。プロジェクトの初期に計画を立て、その計画に従って粛々と作業を進めていきます。プロジェクト管理の要は「計画と実績の差異の把握と、それに対する対応」に尽きるといえるでしょう。プロジェクト管理のベストプラクティス集である「PMBOK（Project Management Body Of Knowledge）」においても、あらゆる領域においてこの点が強調されています（計画立案 → 実行 → 監視・コントロールが基本の流れ）。
しかし、この「計画」は守るべき価値のあるものでしょうか？プロジェクトの初期段階に立てる計画は、多くの仮説に基づいています。仮説が間違えていれば計画も間違えているわけですが、計画は守るべきもの、計画と実績との差はなくすべきものと考えていると、仮説の誤りがわかったときであっても、まずは計画通りに進められないかを検討してしまいがちです。本来なら計画を変更すべきなのに。
アジャイル開発においては、当初の計画に固執することなく、状況の変化に応じて計画も適宜変えていきます、ということを宣言しているのがこの4つ目の部分です。
さいごに
ひとつ勘違いしてはいけないのが、「△△よりも◇◇」というアジャイル宣言の文章は、「△△」を否定するものではない、ということです。アジャイル開発をするときでも、決められたプロセスに従って作業をしたり、何らかののツールを導入したりします。ドキュメントだって作るし、仕事を始めるときには交わした契約は遵守します。計画だって立てます。
「△△」の必要性は理解しつつも、「顧客にとっての価値」が損なわれるようであれば「◇◇」を優先しますよ、というのがアジャイル宣言です。
ライトパスのアジャイル開発も、このアジャイル宣言を守りつつ、お客様にとっての価値を最大化するシステム構築を最優先事項としています。ご興味をお持ちの方は、ぜひお問い合わせページからご連絡ください。