正しいものを正しくつくれているか？　プロダクト開発における「問い」の重要性

なぜ「決め打ち」が起こるのか

市谷聡啓氏：ただ、現実においては決め打ちと言いますか、「経験はないですけど想像するとだいたいこうだと思うので、こう作ります」。あるいは「想像だし決め打ちだけど、いきなり超リアリティのある製品を作ります！」みたいな話も、決して珍しいことではありません。

もちろん一番リアリティの高いものを提供するので学びもありますね。ですが、時間あたりの学びの量が少なくなる可能性が高い。また、もう1つ厄介なのが、関係者との期待を合わせにくいこと。その製品を見たときに関係者が「これでいけるんじゃないの？」と思う。思うのは勝手なんですが、実際にユーザーが使うとなるとまったく検証ができていないので見向きもされないということが往々にして起きます。

するとまったく期待と合ってないので、いざ事業化やっていくぞ、みたいになったとしてもあっという間に頓挫する。つまり、検証結果が出ていないのに、事業自体は進める判断をしてしまうというケースです。

想像だけで決め打ちでいきなり製品を作ってしまうことは、言葉にしたら誰が見ても「このやり方は間違ってるでしょ」と感じると思います。でもなぜそんなことが起きるのか。みんなまじめに考えてるのになんでそんなこと起きるのか。

それは、今までやってきたやり方、考え方、当事者として現実を進めていく過程で目の前の環境、状況に最適化していくことで、ほかの考えや行動がとれなくなっていくからです。何かを作り出そうとしたら詳細なことをつきつめて考えていくので、どんどん状況が詳細になっていきます。

詳細に考えていくと細部のことは形になっていきますが、一方で失っているものもあります。それは「俯瞰的にものを見る」ということです。「そもそもこの活動で大丈夫か」とか「そもそもこのプロセスいいのか」みたいなことに、なかなか気付きにくくなります。

例えばスプリントの中で「必要なバックログを想像してリファインメントしよう」という言葉だったり、「ここは一旦仮決めでいきましょう」「つくって試そう」みたいな言葉は、別に珍しい会話ではないと思います。それが間違ってるかというと、たぶん間違ってはいなくて、前に進んでいける意見です。

ですがこの言葉によって、違う可能性、違う行動、違う思考を無意識に封じ込めてしまっています。そういうことが起きているんじゃないか、というのが問題提起です。

自分がやっていることを「問う」

では、そこで何ができるかというと、問いを挙げることです。自分たちを立ち止まらせる、「これでいいのか」「このバックログでいいのか」「この進め方でいいのかか」ということを問い、ほかの可能性を考えましょう。それが「正しいものを正しくつくれているか？」という問いなんですね。

「正しいものを正しくつくる！　正解を探しに行くぞ！」という話ではなく、「本当に俺たち大丈夫か？」ということを省みるための問いです。

問いは自分たちの思考や行動に別の方向性を与えます。考えたこともないことを考えられる可能性があります。絶対的な正解なんてない、とみんなわかっていますよね。それを踏まえて、自分たちの思考や行動に誤りが混入していないか。気付いていたら当然正していけますが、気付けないから困るんです。では、気付けないことに気付くためにはどうしたらいいか、という話になります。

そのために問いを置く。問いは、「強制的に置ける制約」だと思います。

制約を置いて、その制約のもとで考えようとしたときに何が起きるか。人は制約を置かれたとき、その制約のもとで最適な解を見つけようとします。

例えば「重要なものを選べ」と言ったところで、「全部重要です！　今すぐ、早く欲しいんです」という話になります。これでは選べません。

ですが「重要なものの中からトップ3を決めようじゃないですか」という場合は何をするかというと、おそらく並べてみて1個ずつ比較していくと、重要そうなものが上位3つに並んでいる、という状況を作ることができそうですよね。

この時に起きているのは、基準づくりです。この「トップ3を選び出した」というところには、何か基準があるはずです。

セキュリティとコミュニケーションはどちらを重視するべきなのか、「この文脈だったらセキュリティか」みたいに、何か基準を作り出すからこそ、順番を決めることができます。

そういった基準がプロダクトオーナーの中にしかなかったり、逆にプロダクトオーナーの中にはなかったり、チームもぜんぜんわかってなかったりすることもあります。

「問い」によって、新たな可能性が考えられるように

プロダクトのあるべき姿を最初からわかっている人はいません。永遠にわからないかもしれません。自分たちが気付ける射程距離、気づける範囲をイメージしてみます。

いろいろとやっているつもりだが、わかってるのはこれだけしかないかもしれない。

次に問いを置きましょう。

自分たちの意識に囚われない、「むしろ今までのやり方が正しい」と思ってる、そんな意識に囚われないところに行くためには、「本当に自分たちの活動は間違いないのか」ということに向き直らなければいけません。そのための問いの1つが「正しいものを正しくつくれるか」です。

本当にユーザーのことをわかってるのか、どこまで理解できているのか、もっと理解できるようになる活動はないのか。こうしたことをどれだけ考えられるか。「正しいものを正しくつくれているか」という問いが気に入らなければ、「美しいものを美しくつくれているか」でもいいですよね。それは皆さんで好きに選べば良いと思います。そのチームの文脈に合ってるもので問いかけてみるといいのではないでしょうか。

そういうことをやっていくと、相対的に自分たちの活動や思考を点検し直して、より可能性がある方向性を初めて考えられるようになります。それによって新たな学びが得られるんじゃないか、という考え方です。

おそらく「ようわからん」という不確実性の高い状況ほど、回答可能な問いに答えてもしょうがないんです。どう答えても「わからないままじゃないか」と（笑）。発見が足りない状態になります。むしろ回答不可能な問いをあえて置くことで、自分たちの行動・思考のリミットを外す。それによってあるべき姿に近づいていこう、というのがこのお話の本質です。

では具体的にはどうやっていけばいいのか。そのアイデアの1つが、「仮説検証型アジャイル開発」です。

別にこれじゃなきゃダメという話ではありません。僕はいろいろな体験からこれに落ち着いてます、という話ことです。この詳しいところは本を買って読んでいただきたいと思います（笑）。

ケーススタディ

ただ「理屈はわかった。だけど本当にできるのか」と思われますよね。そこで、ケーススタディをすこしだけご紹介します。伝統的な環境ほど仮説検証をしながらアジャイルで作る組織へ移行するのは難しいと言えます。伝統的な環境、もっとも伝統のモメンタムがかかる組織というのは何か。それはもちろん、みんなご存知「霞が関」ですね！

（会場笑）

昨年度の後半、経産省のプロジェクトをやっていました。助成金や補助金ってありますよね。お金を貸してくれたり、もらえたりする制度です。そんな仕組みが中小企業や、小規模事業者向けに提供されました。そのための情報提供サイト、「ミラサポ」というものがあるのですが、経産省の中ではこれが活用されてないんじゃないか、必要な人に必要な情報が届いてないんじゃないか、と考えられていました。そのために、なにかしようと。

出てきたアイデアは「スマホ向けにプッシュ通知したらいいんじゃないか」とか、いきなりそういう話が出てきたりするわけです。これは「大丈夫か」というという話になりました。これは本当にユーザーに必要とされるのか。

もう1つ「アジャイル開発でいきたい」と彼らは明確に考えていました。これだけアジャイル開発が世の中に広がっている中で、国が調達の段階でぜんぜん考慮できないのはどうなんだ、じゃあ自分たちでやってみて必要な調達の仕方のあり方を考える、と1歩進んでます。

「アジャイル開発でいきたい」。これはいいんですが「アジャイル開発」だけで何を作るべきかが見えるかというと、そういうわけではありません。というのは、やはりユーザーはどんな状況で、こんな課題があって、という仮説を立てて検証し、一番勝ち筋の良さそうなソリューションを起こしていくという活動が必要になります。

当然こんな活動の必要性が調達の仕様書に書いているわけがないので、プッシュ通知を送るという話の前に、こういった活動をやらなきゃいけませんよ、ということでプロジェクトに組み込むことにしました。

具体的に何をやったかというと、まずは集まっている関係者の共通の認識が何なのか、というところでインセプションデッキを作りました。いろんな部署の人が集まってきていますから、認識がずれている可能性がおおいにあります。だからデッキを作ろうと。

そのあとに仮説キャンバスを作って、どんなユーザーでどんな状況なのか、「中小企業」ということはわかっていますが、もっと解像度を上げてユーザーの状況を取りに行かなければいけません。そして仮説を立てたら実際インタビューに行く。これもまた、リソースをあまり使わず効果を上げるための1つの手段ですね。いきなり作るのではなく、まずは反応を見に行きましょうよ、ということをやります。

これはチームで取り組むことなので、経産省の人たちを含めてユーザーインタビューに行きました。やり方については本にも書いてますので、ぜひ見ていただければと思います。

仮説検証をしてわかったこと

プロジェクトの詳細の話は触れられませんが、仮説検証をやっていくと、状況や問題について分かることが増えていきます。状況を深堀りしていくと「検索の機能がわかんないです」みたいな感じではありませんでした。「そもそも自分たちが助成金を使えるかどうかまったくわかりません」みたいな状態になってたりするんですね。

支援策適用の条件が難しすぎるんですよ。そして言葉も難しい。言葉も理解できないし条件も複雑なので、自分のやろうとしていることが本当に当てはまるかどうかもわからない。そんなこと考えるなら、自前のキャッシュでやれるとこやっていこう、ということを考えます。その結果、利用が進んでいないことが分かりました。

そういうことに対するソリューションの仮説もいろいろあります。探すということにそもそも無理があるから「探さない」という手段がいいんじゃないかですとか。この中身について詳細はお話できませんが、ソリューションの方向性を見定めて、プロダクトにしていこう、という流れでやっていきました。

関係者の人たちも「プッシュ通知送ればとりあえずいいでしょ」なんて思っていませんよ。だけども、どうやって自分たちがユーザーや理想的なプロダクトに近づけるかわからない、その手段もわからないという状況でした。だからこそ今回のような仮説検証が必要なのです。このプロジェクトでは、検証して想定ユーザーの状況を理解して、可能性を高めて進めていくやり方を取ることができました。

逆境にある組織を後押ししたい

最終的にどうなったかというと、リリースしませんでした。いろいろ検証をした結果「このまま出してもほぼ使われない」ということになったので、もう少し検証を続けようということになり、年度をまたぐことになりました。

私自身は、こういう「分からないものを分かるようにする」作戦を広げていきたいなと思っています。例えば地方の跡継ぎで、老舗の企業を継いで新規事業を立ち上げなきゃいけない、どうしよう、みたいなことが日本にはけっこうあります。ここには可能性があると思うんですよね。なので、ここにも届けていけたらなと思っています。

また後半に話したケーススタディに関しては、おそらく自治体も同じような状況なんじゃないかなと思っているので、ここにもいろいろな知見が提供できたらと考えています。また、大企業のみなさんも逆境にあるのではないかと感じてます。なぜなら勝てそうなあの大戦略とか、誰もとらないですもんね。それはとれない事情があるわけです。みんなちゃんと考えた上でとれない事情があるわけです。

そういう逆境の中で、それでも前に進もうとしている人たちを後押しするために、こういう活動や発表をやっていきたいな、と思っています。

ということで、私の話は以上です。どうもありがとうございました。

（会場拍手）