アジャイルとウォーターフォールの違いとは2013年07月25日シェアPocketツイートnoteで書く「アジャイル」という言葉が一人歩きしてしまっていて、たまに話をしていても通じないときがあります。それくらいアジャイルという言葉が広く知られるようになったんだと思う一方で、かえって話が通じなくて、もどかしく感じることもあります。いって、そこで「正しいアジャイルとは」みたいな議論をしたい訳でもないのです。広まれば広まるほど、そういった言葉の認識の齟齬が出るのは仕方ないですね。その正しい定義みたいなところを追求するのもナンセンスなので、そんなつもりはないですが、ただ自分がどう考えているかについては書いておいても良いかな、と考えました。ここは私のブログですしね。そこで、この記事では、私の考えるアジャイル開発の本質について、そしてウォーターフォールとの違いについて書きました。Faruque目次アジャイル開発では機能を全部つくらないアジャイルが曖昧なものになってしまう理由アジャイルとウォーターフォールの本質的な違いあわせてよみたいアジャイル開発では機能を全部つくらないこれまで私の中で、アジャイルと言えば当たり前の前提がありました。それは「アジャイル開発では当初に想定した機能を"全部"つくらない」ということです。最初に想定されたいろいろな機能の一覧があったとして、最終的にそれを全部作ってしまうのであれば、ウォーターフォールと変わりません。イテレーションという形で繰り返し型で作っていったとしても、結局は全部つくってしまうのだとしたら、それってアジャイル開発の良さを消してしまうと思いませんか?よく、アジャイル開発のメリットは、変化に対応できること、と言いますよね。アジャイルだと変化に対応できるのか?保守性を重視して作るとかもありますが、大きなポイントは、必要な機能を少しずつ実現していく中で、十分となった時点でそれ以上は作らなくて良いからで、その時点で変化によって新しく出てきた要件に着手することができるからです。十分となるのは、機能数でもあるし、その品質でもあるでしょう。最初に想定した機能を全部つくるなら同じコストで変化に対応など出来るわけがありません。アジャイルでは「変化に対応する」というメリットを得るために、「機能を全部作る」ということを捨てているのです。何のトレードオフもなく、メリットだけを享受できる魔法のようなものは、この世界にはありません。アジャイルは魔法ではないのです。最初に決めた機能を全部作らなくていい、ということを許容できないのであれば、現場がどれだけスクラムだなんだと言っても、ウォーターフォールと変わりません。全部の機能を作るなら、ウォーターフォールの方が良いのかもしれません。このトレードオフをわかっていないと、うまくいかないでしょう。以前にチェンジビジョンの平鍋さんの書かれた記事があります。アジャイルを学ぶ人にとって、とてもわかりやすい記事です。アジャイルの「ライトウィング」と「レフトウィング」ここに書かれているのは、アジャイル開発を構成する要素です。高速に開発するための技術的なプラクティスと、協働のためのチームビルディングのプラクティス。確かにこういった要素を取り入れることで、現場はアジャイルっぽくはなります。実際に、これらのプラクティスは良いチーム作りには大切なことですし、実践することで開発速度を上げることも出来るでしょう。そこに記されたプラクティスを実践することは、ウォーターフォールのプロジェクトだと出来ないのでしょうか。いいえ、決して、そんなことはないはずです。ウォーターフォールのプロジェクトであっても、タイムボックスを切ってふりかえりも出来るはずですし、朝会も見える化もすればいいばすです。テストやビルドの自動化や継続的デリバリーも、やろうと思えば出来るでしょうし、効果もでるはずです。アジャイルという考えの構成要素のプラクティスから考えてしまうと、アジャイルもウォーターフォールもあまり違わなくなってしまうのです。すると、結局は「アジャイルはマインドだ」とか「現場に合わせて考える」とか「バランスとるべきだ」とか言う意見が沢山でてくる訳です。した結果、どんな現場でもアジャイルであると言えるような状態になってしまい、それぞれの人の「アジャイル」という言葉が出来上がり、冒頭で書いたような話が通じなくなってしまうことが起きるのです。そのことは悪いことではありません。良いプラクティスが広まることで、ウォーターフォールだろうがなんだろうが、多くの現場が改善されるならば、それはそれで素晴らしい成果だと思います。「アジャイル」という言葉が曖昧になるだけです。アジャイルとウォーターフォールの本質的な違いアジャイルとウォーターフォールの本質的な違いは、プラクティスを実践するかどうかではなく、手順として繰り返し型にするかどうかではなく、「全部つくらない」を前提とするか「全部つくること」を前提とするかの違いだと考えています。昔あったスパイラルとかRUPとかありましたが、それも「全部つくること」を前提にしていたように思います。繰り返しても駄目なんです。私がシステムインテグレーターで働いていた頃に、プロジェクトをアジャイルに進めるために多くの人に協力や説得をしてまわったことがあります。そこで出た意見が以下のようなものでした。一括請負でビジネスをしているシステムインテグレーターにとっては、システムを完成させることがゴールであり、全部つくることでお客さまに検収してもらえて報酬が支払われます。「全部作ること」こそが仕事な訳です。そんな中で「全部作らないこと」をしましょう、と言っても伝わりません。そこでアジャイルの良さを伝えるために出来ることは「変化に対応する」とか「人を大事にする」とか「顧客満足度を向上」とか「速く・安く」とか、そういったボンヤリした言葉で伝えるしかなくなる訳です。それらはどれも絶対にアジャイルでなければいけないものではない訳です。これまでのやり方だってやろうと思えば出来るものです。これまでのウォーターフォールのやり方から、決定的に違うことを言うのであれば「当初に想定した機能は"全部"つくらない」ということになります。それは一括請負として「決まった機能を"全部"つくること」でビジネスをしている会社では言うことは出来ませんね。私たちソニックガーデンでやっているような月額定額で時間契約をしないモデル「納品のない受託開発」であれば「沢山つくること」がそのままお金になるわけではないので、「当初の機能を全部つくらない」ことが出来ますし、開発しなくて済むなら作らない提案すらします。余計な機能を作ることにリソースを使ってしまって、お客さんが儲からなくなることの方が私たちにとってもリスクだからです。「納品のない受託開発」では、お客さまと共存できるようにリスクを共有しているモデルです。私たちのアジャイル開発の開発速度が速いのは、それは繰り返し型で開発しているからではなく、Rubyを使っているからでもなく、ましてや特別に優秀な人がやっているからでもなく、最初に考えた機能を全て完璧に作ろうとしていないからです。それで本当に必要なもの、大事なものから順に作っていけるので、結果として変化に対応できます。人を重視することも、軽量であることも、動くソフトウェアを中心にすることも、変化に対応することも、顧客との協調すらも、アジャイルの特徴を表したものではあるけれど、その目指すところとまでは言えません。「アジャイル開発では当初に想定した機能を"全部"つくらない」このことは当たり前のことだと思っていましたが、改めて言うと、このことに気付いてなかった人も多かったので、今回の記事にしてみました。これが精神論ではない、アジャイルの本質なのではないか、と考えています。ホウレンソウに代わる「雑談+相談」チームビルディングを成功させるのは、ホウレンソウではなくザッソウ(雑談+相談)なのです。日本初のザッソウ解説本です。「納品のない受託開発」に取り組む"株式会社ソニックガーデン"の代表を務める倉貫義人のブログです。倉貫自身の言葉で、人材育成からマネジメントまで、ソニックガーデンの経営哲学とノウハウについて、日々の学びから記事にしています。「管理ゼロ経営」で注目の社長に聞いてみた』2019-09-17お知らせをもっとみるSonicGarden株式会社ソニックガーデンは、倉貫義人が代表を務める会社です。「納品のない受託開発」という新しい受託開発も行っています。詳しくは、こちらをご覧ください。