※2023年11月14日に開催したオンラインイベント「プロデザ BYリクルート vol.16　　新規プロダクトの市場と事業の価値観をFITさせるプロセス大公開」から内容の一部を抜粋・編集しています。

【登壇者PROFILE】

・川崎 絢司（株式会社リクルート プロダクトマネージャー）
株式会社ユニクロに新卒入社後、店舗経営を経験。その後、ピーシーフェーズ株式会社にてソーシャルゲーム企画・開発ディレクションや、研究開発部にてサービス企画・価値検証・立ち上げに従事。2015年にリクルートへ転職後、小売店や飲食店向けのリピート販促支援や業務支援サービスの価値検証を経て、外食体験を変える『モバイルオーダー 店内版』（旧名称：『Airレジ オーダー』セルフオーダー）を立ち上げ、プロダクトマネージャーを務める。プロダクトマネージャーカンファレンス2020で登壇。

#見出し
開発における意思決定の価値基準をつくる「Discoveryからのファインディングス」

川崎絢司（以下同）：今回のプロデザ! BY リクルートのテーマは、ずばり「PMFまでの道のり」。私がPdMを務めるプロダクト『モバイルオーダー 店内版』（旧名称：『Airレジ オーダー』セルフオーダー）を例に、「新規プロダクトの市場と事業の価値観をFITさせるプロセス」についてお伝えできればと思います。

『モバイルオーダー 店内版』（旧名称：『Airレジ オーダー』セルフオーダー）は、飲食店の卓上に置かれたQRコードをお客さんが自分のスマホで読み取り、そこから注文ができるサービスです。
※QRコードは(株)デンソーウェーブの登録商標です。以下、同様です。

このプロダクトの企画は2018年3月にスタートし、製品版がリリースされたのが2020年7月。今回お話しするのは、2020年1月にMVPをリリースしてから約1年半にわたるPMF期間についてです。

私はPMF期の定義を「意思決定や優先度付の基準、つまり“価値観”を修正していく」期間だと捉えています。

上記の図のように、まだプロダクトがマーケットにフィットしていない左の状態（MVPなど不完全な状態）から、右のフィットした状態へ持っていくためには変化や適応が必要です。この変化の方向性やスピードを決める要素が何かというと、「開発をやるか・やらないかの意思決定」と「優先度付け」です。

そして、その価値基準をつくるのが上流の戦略やDiscoveryであると考えています。なお、ここで言うDiscoveryとは、現場からのファクトなどのファインディングス（発見）のことを指します。

特に、初期に立てたプロダクト戦略というのは、現場からのファインディングスによって大いに修正し得るものです。そこで今回の発表では、このDiscoveryの部分にフォーカスしてお話ししたいと思います。

なお、上の図の「戦略・ロードマップ」の部分については、2023年10月17日に行ったプロデザ! BY リクルートvol.12「粘り強い価値検証！　新規プロダクトのPMFまでの道のり大公開!」でご紹介しています。詳しくは、こちらのnoteをご覧ください。

集めたデータや検証が、開発の意思決定につながらないことも

まず、どのような開発であれDiscoveryを探る際には、さまざまな検証を行うと思います。

ただ、その際に起こりがちな問題が、そうした検証が「開発をやる・やらない」「優先度の意思決定」になかなか結びつかないこと。調査や検証で分かったことを言語化してみても、意思決定をするにはまだ情報が不足していたり、いまいち決め手がかけていたりというケースも少なくありません。

その結果、せっかくデータを集めても、結局はPdMやPO（プロダクトオーナー）の直感で、大きなリスクを背負ったまま決定するしかない。つまり、振り返りと判断、意思決定がしっかりと結びついていないわけです。

この部分を、私たちがどんな取り組みによって解決したのか。現場のファインディングスを戦略・意思決定・優先度付けの基準に連動させる仕組みやプロセスについて、お伝えしたいと思います。

なお、パートは大きく分けて3つあり、まずは「全体像：GISTサイクルと実際の運用方法」について。私たちのプロダクトでは、このGISTサイクルというプロセスをカスタマイズして運用しています。
次に、そのプロセスのなかで登場する「Step Project」という仕組みや「Delivery」を、いかに意思決定や継続投資判断につなげているかについてお話ししてまいります。

 GISTサイクルで開発の優先順位を決定

はじめに、全体像の「GISTサイクル」についてです。

GISTとは、「Goals（ゴール）」「Ideas（アイデア）」「Steps（ステップ）」「Tasks（タスク）」の頭文字をとったもので、ゴールを満たすためのアイデアの蓋然性（確からしさ）をライトに検証して「筋のいいアイデア」を発見し、アイデアの優先順位を組み替えていく方法。不確実性に対して柔軟に方向転換していくためのプロセスとなっています。もともとは、GoogleのYouTubeやGmail、MicrosoftなどでPdMを20年以上経験されたItamar Gilad氏が提唱したもので、私たちはこのエッセンスを取り入れつつカスタマイズして運用しています。

こちらの図のように、まずは「Goals」を置き、その下にこれを達成するための複数の「Ideas」を配置する。ただ、ファクトが少ないPMF初期は特に、これらのアイデアをどんな優先度で実行していくかの意思決定が難しいですよね。

そこで、これらのアイデアを「Steps」というライトなテストに分割します。その上で、「アイデア1はStep1でダメだったから切り捨てよう」や「ステップ3までいったアイデア3には筋があるね」といった判断をしていくわけです。

私たちはこのプロセスを上の図のような形で管理していました。

現場から挙がってくる多くのアイデアのなかには、まだアイデアの形になっていないものも数多くあります。まずはそれをPdMが整えて、ICEスコアリングを用いたラフなスコアリングを行います。そのアイデアはいったん「Parked」のフォルダに溜めておき、そこから筋がいいものをピックアップして「Candidates（候補）」のフォルダに移す。このなかで優先度の評価をして、実際に検証や開発に回す候補を「Working set」のリストに入れます。

そして、2回目のテストでICEのスコアを再評価して、優先度が上がったものをDevelop（開発）に回し、優先度が下がったものは再び「Parked」のフォルダへ戻す。こんなサイクルで管理・運用しています。

 全てのアイデアは、まず「Ideabank」へ溜め置く

ここからは、「Goals」「Ideas」「Steps」の各要素について、詳しく紹介していきます。

はじめに「Goals」についてですが、PMF期において私たちがフォーカスしたのは「セルフオーダーの利用組率」です。つまり、来店したお客さまがセルフオーダーをお使いになる確率を高めること。これをゴールに設定しました。

なお、このGoalsを設定していくプロセスについては、前編で詳しくご紹介していますので、ぜひご覧ください。

次に、これを達成するための「Ideas」についてです。
私たちはアイデアを溜め置く場所を「Ideabank（アイデアバンク）」と呼んでいました。

アイデアは、戦略のイニシアティブや現場からのファインディングスなど、さまざまなきっかけで生まれます。また、営業やオンボーディング、カスタマーサクセス、ヘルプデスクなどから届くVoC（顧客の声）も、重要なアイデアの種になります。

まずはこれら全てを、Ideabankへ溜めていきます。次に、それらのアイデアをトリアージ（充足・分類）し、この中から開発へ回す候補をピックアップするという流れですね。

ちなみに、私たちはアイデアを「課題」と「ソリューション」の組み合わせであると捉えています。特に、PMF期に大切にしていたのは「課題」のほうで、「何が（クライアントや利用者の)お困りごとなのか」という部分にフォーカスしていました。

課題を大切にすることで、機能をつくること自体が目的化するのを避けられ、クライアントへの提供価値に重点を置いたアウトカム思考になることができたと思います。

 戦略上の位置付けとスコアで、アイデアの優先度を決める

では、「セルフオーダーの利用組率」を上げるというゴールに対して、具体的にどんな課題にフォーカスし、アイデアを絞り込んでいったのか。

それを探るために、まずはそもそもの「セルフオーダーの利用組率が上がらない背景」について検証しました。その結果、「飲食店のスタッフさんが、全卓に対してセルフオーダーのQRコードを案内できていない」という課題が見えてきたんです。

なぜ、セルフオーダーを案内されないケースが発生するのか。店舗を訪問して実態を観察してみました。当時のセルフオーダーは店員さんが持つ端末で、お客さんごとにQRコードを生成し、それをスマホで読み込んでもらっていました。ただ、そうしたオーダー方法への理解度や受容度は、お客さんによって異なります。場合によっては、店員さんがお客さんへの案内を躊躇することがあり、その場合はセルフオーダーではなく従来の口頭注文になっていました。

この課題を解決するためには、店員さんが「セルフオーダーを案内するかどうか」を判断するのではなく、来店客自身が「利用するかどうか」を判断する形に変える必要があると考えました。そこで、飲食店の全ての卓に最初から固定のQRコードを置き、店員さんの案内なしでも全てのお客さんがセルフオーダーを使える状態にしようと。これが、最初のアイデアの仮説です。

次に、このアイデアを精査していく過程を紹介します。

まずはアイデアをIdeabankに入れて、「①戦略上の位置付け」とICEスコアリングによる「②位置付け内の優先度」でラベリングします。

戦略上の位置付けは、3つの要素があります。

1つ目が「戦略的な意図」。どのセグメントのどんな課題に対して、どのような価値を提供するためのアイデアなのか、という分類ですね。具体的には「Phase1（今フォーカスしているセグメントの課題解決）」「Phase2（次のセグメントの課題解決のための仕込み）」なのかで分類しています。今回のアイデアは既存セグメントの課題解決にあたるため、Phase1に設定しました。

2つ目は「Product Initiatives」。これは「最終的にどの指標を上げるのか？」という分類で、ここでは「セルフオーダーの利用率」を設定していました。

3つ目は「案件Impact指標」。先ほどの「Product Initiatives」で設定した「セルフオーダーの利用組率」はやや大きな指標になるため、それを少し分解して、具体的にどの指標を直接上げにいくかを設定するものです。今回のアイデアでは「QRコードの読取率」を設定していました。

次に、②の「位置付け内での優先度決め」です。ここではラフなICEスコアリングを用いて点数をつけます。その点数から、セルフオーダーの利用組率に対してどのようなインパクト・影響力があるのかを見て、優先度をつけていきました。

このようなプロセスで筋のいいアイデアを見つけていきましたが、それでもまだ不確実性は残っている状態ですので、このまま開発を進めるわけにはいきません。そこで、次の「Steps」というフェーズで、いかに不確実性を解消していったかをお話ししたいと思います。

実装前にライトな検証を行う「StepsPrj」

次に、開発候補に挙がったアイデアを「Steps」というフェーズにかけます。
私たちはこれを「StepPrj」と呼んでいました。実装前のライトな検証プロセスのことです。

これについて詳しく説明する前に、そもそもなぜ実装前に小さく検証をする必要があるのか、また、どんなものを検証するのかについて説明します。

こちらの図のように、検証するのは「インパクト」が高く、なおかつ「リスク」も高い施策のアイデアです。ここでいうリスクとは、ICEスコアリングのConfidence（信頼性）が低い、つまり、それで本当に問題が解決するかどうか確証が持てないということ。また、Ease（容易さ）が高い、つまり、そのソリューションを実装するためにはかなりの工数がかかることを指しています。

要するに、問題が解決する確証がなく、かつ工数がかかる「失敗したらこける可能性が高いアイデア」を検証していくということですね。

この検証がないまま本開発に進んでしまうと、時間とコストをかけたわりに使われなかったり、想定していたアウトカムが得られなくなってしまいます。最悪の場合、システム全体に後戻りできないような負債を抱えてしまうことになり、その後のプロダクトの成長を止めてしまいかねない。ですから、やはり開発候補に挙がったアイデアのなかで特にリスクが高いものについては、小さく検証する必要があり、それが結果的にプロダクトの成長を加速させるのではないかと考えています。

では、実際にどうやって「StepPrj」を進めていくのか。
これが、そのフローになります。

まず、そもそも意思決定したいのは「本開発をやるか・やらないか」また「優先度をどうするか」です。ただ、これは大きな意思決定になりますので、いったん小さく分解し、判断の順序をつけていく。これがStepPrjのコンセプトです。

具体的には3段階に分けていて、1段階目が「この問題を解くか解かないか」。つまり、この問題を解くためのアイデアの探求や検討を、そもそもやるかやらないかです。この問題を解くと決めたら、2段階目「解き方の決定」。N1分析で実際に解決する方法を見つけていきます。
そして、解き方が決まったら、3段階目の「仕立ての決定」に移ります。それをプロダクトにどう実装するか、どういったビジネスオペレーションを組むかについての意思決定をするということですね。

この３つの段階をクリアすれば、最終的にバッグログ入りできる品質のアイデアであると判断され、本開発に進むことになります。逆にどこかで何らかの懸念が生じた場合は、その時点で後戻りができる。つまり、大きなコストをかけずにピボットできるわけです。

デリバリー後の振り返り

最後に、StepPrjで蓋然性が高まったアイデアをデリバリーしていくフェーズについてもお話ししておきたいと思います。

このフェーズでも、成果設計・振り返りの判断を重視しています。

そもそも、何故この段階まできて、わざわざ振り返りをするのか。

それは、デリバリーをしてスケールさせていくと、特定セグメントではFITせず「想定よりimpactが出ない」「思ったほど改善につながらない」というケースが出てくることがあるからです。

そのため、デリバリー後も振り返りを行い、そうしたセグメントにどんな要求があり、どんなエンハンスのアイデアが必要なのかをあぶり出す必要があります。その上で、残課題の量を見て、その課題に追加投資をするのか、別の「Goals」に移るのかを判断します。

では、具体的にどこに対して成果定義をして振り返るのかですが、ここで意思決定したいのは先ほども言ったように「その課題に追加投資をするのか？　それとも別のGoalsに移るのか？」です。

これに対する判断ポイントは、この仮説アイデアを構成する「impact」「outcome」「課題」「ソリューション」「実装機能（プロダクト）」の各間に、ズレがないか、想定外の白地がないかどうか。これを点検していきます。

実際に振り返ってみると、さまざまなことが見えてきました。たとえば、じつは多くの飲食店がこの「固定QRコード」という新しい機能を認知しておらず、十分に活用されていないこと。あるいは、固定QRコードのことは知っていても、それが「置かれない席がある」ということも分かってきました。たとえば、カウンター席の場合は口頭で注文を取るほうが早かったり、お店によっては個室のお客様には直接オーダーを取りに行くことで「丁寧さ」を出したいといった考えもあって、全ての卓にQRが置かれない状況というのが散見されたんです。

こうした新たな課題一つひとつを分析したり解決策を講じたりしながら、白地がなくなるまで潰していきました。それでも残った課題に対しては、引き続きエンハンスしていくのか、もう白地がほとんどなくなったから別の「Goals」に移るのかを最終的に判断する。これがデリバリーのフェーズにおける、振り返りのプロセスですね。

ということで、本日のまとめです。

改めて、今回お伝えしたかったのは、「現場のファインディングスを戦略・意思決定・優先度付けの基準に連動させる仕組みやプロセス」でした。

まずは「開発のやる・やらない」「優先度」という大きな意思決定を分解し、どの指標にフォーカスするか絞り込んで「Goals」を設定します。今回のセルフオーダーの事例では「セルフオーダーの利用組率を上げる」がゴールでした。

そして、フォーカスした指標、設定したゴールに対して、どのアイデアを優先させるかを決めていく。その際には「StepPrj」を用いて、どの課題やソリューション（アイデア）を優先的に実行するか検証していきます。

検証を経てアイデアをデリバリーし、それが「セルフオーダーの利用組率を上げる」というゴールに対してどれくらい寄与したのか、新たにどんな課題が生まれているのかを振り返っていく。それを踏まえ、引き続き課題に注力するのか、また別の「Goals」にシフトするのかを判断する。大まかに言うと、こんなサイクルですね。

私たちはこのように「開発のやる・やらない」「優先度」の意思決定をしていました。今回の発表は以上です。ご清聴、ありがとうございました。

視聴者からの質疑応答

Q.今回の事例と同じようにGISTサイクルを回すためには、最低限どれくらいの人数やメンバーが必要でしょうか？

川崎：判断やラベリング、計画を立てるのは1人のPdMで十分に回る感覚です。実際、私たちもPMF期のGISTサイクルは、基本的に私一人で回していました。ただ、最初に定義をつくっていく部分はやや難易度が高いので、場合によってはチームの何人かで協力しながらルールを整備していくといいのかなと思います。

Q.Ideabankの管理はPdM単独なのか、チーム全員が管理していくのか、どちらでしょうか？

川崎：「ideabankへのアイデアの投稿」は、各メンバーにお願いしていましたが、そこから先の優先度付けやラベリングなどは、基本的にPdMである私が一人でやっていました。ただ、たとえば「こういう考え方でラベリングしているので、できればあらかじめラベリングした状態で投稿してください」といった具合に、少しずつナレッジを浸透させていくなど、チームの成熟度を見ながら渡せるところは渡すようにしています。

Q.VoCで「こういう機能が欲しい」という意見が出た場合、そこにどういうインサイトがあるのか、どのように探っていますか？

川崎：これは「対開発メンバー」と「対ビジネスオペレーション側」とで対応を変えています。まず、対開発メンバーですが、VoCを挙げるにあたって「ファクトがあるか」をしつこく確認し、ファクトがなければ現場観察やヒアリングを徹底的に行うようにと口酸っぱく伝えています。時には私もクライアント訪問に同席してヒアリングを重ね、インサイトを探っていますね。

一方のビジネスオペレーション側、営業やオンボードチームなどに対しては、あらかじめ「こんな情報を、こんな粒度で挙げてほしい」というフォーマットを定義していました。たとえば営業メンバーは「こういう機能が欲しい」といった、ざっくりとした形でVoCを挙げてくるケースが多いのですが、そうではなく「困りごとは何か」「理想の状態は何か」「そのために何がしたいか（どんな機能が欲しいか）」といった形で挙げてもらえるよう、こちらからも具体案を示しつつお願いしていました。

お知らせ｜プロデザ室は仲間を募集しています

プロダクトデザイン室の募集情報は〈こちら〉のサイトからご確認いただけます。ぜひご一読ください☆
https://blog.recruit-productdesign.jp/

お願い｜noteのフォローをお願いします！

こちらのnoteアカウントをまだフォローしていない方！ぜひフォローしてくださいね。皆さんのキャリアやお仕事に役立つ記事を発信していますので、絶対損させませんよ！！！

お願い｜できればX(旧twitter)もフォローをお願いします

プロダクトデザイン室の公式X（旧twitter）ではイベントの見どころやオリジナルコンテンツを更新しています。ぜひフォローしてください。
https://twitter.com/Recruit_PD_PR