アジャイル開発の旨味は「ビジネスリスクを減らせる」こと　VUCASの時代だから重要な“小さく失敗する”考え方

このスライドはいったい何を示したものでしょうか？

朱峰錦司氏：アジェンダを踏まえて本題に入ります。今日の私の話の6割ぐらいは、基本的には一般論です。もしくは「私はこう考えています」という話です。そこに私の経験を30パーセント加えます。この発表の中だけでなく、事前にいくつかピックアップした質問にも後半で答えようと思っています。最後の10パーセントはちょっとだけ宣伝要素があります。ぜひ聞いてください。

では中身に入ります。話の前に、1つだけみなさんにクイズを出します。制限時間は1分間です。したがって、私は1分間なにもしゃべりません。ちょっと考えてみてください。

（スライドを示し）こちらのスライドですが、特にタイトルはなく画像がただあるだけです。2段にわたって製品・プロダクトらしきものが並んでいて、その下にはなにやら期間のような情報が並んでいます。

左上には飛行機のアイコンが載っていて、その下に68年と書かれています。一方、右下は飛行機とはまったく違う方向性で「ポケモン GO」ですね。言わずと知れたスマホゲームである「ポケモン GO」、その下には19日間。

このスライドはいったい何を示したものでしょうか。みなさん、ぜひ考えてみてください。

このスライドを知っている人はネタバレしないようにお願いします。初見の人はちょっと考えてみてください。「あ、これなんじゃないのかな」というのがあれば、コメント欄に書き出してみてください。当てたりしませんし、成否を見たりもしませんので、書いてみてください。私も手元でみなさんのコメント欄を開きます。

ちょっと短いかもしれませんが、以上でいったん区切ります。いろいろな解答をいただきありがとうございます。すべての解答を読み上げることができず申し訳ありません。

本日はソフトウェアテストに関するイベントということで、テストや運用を切り口にした解答もいくつかありました。例えば、「テストにかかった時間なんじゃないのか」など、いろいろな解答がありました。

この絵のことを知っている人もいると思うので、答えを言います。たいへん申し訳ありません。この絵はテストにはまったく関係ないものでした。これは「そもそもアジャイル開発ってなんだっけ」というパートなので、テストは関係ありません。

そんな中、ドンピシャで書いている人がいました。答えは「そのプロダクトや製品がなんらかのかたちで世の中に発表されてから、そのユーザー数が5,000万に達するまでにかかった期間」です。それを示したチャートです。

あとでいくつかのスライドを削除するかもしれませんが、今日のスライドは基本的に無料で公開したいと考えています。

飛行機は68年もかかった。車は62年かかった。ATMはぐっと縮まって18年でした。プロダクトの主戦場がWebやモバイルにだんだんと移行していく中、最後の「ポケモン GO」は驚異的です。これは非常に極端な例をあえて書いていますが、1ヶ月もかからずに5,000万ユーザーに達しました。

これが今の時代を極めて端的に表現しているチャートということで、私は愛用しています。ちなみに、これは前職から使っているスライドです。今日の参加者の中に、私の前職の同僚がいるのでちょっとドキドキしています。

エンジニアとしてタフな時代に立ち向かっている

こんな非常に素早い時代をどうラベル付けするか。いろいろなラベル付けがされていますが、代表的なものとして「VUCAの時代」と呼ばれています。今はVUCAにさらにSを加えて「VUCASの時代」ともいわれています。

このV・U・C・Aが何の略かというと、1つ目は変動性（Volatility）。とにかく何が起こるかわからない。どんどん様変わりしていく時代であることを表現しています。

2つ目は不確実性（Uncertainty）。今までのやり方が明日には通用しなくなってしまう可能性がある。何が正攻法かまったくわからない、不確実な時代。

そんな中で我々はどのようなものに向き合わないといけないのかというと、3つ目の複雑性（Complexity）です。この後にスケールの話をしますが、ITプロダクトはスケールしていて、組み込み製品とWeb製品が合体したようなソリューション、コネクテッドのようなソリューションが出てきています。扱うものはどんどん複雑になっていきます。

4つ目は曖昧性（Ambiguity）。ユーザーが欲しがっているものは曖昧になっていきます。金融法における金融商品のように、法律にのっとったものであれば仕様をしっかり決めることができます。しかし、そうでなければユーザーが何を求めているかなど我々はわかりません。曖昧な要望に立ち向かっていかないといけない。非常に変動し、まったく先がわからない不確実な中で、我々は複雑なプロダクトを生み出し、曖昧な要求を実現していかないといけないのです。

そして最後、さらにおまけにSが付きます。スケーラビリティ（Scalability）です。それをさらに拡大していかないといけない。

我々はエンジニアとして非常にタフな時代に立ち向かっているのではないかと考えます。

アジャイル開発の旨味は「ビジネスリスクを減らせる」こと

そんな時代に今までどおり物を作っていてはダメというのが、アジャイル開発の基本的な考え方だと私は思っています。アジャイル開発が何かというのは諸説あるテーマです。なので、これはあくまでも「朱峰というおじさんがこう考えている」という1つの指針ととらえてください。

こんなに早い時代の中で、例えば2年、3年かけて物を作っていざローンチしたらまったく買ってもらえなかった。これはもう目も当てられないです。

今日は非常にたくさんの人が参加してくれているので、過去に開発に携わっていた人がいたらたいへん申し訳ないのですが、私がよく使っている例の1つとして3Dテレビがあります。

2010年くらいにいろいろなメーカーが（この商品を）出して、家電量販店に行くと並んでいました。眼鏡をかけることで自宅にいながら3D映像が楽しめる製品だったのですが、今の時代に家電量販店に並んでいるかというと、たぶん並んでいないと思います。今並んでいるテレビは4Kや8Kなど。3Dではなく、2Dをいかにきれいに見せるかという方向に大きく舵を切っていると思います。

「3Dテレビはダメだったんだ」と無下に切るつもりはありません。おそらく開発に携わった人々はいろいろなリサーチをしたのだと思います。いろいろとユーザーリサーチをする中で、「あ、3Dいいんじゃない」と答えたユーザーもきっとたくさんいたと思います。でもいざ出したら売れない。これが世の中のつらいところなのではないかと思います。

いっぱい下準備をして、その上でいっぱい時間をかけていざ出しても、やはり売れない。これが今の時代ですが、これじゃいかんと。

なので、いかに失敗リスクを下げるか。これがアジャイル開発のポイントだと私は思っています。「大きく失敗するより小さく失敗するほうがマシだよね」。これがアジャイルだと思います。

身も蓋もない話ですが、開発のプロセスを変えたからといってすばらしいプロダクトが作れるかというと、そんなことはないと思います。世の中のヒット作は、極めて限られた天才が世に出してるのではないかと私は考えています。ですから、プロセスを工夫したから商品がすばらしいものになるかというと、そのようなことはないのだと思うのです。

ただ、プロセスを工夫することで、失敗のリスクやダメージを減らすことはできると私は考えます。まさにそれがアジャイル開発なのではないかということです。

何もない状態でのヒアリングではなく、ちょっと作ってみて何かしら動くものを出してみて、反応を見て、「こうじゃなかったな。こうだな」と補正して、またちょっと出して、聞いて、また補正して、またちょっと出して、また補正して。

これを繰り返すことで、結果的に同じだけ時間をかけた時に、一発勝負するよりもダメージ・落差を少しでも小さくすることができるのではないかと思います。それがアジャイル開発。細かく区切って繰り返しやっていくこの開発アプローチが、アジャイル開発の本質なのだと私は考えています。

したがって「アジャイル開発とは何ですか？」と問われた場合、私はこう回答します。「VUCAないしVUCASの時代において、ITビジネスリスクを低減させるシステム開発のスタイルです」と。

アジャイル開発には「開発」という言葉が付いていますが、開発のスタイルではありつつ、これが貢献するのはビジネスなのだと。ビジネスリスクを減らせる。これがアジャイル開発の旨味なのだと思います。

なので、アジャイル開発はそもそもどのような領域に適応して、どのような領域に適応しないのかという議論が世の中にはあって、（その議論には）ここが1つの指針になるのだと思います。

すなわち、ビジネスリスクがないシステム、社内の基幹システムなどはいいと思うのです。そういったものはしっかりと計画して、しっかりと仕様を決めて作ったほうが、むしろ手戻りが少ないと私は考えます。

一方で、「これは本当にいけるんだっけ？」というビジネスリスクを抱えた物こそ、ちょっとずつ作って出したほうがいいのではないかということで、アジャイル開発が向いている領域だと私は考えています。

必要なものを適材適所で組み合わせることで、アジャイルになれる

アジャイル開発とは何かという問いに対して、最後に「スタイル」というかたちで結びました。アジャイルとは、状態や（何かを）やっている様子であって、何か具体的なやり方を示しているわけではないと思います。

とはいえ、何もない状態から始めるのは非常に難しいです。でも、世の中の先駆者たちが仕事の具体的なやり方を提示してくれています。つまりアジャイルになるためには、アジャイルな開発を実現するための具体的なプロセスであったり、具体的な技術のアプローチであったりが必要となります。

例えば、リーンスタートアップの考え方や、冒頭で触れたスクラムの考え方などです。リーンスタートアップとスクラムは、どちらかというとプロセス的・段取り的な仕事の進め方の側面があります。一方で、プロセスだけでは物は作れないので、エンジニアリングや技術の領域をしっかりサポートしてくれるエクストリームプログラミング、略してXPなどの技術の体系があります。最初はこういったものを駆使しながらアジャイルに一歩近づいて、自分たち流のやり方を見極めていき、最終的にはそのチーム独自のやり方になっていくのだと思います。

ただ、このような方法論やフレームワークは、最初の取っかかりとしては非常に良いのですが、盲信するのはけっこう危険です。「このプロジェクトはやり方がスクラムじゃないよね」「スプリントプランニングで2時間以上使っているよね」などと、あまりにも体系にのっとり過ぎるのは危険です。

あくまでも目的はアジャイルになることです。自分たちがプロダクトを世に出すためにかかっている時間が短くなっていれば、Be Agileに一歩近づいている。そういった見方をみなさんにはしてもらいたいと考えています。

また、どの技法が良い・良くないというのも良くないと思います。（スライドを示し）例えば、ここにリーンスタートアップ・スクラム・XPの3つが並んでいますが、すべて併用できるものと私は考えます。

リーンスタートアップはどちらかというとデリバリーの外側です。そもそも、ビジネスに対してどうアプローチしていくかという話です。一方でスクラムはその内側、どちらかというとデリバリーにわりとフォーカスしたアプローチの話です。そして、XPは先ほど言ったとおりプロセスではなく技術の話です。プロセスと技術は両輪ですので、併用できるということになります。

したがって、何か1つを選ぶのではなく、自分たちの仕事の進め方に必要なものを適材適所でしっかり組み合わせて使っていくことが、アジャイルになる秘訣だと考えています。

（次回につづく）