初めまして。株式会社カミナシでPMをやっているGTOです。
先日6/30に、マネーフォワードさんと合同で勉強会を実施しました！当日お集まりいただいた皆様、ありがとうございます。
登壇者として出席させていただき、「PMの自分が如何にユーザーの声をエンジニアの共通言語へ変えたか」というタイトルで発表しました。
カミナシでも、紙というツールを介して長年使われ続けたそのフローをいかにプロダクトで解決していくのかは大きなテーマの一つです。
そんな中でユーザーさんへの価値をどう作り、またプロダクトチームへどう伝えていったのかを話してきました。
当日の登壇でお話し出来なかった部分もあるので、一部掘り下げてこの記事内で紹介します！
登壇資料
登壇の概要
お客さんへの価値をどのように見つけ、チームと対話をし伝えるのかは最近の自分の悩みごとでした。
- お客さんへの価値をどのように見つけ => 仮説検証
- チームと対話 => チーム間のコミュニケーション
「使われる」プロダクトを「最小単位」でどうやって作ったらいいんだろうね？と模索の過程を話しています。
仮説のアイデア出し
仮説を作る前にまず、デザインスプリントを使いアイデアを集約させます。
MTGを毎回行うより、討論しながら一緒に知識の獲得とアイデア出しを行えるメリットがあります。
通常デザインスプリントは1週間をかけてサイクルを回し切ることが多いのですが、1日で背景揃える/課題の整理/アイデア出しをやっています。
ビジネス含め、全員が揃うタイミングもなかなか合わせづらい部分もあるのでギュッと凝縮してやります。
ここはいろんな背景のメンバーを少人数集めるのが重要かなと思っていてます。後、アイデア出しなので楽しくやるのも結構大事。
実際に背景を揃える部分では、動画のイメージやソリューション, 戦略を共有したり、人物像が複雑に入り組んでいるものは登場人物の関係図を整理したりします。
手法自体は、デザインチームが主導でファシリをしたりしますが、ビジネスとプロダクトをうまく役割分けて準備をします。
それぞれの知識や手段に偏りがあればあるほど、議論としては極端に傾きいい意見が出て良いです。
実現可否は一旦横に置き、アイデアを広げる方が思いつかなかった発想につながって良い議論が出来るのでオススメです。
出したアイデアを元に、仮説をテーブル上に並べて取り組むべき課題を選択し、前に進めていきます。
身銭を切る仮説を作る
仮説を選ぶ時に意識するのは、「そのアイデアに身銭を払ってくれる」仮説かどうかだと思います。
「身銭」は、本気で取り組むというあかしになり、必要な準備が整い、困難があっても投げ出さないという宣言にもなる
重要なのは相手の意見や予想ではない。あなたの製品に対し、ターゲットとなる人たちが切ってくれる「身銭」なのだ！『Google×スタンフォード NO FLOP! 失敗できない人の失敗しない技術』 アルベルト・サヴォイア 著 石井 ひろみ 訳 サンマーク出版
身銭というものは、お互いの本気で取り組むための制約です。
作り手と受け取り手のどちらもが目の色を変えていく必要があり、それは身銭によってより良い緊張感が生まれます。
なのでプロダクトを作りきる前に、アイデアや仮説から作ったプロトタイプを提げて売りに出します。
ここはデザイナーの力を借りて、アイデアを形にしていきます。
実際に売ってみると、仮説自体の筋が良かったのかの判断がつきやすくなります。
売る前は良さそうだなと思ったものも、商談にいざ出してみると全くだめなこともあったりします。
外部に評価をされる中で大きく外し、次の手を高速で考え出しまた次に活かすこと。
失敗をすることも、学びに繋がることもたくさんあるので、ここは執着して当てるまで作りこみます。
仮説作って事実を集めて失敗し、また次のより良い仮説を作る。
発散と収束を繰り返し思考を交差させながら売りに行き、次の仮説を作っていくのが良いかなと思います。
体験をチームへ共有する
アイデアや仮説や作るものも徐々に決まり、チームへ伝えていきます。
お客さんの体験をチームへどう伝えるのかの部分は、見て感じたお客さんの行動を元に整理していきます。
僕らはKA法に近い手法でユーザーの行動や感情から、価値を抽出し価値マップを作成します。
ユーザーで伝えたいような体験となるものになるので、設計/関係性/背景を残すようにします。
機能単位では、ユーザーストーリーマッピングをしていきながら、Minimum Viable Product（最初のリリースで達成したいこと）では何を作るべきなのかを残しています。
MVPで意識するべきことは、最小の機能で、価値を最大のに出来る体験はどんなものかを定義するだと思います。
いかに最小の労力で、一番初めのお客さんに愛してもらえるような体験をどう作るのかが観点で、単一の機能を作ることだと曲解しないようにする必要があります。
ここが誤ってしまうと、お客さんに本来提供したい運用フローが機能不足で本来提供したい価値が伝わりきらないことがあります。
それは正しい検証が出来たとは言えません。
機能ではなく本来提供したい体験や価値を実現できる最小限の機能なので、変に削りすぎないことは割と大事な観点だったりします。
まとめ
仮説検証, チーム間のコミュニケーションを正しく行うためにも、チームが正しくお客さんの価値へ向き合うことが重要だよね！ということを登壇の中で伝えてきました。
開発もなるべく作ったものがお客さんに使われて喜ばれる姿を一緒にワイワイ共有したいし、失敗した時には一緒になんで失敗したのかを真剣に振り返っていきたい。
スタートアップで僕らもまだまだ未知なことも多いし、失敗も多く重ねていきます。
そんな失敗をチームが修正できる仕組みが最高ですし、そんな強い組織を作りたい気持ちです。
仕組みを徐々に整えることで、少しでもチームが自律的にお客さんへ向かうことが重要だな、もっとやれることもあるなと振り返る登壇となりました。
事業の成長に向けてより一層引き締めていきたい所存です！
最後に宣伝です。
カミナシでは仮説検証を始めとして、他にも事業が前にすすむような技術的にも事業的にもチャレンジが出来る企業です。
幅広く全職種で募集しています。エントリーお待ちしております！！
では👋
