プロダクト開発における“不確実性”に立ち向かう

分からないものを分かるようにする

市谷聡啓氏：私のセッションは「分からないものを分かるようにする」というタイトルで発表したいと思います。まず自己紹介から。

改めまして、市谷と申します。ギルドワークスという会社とエナジャイルという会社をやっていますが、本日ブースを出しているのはギルドワークスという会社になります。そこで「新規事業、新規プロダクトを立ち上げたい」「アジャイル開発をやれるようになりたい」というご相談を受けて、そのご支援をしている会社になります。

「越境」や「正しいものを正しくつくる」であったり「仮説検証型アジャイル開発」ということを私自身のキーワードにしております。詳しくはプロフィールサイトがありますので、こちらをご覧いただければと思います。

あとは、『カイゼン・ジャーニー』という本を新井（剛）さんと一緒に書いております。現在4刷目ですね。また、『正しいものを正しくつくる』という本を6月14日に発刊しました。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について

今日はこの本の内容と関わってくるテーマについてお話しようと思います。プロダクト開発をどうやっていくのかについての解説ですね。

他には、ベータローンチしたばかりですが、GuildHubというツールを展開しています。

まだ提供し始めたばかりのものですが、プロダクト開発管理ツールという位置付けです。プロダクトづくりする際、プロダクトバックログを置いてチームで取り組んでいくことになると思います。その中で、特にプロダクトオーナーがやっているようなタスクについて、ツールでまずはフォローできないかと思って作っていってます。

ギルドワークスでやってきたなかで、「こういうツールや支援があればいいのにな」というものがけっこうありましたので、それなら作ってしまおう、ということで作りました。プロダクトオーナーだけではなく、チームで使うものをイメージしています。

プロダクトを作るときにどんなユーザーに提供するのか、どんな問題を解決するのかを「キャンバス」と呼ばれるフォーマットで整理していくことを前提としているツールです。それもWeb上でチームと共有しながら行うことができます。もしご興味があれば、検索していただければと思っております。はい、宣伝終わり！

不確実性の高い状況にどう立ち向かうか

今日のテーマは、最初は本にちなんで「正しいものを正しくつくる」という内容でいこうと思ったんですが、この言葉が非常に賛否両論でして。「正しさとは何ぞや」みたいな話になりがちです。今回は、より分かりやすくなるように「分からないものを分かるようにする」という言葉を頼りにお話をしたいと思います。

お話はまず文脈が大切です。いかなる文脈にも通じるような開発、みたいなものはこの世にないという前提に立ちます。

ギルドワークスでは「新しい事業を作っていきたい」とか「今までとは違うサービスを立ち上げたい」というご相談を受けることが多く、そういった領域をもとにした内容です。

あとは「初めてアジャイルに取り組む」という文脈に置いてもこの話は通用すると思っています。この2つに当てはまる方はぜひ聞いていただければと思います。

ただ、この2つを並べたら「ん？」と思われるかもしれませんね。「これって同じ文脈なの？」と。開発と開発のやり方とで、合致するのかと感じられたかもしれない。

実は共通性を見ていくと、こんな話かなと思っています。

「どっちもどうなるかわかりません」と。このサービス作って、本当にユーザーいるかどうかわかりません。ユーザーが本当に使ってくれるかわかりません、ユーザーがお金を出してくれるかもわかりません、誰にもわかりません、と。仕事のやり方を変える場合でも「このやり方をすれば必ずうまくいく」という術はおそらくありません。なので、どちらも同じ状況に陥ると言えると思います。

問題は、そういう分からない状況になっても、組織やビジネスをやっていく上ではそれでも前に進まなければいけません。いわゆる「不確実性の高い状況にどう立ち向かうか」。拠り所のない中で、それでも前に進むためにはどうしたらいいのか、という話をさせていただきます。

不確実性の中で確実なものを見いだす

そこで基本的な戦略として「分からないものを分かるようにする」ということを頼りにやっていこうじゃありませんか、というのが今日の私の話になります。

言葉としてはわかりやすいですが、具体的にはぜんぜん分からないですよね。ちょっとずつ見ていきますと、まず「分からないものを分かるようにする」というのは、難しく言うとどういうことかというと、「『不確実』な中に『確実』（＝学び）を作る」ということです。つまり「よくわかってない中で分かるところを作っていこう」というのが、この「分かるようにする」という言葉の意味合いになります。

「不確実」な中での「確実」、これは何かをやった、その結果わかったこと、つまり学んだことが確実な部分になります。そういう部分を作っていきましょう、というのが基本的な考え方になります。

一方そういうことをやらずに、分からないものを分からないままに進めたらどうなるか。やったらやったで何か分かるんですが、狙ってわかっているわけではありません。ですので、本当にそのあと役に立つかどうかは分からない。どちらかというと運任せになってしまいます。

分からないものを分からないまま進めるとどうなるか

これをイメージで示すと、こんな感じです。

左側が分からないものを分からないままに進めた場合のイメージ。上の四角が「学習済みのイメージ」ということで、頭の中だと思ってもらえればいいです。この四角がわかったところです。左側は明らかにわかっている領域が少ないです。

分からないまま作ろうとしたら何が生み出されるかというと、下の図にあるようなものができます。これは作り手が想像したものでしかなくて、本当にユーザーに必要なものかどうかは分からない。試してみるとユーザーが想定したようには使ってくれないとか、まったく見向きもされないことは珍しいことではありません。

このように「うまくいくかどうかわかりません、とりあえずやってみよう」みたいな運任せはなかなか大変です。分かることはあとでいろいろわかってきますが、大抵の場合は後の祭りです。機会損失も大きいですね、お金も使ってしまいますし、何より時間を使います。ビジネスでやっていると、ある時点において何かを生み出したいという要請があります。そういうものも間に合わない、なんてことが起きてしまう。「もうこれでいくしかない」みたいなことになって、結局誰も使わないということが繰り返される……という状況があると思います。

右側は「不確実」な中に「確実」を作っていった場合です。分かるための活動を繰り返す中で、だんだんと学習済みの領域を増やしていった例ですね。だんだんとわかってきた上で作っていくプロダクトは、ユーザーが求めるものに近しいものになっていきます。

検証活動における3つのポイント

では、分かるようにするための活動とは何でしょうか？　ユーザーはそもそもどんな状況にあるのかを知らなければなりません。いろんな問題を抱えているなかでも「この我々が取り組む問題は、解決に値する問題なのか」ということも、やはり知らなければいけません。「確かに問題に思っていますけど、お金を出すほどではないです」となると、そのプロダクトは売れないですよね。

そういう「分かるための活動」を「検証活動」と言います。これを重ねることで空白地帯、分からない領域を減らしていきましょう。知識で埋めていきましょう、わかったことで埋めていきましょう、という考え方です。

これをもう一段深めていくと、3つほど、注意しなければいけないことがあります。

まず1つ。何から作ればいいか分からない場合。そんなときは選択肢を広く持ちましょう。決め打ちして「これでいいや」と思って出して、誰も見向きもしませんでした、という場合の時間的損失は大きいです。つまり時間あたりで得られる学びが少ないということになります。

例えば3ヶ月でちゃんと動くMVP作ったとします。だけどぜんぜん見向きもされなかった場合、見向きもされなかったことが分かるわけですが、これを分かるために本当に3ヶ月もの時間を使ってよかったかというと、大抵は割りに合いません。

なので、決め打ちではなくて「これかもしれない」「それかもしれない」「このソリューションはどうだ」といった選択肢を持って進めていき、ダメな選択肢を省いていく、みたいな進め方が良いと思います。

いかに現実に近い状況を作り出すか

2つ目。もっとも「分かる」タイミングはいつなのか。想像しているうちはぜんぜん分かるようになりません。やはり実際にプロダクトを手渡され、それを使ったときに一番分かると思いませんか？　「あ、これいらんわ」とか「これいけてるね」ということが分かります。

なので作戦としては、「いかに現実に近い状況を作り出すか」。ただ、それは時間かけてお金かけて繰り返すことはできないので、コスパよくその状況を作れるかどうかが重要です。

3つ目。この「分かる」という状態を作るために使う「距離」を、段階的に置いていきましょう。「距離」というのは、時間や予算のことですね。段階的に時間・予算を使う作戦を立てましょう。何かを学んだら、それを活かす「次」がないと学んだ意味がありませんよね。なので今の活動が次に活きるためにやっているとするならば、今何をやるべきかと同等以上に「次に何をやるか」が非常に大事です。なので「次」の段階設計を、考えていきましょう。

こういう曲線が、1つの例としてあり得るかなと思います。横軸がリソース、時間だったり予算で、縦軸がリアリティ、現実感ですね。現実感を突き詰めると最終的には現実になりますから、一番上の破線は現実です。

そんなイメージで捉えたときに、一直線ではない傾きの直線があります。例えば最初にランディングページを作っていますね。これはプロダクトとは言えないかもしれませんが、人に対して「こんなのどうですかね」とを聞くには十分です。比較的簡単にできますが、リアリティはまったくないですね。想像は搔き立てますけど、プロダクトではありません。

次の段階にいくと、プロトタイプを提供します。ビジュアルデザインを練り込んであるけど、タップしたらページが進んでいく程度の、紙芝居的なプロトタイプのイメージです。それでも、飛躍的にリアリティが上がっていますね。ランディングページよりはかなりプロダクトに近づきました。見た目だけで裏側のシステムはありません。だから、少ないリソースでも実現できます。

その次の段階から、エンジニアが作り込みを行うイメージになります。例えばフロントエンドだけ実装する。サーバーサイドはまだ用意しないか、それかFirebaseみたいなサーバーレスのサービスを利用してデータ提供だけできるようにする。

その結果よりフロント側の動きが実現できるようになるので、ユーザーにとっては体験ができるようになります。もちろんリアリティも高まります。一方で作りこみが発生していますから、必要なリソースも上がっていきます。

そして最終的にはインターネット上で公開できる機能性等が備わったMVPみたいなものを作ります。リソースも一番かかりますが、代わり現実には一番近いところにいます。

現実歪曲曲線から考えられる戦略

では、この曲線をこう捉えてみましょう。

2つの視点をとって差を見たときに何が言えるかというと、ビジュアルが入ってるただの紙芝居のプロトタイプと、動くMVPでは、横軸は最初の学びを得るまでの時間差がけっこうありますね。当然左側のほうがサクッとできます。もしランディングページを作らずにいきなりMVPを作るとしたら、最初の学びを得るまでにこれだけの距離がかかる、とイメージできます。

一方縦軸は、得られる学びの量や質です。学びの質というのはより現実感のある反応に基づいた学びというイメージです。これにも差があります。当然ながら現実に近い手段を提供したほうがリアリティのある反応になります。「こんな感じになるんだ」「こうしたらこうなるんだ」「なんかこうじゃないな、この動作がおかしい」みたいな、具体的な反応になっていきます。

ただポイントは、この差があったとしても、最初の学びを得るには左下で十分なことがあり得るわけですよね。何を作るべきかまったくわからん、みたいな極端に下の状況だとすると、いきなり右上ではなく、左下のほうを提供するだけでもたくさんのことが学べます。早く学びを得ることのほうが、お金をかけてリアリティを作るよりは、作戦としては有利じゃないかなと思います。そうしたら次のアクションを変えることもできますからね。

こう捉えると、MVP的なものを提供しいこうとするときに、こんな力学がはたらいていることが分かります。

まずリソースをできるだけ最小化したい。お金がもったいないということもありますが、それ以上にリソースを少なくしたいのが時間ですね。ちょっと学ぶのに3ヶ月かかっていたら、あっという間に1年経ってしまいます。そうじゃなくて早く分かるように、力学的にはこういう力がはたらくわけです。

ちなみにこの曲線、「現実歪曲曲線」と名付けました（笑）。「現実じゃないけど現実に近い状況を作り出したい」ということで、イメージでこの名前にしました。

少ないリソースで最大の検証結果を得るためには

さて、当然ですが効果は最大化したいですよね。どうにか上方向にいけないか、という力がはたらきます。では、効果的な学びがこういうイメージになるとするならば、この曲線の中でどこを狙っていくか。

矢印の通りに考えると、曲線上ではないところにあります。できるだけこういうずるいやり方ができないか、初期の段階こそ考えたいわけです。

例えばコーディングを必要とせずプロトタイプを作るツールが実際ありますね。そういうものでより動きのあるものを提供していく。なおかつリソースもMVPをつくるよりは小さくて済む。

あるいは左上がもっともチートですね。代替製品によるMVP検証です。これはどういう意味かというと。例えばプロジェクト管理に関するツールを新しく作るとします。何らかの切り口、新たな問題意識に基づいて新製品を構想する。一方、世の中にはプロジェクト管理ツールなんて山ほどありますよね。

そういう既存の製品担いで検証にいくんです。そうすると、当然リアルな反応が返ってきます。もちろんそこで取りたい観点は、競合他社の製品では足りない機能がある、あるいはぜんぜん適応できていない課題があるはずだということです。そうした仮説が代替製品を与えたときに本当に出てくるのか、ということを検証したいわけです。

出てこないとしたら、仮説が間違ってるかもしれないので、もう作る必要はないと言えるかもしれません。もしくは、「いやぁこのリストでは、バックログ管理をするのムリなんですよ」という意見が出てくるかもしれない。そうなった時には、自分たちの立てている仮説と合致しているんじゃないかと想像することもできます。

であれば、次は新しく自分たちでMVPを作って試していくという判断がとりやすくなります。

複数の検証を並列に行う

一方、大企業での戦略はまた一段変わってくるなと思います。大企業で大戦略ということで、大企業らしく予算を投下してしまいましょう。戦略の1つに「選択肢を広く持とう」というのがありましたよね。まさにそれをやろう、ということです。1個の曲線をちまちま持っていくなんてことはやらずに、複数の曲線を全部並べてあり得るパターンを試していくと。

ある課題を解決したいとき、Aソリューション、Bソリューション、Cソリューションがあったとしたら、それぞれプロトタイプを作るのかランディングページ作るのか、それぞれ試していきます。もちろん試してみたら「これはあかん」ということもわかるので、今度は段階的にあかんやつを省いて、より精度のある、現実に近いプロトタイプを残った選択肢で作っていきましょう。

これはけっこう有意義ですよね。1つの曲線を検証するよりも、いろんな選択肢を同時に試して返ってくるので、より短時間で学びをたくさん得られます。そんな戦略は大企業であればとれるはずですし、とっていくことに優位性があります。

もっと言うと、そもそも扱う課題をA、B、Cと並べてそれぞれ試しましょう。そういう大企業らしいスケールの進め方もぜひやっていただきたいなと思います。