ウォーターフォールとアジャイルを比較する話は、違いを説明する都合で、実際によく話をすることがあるのですが、実際にウォーターフォールと比較すべきなのはアジャイルではないと思っています。書籍 More Effective Agileには「アジャイルと比較すべきはシーケンシャル開発である」と記載されていますが、そういったいわゆるウォーターフォール的な開発だとみんなが認識しているものと比較すべきなのは、「スケールされたアジャイル」だと私は思います。

いわゆるウォーターフォールをソフトウェア開発で採用するのは、PMBOK で必要なプロセスとドキュメントがしっかりと定義されていて、エンタープライズ開発で採用しやすいからです。これがなければどのように進捗や品質を管理すればよいのか?わからなくなってしまいます。

そこでもしウォーターフォールから切り替えるとするならば、切り替える先としては、「アジャイルを採用した小規模な開発」ではなく、「大規模な開発も扱えるアジャイル」が求められます。しかし、一般的なアジャイルのフレームワーク「スクラム(Scrum)」では、最大10名までのチームで扱える範囲の開発しか対応できそうにありません。これがフィットする規模の開発であれば、例えば社内システムの開発で小規模から始めるというのであれば、イメージしやすく「アジャイル(Scrum)でやってみましょう」と言いやすいでしょう。しかし、ソフトウェア開発を請け負う会社にとっては、多くの場合は規模が小さすぎます。もっと大きな規模のエンタープライズ開発に耐えられる方法が必要です。そこでついつい、Scrumを自分たちにフィットするように変えてしまう Scrum But になってしまいます。しかし、Scrum But は成功しません。その結果「アジャイルはダメだ」という主張になったり、完全にウォーターフォールのまま用語だけ変えた「なんちゃってアジャイル」が流行ったりするのだと思います。

本来、ウォーターフォールから切り替えるべき先は「スケールされたアジャイル」です。それは(シンプルな Scrum ではなく) NEXUSSAFe、あるいは Scrum of Scrums でしょう。

それぞれ、Scrum を変更するのではなく、Scrum をそのままに、必要なプロセスなどを追加して拡張したフレームワークになっています。それぞれ拡張の仕方が微妙に異なりますが、どれも Scrum But にならないように十分に注意しながら、それでいて1チームだけで Scrum に取り組んだ時にはとても対応できないような、複数のチームが同時に取り組まなければならない大規模なアジャイルが行えるように工夫されています。

「スケールされたアジャイル」は、また、いわゆる開発期間だけに対応するものではありません。従来のウォーターフォールでいえば、要求定義・要件定義から、設計・開発・テスト・リリースを含めて、そのあとの運用・保守の範囲もすべてカバーしています。もっと言えば、さらにそれよりも広い範囲で、事業計画から予算どりと人員のアサインメントまで含めて、もっと広範囲に、会社組織の動き方そのものをすべてアジャイルにしてしまうことを想定しています。以前、Microsoft のイベントで「会社をすべてアジャイルにしたのがDevOpsです」という説明を聞いたことがあります。これはまさにそのイメージです。その規模ですべてアジャイルで扱えるようになった組織であれば、従来のウォーターフォールとはとても比較にならないようなアジリティ(機敏さ)の効果が得られるというのがアジャイルの本来目指すところです。

ただ、残念なことに、ウォーターフォールからスケールされたアジャイルにすぐに切り替えることは、まず、できません。スケールされたアジャイルは、当然、アジャイルが十分に習熟していることが前提になっているからです。まず先に、小規模なアジャイル、1チーム10人程度までの Scrum ができるようになる必要があります。

スクラムが未熟なうちに複数のスクラムチームを同時並行でスタートさせるのもうまくいきません。おそらく全く関係がないものをそれぞれ作るチームであれば、それは問題にならないような気がしますが、そうではなくて例えば同じアプリケーションを複数のチームで同時に開発したいということでしょう。その目的だと、スクラムチーム間の連携がうまくできずにすぐに行き詰ります。これに対応するために、スケールされたアジャイルのフレームワークを取り入れる必要があるのですが、スクラムチームがまだ未熟なのでそのスケールされたアジャイルのフレームワークの文脈も正しく扱うことができないのです。

そして、結局いつまでも小規模なスクラムを始められないために、スケールされたアジャイルもできるようにならず、ウォーターフォールからアジャイルに切り替えることができずにいる、ということになるのです。これはいわゆる「イノベーションのジレンマ」とほとんど同じような状態なのではないでしょうか?

例えば、初めてできたSSDは容量が小さすぎてHDDの代わりになりません。しかし、SSDを作り続けないと、大容量のSSDを作ることはできないため、まずは容量が小さくても使えるところでSSDを使ってもらえるように販売していきます。そしてその後、いよいよ大容量のSSDが作れるようになったところで、HDDの代わりとして使ってもらえるようになります。でも、大容量のHDDを作っているときに、(その同じ顧客には容量の小さいSSDを売れないので)SSDを作り始めるのはかなり難しい。でも作り始めないといつまでも作れるようにならずに、他のSSDを作れるようになった会社に負けてしまう、というようなお話ですね。

アジャイルも、すでにウォーターフォールでやっている大規模なエンタープライズ開発をそのまま全部置き換えてしまうようなことは難しいです。まず最初に1チーム10人までの規模で、ちゃんと Scrum ができるようになる必要があります。そのチームが成熟してきたら、2つに分割して新しいメンバーを入れてまたスクラムの成熟度が上がるように成長を待ちます。またチームが成熟したらチームを分割して・・と繰り返しながら少しずつアジャイルがスケールできる状態にしつつ、準備が十分に整ったところでスケールされたアジャイルのフレームワークを取り入れて、ようやく大規模なエンタープライズ開発ができるようになる。そういう中長期的な戦略を持って取り組まなければならないのが、「アジャイルのジレンマ」という感じでしょうか。

コメント