よく「アジャイルはどんなプロジェクトに向いているの？」という質問を受けます。以前は「計画通りに進められるプロジェクトなら、ウォーターフォールの方が向いていますよ」と説明していましたが、どうも伝わっていない感じがしていました。また、向いていない場合に「ウォーターフォールの方がいいですよ」と言うと、怪訝な顔（リモートワークだと「声」でしょうか）をされたり、アジャイルが向いていないプロジェクトがあるのか？と驚かれることがよくありました。
ずっと「どう説明するのが伝わるかな？」と色々考えて試していたのですが、昨年（2022年）は「持続的イノベーションにはウォーターフォール、破壊的イノベーションにはアジャイルが向いていますよ」という説明をしてみました。
この説明が今までで一番よく伝わったように思います。
目次
持続的イノベーションと破壊的イノベーション
新しいことをすると言うと「イノベーション」という言葉が思い浮かびます。プロジェクトや会社全体の方針なので「イノベーションを」というようなフレーズをよく聞きます。そして私たちの仕事であるソフトウェア開発では、そのイノベーションを実現するために、あるいは実現したものとして、「何かを作る」というわけです。
クレイトン・クリステンセン (著) の 書籍「イノベーションのジレンマ」では、そのイノベーションには2つあると説明されています。持続的イノベーションと、破壊的イノベーションです。
持続的イノベーションは、すでに成功している組織がさらに成長することを目指すとき。市場や顧客がそこにあって、すでに売れている商品やサービスがあって、そこに新しい機能を追加したり、性能を改善してこれまどより新しい価値を提供したり、というソフトウェア開発が持続的イノベーションです。
それに対して、全く新しい商品・サービスを生み出すのが、破壊的イノベーションです。まだ商品やサービスは完全には完成していなくて例えばアイディアや役に立つ技術が生まれたばかり。それを使ってお金を払ってくれる顧客がどこにいるのか？どういう人が使うのか？市場を探さなければならない。あるいは市場を自分たちで作っていかなければならない。そういうソフトウェア開発が破壊的イノベーションです。
多くの場合、私たちは会社を成長させるために、持続的イノベーションを扱っています。対して、破壊的イノベーションを扱う新しい商品・サービスは、最初は十分な売り上げが期待できないので、すぐには会社を成長させることができません。たとえ会社のトップダウンで破壊的イノベーションを扱うと決めたとしても、実際に商品・サービスを扱うマネージャーや営業には「それでは十分な成績があげられない」と嫌われて、扱われず、結果として破壊的イノベーションを扱うことは通常の会社では成功しません。
しかし、破壊的イノベーションをうまく扱うことができた会社は、これまでにない全く新しい顧客を見つけ出し、新しい市場を作り出して、次第に十分に成長できるようになります。時間がかかるものの、その間に、製品・サービスの性能や生み出す価値が著しく向上して、ある時点から、既存の商品・サービスの市場を完全に奪って置き換わるようになります。（例えば、SSDは最初は容量が小さく、価格も高かったので、HDD の代わりに使われることは難しく、容量が小さくてSSDでなければ扱えない場面でしか使われませんでした。しかし、時間が経って SSD はずっと大容量になって価格も下がり、そうすると HDD を買っていた人が HDD の代わりに SSD を買うようになりました。）実は、そういうことがこれまでも何度も起きているので、経営層は破壊的イノベーションの登場に合わせて、自分たちも破壊的イノベーションを扱いたいと考えているはずです。
「イノベーションのジレンマ」では、一般的に大きく成長した会社では破壊的イノベーションを扱うことができないため、最初の小さな市場でも十分にやっていけるような小さい別の新しい会社を作って、そこで破壊的イノベーションを扱うべきだろうと言っています。
破壊的イノベーションはアジャイル（Scrum）
「イノベーションのジレンマ」を読むと、この新しい市場を探す・作るのがいかに大変かというのがわかります。ここでは最初に立てた計画はほとんど役に立ちません。計画通りにソフトウェア開発を行うスキルよりも、新しいものをすぐに作って顧客になりそうな人に試してもらって、フィードバックをもらって、よりニーズに合わせた商品・サービスになるように作り変えていく。そういうスキルが求められます。
これは相当大変なことです。そして大きく成長した会社で働く人は、これを行うことに全く慣れていません。そこで、そういうソフトウェア開発をするにはどうすればいいのか？その基本的なプロセスを整理したものが Scrum というわけです。
「アジャイルでやれば早くできるよね」とか「アジャイルでやれば柔軟に作れるよね」と、よく言われますが、これらがうまくアジャイルを表現できていないのを感じます。破壊的イノベーションを扱うために、「最初の役に立たなくなった計画を早く捨てて、新しい計画を立て直して開発することがアジャイルならできるよね」とか、「思ってた顧客や使い方と違うところで売れそうだから、全然違うソフトウェアに作り替えなければならないけれど、アジャイルなら変えていけるよね」というのがより正しいイメージと思います。
Scrumでは、顧客のニーズを聞くために定期的に（数週間ごとに）スプリントレビューを開催します。実際に動作するソフトウェアをユーザーに見せてフィードバックをもらって、すぐ開発に反映させる。ここに顧客や実際にソフトウェアを使っているユーザーが参加していなければ、到底これを実現することができないと言われるのは、なるほどそうだなあと感じます。
持続的イノベーションはウォーターフォール
逆に、新しいことではあるけれど、今までの延長線上でイメージができるソフトウェア開発であれば、従来通りのウォーターフォールが向いていると言えます。やったことがあることを計画通りに行えば、必ずソフトウェア開発に成功して、計画通りの工数で実装ができて、期待した通りの売り上げがあがって会社が成長する。顧客やユーザーの声をわざわざ新たに聞かなくたって、市場のことはよくわかっているし、ソフトウェア開発者は計画通りに作ればいいんだ。こういう場面では、計画通りにソフトウェアを作れるスキル。そしてもし計画通りにいかない場合には、計画と実績の差を把握して、そのギャップをうまく埋められるようなスキルが求められます。そして最終的には、おおよそ計画通りに開発が完了して、ソフトウェア開発は成功した、と言えなければなりません。
これはこれで大変なことですが、多くの会社ではこの「計画通りに行う」というのは慣れていることなので、ソフトウェア開発であってもイメージがしやすいのではないでしょうか。
ソフトウェア開発では、そのソフトウェアを作る技術そのものの他に、WBS（Work Breakdown Structure）や V字モデルを基本として、EVM（Earned Value Management）によって計画と実情の差を把握したり、ドキュメント体系やプロセスを定義してできるだけ正確に計画通りに作れるようにしていきます。これがいわゆる ウォーターフォール と呼ばれている開発方法です。
もし自分たちが扱っている商品・サービスの開発に、顧客や実際のユーザーの声が必要ない、あるいはフィードバックをもらうようなイベント・プロセスは含まれていない、というのであれば、間違いなく商品・サービスが扱うものは持続的イノベーションでしょう。計画通りに成長できることがわかっているのですから、そんな時間をかけることは無駄でもったいないことですし、やる意味が分からないのも納得できます。
MVP（必要最小限の製品）を作るアジャイル
もうひとつのキーワードとして。アジャイルやリーンの文脈では、MVP（Minimum Viable Product）を作ることが重要とされます。これも、破壊的イノベーションをイメージするとわかりやすいと思います。
MVPは、リリース可能で、それだけでユーザーに何かしらの価値を与えることができる最小限の製品ということです。MVP の説明でよく見るこの図では、車を作るとき、タイヤはそれだけでは移動に使えないので MVP ではなく、最初に作るべきはスケボーであると。ソフトウェア開発では（ハードウェア＝物の開発と違って、ソフトに）製品の形を変えられるので、スケボーがキックボードに変化し、次第に自転車、バイク、オープンカー に形を変えて価値を高めていきましょうと、説明されています。
この例を見たとき、「なるほど言っていることはわかるけど、顧客はオープンカーを期待しているんだから、その顧客にスケボーは売れないでしょ」と思ったなら、それはそうでしょう。破壊的イノベーションの説明の通り、スケボーではオープンカーの顧客・市場には売れず、まずスケボーを買ってくれる人に売って会社と製品を成長させていかなければならないのです。これが MVP をイメージしづらいポイントと思います。
さらに、「オープンカーが欲しい」というのは、オープンカーを知っている人にしか言えないことなのです。これは例なので、誰もが知っていてわかりやすい例としてオープンカーが描かれていますが、本当は「まだ誰もオープンカーを知らないときに製品を作り始めた」という感じの方が、より正しいイメージのはずです。（例えばスマートフォン。iPhone がヒットする前に、スマートフォンの前身のような製品をが沢山出ていましたがどれもそこまで大きくヒットすることなく、使っている人は少数派でした。私もスライド式のキーボードがついた携帯電話を使用していました。それはまさにスマートフォンのようなものでしたが、今のスマートフォンとは別のものでした。きっとその時代、誰もが持ち歩ける何かしらのデバイスが近い将来大ヒットするだろうことは、多くの人がイメージできていたものの、今のスマートフォンのような形が一番受け入れられるとは誰もまだイメージできていなかったのです。そういう時代に、まさにスマートフォンのようなものを作り始めようとしているときに、「iPhone のような形を最初から作ればいい」とは誰も言えないのです。）
もし自分たちのソフトウェア開発で、MVP を実際に動作する最小限の製品としてイメージできないのであれば、破壊的イノベーションが求められているのではなくて、やっぱり実質的には持続的イノベーションを扱っているのではないでしょうか？
もし本当に破壊的イノベーションを扱うのであれば、とりあえず小さくて動くものを作って試してみることが求められるはずです。そういう場面では、計画通りに作るスキルがある人よりも、MVP を作れるスキルのある人を集める必要があったり、「イノベーションのジレンマ」の説明の通りに会社・組織そのものを新たに用意しなければならないかもしれません。ベンチャー企業での働き方や、ソフトウェア開発で求められる方法が、まさにこのアジャイルの MVP を作るということだと思います。逆に、折角小さい会社を作ったのに、大きな会社・組織と同じように従来通りのウォーターフォールのプロセスで、長期的な計画でソフトウェア開発を行ったのではうまくいかないのではないでしょうか？
もちろんスケールするには大規模向けのフレームワークが必要
ウォーターフォールであっても、例えばWBSやV字モデルを知っているだけでは、大規模なプロジェクトを成功させることはできません。EVMをやっていない（CPI・SPIを算出していない）ようなプロジェクトは、まず間違いなく炎上します。これは同じウォーターフォールであっても、プロジェクトに参加する人数が増えるなど、規模によって複雑さがずいぶんと違って、それに合わせてうまく適用できるプロセスが全く異なるということです。
同じように、アジャイルでも、大規模向けにはそれにあったフレームワークが必要です。
Scrum は約10人までのチームでソフトウェア開発するための方法です。それ以上の人数にするとうまくいきません。チームを複数に分けて、複数のチームで1つの製品を開発するには、Scrumで定義されたプロセス・イベント以外のチーム間での連携のためのプロセス・イベントが必要になります。「アジャイルはエンタープライズ開発に向かないよね」ということをいう人がいたら、それは「アジャイルは」ではなく「Scrum 1チームでは」と言っているわけですよね。そりゃ10人、1チームで大きな開発はできないでしょう。あるいは Scrum の原則を無視して、無理やり大人数で Scrum をやれば、それは失敗するだろうなと思います。大きな規模の開発を行うには、より大規模向けのフレームワークを導入することが必要です。
例えば Nexus™ は、Scurm をそのままスケールして複数のチームで Scruｍ をやれるようにします。それよりももっと大きく、会社組織全体の意思決定をアジャイルで行いたいという場合には SAFe® を導入します。
例えば、アジャイルで破壊的イノベーションを扱うために、最初は小さな会社を作って 10名程度の Scrum １チームでソフトウェア開発を行っていて、それに成功して、市場も会社も大きくなった時にどうするか？成長を続けるために持続的イノベーションを扱う会社・組織に変わるのか？それとも、そのままずっとより新しい破壊的イノベーションを扱える会社・組織であり続けるのか？その道は「イノベーションのジレンマ」ではずいぶん険しそうに見えましたが、もしそれを続けるのであれば SAFe® を導入するような会社・組織の在り方を考える必要がある、ということなのだと思います。
コメント
