セッションで伝えたいこと

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

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

なぜ小さい単位で仮説検証をするのか

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

かつて「MAU○千万のアプリに、新たなコア機能を搭載したい」というオーダーが来たことがある。「いきなりそんな巨大機能を追加するなんて怖くてできない」と思った飯沼氏は以下のように仮説検証を分解した。 ■ ［Step1］ テスト専用アプリを作る いきなり新機能を追加して、もしネガティブな印象を与えたらビジネスに大打撃になるので、本番アプリとは別のテスト専用アプリを作った。 ■ ［Step2］ 社内テスト（使えるアプリになっているか） きちんと使えるかどうか、仮想店舗を使って社内の人がUXをチェック。 ■ ［Step3］ クローズドβテスト（実店舗で使えるか） 一般ユーザー100人くらいに実店舗での新機能をリリースし、機能に不足がないか、きちんとオペレーションとして回るか確認。 ■ ［Step4］ 地域限定テスト（負荷テスト） 特定の地域のユーザーに限定して新機能をフルオープンにする。社内の開発環境でも負荷テストをするが、いろいろな場所からさまざまな回線でアクセスした場合でもパフォーマンスに問題がないか、実際のユーザーに使ってもらって検証する。そして、テストの地域を徐々に広げていく。 ■ ［Step5］ さまざまな項目の検証 負荷テストの地域を広げていく期間に、以下のような項目も検証していく。 ・コールセンターの負荷確認 ・イレギュラーオペレーションの確認 ・機能追加の社内コミュニケーション ・地域を絞ったCMの配信 ■ ［Step6］ 本番リリース すべて問題がないことが確認できたら、本番アプリに新機能をリリースする。 仮説検証を細切れにし、それぞれの仮説を検証するタイミングを明確にし、検証結果に基づいて次のステップに進むか判断する。こうすることで、成功に導くことができる。