B2B SaaSのUXデザイン、プロセスとアウトプットを公開します
こんにちは、カミナシでPMをしているかもしー (@96kemu96) です！
外気浴が楽しい季節になってきました。
さて今回は、今取り組んでいる新機能開発にあたって「どのように仮説検証をしたか」を具体的に紹介していきたいと思います。
💡誰のためのnote?
・ユーザーの仮説検証を具体的にどうやっているのか知りたい
・B2B SaaSのプロダクトにおける仮説検証プロセスを知りたい
先に前提をお伝えすると、今回は全く新しい概念のコンセプトや課題を検証したのではなく、既存ユーザーからも声が上がっていた課題をベースに仮説を立てました。そのため、課題や解決策の方向性はある程度あたりがついていたところからスタートしています。
プロダクトとしては中規模なボリュームの新規機能であるため、今回は一定時間を投下して検証するプロセスを踏みました。
やり方は模索中なので、ぜひこうしたらうまくいった！違うんじゃない？という意見がありましたら、コメントいただけますと嬉しいです！
カミナシってなんの会社？
ご存じない方もいると思うので、まずカミナシについて簡単に紹介します。
カミナシは「ノンデスクワーカーの才能を解き放つ」というミッションのもと、現在は現場DXプラットフォーム「カミナシ」というホリゾンタルSaaSを提供している会社です。
カミナシを通じて、PCやデスクのない現場で働く人々のポテンシャルを IT の力で最大化し、3,900万人のノンデスクワーカーが非効率から解き放たれた世界を実現したいと思って、取り組んでいます。
まず仮説検証の全体像を把握する
まずアサインされて思ったことは、社内外に仮説っぽいものがたくさんある！ということでした。
たとえば
「この機能を作れば、売上が上がるのではないか？」
「このユーザーもあのユーザーも、それが困っていると言ってた。」
「こういう機能をつくったら、使ってもらえると思う。」
これらはよく見ると仮説の「対象」が異なります。
ということで、仮説検証の地図を作成し、今何は検証できていて、どこにいるのかを把握しました。
この図における定義
課題発見・ビジネス仮説：取り組むべき課題があるのか
顧客の課題仮説（Customer Problem Fit）：だれがなぜ何をしたいのか
解決策仮説（Problem Solution Fit）：何があれば解決できるのか
機能仮説（Solution Problem Fit）：どうつくれば解決できるのか
開発フェーズのサイクル
リリース後UX改善のサイクル
※以下を参考にPMFに至るまでのフェーズを（）に記載
※仮説検証は1〜6まであり、6まで行った後は1や2などにループ
ポイント：顧客の課題仮説を先に検証する
この図の最大のポイントは、「顧客の課題仮説」があったうえで、「解決策仮説」と「機能仮説」を検証することです。
なぜなら「だれの」「なんの課題か」のどちらか一方でも変わると、「どう解決するのか」「なにをつくるのか」も当然変わるからです。
そのため、もし手段から、つまり解決策や機能のアイディアから検証を始めてしまうと、実装の実現可能性に引きずられて顧客課題にあまり刺さらないものをつくってしまったり、上段の目的であるビジネス戦略的に得たいアセット（売上やチャネルなど）を期待通りに得られない可能性が高まります。
したがって自社がこの課題に取り組むべきか、を踏まえたうえで、顧客課題の検証からはじめることが大事だと考えています。
今回の記事では「2. 顧客の課題仮説」と「3. 解決策仮説」に絞って書きます。
顧客の課題仮説の検証
仮説検証できたと言える状態
それは、以下2つが検証できた状態だと考えています。
誰が、なぜ、どのような課題をもっているのか？その課題は本当にあるのか？が明確である ＝顧客の文脈理解と課題の存在
それはユーザーの十分な痛みを伴うものなのか？が検証されている ＝課題の深さ
課題仮説検証でおさえておきたいポイント
💡課題が発生する「前提条件」を明確にすること
課題仮説の検証においては、課題が発生する前提条件を確認するのが大事なポイントだと考えています。
理由は2つ。1つ目は、意思決定を間違うときは「仮説のベースとなる重要な前提のどれかが間違っていた時」か「正しく検証できなかった時」だから。
2つ目は、仮説に仮説を重ねていく状態になると仮説の精度が下がるから。
揺るがない事実や前提の上に、論理的に考えるとこういう課題は発生するよね、という考え方をするようにしていました。そうすると、前にすすめるのではないかと思っています。
実際にやったこと
顧客の選定→CSヒアリング→顧客ヒアリング、の順で検証しました。
顧客の選定
企業の特徴ごとにバランス良く、課題がありそうな10社を選定
事前準備としてのCSヒアリング
（業務効率化に関する機能なので）CS議事録などからユーザーの実業務を理解
ユーザーの業務の特徴、業務の流れ、重要そうな課題をCSにヒアリング
その後の顧客ヒアリングでは、CSヒアリングから得られた前提情報や仮説をもとに、よりその精度をあげていきます。
顧客ヒアリング
課題の存在・発生の背景と前提の確認
実際に現地に行って、業務の様子を見学・ヒアリング
業務の流れを簡単にスライドにまとめて確認
課題の深さを確認
簡易プロトタイプを触ってもらったり、UI画面をスライドで見せながら、リアクションを見る
その上で「導入したいか？」「運用できそうか？」を聞いて深堀り
顧客ヒアリングでやらなかったことは、直接的に「課題はありますか？」「どれくらい困ってますか？」と聞くこと。
なぜならその業務が当たり前だと思っていたら課題と認識しないからです。代わりに簡易プロトタイプやUI画面を見せながら、リアクションを確認しました。そのやり方は後ほど説明します。
解決策仮説の整理
仮説検証できたと言える状態
以下が検証できた状態だと考えました。
その解決策で「運用したい」「導入したい」と思えるかどうかが、はっきりすること
今回は、業務効率化に関する機能だったので、今の運用を置き換えられそうか？置き換えたいと思うか？を聞きました。
課題仮説検証でおさえておきたいポイント
💡ヒアリングの最後に、課題解決になるのかを「別角度」で問うこと
ヒアリングの最後に以下3つの質問をしたのですが、非常に示唆がありました。
導入したいですか？
運用できるイメージはありますか？
今の業務を置き換えられると思いますか？
それぞれに対して1~5段階評価をしてもらい、理由を聞きます。
ちなみに、1って言っても怒らないので正直に！と言うと笑いをとれます。笑
実はこの3つの質問、似ているようで、聞いていることが違います！
実際にユーザーに聞くと違う回答が返ってきます。
導入したいですか？
質問意図：ワクワクするか、どれくらい嬉しいか運用できるイメージはありますか？
質問意図：導入した後に毎日毎日これを使っていけるかどうか今の業務を置き換えられると思いますか？
質問意図：今の業務で、重要なことと、やらなくてもいいことはなにか
プロトタイプを見せた時は好感触だったのに、最後にこの質問をしたら実際は評価が低かったことなどもあったので、価値がある聞き方でした。
先方が複数人の場合、ここでいろいろな立場の人の視点が分かるのもポイントです。
実際にやったこと
オンラインMTGや訪問で、顧客ヒアリングをしました。
ヒアリングの流れ
アイスブレイク・自己紹介
業務内容の確認
考えている解決策としての機能を説明
手法：画面だけのプロトタイプ、スライドでUI画面の紙芝居
ポイント：複数の案を比較して提示
全体感を最後にヒアリング
解決策仮説としての画面を見せると、基本的には「あったらいい！」「ほしい」と言われるはず。
そのため複数の案を見せて比較することで、なぜ欲しいと思うのか？これだとなぜだめなのか？本当に必要なのか？を判断しました。
検証をしてみて
このように検証してきましたが、業務効率化に関する機能の場合、実際に何日か使ってみてもらわないとわからない部分がありました。
そのため、アジャイルに開発していくことが重要なのですが、そこはまた追って書きます！
長くなりましたが、最後に重要だと思ったことを3つだけ。
顧客は自分の課題を伝えられない
ユーザーに聞けば分かるわけではない
たくさん会うことで、感覚や肌感がつかめる
以上、私がB2B SaaSのプロダクト開発で、ユーザーの課題検証と解決策検証をどうやってきたのか、でした。
この記事を読んで「面白かった！」「学びがあった！」と思っていただけたら、スキを押していただけると嬉しいです！
他の方がどうやっているのかも気になるので、もしこうやったよ！違うんじゃない？があれば、ぜひ話しましょう！
最後に、カミナシはPM/UXデザイナーを大募集しています！
カミナシのPMチームはまだ立ち上がったばかりで、新しいことにどんどん挑戦していきます！
面白そう！と思った方がいましたら、カジュアルにお話しましょう！
募集はこちら
PMチームについてはこちら