プロマネが考える「いい失敗」と「悪い失敗」は？ プロダクトを成功に導くための“小さな失敗”

失敗せずに成功するなら、もちろんそれが一番いい。しかし、人は成功への道筋を必ず知っているわけではないので、失敗はつきものだ。「Web担当者Forum ミーティング 2024 春」に登壇したキャディの飯沼亜紀氏のセッションでは、小さな失敗をデザインすることで大きな失敗を回避し、目標を達成する方法について掘り下げた。

プロダクトマネジメントの考え方

プロダクトマネジメントとは、「ユーザー・ビジネス・テクノロジーの3つの領域が重なる部分に立ち、プロダクトを成功に導くためのあらゆるいとなみ」のことだ。

では、プロダクトマネジメントとプロジェクトマネジメントはどう違うのか。たとえば、Webサイトのリニューアルプロジェクトの場合、「Webサイト」はプロダクトで、「リニューアル」はプロジェクト。つまり、

• プロダクト＝Webサイトやアプリなど「モノ」
• プロジェクト＝「モノ」を通じて何かを成し遂げること

となる。そして、この両者で端的に違うのは、期限があるかどうかだ。プロダクトは常に修正や改善するので、基本的には期限がない。一方で、リニューアルする、新機能を追加するなどのプロジェクトは、期限が決まっているのが普通だ。

また、Web・アプリキャンペーンはデジタル依存度がかなり高いため、「構築」「仮説検証」と切り離すのは難しい。

理由のひとつは、ベストプラクティスが飽和していること。10年以上前ならInstagramでキャンペーンをやること自体が新鮮で尖った取り組みだったが、今では普通のことだ。このような状況では、何か新しいことをいち早く実現することよりも、よく検証された「勝ちパターン」のアイデアを実現することが重要になっている。

さらに、テクノロジーの進歩により、生成AIやノーコードツールが普及している。以前は、何かを構築するためには高いコストと専門知識を持つ人材が必要だったが、今では構築のハードルが低くなり、その結果、いかに手早く価値を生み出せるかが問われている。 

デジタルのキャンペーンでは何かしらの開発や構築が必要なことが多く、仮説を検証し続けて開発効率性を上げる（無駄なものを作らない）ことが重要になっている（飯沼氏）

避けたいのは、成功につながらない失敗

数億円をつぎ込んだ大規模プロジェクトの末に、リリースしたアプリが鳴かず飛ばず……。

 これは、明らかな大失敗であり、金額的にも、会社の許容度を超えている。とはいえ、人は成功への道を知っているわけではないので、失敗はつきもの。重要なのは失敗しないことではなく、最終的に大きな成功を掴むことである。ただし、大きなことを成し遂げなければ、大きな成功は得られないという誤解を避ける必要がある。

 大きな賭けに出て失敗すると、リスクが大きい。これを防ぎながら最終的に大きな成功にたどり着くためには、早く小さく失敗することが重要だ。ダメだと分かったら、引き返して別ルートへ行く。そうやって徐々に不確実性を減らしていけば、リスクを下げながら最終的に大きな成功を掴むことができる。

何億円もかけて作ったものがうまくいかなかったというのは困るが、50万円でプロトタイプを作って試したが失敗ということなら比較的許容される（飯沼氏）

冒頭でプロダクトマネジメントについて言及したが、その定義は「成功に導くためのあらゆるいとなみ」であり、失敗するなとは言っていない。つまり、成功につながるなら失敗も許容するのがプロダクトマネジメントだ。逆に言うと、成功につながらない失敗はしたくないということになる。

成功につながらない失敗とは

失敗とは「計画通りに物事が進まない」ことと定義されているが、影響の大小により大きな失敗と小さな失敗がある。影響とは許容できるかできないかで、金銭的な大小以外にも「大量の個人情報が流出した」などは許容できないリスクなので、大きな失敗と言える。そして、大小にかかわらず避けたいのは、「次につながる学習ができない失敗」だ。

たとえば「誰にも使われなかった」という失敗は、そこから何も学習できないので避けたい。あるいは、「これまでと同じ要因での失敗」も学習につながらない。

実は、「これまでと同じ要因での成功」も良くない。成功ならよいのではないか、と思うかもしれないが、テッパン施策がいつまでもテッパンとは限らない。市場は変化するので、それが通用しなくなったときにどうすればいいか分からないという状態になる。さらに、得た知見が活用できない失敗も、次につながらないので避けたい。

失敗を学習につなげるために必須なのが、仮説検証だ。セッション全体で飯沼氏が伝えたいことをまとめたのが、以下の図だ。

小さく失敗して、そこから必ず学ぶ

小さい単位で仮説検証をすることには、いくつものメリットがある。以下の図では、6つのメリットを挙げているが、ポイントは失敗の影響を小さくして、そこから得た学びを迅速にフィードバックすることだ。

かつて「MAU○千万のアプリに、新たなコア機能を搭載したい」というオーダーが来たことがある。「いきなりそんな巨大機能を追加するなんて怖くてできない」と思った飯沼氏は以下のように仮説検証を分解した。

Step1テスト専用アプリを作る

いきなり新機能を追加して、もしネガティブな印象を与えたらビジネスに大打撃になるので、本番アプリとは別のテスト専用アプリを作った。

Step2社内テスト（使えるアプリになっているか）

きちんと使えるかどうか、仮想店舗を使って社内の人がUXをチェック。

Step3クローズドβテスト（実店舗で使えるか）

一般ユーザー100人くらいに実店舗での新機能をリリースし、機能に不足がないか、きちんとオペレーションとして回るか確認。

Step4地域限定テスト（負荷テスト）

特定の地域のユーザーに限定して新機能をフルオープンにする。社内の開発環境でも負荷テストをするが、いろいろな場所からさまざまな回線でアクセスした場合でもパフォーマンスに問題がないか、実際のユーザーに使ってもらって検証する。そして、テストの地域を徐々に広げていく。

Step5さまざまな項目の検証

負荷テストの地域を広げていく期間に、以下のような項目も検証していく。

• コールセンターの負荷確認
• イレギュラーオペレーションの確認
• 機能追加の社内コミュニケーション
• 地域を絞ったCMの配信

Step6本番リリース

すべて問題がないことが確認できたら、本番アプリに新機能をリリースする。

仮説検証を細切れにし、それぞれの仮説を検証するタイミングを明確にし、検証結果に基づいて次のステップに進むか判断する。こうすることで、成功に導くことができる。

マーケティング施策の仮説設定と検証の手順

マーケティング施策を仮説検証する場合、まずは仮説を設定しなければならない。これは現状と目標のギャップを埋める手段を考えるということで、仮説は検証可能な予測であることが重要だ。つまり、条件（どのような状況・環境で検証するのか）、結果（どのような結果が期待されるか）、測定方法（どのように結果を測定・評価するか）の3つが明確になっていることが望ましい。

• 条件：ターゲットリストに対して週に1回、3週間連続でメールを送る
• 結果：流入数が10％以上増加する
• 測定方法：メール開封率と流入数のデータを分析する

次に、検証のスコープ（検証対象の範囲や条件）を限定する。これには以下のような理由がある。

• 複数の変数を同時に扱うと、どの要因が影響を与えたかわかりにくい
• リソースが限られている
• 失敗の影響を最小化する

仮説立案ができたら、優先順位をつけて検証を実施し、得られたデータを分析し（検証・振り返り）、検証結果をフィードバックする。

重要なのは、得られた結果から次の仮説につながるサイクルを作ること。そのためにフィードバックループの構築が重要（飯沼氏）

ステークホルダーからのさまざまな要望をどうマネジメントするか

最後は、土台としての組織文化の話だ。失敗して学習するというサイクルを許容する文化が必要だが、もうひとつ重要なこととして、ステークホルダーとのコミュニケーションがある。

いろんな人の要望に応えまくっていたら、尖っていたはずのキャンペーンが丸くなっちゃった。

これは、よくある失敗例かもしれない。ステークホルダー、たとえば事業部やクライアントからさまざまな要望が出ると思うが、何でも受け入れていると問題が起きる。それを避けるために必要なのが、「何をやらないか決める」ことだ。

問題リソース不足

限られたリソースを最大限に活用するためには、優先順位をつけ、重要なことに集中することが必要。

問題フォーカスがブレる

会社やプロダクトのビジョンやミッションに沿ったことに集中することで、ブレない方向性を保つ。

問題わかりにくくなって市場ニーズに的確に応えられない

市場ニーズに応えるには、不要なもの（＝分かりにくさの原因）を省き、価値の高いものを提供することが重要。

このイメージを伝えるものとして、飯沼氏は以下の図を紹介した。

十徳ナイフは、コンパクトにまとまったツール群として便利なものだ。しかし、さまざまな道具を加えていくと、おもしろいツール群とは言えるが、「コンパクトにまとまった」は消えてしまう。

できることの多さは、必ずしもプロダクトの価値と直結しない（飯沼氏）

Noと言いにくい場合のコミュニケーション術

キャンペーンの場合も、何かを捨てることで尖らせたのが「尖ったキャンペーン」なので、多くの人の言うことを取り込んでいくと、尖りがなくなる。それを避けるために、立場を理解してもらいつつうまくNoと言うには、以下のようにコミュニケーションするのがお勧めだ。

相手の話をよく聞く

内容が予測できても、まず聞く姿勢を見せる。これにより、「ずっと言っているのにちゃんと聞いてくれない」と思われないようにする。

どのような価値があるかについての共通理解を持つ

課題感などを、できれば数値化して具体的にする。話をきちんと理解していると相手に伝えることができるし、相手側もそのリクエストの裏にある思いを言語化できるようになる。お互いが共通理解を持つことで、「ちゃんと理解していないくせに断られた」と思われないようにする。

実現するための必要なコストを説明する

金銭的なコストだけでなく、リソースやブランドレピュテーションなども含めて説明する。リクエストする側は簡単だと思っているが実際にはそうではないこともあるので、「簡単な話なのにやってくれない」と思われないようにする。

NoをNotに言い換えて、何をやらないか決める

ここまでのコミュニケーションで、リクエストする側が納得して取り下げることもある。とはいえ、どうしても断らなければいけないこともある。そのときは、「Noと思ったらまずNotで考える」のがお勧めだ。

たとえば、他に優先順位が高いものがある、前提条件が整っていないなどの場合は「Not Now（今じゃない）」。もっといい方法がある、技術的に無理という場合なら「Not That Way（その方法じゃない）」といった具合だ。

NoをNotで言い換え、それをポジティブな表現に言い換えることで、否定型を使わなくてもNoを言える。ただし、ビジョンと合っていない場合は、はっきりNoと言った方がいい。このようにコミュニケーションをとることで、「我々もビジョンに沿ったものを作りたいと思っている」ことを理解してもらえる。

これを繰り返していくと、だんだんリクエスト側の勘所が育って、リクエストのクオリティが徐々に上がっていくことも期待できる（飯沼氏）

避けたい失敗がある状態でそのまま突き進むと、大きな失敗につながる。そうならないためには、小さな失敗をプロセスの一部に組み込んで、随時軌道修正できるようにする。これが仮説検証で重要だと強調して、飯沼氏はセッションを終えた。