顧客から何度も要望されていた機能を、2か月かけて出した。リリースの日には社内のチャットで「おつかれさまでした」が並び、翌週からは次の機能の開発が始まった。半年後、別の機能の相談をしている最中に、ふと「そういえば、あの機能はどのくらい使われているのか」と気になった。調べてみると、使っている顧客は数社だけで、要望をくれた顧客も、最初の数回使ったきりだった。
こうしたことは、少人数で開発しているスタートアップでは珍しくありません。作ることに手いっぱいで、出したものを確かめる時間が取れない。確かめようにも、何の数字を見ればよいのか決めていない。結果として、使われていない機能が増え、次に何を作るかの判断も、勘に頼ったままになります。
機能は、出した時点では「作った」にすぎません。顧客の行動が変わったかどうかを確かめて、初めて「成果が出た」かどうかが分かります。
本記事では、プロダクトの判断を担いながら、事業全体も見ている方に向けて、機能を出したあとの効果検証と振り返りを、無理なく続けるための4つのステップを解説します。
リリース後の効果検証とは何か
リリース後の効果検証とは、出した機能によって、ねらっていた変化が実際に起きたかを確かめることです。振り返りは、その結果をもとに、機能を「続ける」「直す」「やめる」のどれにするかを決め、次の判断に活かすことを指します。
似た言葉に、開発の進め方を見直す振り返り（スプリントの振り返りなど）があります。こちらは「作り方」を見直すもので、本記事で扱うのは「作ったもの」が役に立ったかどうかです。両者は別のものとして扱います。
効果検証というと、A/Bテストのような厳密な比較を思い浮かべる方もいるかもしれません。しかし、利用者がまだ少ないスタートアップでは、統計的に意味のある比較ができる場面は限られます。本記事では、厳密さよりも、出したものを必ず一度は確かめる習慣をつくることを優先します。
なぜ「出して終わり」になってしまうのか
確かめることが大切だと分かっていても、実際には後回しになりがちです。理由は主に3つあります。
1. 次の開発がすでに始まっている
機能を出した翌日から、開発チームは次の機能に取りかかります。経営者も、次の商談や採用、資金調達のことで頭がいっぱいです。出した機能を見返す時間は、誰の予定にも入っていません。予定に入っていないことは、忙しいときほど後回しになります。
2. 何を見れば成功なのかを決めていない
リリースしてから「さて、うまくいったのだろうか」と考えても、何の数字を見ればよいかが決まっていなければ、判断できません。とりあえず利用回数を調べてみても、その数が多いのか少ないのかの基準がないため、「まあまあ使われている」という感想で終わってしまいます。
3. 結果を知るのが怖い
あまり語られませんが、これも大きな理由です。時間とお金をかけて作った機能が、ほとんど使われていなかったと分かるのは、気持ちのよいことではありません。特に、自分が強く推した機能であればなおさらです。確かめなければ、失敗だったと分かることもない。そうした気持ちが、検証を遠ざけます。
ただ、使われていない機能は、確かめなくても残り続け、画面を複雑にし、保守の手間を生み続けます。早く知るほど、直すにしても、やめるにしても、打てる手が増えます。
効果検証と振り返りの4つのステップ
ここからは、具体的な進め方を4つのステップで説明します。ポイントは、リリースしてから考えるのではなく、リリースする前に、何をいつ確かめるかを決めておくことです。
ステップ1：リリース前に「何が変われば成功か」を決める
最初に行うのは、機能を出す前に、その機能によって何が変わってほしいのかを言葉にすることです。
決めるのは、次の3つです。
- ねらい：この機能で、誰のどんな困りごとを解消したいのか
- 見る数字：その困りごとが解消されたら、どの数字が変わるはずか
- 目安：どのくらい変われば「成功」とみなすか
たとえば、請求書の一括ダウンロード機能を出す場合は、次のようになります。
| 項目 | 例 |
|---|---|
| ねらい | 月末に請求書を1件ずつダウンロードしている経理担当者の手間を減らす |
| 見る数字 | 請求書を発行している顧客のうち、一括ダウンロードを使った顧客の割合 |
| 目安 | 2か月後に、対象顧客の半数以上が月末に使っている |
見る数字は、できるだけ1つに絞ります。数字を5つも6つも並べると、どれかは必ず良くなっているため、「全体としては成功」という結論になりがちです。補助として見る数字を1〜2個添えるのは構いませんが、成功かどうかを判断する数字は1つにします。
目安は、厳密な根拠がなくても構いません。「これくらい使われなければ、作った意味がない」という感覚で置いてみることが大切です。目安があることで、結果を見たときに「思ったより良かった」「思ったより悪かった」と比べられるようになります。
ここで決めたことは、開発を始める段階の仕様書やチケットの冒頭に書いておきます。開発チームにとっても、何のために作るのかが分かると、細かな判断をそろえやすくなります。
ステップ2：確かめる日を、先に予定に入れる
見る数字を決めたら、次は、それをいつ確かめるかを決め、その場で予定に入れます。
おすすめは、次の2回です。
- 1回目（リリースから2週間後）：機能が見つけてもらえているか、使い始めてもらえているかを確かめる
- 2回目（リリースから6〜8週間後）：使い続けてもらえているか、ねらいどおりの変化が起きているかを確かめる
2回に分けるのは、確かめたいことが時期によって違うためです。リリース直後は、目新しさから一度は触ってもらえることが多く、継続して使われるかどうかは分かりません。一方で、2か月待ってから初めて見ると、「そもそも機能の存在に気づかれていなかった」という早く直せたはずの問題を見逃します。
月に一度しか使わない機能（月末の締め処理など）であれば、2回目は、その処理を2回経たあとに置きます。機能が使われる周期に合わせて、日付を決めてください。
予定は、カレンダーに30分の枠として入れてしまいます。「そのうち見る」は、まず実行されません。日付と時間が決まっていれば、その日に数字を開くだけで済みます。
数字を見る準備も、このときに済ませておきます。必要な数字がいまの仕組みで取れるかを、エンジニアに確かめてください。取れない場合は、リリースの時点で記録が残るようにしてもらいます。リリースしたあとに「数字が取れていなかった」と気づくと、その期間の様子は二度と分かりません。
ステップ3：数字と声の両方で確かめる
予定した日が来たら、結果を確かめます。このとき、数字だけでなく、使っている人の声もあわせて見ます。
数字は、3つの段階に分けて見る
数字は、次の3つの段階に分けて見ると、どこでつまずいているかが分かります。
- 見つけてもらえたか：対象の顧客のうち、機能の画面を開いた、または機能を一度でも使った割合
- 使い続けてもらえたか：一度使った顧客のうち、2回目以降も使っている割合
- ねらいどおりの変化が起きたか：ステップ1で決めた数字が、目安に届いたか
3つ目だけを見て「目安に届かなかった」と分かっても、何を直せばよいかは分かりません。1つ目が低ければ、機能の存在が伝わっていない、入口が見つけにくいといった問題です。1つ目は高いのに2つ目が低ければ、使ってみたものの期待と違った、使い方が分かりにくかった、という問題が考えられます。段階ごとに見ることで、次に打つ手が具体的になります。
声は、3つの場所から集める
数字からは「何が起きたか」は分かりますが、「なぜそうなったか」は分かりません。理由を知るために、次の3つの場所から声を集めます。
- 問い合わせ：機能について、どんな質問や不満が届いているか
- 営業や顧客対応の担当者：顧客との会話の中で、機能について何を言われたか
- 使っている顧客、使っていない顧客への短い聞き取り：それぞれ2〜3社に、15分ほど話を聞く
特に大切なのは、使っていない顧客に話を聞くことです。使っている顧客は、たいてい機能に満足しています。使っていない顧客からは、「そもそも知らなかった」「試したが、自分たちの業務の流れに合わなかった」といった、数字だけでは見えない理由が聞けます。
聞き取りの際は、「この機能はいかがでしたか」と尋ねるよりも、「月末の請求書の作業は、最近どのように進めていますか」と、業務そのものを尋ねるほうが、実際の使われ方が分かります。
ステップ4：続ける・直す・やめるを決めて、記録する
数字と声がそろったら、その機能をこれからどうするかを決めます。選ぶのは、次の3つのいずれかです。
| 判断 | 当てはまる状態 | 次の行動 |
|---|---|---|
| 続ける | 目安に届いた、または届きそうな勢いがある | 追加の手当てはせず、通常の改善の候補として扱う |
| 直す | 目安に届いていないが、つまずいている段階と理由が分かっている | 直す内容をバックログに入れ、もう一度確かめる日を決める |
| やめる | 目安から大きく離れ、直しても使われる見込みが薄い | 提供を止めるか、別の機能に統合するかを検討する |
「直す」を選んだ場合は、何を直せば、どの段階の数字が良くなるはずかを、ステップ1と同じ形で書いておきます。「見つけてもらえていない」なら案内の出し方を変える、「使い続けてもらえない」なら操作の手順を減らす、といった形です。そして、もう一度確かめる日を予定に入れます。
ただし、「直す」は何度も繰り返すものではありません。2回直しても目安に近づかない場合は、そもそもの「ねらい」がずれていた可能性があります。その場合は「やめる」も含めて考え直します。
判断を決めたら、次の内容を短く記録します。
- 機能の名前と、リリースした日
- ステップ1で決めたねらい・見る数字・目安
- 実際の結果（3つの段階の数字と、集めた声の要点）
- 判断（続ける・直す・やめる）と、その理由
- 次に確かめる日（直す場合）
この記録は、半年後に「なぜこの機能があるのか」「なぜあのとき直したのか」を説明する材料になります。そしてもう1つ、次に何を作るかを決めるときの材料にもなります。過去に出した機能のうち、ねらいどおりになったものと、ならなかったものを並べると、自分たちが顧客の困りごとをどのくらい正しく読めているかが見えてきます。
少人数で無理なく続けるための工夫
4つのステップをすべての機能に厳密に当てはめると、それだけで手がかかりすぎて、続かなくなります。少人数のチームで続けるには、次のような工夫が役立ちます。
確かめる対象を絞る
小さな文言の修正や、不具合の修正まで、すべてを検証する必要はありません。対象にするのは、次のような機能です。
- 開発に2週間以上かかったもの
- 特定の顧客や商談をきっかけに作ったもの
- 新しい顧客層や新しい使い方をねらったもの
目安として、月に1〜3件ほどに収まる範囲にすると、無理なく続けられます。
月に一度、まとめて振り返る場をつくる
個別の機能ごとに予定を入れるのに加えて、月に一度、その月に確かめた結果をまとめて見る場を30分ほど設けます。参加するのは、プロダクトの判断を担う人と、開発の中心になっている人、顧客対応や営業の担当者です。
この場では、個々の機能の判断に加えて、「ねらいどおりにならなかった機能に、共通点はないか」を話します。たとえば、特定の大口顧客の要望で作った機能ほど、ほかの顧客に使われていない、といった傾向が見えてくることがあります。それは、次の計画の立て方を見直すきっかけになります。
結果を、開発チームと共有する
検証の結果は、良いものも悪いものも、開発チームに共有します。自分たちが作ったものがどう使われているかを知る機会は、エンジニアにとって思いのほか少ないものです。
使われていなかった結果を共有するときは、「誰の判断が間違っていたか」ではなく、「次に作るときに何を変えるか」に話を向けます。結果を責める場になると、次からは都合の悪い数字が出てこなくなります。
よくある失敗
- リリースしてから見る数字を考える：あとから数字を選ぶと、良い結果が出ている数字を無意識に選びがちです。見る数字と目安は、必ずリリース前に決めます。
- 利用回数の合計だけを見る：一部の顧客が何度も使っているだけで、合計の回数は大きく見えます。「何社が使っているか」「対象の顧客のうち何割か」で見ます。
- 要望をくれた顧客だけに聞く：要望を出した顧客は、使ってくれる可能性が高い一方で、ほかの顧客を代表しているとは限りません。使っていない顧客の声も集めます。
- 「直す」を繰り返して、やめる判断を先送りにする：直すたびに少しずつ良くなっても、目安に遠く届かないままなら、ねらいそのものを見直す時期です。
- 記録を残さない：判断の理由が残っていないと、半年後に同じ議論を繰り返すことになります。数行で構わないので、必ず書き残します。
具体例：要望の多かった機能が、ほとんど使われていなかったケース
従業員12名、建設会社向けに現場の日報管理サービスを提供するスタートアップを想定した例です。プロダクトの判断は経営者が担い、開発はエンジニア3名で進めていました。
大口顧客3社から強い要望があり、「日報の内容をまとめて週報として出力する機能」を、1か月半かけて開発しました。リリースの時点では、ねらいや見る数字は決めておらず、出したあとはそのまま次の開発に移っていました。
3か月後、別の顧客との打ち合わせで週報の話題になったことをきっかけに、利用状況を調べてみました。すると、次のことが分かりました。
- 週報の画面を一度でも開いた顧客は、全体の約4割
- 開いた顧客のうち、2回目以降も使っている顧客は2割に満たない
- 要望をくれた3社のうち、継続して使っていたのは1社だけ
使っていない2社に話を聞くと、「出力された週報を、結局エクセルに貼り直して社内の様式に合わせている。それなら最初からエクセルで作るほうが早い」という声が返ってきました。見つけてもらえていなかったのではなく、使ってみたうえで、業務の流れに合っていなかったのです。
そこで、出力の形式をエクセルで開ける形に変え、項目の並びを顧客側で変えられるようにしました。今度はリリース前に、「週報の画面を開いた顧客のうち、6週間後に2回以上使っている顧客が半数以上」を目安とし、リリースから2週間後と6週間後に確かめる予定を入れました。
6週間後、継続して使っている顧客は、開いた顧客の6割ほどまで増えたという想定です。経営者は、「最初に確かめていれば、3か月早く直せた。それ以上に、要望の言葉をそのまま形にするのではなく、その先の業務まで聞くべきだったと分かった」と振り返っていました。以後、開発に2週間以上かかる機能には、仕様書の冒頭にねらいと見る数字を書くことにしました。
よくある質問（FAQ）
Q1. 利用している顧客が少なく、数字で判断できるほどの量がありません。
顧客が数十社ほどの段階では、割合が大きく動きやすく、数字だけで判断するのは難しいことがあります。その場合は、数字は「何社が使っているか」という実数で見て、声の比重を高めます。使っている顧客と使っていない顧客、それぞれ2〜3社に話を聞くだけでも、続ける・直す・やめるの判断に必要な材料はおおむねそろいます。
Q2. 必要な数字を取る仕組みがありません。分析ツールを導入すべきでしょうか。
最初から本格的な分析ツールを入れる必要はありません。多くの場合、データベースに残っている記録（機能を使った日時や顧客）から、エンジニアに集計してもらうだけで足ります。大切なのは、リリースの前に「この数字が取れるか」を確かめておくことです。取れない場合は、機能と一緒に記録が残る仕組みを入れてもらいます。
Q3. 検証の結果、「やめる」と判断した機能は、すぐに消すべきですか。
すぐに消す必要はありません。使っている顧客が少数でもいれば、その顧客への影響を確かめ、代わりの手段を用意してから進めます。新しい顧客への提供だけを先に止める、別の機能に統合する、といった選択肢もあります。
Q4. 経営者が強く推した機能の結果が悪かった場合、どう扱えばよいでしょうか。
自分が推した機能ほど、結果を冷静に見るのは難しいものです。だからこそ、ステップ1でねらいと目安を先に決め、それに照らして判断することが役立ちます。結果は「判断が間違っていた」ではなく、「顧客の困りごとの読み方を更新する材料」として扱います。経営者自身がそうした姿勢を見せると、チーム全体で結果を率直に話せるようになります。
Q5. 1人目のプロダクトマネージャーを迎えたら、この仕組みはどう引き継げばよいですか。
効果検証と振り返りは、プロダクトマネージャーに任せやすい仕事の1つです。引き継ぐときは、これまでの記録（ねらい・見る数字・結果・判断）を一緒に渡すと、どんな機能がうまくいき、どんな機能がそうでなかったかを、短期間でつかんでもらえます。経営者は、月に一度の振り返りの場に参加し、判断の結果を聞く立場に移るのがおすすめです。
まとめ
機能は、出した時点では「作った」にすぎません。顧客の行動が変わったかどうかを確かめて、初めて成果が出たかどうかが分かります。
出して終わりにしないためには、(1)リリース前に「何が変われば成功か」を決める、(2)確かめる日を先に予定に入れる、(3)数字と声の両方で確かめる、(4)続ける・直す・やめるを決めて記録する、という4つのステップで進めます。すべての機能を対象にする必要はなく、開発に時間がかかったものや、特定の顧客の要望で作ったものから始めれば十分です。
まずは、この3か月に出した機能の中から1つを選び、いまどのくらい使われているかを調べてみてください。思っていたとおりか、思っていたより少ないか。その答えが、次に何を作るかを考えるときの、確かな手がかりになります。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。
「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。
おおむね2営業日以内にご返信します。
