こんにちは！
プロダクトマネージャーの竹村（@juntakemura_pdm）です。
早いもので前回のブログから1年以上が経ちました。
今回が2回目のブログです。
さて、前回のブログではMVPについて書かせていただきました。
lab.astamuse.co.jp
その中で、「MVPであれど必要な質をないがしろにしない。」ということを重要なポイントとして挙げておりました。
今回はそれに関連し、これまで私が色々な施策を企画する中で蓄積してきた
「プロダクト施策立案のチェックリスト」
を紹介させていただきます。
このチェックリストは、
「プロダクトの施策立案を行う際、その施策の精度を高めアウトカムの期待値を上げること」
を目的として作成しました。
普段私が施策を立案する際は、このチェックリストを元に一人壁打ちを行ったり、各項目を元にして論点を定め、企画のブラッシュアップを行っています。
施策立案をする際、あるいはチームで施策を議論する際に、参考にしていただければ幸いです。
なお、このチェックリストは日々ブラッシュアップをしています。
「他にもこんな観点があるよ」等、ご意見をいただけると大変喜びます！
このチェックリストが生まれた背景
私は日々、プロダクトマネージャーとしてプロダクト開発の施策立案・推進を行っています。
そのような中で強く感じているのは「時間や工数は限られている」ということです。
やりたいことが100あったとして、実際にできるのは10未満というくらい、できることは限られています。
「その10を可能な限り活かしたい...ならば施策の成功率を少しでも上げよう。そのためにはどうするべきか？」ということを考えました。
そこで、まずは1年間で行った施策と、その成功率、そして失敗したものの要因を分析しました。
（成功率に関することはこちらの記事で紹介しています。）
失敗した施策の失敗要因を見ていくと、いくつか共通する部分が見えてきました。
それらの共通する部分をまとめ、「企画の段階で考慮するべきポイント」をまとめたのが今回のチェックリストです。
内容を紹介する前に
チェックリストをご覧いただく前に、2点ほど前置きを。
MECEにはこだわっていない
チェックリストをご覧いただくと、似たような内容の項目が存在することに気づく方もいらっしゃるかと思います。
例えば「データ・仮説」と「必要性と根拠」は似たような内容を含む項目です。
それでもあえて項目を分けているのは、同じ内容を別の側面（別の言葉）で見た時に気づくことも多くあるためです。
先ほどの例で言えば、
「データ・仮説」：あるデータが、その施策の元になっているか
「必要性と根拠」：あるデータが、その施策の必要性を示しているか
といった形で、データを評価する角度を少し変えるニュアンスがあります。
このそれぞれのニュアンスいずれも重要だと考えた結果、この形になりました。
各項目で多少のダブりを含むものになっておりますが、それを念頭にご覧いただければ幸いです。
問いの形式にしている
各項目は問いの形式にしています。
問いの形式にすることで、自分で立案した施策でも客観的に思考を働かせやすくすることを意図しました。
もし活用される際は、この質問に答えるようにしてみてください。
プロダクト施策立案のチェックリスト全21の項目
それでは、チェックリストの各項目を紹介させていただきます。
なお、文中で「施策」「機能」という言葉が出てきますが、これらはほぼ同一で「企画した対象物」の意で捉えてください。
Googleスプレッドシート版はこちら
プロダクト施策チェックリスト
ここからは各項目を紹介させていただきます。
～施策の基本情報～
1.目的
「この施策の目的は何か？」
まずは目的を明確化・言語化します。
目的のない施策はありませんし、企画の段階で示されないこともほぼ無いでしょう。
ただ、施策内容が目的に対して芯を食っていないことや、議論の過程でズレていってしまうことは意外と多いです。
「これ何のためにやるんだっけ？」と、意識的に目的に立ち返ることでそういったズレが防げることもあります。
そのためにも、まずは目的を明確にすることは重要です。
2.対象・範囲
「この施策の対象となるユーザーは誰か？」
「この施策の範囲はどこまでか？（何をして何をしないか）」
この情報を整理することで、後に登場する「母数」や「影響度」も整理しやすくなります。
それによっては、
「インパクトが少なそうだから優先度を見直そう」
「もっと多くのユーザーに価値を提供できる方法を考えよう」
という思考へ発展させることもできます。
3.データ・仮説
「この施策の根拠となるデータ、仮説は何か？」
後述の「必要性と根拠」や「事前検証」につながる情報です。
根拠となるデータや仮説がない施策は単なる思いつきになってしまいます。
これらは必ずしも定量的である必要はなく、定性的なもの（顧客の声やそこから得られるインサイト）でも構いません。
4.目標数値・モニタリング指標
「この施策の目標数値、モニタリングする数値は何か？（指標と閾値の両方を明記。）」
施策は可能な限り定量的に評価することが望ましいです。
「どの指標」を、「どこまで」上げるかを事前に明確にしておくことで、OK/NGの意思決定も素早く行えます。
また、施策を行うことで影響のありそうな指標を「モニタリング指標」として、目標数値とは別で計測しておくと良いでしょう。
こちらも、クリティカルな部分であれば「○○%の下落までは許容」などと閾値を決めておくとその後の意思決定に役立ちます。
～ユーザーに十分に・正しく利用してもらうために～
5.導線
「この機能をユーザーに利用してもらうための導線は十分か？」
「単一になっていないか？」
「機能の中身に気を取られていて、導線を考えてなかった...」ということは意外とありがちです。
作った機能をきちんとユーザーに利用してもらえるよう、導線を設計しましょう。
また、「メニューに項目追加して終わり」といったことにならないよう、「どのタイミングでユーザーに利用してほしい機能なのか」をきちんと考え、適切な場所に導線を設置することが重要です。
6.文言
「この機能の存在をユーザーが認識できる文言は十分か？」
「単一になっていないか？」
導線が設置されていても、それが分かりにくい場所だったとしたら、ユーザーは機能の存在を認識できません。
デザインや機能の構成上、導線が分かりにくくなってしまう場合は、文言等で補うようにしましょう。
7.説明
「この機能の使い方をユーザーが理解できるか？」
「説明は十分か？」
機能を正しく利用してもらうには、使い方をユーザーに理解してもらう必要があります。
初めて見たユーザーでも使い方が理解できるよう、十分なガイドを設けるようにしましょう。
8.トリガー
「この機能をユーザーが利用するトリガーは十分か？」
「単一になっていないか？」
先述の「導線」と合わせて検討したいのが、ユーザーが機能を利用するトリガーです。
特に、既存のフローの中で利用するものではない場合、ユーザーがその機能を利用するトリガーは何なのかを確認し、必要に応じてメールやプッシュ通知等のトリガーを提供しましょう。
9.モチベーション
「この機能をユーザーが利用するモチベーションを与えられているか？」
ユーザーが機能を利用するには動機やモチベーションも必要です。
正攻法としては、得られるメリットや活用法をきちんと伝えることが良いでしょう。
また、行動経済学のような人間の行動原理を活用した手法も、時には有効です。
10.印象
「この機能を通じてユーザーが良い印象を抱けるか？」
「次も使おうと思えるか？」
前述の「モチベーション」とも関わりますが、ユーザーがその機能を2回以上利用するかどうかは、過去に機能を利用した印象に影響されます。
「次も使おうと思えるか？」「次に使おうとした時に引っ掛かりを生むような体験はないか？」といった観点で見直してみると良いでしょう。
11.UI
「UIは一般ユーザーが慣れているものか？」
「戸惑う部分はないか？」
UIは「一般的に良くあるUI」がベターです。
できるだけユーザーが普段慣れ親しんでいるUIに近づけ、戸惑うことが無いようにしましょう。
※ただし、UI自体に工夫や検証をする施策の場合、その限りではありません。
～施策が工数に見合った効果を残すために～
12.必要性と根拠
「この施策・機能は本当に必要なのか？」
「ニーズはあるのか？」
「根拠となるデータはあるか？」
今一度、「この施策、本当にやる？」と問う項目です。
せっかく企画した施策は無下にしたくないという気持ちになります。
ただ、どの段階でもこの問いに自信を持ってイエスと言えない施策は、リリース後に「あれ、これやる意味あったのかな・・・」となりがちです。
もしイエスと言えないならば、後述の「事前検証」「課題の本質」「実施タイミング」「実現方法」などを改めて検討してみましょう。
13.事前検証
「この施策のインパクト・ニーズを事前に検証できる方法はあるか？」
前述の「必要性と根拠」に自信が持てない場合、まずは事前検証の方法を検討することは有効な手段です。
プロトタイプやMVPで検証する方法や、既にあるデータから分かることもあるでしょう。
事前検証を行うことで、開発の無駄を削減できる場合があります。
14.母数
「この施策で影響を与えられるユーザー・数値の母数はどのくらいか？（多くのユーザーに関わるもの、ユーザーが繰り返し使うものが望ましい）」
施策のインパクトは、「多くのユーザー」が「繰り返し使うもの」が最も大きくなります。
必ずしもそうでなければいけないという訳ではありませんが、一つの情報として把握しておくと良いでしょう。
15.影響度
「この施策で与えられる影響はどのくらいか？」
施策のインパクトを「母数」×「影響度」と考えた時の後者に該当するものです。
「目標数値・モニタリング指標」とほぼ同じですが、ここでは「施策の必要性や重要度を評価する」目的で整理する情報と捉えてください。
どの数値が何%上がるのかを試算し、前述の「母数」と合わせて評価することで、施策のインパクトを推し量れます。
16.課題の本質
「解決する課題・解決方法は本質的か？」
もう少し噛み砕くと、
「施策で解決しようとしている課題は、プロダクトの中で重要な課題か？」
「ユーザーへのコアな価値提供につながるのか」
「課題に対して対処療法的な解決策になっていないか」
といった問いです。
施策としては論理的整合性は取れているけど...何か違和感がある、という時に確認すると良いでしょう。
施策の根幹部分であり、最終的なインパクトにも直結する部分です。
非常に難しい問いですが、確実に施策の質の向上につながります。
17.実現方法
「課題に対する解決策はこれが適切か？」
「他のアプローチでインパクトを残せる方法や箇所は無いか？」
施策を行うことはあくまでも手段で、目的は課題を解決することです。
先述の「課題の本質」とつながりますが、今一度目的や課題に立ち返り、他のアプローチを検討することで、施策を幅広い視点で捉えることができます。
18.運用設計
「営業・マーケ・運用など、この施策を成功させるために必要な活動は定義されているか？」
「リリーススケジュールと足並みは揃っているか？」
事前にユーザーへ周知が必要な機能や、社内の運用体制が必要な機能などは、単に機能をリリースだけでは終わりではありません。
リリースしたのにその他の準備ができていなければ、「こんなに急いでリリースする意味あったんだっけ」となってしまいます。
開発以外のタスクも含め、どんな準備が必要で、どのように足並みを揃えるのかをきちんと定義しましょう。
19.実施タイミング
「タイミングは「今」が適切か？（開発以外の運用の準備状況、プロダクト全体の状況、優先度、といった観点から）」
実施するタイミングも施策の成功を左右します。
先述の「運用設計」の準備状況、先に仕込むべき別の施策、他にやるべき優先度の高い課題など、「いつやるべきなのか？」を整理することは重要です。
～施策が狙った方向に動くために～
20.既存機能との不整合
「既存機能と不整合や矛盾が起きる部分は無いか？」
「サービス全体のユーザー体験として、一貫性が保てているか？ 」
「新しい機能をリリースしたら、既存のユーザー体験と不整合が生じてしまった。」ということを防ぐための問いです。
画面によって表示される情報が違ったり、表現が異なることでユーザーを混乱させてしまうことなど、追加する機能にフォーカスしてしまうと意外と気が付かないものです。
サービス全体のユーザー体験として不自然ではないか、俯瞰的にチェックしましょう。
21.逆効果リスク
「この施策を行うことによるリスクは何か？」
「利便性が上がる半面で、悪い印象になる部分・体験を損ねる部分が無いか？」
施策を企画する時、ついついメリットばかり見がちです。
施策を行うことによるリスクや逆効果もセットで考えましょう。
例えば、「検索一覧画面で詳細な情報を表示したが、逆に重要な情報が埋もれてしまった。」「検索条件の絞り込みを詳細に行えるようにしたが、ヒットしないケースが増えてかえって印象が悪くなった。」などが考えられます。
それによって「リスクがあっても実施するかどうか」「リスクを回避する方法はあるか」などの検討が可能になります。
チェックリストの使う際の注意点
すべての項目を完璧にする必要はない
各項目が全て完璧になっているのが理想ですが、必ずしもその必要はありません。
やってみなければ分からないこともありますし、完璧にしたからといって100%成功するものでもありません。
あくまでも、事前に可能な範囲で質を上げるためのものとして活用いただければと思います。
逆に、こういった項目は施策のアウトカム期待値を左右する変数になり得るものもあります。
例えば、「トリガー」や「モチベーション」の設計次第で上手くいくものもありますし、「必要性と根拠」の「ニーズがあるのかどうか」というポイントはアウトカムの根本になる部分でもあります。
こういった項目については「リリースしてみないとわからない」という側面もあるため、無理に企画の段階で精度を上げようとせず、リリース後の検証ポイントとする、という活用方法も考えられます。
このあたりは施策によって柔軟に活用してみてください。
スピードとのバランスは取る
おそらく一部の方は、「企画の段階であれこれ考え過ぎるとスピードが落ちるのではないか」と思うのではないでしょうか。
これはまさにその通りで、考え過ぎて全然施策が実行できない、というのは本末転倒です。
先述した通り、企画の段階で全てを完璧にすることは不可能ですし、リリースしなければわからないポイントは存在します。
そのようなポイントは、リリース後の検証ポイントとして施策を実行するべきです。
一方で、企画の段階でできる限り質を上げておくことは、リリース後の仮説検証の質も向上させます。
スピードを優先するあまり企画の質を上げる作業がおろそかになると、本来意図する仮説検証が行えなかったり、必要な仮説検証の数が増えることになり、結果的に時間も工数もかかるということにつながります。
「とりあえずABテストしてみる」「まずリリースしてみる」といったプロセスはスピーディーに見えますが、きちんとしたデータや仮説・段取りの整理・できるはずの質の向上をすっ飛ばして進めるのは工数の無駄になりかねないので気を付けたいですね。
このように、施策実行のスピードは落とさず、かつ企画の精度を可能な限り上げる、という相反する2つのバランスを取ることが、結果的にアウトカムの期待値を最大化させることにつながります。
企画にどれだけ工数をかけることができるか、開発にどれだけ工数をかけることができるか、検証にどれだけ時間がかかるか、といった各プロダクトの事情によってバランスが変わってくるので、最適なバランスは常に意識しましょう。
最後に
現在アスタミューゼでは、プロダクトマネージャー・エンジニア・デザイナーを絶賛募集中です。
ちょっと話を聞いてみたいなど大歓迎です！
少しでも興味を持っていただけた方はぜひ採用サイトからご連絡ください。
お久しぶりでございます。scala等でバックエンドを開発しているaxtstarでございます。
