不確実性と向き合い続ける

毎週更新 #PdMノウハウ の第4回目のnoteです。第3回目のnoteは「プロダクトを成功に導くための意思決定」でした。もし良ければ読んでいただけたら嬉しいです。今日はプロダクトマネージャー (PdM) と切り離すことができない不確実性と向き合うことを言語化したいと思います。

不確実性とは

「不確実性」はとても抽象度が高い言葉であり、エンジニアリング的な側面や新機能リリース、広くはプロダクトの成功などの側面を持ちます。このnoteでは噛み砕いて「プロダクトそのもののから、機能改善、新機能リリースなどにおける、成功するかどうかの尺度」として扱います。つまり、不確実性が低い状態とは、プロダクトが成功するかしないかがある程度わかってきている状態にあります。

不確実性をエンジニアリングの観点から捉えてみます。「エンジニアリング組織論への招待」という本を是非とも読んでいただきたいのですが、この本の中に不確実性コーンという図があります。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

プロジェクトがスタートした時が最も不確実性が高い状態です。この状態においては次のようなやりとりがよくあると思います。

PdM「〇〇を開発するのにどのくらいの工数が必要ですか？」
エンジニア「ざっくりとですが、早くて2週間くらいで、遅くても3週間あれば終わると思います」

PdMはざっくりとしたスケジュールを作成し、ヒアリング結果を元にしてエンジニアと合意してリリース日を置きます。最初に引いたリリース日通りに事が進むことはほとんどないと思います。実装をしていく中で、要件定義が甘く仕様が変更になる、想定できなかった解決しなければならない技術的な壁にぶち当たって工数が増えるなど多くの困難が生じることもあるかと思います。基本的には実装が進むにつれ、不確実性が低くなっていきます。この「不確実性を減少させる知識」のことを本の中では「情報」と定義されています。PdMはこの「情報」を集めて不確実性と向き合っていきます。これはエンジニアリングの観点ですが、このnoteではプロダクトマネージメントにおける不確実性を捉えて「不確実性を減少させる知識」のことを「学びを得る」と表現したいと思います。

ノーコードで向き合う

プロダクトマネージメントにおける不確実性をここでは「この施策、機能、プロダクトをリリースした際の成功するかどうか」として扱います。PdMとしていつも悩まされることかと思います。実際、成功する確度がある程度わかってる施策ならば、そんな簡単な話はないかと思います。いずれにしても不確実性は存在していて、最終的にはリリース後においてその成功がわかります (つまり最も不確実性が低い状態) 。

しかしながら、プロダクト開発においてデザイン、エンジニアリソースは非常に貴重です。そして、リリースという行為はプロダクトのフェーズが進むにつれてコードの複雑性、開発の仕組みなど様々な要因から工数が大きくなってしまいます。できれば、デザインやコードを書くことなく不確実性を落とす方法を模索したいです。

まず、既存のプロダクトにおいて同様の機能が提供されていないかを調べてみましょう。例えば、マッチングアプリのPdMをしているとしてメッセージ機能において画像を送れる機能を実装しようとします。メッセージ機能において画像を送れる代表格はLINEでしょうか。まずはLINEをユーザーに使ってもらい、ユーザーインタビューを通して「学び」を得ましょう。次に業界は違ったとしてもマッチングに近いプロダクトにおいてメッセージを送れる機能があるプロダクトでユーザーインタビューをしてみましょう。画像を送ること自体は簡単だったとしても、ユーザー心理における障壁や思いも寄らなかったことが得られるかもしれません。

次に解決しようとしている課題が本当に課題として存在するかを既存プロダクトを使って調査できないかなどを模索してみます。Google Formでも良いかもしれないですし、ビザスクのような専門家に聞けるプロダクトを利用してもいいかも知れません。知り合いにヒアリングするだけでも十分に不確実性を落とせることもあります。コードを書かずしても不確実性を落とす方法は無限に考えられます。簡単に実装することなく、本当に開発が必要なものかを今一度考えてみると良いと思います。

プロダクトタイピングで向き合う

新プロダクトや機能のプロトタイプを作成し、不確実性を落とすアプローチは多くのPdMが実際に行っていることかと思います。幸いなことに、プロトタイピングツールは非常に充実しています。ググれば沢山の記事がヒットするので、ここではプロトタイピングツールの紹介はしません。プロトタイピングツールなどを使用してプロトタイプを作成することの本質は、ユーザーが評価可能な具体性を持った擬似的なプロダクトを通して学びを得ることです。

このスライドにあるように、プロトタイプにはFidelity (忠実度) という概念があります。具体的にはLow-Fidelityはペーパープロトタイプやワイヤーフレームなどで、High-Fiedelityは実機で動く本物に似せたプロトタイプです。プロトタイプを作成する時に最も注意しなければならないことは、そのプロトタイプは学びを得ることができる最低限度のFidelityであるかということです。実機で確認できると良いですが、その分の工数が発生してしまうため、よく考える必要があります。スマートフォンのアプリを開発をしている場合は本番に近いデータの検証環境と開発中の実機をつないでユーザーインタビューをすると実際にリリースした際に近い「学び」を得る事ができます。

リリースして向き合う

もっとも不確実性を減らすことができる方法はリリースをして定量的、定性的なユーザーの反応を見ることです。プロダクトの初期フェーズであれば、この方法の方が素早く学びを得ることもできると思います。慎重になりすぎてスピードが重要なフェーズでプロトタイプを作成して不確実性を検証していては競合との差がついてしまうこともあります。プロダクトがまだPMFしているかどうかわからない状態の時などはリリースしてしまった方が早いかも知れません。

また、フェーズが進んだプロダクトにおいてもリリースしてしまった方が早いこともあります。競合サービスが実装していてほぼ確実にユーザーに受け入れられるであろう (つまりは初期から不確実性が低いであろう状態) となれば、リリースを急いだ方がプロダクトは成功に近くかも知れません。

しかしながら、一つの機能でもリリースをしてしまえば好んで使ってくれるユーザーはいるものです。好んで使っているものがある日プロダクトから取り除かれたとして、少数ながら離脱してしまうユーザーもいるかも知れません。そこまで臆病になることはないかも知れませんが、ある変更をリリースするということはユーザーにとっては大きい変更になることもあるので、できる限り慎重にした方が吉かと思います。

最後に

不確実性を落とすために何をすべきかという本質は、不確実性は何かということに向き合い、どうすれば不確実性を減らすことができるのかを考えて、様々な方法からアプローチすることです。手法に拘らずに、どのように「学び」を得ていくか。PdMは不確実性に向き合い続けられる強いチームを創るにはどのような仕組みを整えていくべきか。そうに考えるきっかけだけでも生まれてくれれば幸いです。