日記兼ポエム（2026/07/20）

アジャイル開発の本質って不確実性との付き合い方にあるよね

ネットを見れば色んな人がいろんな言葉でもって語っている内容だが、私も私の言葉でこの話をまとめたいなと思った。

というのも、大学院時代に受けていた授業で、教授が「ミッションクリティカルなシステムではウォーターフォールのほうが向いている」という趣旨の発言をしていたのがずっと頭に引っかかっているからだ。ウォーターフォールとアジャイルはそれぞれにメリット・デメリットがあり、どちらがより優れているというものではなく、使い分けるべきものである、と。私は初めてこの意見を聞いたとき、よくある極論ではない、冷静な分析に基づいた極めて客観的な意見であるように感じた。

だが、実際にソフトウェアエンジニアリングの実務に触れてみて、少しずつこの意見に対して懐疑的な目を向けるようになってきた。というのも、私が当初持っていたアジャイルに対するイメージやそのメリットは実はアジャイル開発のほんの一面を表しているに過ぎないのだということを学んだからである。

私が当初持っていたイメージというのはすなわちこうだ。「アジャイル開発とは、不完全な状態でもとにかく早くリリースして、ユーザーフィードバックを受けながら改善していく手法である。」よく言われている、時間をかけて80点を取るよりも、早いタイミングで60点取ることを目指せという、あれだ。

ただ、実務をやってみてわかるのは、アジャイル開発において必ずしもこうした素早いリリースは必要ないということだ。そうではなく、アジャイル開発において本当に大切なのは「不確実性をさっさと潰す」ということだ。そして、不確実性を潰すために一番効果的な手法は実際に動くソフトウェアを作ってしまうことである、とアジャイル開発宣言は主張している。もちろん、市場で受け入れられるのかどうかが最も不確実な要素なのであれば、さっさとリリースして市場の反応を見るという選択肢は大いに推奨される。しかし、そこがプロジェクトの成功にとってクリティカルな不確実性でないのであれば別に無理してリリースなんてする必要はない。例えば、社内システムを作っているのであれば、そもそも市場に出すものではないのだから、無理してリリースするよりも積極的にプロジェクトに関わってくれる社内ユーザーに何度も触ってもらってレビューをもらうほうが大事だ。

と、いったように、動くソフトウェアを作ることでいろいろな不確実性を潰すことができる。そして、私から見ると、ウォーターフォール開発はこの「実際に動くソフトウェアを作ってしまう」という手段をあえて使わない、いわば縛りプレイ開発であるようにしか見えない。プロジェクトの成功のみを価値と定義したとき、プロジェクトの難易度を上げるだけの縛りプレイのほうが優れている場面など果たしてあるのだろうか？こういったことから、私はアジャイル開発がウォーターフォール開発よりも優れた手法であるということを信じている。

では、なぜ世の中にまだまだウォーターフォール開発のプロジェクトが存在しているのか？ここからは私の推論だが、ほとんどのプロジェクトでウォーターフォールのほうが優れていると思って選ばれているのではなく、アジャイルを選べないだけなのではないかと思っている。例えば、複数企業の数十人、数百人の開発メンバーが関わるプロジェクトをアジャイルで進める方法は？と言われても、今の私にはパッと思いつかない。とはいえ、あえてアジャイルをやるとなったら、おそらく数十人、数百人の開発メンバーを複数のいわゆるピザ2枚チームに分けて、それぞれが干渉しないようドメインを分割して作っていくことなるのではないだろうかと思う。

じゃあ、実際に企業がこの選択肢を選べるのかと言うと、契約形態や組織構造がそういう形になっていないせいで、結局選べない選択肢になってしまっているのではないかというのが私の推論である。というのも、これまでウォーターフォール開発に最適化してきた組織をアジャイルのために編成し直すのは容易ではないからだ。

まあ、組織の場合であれば究極、組織体制を変更しさえすればアジャイル開発を選べるかもしれない。しかしさらに別軸で、試作コストが高すぎる場合や外部制約によってそもそも動くソフトウェアが作れない場合には本格的にアジャイル開発が選択肢に挙げられなくなるだろう。例えば、独自のハードウェアを必要とするソフトウェア開発や、航空機ソフトウェアなどの品質規制がガチガチにかかっているソフトウェアを作る場合はこれに該当しそうだ。

いずれにしろ、これらはウォーターフォールにメリットがあるから選ばれているわけではない。アジャイルを選べないから仕方なくウォーターフォールが選んでいるのである。逆に言うと、アジャイルを選べるのであれば、基本的にはアジャイルを選んでおくほうが良い、というのが今の自分の整理だ。

と、ここまでウォーターフォールについて色々腐してきたが、私は実際には本格的なウォーターフォール開発を経験したことはない。だからこそ、人生で一度くらいは、音に聞く地獄の大規模ウォーターフォールプロジェクトに参画してみたいという気持ちはある。とはいえ、上記のようにウォーターフォールでなければならない場合は実際にはそんなに多くないのではないかと思っている。なので、アジャイルでもいいのに、あえてウォーターフォールが選ばれているプロジェクトに参画してしまったら、それこそ縛りプレイを感じてストレスマッハになりそうだなとは思う。

何にしろ、ソフトウェア開発で最も重要なのが不確実性のコントロールであるということは開発手法によらず普遍の真理であるというのは既に述べたとおりである。このことだけは常に肝に銘じつつ、システムやビジネスと向き合っていきたいと思う今日このごろであった。