アジャイルに馴染みの少ない方に、アジャイルとは何なのか、そしてなぜ必要なのかを簡単に説明してみたいと思います。
アジャイルの普及は「まだまだだ」と言われつつ、実際には徐々に広がってきましたよね。しかし、普及が遅れる中で、ウォーターフォールの文化に由来するデマや誤解も広がって、アジャイルがバズワード化しているようにも感じます。そこで、一度ちゃんと整理しておくのが良いかなと。あくまで私個人の見解になりますが、ぜひ参考にしてみてください。
アジャイルの話をする上で、まず出てくるのが「アジャイルソフトウェア開発宣言」ですね。
「私たちは、ソフトウェア開発の実践やそのサポートを通じて、より良い開発手法を見つけ出そうとしている。そしてこの活動を通して、以下の価値に至った。」
- プロセスやツールよりも→個人と対話を
- 包括的なドキュメントよりも→動くソフトウェアを
- 契約交渉よりも→顧客との協調を
- 計画に従うことよりも→変化への対応を
「価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。」
要するに、左側の要素も重要だけど、右側の要素にもっと価値を置く、という宣言ですね。
これは、ウォーターフォールのような固定されたプロセスへの対抗として生まれた宣言です。でも、これは半分歴史の話だと思っておいていいかもしれません。最近のウォーターフォール開発では、全ての設計書を揃えるような「包括的なドキュメント」はほとんど見かけませんし、当時想定されていた「プロセスやツール」も今ほど簡単に使えるものではありませんでした。だから、宣言文をそのまま鵜呑みにするのではなく、歴史的背景を理解して考えるのが重要です。
さて、一般的にはアジャイル開発はウォーターフォールの反対側に位置するものと考えられがちです。
ですが、ここで重要なのは、カウボーイコーディングというスタイルも存在するということです。アジャイルでもウォーターフォールでもない開発手法、つまり計画なしに突き進むスタイルです。もし、アジャイルでなければウォーターフォールだろう、と考えるとこのカウボーイコーディングが見落とされがちです。実際、意外と多くのプロジェクトがカウボーイコーディングに分類されることもあります。その可能性を見落とすと、勘違いすることになります。
ウォーターフォールは、すべてを計画通りに進める手法であり、アジャイルは変化に対応するための体系的な手法です。一方、カウボーイコーディングは、勘や経験に頼る「行き当たりばったり」のスタイル。きちんとした枠組みがない分、ある意味で大胆な進め方とも言えますね。
これら3つは、明確な境界で区別されるわけではなく、重なり合う部分もあります。例えば、アジャイルっぽいカウボーイコーディングや、ウォーターフォールっぽいアジャイルの手法など。こうした曖昧さが、議論を複雑にしているんですね。
特に、歴史的にウォーターフォール開発が主流だったこともあり、アジャイルとカウボーイコーディングが混同されがちです。ウォーターフォール開発に慣れた人たちは、アジャイルを批判するつもりが実はカウボーイコーディングの問題点を指摘しているだけ、なんてこともよくあります。でも、アジャイルは決して「行き当たりばったり」ではありません。
実際には、アジャイルとウォーターフォールは多くの点で共通しています。両者は理論的にしっかりと体系立てられた開発手法であり、対してカウボーイコーディングにはそれがない。つまり、仲間外れはカウボーイコーディングなのです。
ウォーターフォールとアジャイルのどちらが優れているというわけではなく、それぞれメリットとデメリットがあります。両者は異なる手法で同じ問題に取り組んでいるにすぎません。
例えば、ウォーターフォールは以下のような手法で問題に対処します。
- プロジェクトマネジメント手法
- 手戻りのない設計
- 体系的なテスト技法
一方で、アジャイルはこういった手法を使います。
- スクラム
- テスト駆動開発（TDD）
- CI/CD
どちらも、取り組む課題は同じです。やり方に違いはありますが、問題に対する基本的なアプローチは似ている部分も多いんです。だから、完全に対立しているわけではなく、ただ違った方法で同じ目的を達成しようとしているだけなんですよね。
では、ウォーターフォールに慣れた人がアジャイルを学ぶとき、どんなことが起こるか考えてみましょう。例えるなら、自動車と冷蔵庫の違いのようなものです。最初はまったく異なるように見えます。
実際にはどちらも鉄板やネジで組み立てられている工業製品です。
細かいところを見ていくと、アジャイルとウォーターフォールにも同じような共通点が見えてきます。両者ともプロジェクト管理や品質管理に力を入れていて、やり方こそ違えど、目指していることは同じなんです。違いは、どの手法を選ぶかにすぎません。
それに、アジャイルがここまで「新しいもの」として広まった背景には、アジャイルエバンジェリストたちが「すごい！」と感じさせるように工夫して伝えてきたこともあります。
「アジャイルは自由だ！」というイメージが広がったのも、特にアメリカで自由を好むプログラマーたちに受け入れられるために、かなり強調されていた部分があるんです。
ですが、実はアジャイルの起源は日本にあります。トヨタ生産方式がアメリカで科学的に研究され、製造業に広まったリーン生産手法がそのベースです。この手法をソフトウェア開発に応用したのがアジャイルなんですね。なので、考え方自体はトヨタ方式と大きく変わりません。
トヨタの昔の社長のエッセイなんかを読むと、アジャイルのエッセンスをよく理解できるかもしれません。「アジャイルは自由すぎて苦手」と感じる人には、トヨタ方式の本を読むことで、規律あるアジャイルを学ぶのも良いかもしれませんね。
さて、アジャイルが目指す本質に触れていきましょう。アジャイルが最も大事にしているのは「変化に対応すること」です。
ダーウィンの進化論で有名な言葉に「最も強い者が生き残るのではなく、最も賢い者でもない。生き残るのは、変化できる者である」と言われるものがあります（実はダーウィン自身の言葉ではないようですが、いい言葉なので使います！）。ソフトウェア業界でも変化に対応することは非常に重要で、コストの大部分もそこにかかっています。
ウォーターフォール開発は、変化がないことを前提にしています。でも、現実はそう簡単にはいきませんよね。だからこそ、変化に対応できるアジャイルが必要になったんです。
アジャイルでは、変化に対応しながらも、予測を立てることが求められます。しかし、これが実はとても難しいのです。
あるアジャイルの有名な例え話に「明日の天気予報」があります。大金をかけて作り上げた天気予報システムが、実際の精度は70％だと公表されました。ところが、誰かが「今日の天気は昨日と同じだ」と予測しても、69.5％の精度で当たることに気づいたのです。つまり、頑張って予測を立てても、それほど結果が変わらないことがあるんです。
アジャイルでは、この予測の習慣を身に付けることがとても大切です。タッチタイピングのように、常にホームポジションを維持するのと同じで、常に対応できる状態を保つことがアジャイルの肝なのです。
さて、「アジャイルは大規模開発には向かない」といまだに言われることがありますが、それはもう昔の話です。20年前に言われていた話ですね。それから時間がたち、今ではアジャイルにも大規模開発に対応するノウハウがたくさん蓄積されています。
実際、世界中でアジャイルが広がっていて、特に欧米では顕著です。2017年の調査では、96％の企業がアジャイルを導入しているという結果が出ています。
「欧米は欧米、日本は日本」という気持ちもわかりますが、普段使っているフレームワークやライブラリは多くが欧米で生まれたものです。もう、日本独自のウォーターフォール対応ライブラリでエコシステムを作り出す力はありません。アジャイルに合わせる時代が来ています。
アジャイルを中心に、ソフトウェア開発のエコシステムは動いています。ウォーターフォールが経営から開発、インフラまでをカバーしていたように、アジャイルもそれぞれ対応する手法が整っています。一つだけ昔のやり方にこだわると難しくなるので、潔くアジャイルで統一する方が合理的です。
慣れるとアジャイルはとてもやりやすくなります。ぜひ挑戦してみましょう！
(編集協力：ChatGPT 4o様)
(当記事はZennにもマルチポストされます)
Zenn
(スライド全体はこちら)
speakerdeck