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