アジャイルは「手法」ではなく「価値観」

アジャイル開発を「スクラム」や「2週間スプリント」のことだと思っている方は多いですが、それは正確ではありません。アジャイルとは特定の手法ではなく、ソフトウェア開発に対する価値観・マインドセットです。

2001年、17人のソフトウェア開発者がユタ州に集まり「アジャイルソフトウェア開発宣言」を発表しました。彼らはXP、スクラム、DSDM、Crystal など異なる手法の実践者でしたが、共通する価値観を言語化したのがこの宣言です。つまりアジャイルは、既存の複数の手法から抽出された上位概念なのです。

4つの価値と12の原則

アジャイル宣言は4つの価値を掲げています。

重要なのは、宣言に続く一文です。「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」。左側を否定しているのではなく、優先順位の話をしています。

この4つの価値を具体化したのが「12の原則」です。たとえば「動くソフトウェアを2〜3週間から2〜3ヶ月という短い間隔でリリースする」「ビジネス側と開発者は日々一緒に働く」「最良のアーキテクチャ・要求・設計は自己組織化したチームから生まれる」など。手法ではなく、何を大切にするかを示しています。

アジャイルは「計画に従うことよりも変化への対応を」と言っていますが、計画を立てないわけではありません。むしろスクラムでは、スプリントプランニング、リリースプランニング、プロダクトバックログの優先順位付けなど、計画の機会は頻繁にあります。違いは「計画は変わるもの」という前提に立っていることです。

「動くソフトウェア」を重視するのは、ドキュメントだけでは認識のズレに気づけないからです。必要なドキュメントは書きます。ただし「誰も読まない100ページの設計書」より「チームが実際に使う10ページ」を選ぶ、という優先順位の話です。

変化に対応できることと、いつでも無制限に変更できることは違います。スクラムではスプリント中の変更は原則として受け付けません。変更を受け入れるには適切なタイミングとコストの認識が必要です。「アジャイルだから仕様変更し放題」は発注側・受注側双方にとって不幸な誤解です。

アジャイルは開発速度を上げる手法ではありません。価値あるものを早く届け、無駄なものを作らないことで、結果として効率が上がる可能性はあります。しかし同じスコープを同じ品質で作る場合、アジャイルだから速いということはありません。

日本のシステム開発では「請負契約」が一般的です。成果物と金額を事前に決め、完成責任を負う形態です。しかしアジャイル開発は、スコープが変動することを前提としています。この相性の悪さがアジャイル導入の障壁になることがあります。

アジャイル開発では「準委任契約」が適しています。稼働時間に対して報酬を支払い、成果物は都度協議する形態です。ただし発注側には「何ができるかわからない状態で契約する」不安があり、受注側には「いつまでも終わらないリスク」があります。信頼関係と適切な契約設計が必要です。

特に日本のSI業界では、元請け→下請け→孫請けという構造の中で、末端の開発者が顧客と直接対話できないことが多くあります。この構造でアジャイルを導入しても、形骸化しやすいのが現実です。

「毎日朝会をやっている」「カンバンを使っている」だけでは、アジャイルを実践しているとは言えません。形式だけ取り入れて、価値観が伴っていない「カーゴカルト・アジャイル」は珍しくありません。

逆に、朝会もスプリントもなくても、顧客と協調し、動くソフトウェアを頻繁に届け、変化に対応しているなら、それはアジャイルの価値観を体現しています。

手法やプラクティスは手段であり、目的ではありません。自分たちのコンテキストで何が有効かを考え、継続的に改善していくこと自体がアジャイルの本質です。