認識違いの事例から考える、プロダクト開発における「不確実性」の意味と潰し方
こんにちは。UbieでAI問診サービスのプロダクトオーナー（PO）を務めている、まつむら（@matsumura_ubie）です。
今回は、Ubieの2020アドベントカレンダー4日目の枠で、プロダクト開発における「不確実性」について再考してみたいと思います。
【特にこんな人に読んでほしい】
・プロダクト作りに関わる全ての人（エンジニア/非エンジニア問わず）
・"PoC"が何なのか、分からなくなってきた人
・"リーンスタートアップ"を読んでも行動に踏み出せない人
なぜ今さら「不確実性」なのか？
Ubieでは、会社の立ち上げ当初からリーンなプロセスでプロダクト開発を進めています。リーンな開発とはつまり、最も大きなリスクを潰すことにフォーカスしつづける開発です。AI問診ユビーは、すでに医療機関の業務効率化ツールという側面では、おかげ様で多くの医療機関にて導入実績を積み上げる段階になっており、既存機能の改良・拡充を進めています。一方で並行して、医療従事者の未解決の課題に対し、全く新しい価値を提供するべく、新しい機能の開発もガリガリと推進しています。
私が先代からPOを引き継いだのは9ヶ月ほど前ですが、エンジニア/非エンジニアに限らず開発メンバーの多くは、すでにリーンな開発やスクラムに大なり小なり習熟していました。一方で、チームも大きくなり、あらためて新しい課題・機能の開発に取り組む中で、「認識違い」が起こり、多少なりとも非効率な部分が出てきてしまったのも事実です。
そこで今回、開発の中でどのような「認識違い」が起きたのか、その原因は何だったのかを言語化しつつ、あらためて「不確実性」の意味と向き合い方を考えてみたいと思います。
※お断り：新機能については現在も開発・検証中ですので、具体的な説明ができません... 読みづらいかもしれませんが、ご自分の関わるプロダクトに置き換えてみてください。
AI問診の新機能開発で、何が起こったか？
大小様々な失敗と学びがありますが、今回は2つ取り上げます。
【1】どの不確実性を潰すのか（What）が明確でなく認識がすれ違うことがあった。
【2】適切な不確実性の潰し方（How）の認識がずれ違うことがあった。
具体的にどんな非効率が起きたのか説明します。
1つ目の、どの不確実性を潰すのかの認識違いでは、例えばユーザーインタビューで聞いておくべきことを一部聞き漏らしたり、仮説の検証に必要な機能以外の細かい部分も開発してしまったり、といったことが起きました。
2つ目の、適切な不確実性の潰し方の認識違いでは、検証項目を盛り込みすぎてMVPが大きくなってリリースが遅れたり、果たして機能が使われるのかどうか確信が持てないまま進んでしまったり、ということが起きました。
どれもこれも、振り返ってみると「教科書に書いてあるような失敗事例では」という感じではありますが、実際に起きた課題から経験主義的に学ぶという意味でも、あらためて整理してみようと思います。
そもそも不確実性って何？
Ubieでは「不確実性」という言葉が頻繁に飛び交います（特に、代表の阿部・久保はよく使います）。私個人は時々、この「不確実性」という言葉が何を指しているのかよく分からず、抽象的な議論についていけずモヤモヤすることがありました。単に私が具体的なイメージに変換できていなかったというのもありますが、どうやら「不確実性」という言葉が指すものが人によって微妙に異なっているようでした。
リーンなプロダクト開発における「最も大きなリスクとなる不確実性を潰す」という行動原則を大切にするからこそ、「不確実性」という言葉の定義と認識合わせが重要です。
不確実性とは、不確かだということ、まだ確実ではないことです。多くの場合、確信が持てない、と言い換えることもできそうです。何を当たり前のことを...と思うでしょうが、不確実性 = 分からないこと、と言い直すと実は2つの意味を含んでいることがよく分かります。
一つは、選択肢が十分に分からないこと。もう一つは、その選択肢が適切なのか分からないことです。唐突ですが、おいしいキノコを探して持ち帰る、という例で考えてみます。山に入って30分歩いたら、キノコが3種類見つかりました。「本当にキノコって3種類なんだっけ？ 他にキノコは無いんだっけ？」というのが「選択肢が十分に分からないこと」です。そして、それぞれのキノコが美味しいのか、食べて体が痺れてしまわないか、は試さないと分かりません。これが「選択肢が適切なのか分からない」に当たります。
繰り返しますが、不確実性とは、選択肢が十分に分からないこと、選択肢が適切か分からないこと、の2つを指しています。逆に言うと、これ以外のものは不確実性ではないです。よくある間違いですが、うまく行かないこと、選択肢が不適切だということは不確実性ではありません。選択肢が適切ではないとすでに分かっているからです。理屈では分かっていても、意識しないと時々この間違いは犯します。
不確実性を潰す、って何？
次に、不確実性を潰すとはどういうことなのか、考えます。「選択肢が十分に分からない」という不確実性の場合は、探索を行う必要があります。行動観察（エスノグラフィー）でもインタビューでもブレストでも、何でもいいので選択肢を生み出す必要があります。一方で「選択肢が適切なのか分からない」という不確実性の場合は、とりあえず試してみるのが早いです。もちろん、毒キノコを食べて死ぬ可能性がある、ということであれば化学的に分析する若干面倒なアプローチを取らざるを得ないでしょうが、まあせいぜい痺れる程度なら食べるのが一番早いし確実です。
では、プロダクト開発において、どちらのタイプの不確実性を潰すことが、より困難でより重要でしょうか？ 顧客や課題や事業ドメインにもよりますが、多くの場合は後者の「選択肢が適切なのか分からない」不確実性の方だと私は考えます。なぜなら、キノコに毒があるかどうかはともかく、美味しいのか口にあうのか、もっと言うとキノコを買ってもらえるのかどうかは、ユーザーに食べてもらわないと判断がつかないからです。つまり基準がユーザー（=他人）にあるので、巻き込んでいくことが必要不可欠です。
一方で「選択肢が十分に分からない」という不確実性は、自分たちでいち早く解決すべきです。なぜ自分たちでできるかと言うと、一つは全ての選択肢を取り尽くす必要はないためです。世の中にある全てのキノコを食べ比べのテーブルに乗せる必要はありません。それなりに美味しいキノコを見つけ、食べて買ってもらえばいいだけです。またもう一つ、キノコを探す手立ては色々あるためです。そもそも、キノコに詳しい人を探索に巻き込めば、あの山にたくさん生えてる、樹木ごとに生えるキノコは違う、など選択肢は広がるはずです。逆にいうと、キノコがどこに生えてるのか分からないのでとりあえず海に潜ります、という類のナンセンスな探索を始めたら、アプローチを絶望的に間違えているので活動をやめたほうがよさそうです。
いち早く仮説を立てて検証する
ここまでの話から、不確実性を潰すためには、いち早く選択肢を広げて、その選択肢が適切かどうか試す、ことが重要そうです。
さらに効率よく不確実性を潰すために、筋のよい仮説を作ることが大切です。キノコを30種類、片っ端から食べていって29番目のキノコが美味しかった、という行き当たりバッタリでもいいですが、時間がかかりすぎるし、大抵の場合は資金が尽きます。最初から毒のありそうなキノコを弾いて、美味しそうなキノコから食べていけば、もっと効率的においしいキノコにたどり着けます。経験やドメイン知識、なんらかのヒューリスティクスを用いて、いかに筋のよい仮説を立てて、いち早く適切かどうかの検証に移れるか、がキモになりそうです。
どの不確実性を潰すのか、認識を揃えるために
キノコの話が続きましたが、ようやくUbieのプロダクト開発の話に戻ってきました。開発チームでは、PBI（プロダクトバックログアイテム、開発チケット）を作成する際に可能な限り、どの不確実性を潰すための開発なのかを書くことにしました。つまり、
①この開発はどの選択肢を表しているのか？（ = どのキノコを指しているか）
②この開発が筋のよい仮説だと考えられるのはなぜか？（ = なぜこのキノコが適切だと思われるのか）
③この開発は何を評価しようとしているのか？（ = ユーザーが手に取るを試しているのか、美味しさを試しているのか、買うのかを試しているのか）
の3つを1文で簡潔にチケットに記載し、起案者も開発者も認識を揃えようとしています。まだ、必ずしもうまく表現できているわけではないですが、これによって違うキノコを調理したり、キノコの見た目にこだわったり、といった非効率やミスコミュニケーションは起きにくくなってきていると思います。
不確実性の潰し方、それぞれに適した方法
【2】適切な不確実性の潰し方（How）の認識違いについて、分析してみます。開発チームでは、Figmaによるモックアップ作成とインタビューにかなり時間をかけ、ソリューション仮説をもりこんだMVPの開発が走り、結果的にリリースが少し遅れてしまった、ということが起きました。幸い、インタビューでしっかり確認していたので、MVPの仮説は外していないと言える結果でしたが、この事例をもとに、何から・どのように検証するのがよいのか、振り返りをしました。
プロダクトの不確実性を潰すために、実現性やコストパフォーマンスの観点で、ユーザーインタビューとプロダクト（MVP）のテスト、の2つのアプローチが多用されると思います。それぞれのアプローチで、どの不確実性を潰せるのでしょうか。
PSFはインタビューで確認し、プロダクトで検証する
PSF（Problem Solution Fit）という言葉があります。ユーザーの課題に対して、ソリューション（＝プロダクト）の方向性が合致している状態を指します。PSFを達成するためには、優先順位の高い適切な課題を捉えられていて、かつそれを解決しうるソリューションが提示出来ている必要があります。
この段階では、インタビューベースで顧客の課題の優先順位や切実さを把握し、モックアップや紙芝居、イメージ映像などでソリューション案が課題を解決しうるものであるかを検証することが多いです。従って、プロダクト（MVP：Minimum Viable Product）を開発せずとも、ある程度確信を得ることができます。
一方で、課題とソリューションが適切なのか、その不確実性を十分に下げるためには、プロダクト（MVP）による検証もやはり必要ではないかと思います。実際に使ってみたら、これは実はそこまで切実な課題じゃなかったとか、よさそうなプロダクトだけど"自分は"使わないかも、といったことが起こるからです。
下記を話あって決めました。これから開発チーム全体で実践・浸透していくつもりです。
・課題とソリューション案の適切さは、インタビューで"確認"し（確信度50%くらい）、さらにプロダクトで"検証"すること（確信度95%？くらい）。
・課題とソリューション案の適切さ、とはWhy/Who（なぜこの課題なのか、誰の課題なのか）とWhat（このソリューション案でいいのか？）のことです。
・プロダクト開発はリードタイムが必要なので、いち早くリファインメントに着手し、早々に確信度95％になるよう検証すること。
PMF（継続利用）はプロダクトで検証する
上記、MVPで「これが課題だったんだ」「このプロダクトで解決できそう（お金払ってでも使いたい！）」という検証が出来た後は、本当にそれを継続して使ってくれるのか、の検証が必要です。課金して、継続利用してくれるユーザーが一定数いれば、PMF（Product Market Fit）したと言えそうです。
継続して利用してくれるためには「実用に耐えうる」ことが必要です。もちろん、欲しい機能が全て揃っていて、ユーザービリティが完璧、なんてプロダクトはほぼ存在しないので、大きな使いにくさを潰していって、細かい不便さを飲み込んでも提供価値が圧倒的に上回る、というレベルまでUI/UXを引き上げることになります。
今回あらためて、UI/UXの検証は、インタビューでは難しいということが確認できました。もちろん、いつ・どんな手順のワークフローがあるのかを理解するためにインタビューは有効ですが、情報の出し方、操作の仕方をインタビューベースで聞くのは困難です。モックアップに対して返ってくるのはアイディアと感想が多くなってしまうため、価値提供を最大化するために本当に必要なUI/UXが何なのか、はプロダクトでの検証のほうが適切です。「今のプロダクトで、どこが使いにくいか？ 何が足りないか？」という質問が、一番クリティカルな意見を引き出せると思います。
今検証することに応じて、適切なアプローチを取る工夫
上記の教訓を得て、開発チームでは次の2つを意識し始めています。
1. 今、どのフェーズのどんな不確実性の検証なのかを意識し、なるべく早くプロダクトを通じた検証ができるようにする
これは先ほど書いたとおり、確証を得るためには実際に使ってもらう必要があるためです。「本当にそれが課題なのか？」「このソリューションの方向性で課題を解決しうるのか？」であれば、インタビューである程度の確認をし、プロダクトで確度を上げるべきですし、「どうやったら負荷少なく継続して使ってくれるのか？」に関してはやはりなるべく早くプロダクトをベースに確認しよう、ということです。
2. インタビューで補足的に分かった情報や仮説は開発に連携する
インタビューの結果には、様々な情報を含みます。不確実性を検証した結果もあれば、ユーザーからの感想やアイディアなども含みますし、またそれらを元にチーム内で考えた仮説なども生まれます。
これらの情報は、PBIを起票してプロダクト開発する時点で、なるべく損失なく連携しよう、ということを意識するようにしています。と言っても、例えばインタビューメモ・サマリーを共有したり、仮説検討したメンバーとクイックに話をしたりするだけです。ですが、PBIに記載されたAC（受け入れ規準）だけではやはり情報損失が起きて、インタビューで得られている仮説が再発明されたりする非効率が発生するので、都度都度分かっていることをメンバーで同期するのは意外とよさそうな取り組みです。
まとめ
【1】どの不確実性を潰すのか（What）が明確でなく認識がすれ違うことがあった という課題に対して、下記の取り組みを行っています。
・「不確実性」が何を指しているのかを確認する
・しっかり「仮説」を持って不確実性の検証を行う
・PBIを起票する際に、どんな不確実性検証を行うものなのか言語化する
また【2】適切な不確実性の潰し方（How）の認識がずれ違うことがあった、という課題に対して、下記の取り組みを行っています。
・インタビューで確認し、なるべく早くプロダクト（MVP）で検証を行うよう意識する
・今、どのフェーズのどんな不確実性の検証なのかを意識し、なるべく早くプロダクトを通じた検証ができるようにする
・インタビューで補足的に分かった情報や仮説は開発に連携する
上記の取り組みは、まだ着手したばかりのものも多いですが、意識してチームの共通言語を揃えていくことでどんどん習熟し、今何をやっているかの認識や情報伝達の密度が上がっていっているのを感じます。
このように、進め方そのものを経験主義的に学びながら、プロダクト作りそのものが効率化していく取り組みはとても刺激的です。一緒に開発してみたい、あるいは意見交換をしたい方は、ぜひお声がけください！
この記事が気に入ったらサポートをしてみませんか？