← 実践記事

OTSUMU KNOWLEDGE

新機能の効果測定の方法:リリース後に見る指標と継続判断の仕方

新機能の効果測定は、リリース前に「何が変われば成功か」を決め、利用率・継続への影響・売上への影響の三段階で確かめるのが基本です。見る指標、測り方の手順、効果がない機能を改善・縮小・廃止する判断の仕方を解説します。

新しい機能をリリースした後、「使われているのか」「事業に効いているのか」を確かめないまま、次の開発に移っていないでしょうか。効果を測らずに機能を追加し続けると、プロダクトは複雑になり、使われない機能の保守に開発の時間が奪われていきます。

新機能の効果測定の結論は、「リリース前に成功の基準を決め、利用率、継続への影響、売上への影響の三段階で確かめ、効果がなければ改善・縮小・廃止を判断する」ことです。リリース後に慌てて指標を探すと、都合のよい数字だけを拾ってしまいがちです。測る指標と判断の基準を事前に決めておくことで、機能の継続を冷静に判断できるようになります。

この記事は、SaaSやWebサービス、アプリのプロダクトマネージャー、事業責任者、開発チームに向けて、新機能の効果測定で見る指標、リリース前の準備、測定の手順、比較の方法、効果がない機能の扱い方、よくある失敗を解説します。

新機能の効果測定が後回しにされる理由

効果測定の重要性は多くの人が理解しています。それでも後回しにされるのは、いくつかの構造的な理由があるからです。

  • 開発の締め切りが優先される:リリースに間に合わせることが目標になり、計測の実装が削られる。
  • 成功の基準が決まっていない:何が起きれば成功かが決まっていないため、リリース後に何を見ればよいか分からない。
  • 次の開発がすぐに始まる:リリースした時点でチームの関心が次の機能に移り、振り返りの時間が取られない。
  • 効果がないと分かるのが怖い:時間をかけて作った機能の効果がないと分かることを、無意識に避けてしまう。

これらの理由は、個人の意識ではなく、開発の進め方の問題です。リリース前の計画に効果測定を組み込み、リリース後の一定時期に振り返りの場を設けることで、仕組みとして解決できます。

新機能の効果を測る三つの段階

新機能の効果は、三つの段階で確かめます。段階が進むほど事業への影響に近づきますが、測るのに時間がかかり、他の要因の影響も受けやすくなります。

段階確かめること主な指標結果が出るまでの時間
1. 利用機能が見つけられ、使われているか発見率、利用率、繰り返し利用率リリース後すぐ〜数週間
2. 行動・継続機能を使った人の行動や継続が変わったか継続率、利用頻度、主要な行動の回数数週間〜数か月
3. 事業成果売上や解約などの事業指標が変わったか有料転換率、アップセル、解約率、問い合わせ件数数か月以上

第一段階:利用されているか

最初に確かめるのは、機能がそもそも使われているかです。ここでは三つの数字を分けて見ます。

  • 発見率:機能の入口(ボタンやメニュー)を見た人の割合。低ければ、機能の存在に気づかれていない。
  • 利用率:機能を一度でも使った人の割合。発見されているのに低ければ、価値が伝わっていないか、使い始めのハードルが高い。
  • 繰り返し利用率:一度使った人のうち、再び使った人の割合。低ければ、試しに使ったが期待した価値がなかった可能性が高い。

この三つを分けると、利用されない原因が「気づかれていない」「試されていない」「続かない」のどれなのかが分かり、打つべき手が変わります。分母を「その機能を必要とする可能性がある人」に絞ることも大切です。管理者向けの機能の利用率を全ユーザーで割ると、効果が低く見えてしまいます。

第二段階:行動や継続が変わったか

次に、機能を使った人の行動や継続が変わったかを確かめます。新機能が、ユーザーの主要な目的をより早く、より楽に達成できるようにするものなら、その目的の行動の回数や、サービスの継続率に表れるはずです。

ただし、ここでは注意が必要です。機能を使った人の継続率が高いからといって、機能が継続を高めたとは限りません。もともと熱心なユーザーほど新機能を試しやすく、継続率も高いからです。この偏りを避ける比較の方法は、後の節で説明します。

第三段階:事業成果が変わったか

最終的には、有料転換、アップセル、解約、問い合わせ件数といった事業の指標への影響を確かめます。事業成果は多くの要因で動くため、一つの機能の効果だけを取り出すのは難しいものです。それでも、機能の企画時に想定した事業上の目的と照らし合わせて、方向性が合っているかを確かめることは欠かせません。

リリース前に決めておくこと

効果測定の成否は、リリース前の準備で決まります。企画の段階で、次の項目を一枚の文書にまとめておきましょう。

  1. 機能の目的:どのユーザーの、どんな課題を解決するための機能か。
  2. 仮説:「この機能を使うと、ユーザーの何がどう変わり、その結果どの事業指標が改善するか」を一文で書く。
  3. 見る指標:三段階それぞれで見る指標を決める。主に見る指標は一つか二つに絞り、悪化していないかを確かめる指標(ガードレール指標)も決める。
  4. 成功の基準:いつまでに、どの指標がどうなれば成功とみなすか。基準を決めにくい場合は、「改善」「現状維持」「悪化」の判断の目安を決める。
  5. 計測の実装:必要なイベントを洗い出し、機能と一緒に計測を実装する。計測の設計はGA4のイベント設計やプロダクトのイベントログ設計を参考に。
  6. 比較の方法:機能を使った人と使わなかった人をどう比べるか、段階的に公開するか、などを決める。
  7. 振り返りの日程:リリースから何週間後、何か月後に結果を確認するかを決め、予定に入れる。

ガードレール指標は見落とされがちですが重要です。新機能の利用率が上がっても、そのせいで主要な機能の利用が減ったり、画面の表示が遅くなったり、問い合わせが増えたりしていれば、全体としては悪化しているかもしれません。

仮説の書き方にも工夫があります。「便利になるはず」のようなあいまいな仮説では、結果を見ても成功か失敗かを判断できません。「案件数の多いユーザーが一括編集を使うと、案件の更新漏れが減り、三か月後の継続率が上がる」のように、誰が、何をすると、何が、いつまでに変わるのかを具体的に書きます。仮説が具体的であるほど、見るべき指標と比べる相手が自然に決まります。

効果を正しく比べる方法

新機能の効果を正しく測るには、「機能がなかった場合」と比べる必要があります。比べ方には複数の方法があり、確からしさと手間が異なります。

比較の方法内容確からしさ注意点
A/Bテストユーザーを無作為に分け、片方にだけ機能を公開する高い十分なユーザー数と、出し分けの仕組みが必要
段階的な公開一部のユーザーから順に公開し、公開前のユーザーと比べる中程度公開順に偏りがあると比較がゆがむ
リリース前後の比較リリース前の一定期間とリリース後の一定期間を比べる低い季節やキャンペーンなど他の要因と区別しにくい
利用者と非利用者の比較機能を使った人と使わなかった人を比べる低い熱心なユーザーほど使うという偏りが入る

最も確からしいのは、ユーザーを無作為に分けるA/Bテストです。機能の出し分けができる仕組みがあり、ユーザー数が十分にあるなら、重要な機能ほどA/Bテストで検証する価値があります。設計の詳細はA/Bテストの設計で解説しています。

A/Bテストが難しい場合でも、比較の工夫で確からしさを高められます。たとえば、利用者と非利用者を比べるときは、機能のリリース前の行動がそろっている人同士で比べる、リリース前後の比較では、同じ期間の前年や、機能の影響を受けないユーザー群の変化と合わせて見る、といった方法です。

ユーザー数が少ない場合の考え方

BtoBのサービスなど、ユーザー数が少ない場合は、統計的に意味のある差を確かめるのが難しくなります。その場合は、利用状況の定量データに加えて、ユーザーへの聞き取りを重視します。機能を使った人に「何がどう変わったか」を聞き、使わなかった人に「なぜ使わなかったか」を聞くことで、数字だけでは見えない効果と課題が分かります。

新機能の効果測定の進め方:リリース後の手順

リリース後は、次の流れで効果を確かめます。

  1. 計測の動作を確認する:リリース直後に、イベントが正しく記録されているかを確認する。記録漏れがあれば、すぐに修正する。
  2. 第一段階を確認する:リリースから数日〜数週間で、発見率・利用率・繰り返し利用率を確認する。
  3. 利用の障壁を取り除く:発見率が低ければ入口の位置や案内を、利用率が低ければ使い始めの手順を見直す。
  4. 第二段階を確認する:利用が安定したら、比較の方法に沿って継続や行動の変化を確認する。
  5. ガードレール指標を確認する:主要な機能の利用、表示速度、問い合わせなどに悪化がないかを確認する。
  6. 第三段階を確認する:数か月後に、事業指標への影響を仮説と照らし合わせて確認する。
  7. 継続の判断をする:結果を振り返りの場で共有し、継続・改善・縮小・廃止を判断する。

振り返りの場は、開発チームだけでなく、事業責任者やカスタマーサクセスの担当者も参加して行うと、数字の解釈に現場の知見を加えられます。

機能ごとの指標を一覧で追う

リリースする機能が増えてくると、機能ごとに別々の資料で効果を確かめるのは手間がかかります。直近にリリースした機能を一覧にし、機能名、リリース日、目的、主に見る指標、現在の値、成功の基準、次の振り返り日を並べた表を用意しておくと、どの機能の確認が遅れているかが一目で分かります。

この一覧は、プロダクトの定例会議で定期的に確認する資料として使うのがおすすめです。新しい機能を企画するときにも、過去に似た目的で作った機能の結果を参照できるため、同じ失敗を繰り返しにくくなります。分析ツールのダッシュボードで機能ごとの利用率を自動で表示できるようにしておくと、確認の手間がさらに減ります。ツールの選び方はプロダクト分析ツールの選び方で比較しています。

一覧には、効果がなかった機能や廃止した機能も残しておきましょう。うまくいかなかった仮説の記録は、次の企画で同じ前提を疑うための貴重な材料になります。

効果がない機能の扱い方:改善・縮小・廃止の判断

効果測定の結果、期待した効果が出ていない機能が見つかることは珍しくありません。そのときに大切なのは、「せっかく作ったから」と残し続けるのではなく、根拠を持って扱いを決めることです。判断の目安を示します。

状況判断次の行動
発見されていない改善入口の位置や案内を見直し、再度測る
試されるが続かない改善または縮小使ったユーザーに理由を聞き、価値の届け方を見直す
一部のユーザーには強く使われている維持・対象を絞る使っているユーザーの特徴を調べ、その層に向けて案内する
使われているが事業指標に影響がない判断を保留・仮説を見直す仮説が誤っていなかったか、測る期間が短くないかを確認する
ほとんど使われず、保守の負担が大きい廃止を検討利用者への影響を確認し、告知と代替手段を用意して終了する

機能の廃止は、使っている少数のユーザーにとっては不利益になります。廃止を決めたら、利用しているユーザーを特定し、事前に告知し、代わりの方法を案内するなど、丁寧に進めましょう。BtoBのサービスでは、契約上の約束や個別の要望がないかも確認が必要です。

使われない機能を減らすことは、プロダクトを分かりやすくし、開発チームが本当に価値のある機能に集中するための重要な判断です。機能を追加するだけでなく、減らす判断もできるチームは、長い目で見てプロダクトの質を高められます。

架空の例:業務アプリの一括編集機能の効果測定

たとえば、案件管理の業務アプリで、複数の案件をまとめて編集できる一括編集機能をリリースしたとします。目的は「案件数の多いユーザーの作業時間を減らし、継続率を高める」こと、仮説は「一括編集を使うユーザーは、案件の更新を滞らせずに済み、アプリを使い続ける」でした。

リリース後の第一段階で、利用率が想定より低いことが分かりました。調べると、一括編集の入口が一覧画面の右上のメニューの奥にあり、発見率が低いことが原因でした。入口を一覧画面の上部に移し、複数の案件を選んだときに一括編集を案内する表示を加えると、発見率と利用率が改善しました。

第二段階では、案件数の多いユーザーに絞り、リリース前の更新頻度がそろったユーザー同士で、一括編集を使った人と使わなかった人の継続状況を比べました。差は見られたものの、熱心なユーザーの偏りを完全には除けないため、カスタマーサクセスの担当者が利用者に聞き取りを行い、作業時間が減ったという声を確認しました。事業指標への影響は、数か月後に案件数の多い顧客の解約状況を見て判断します。

新機能の効果測定のチェックリスト

  • 機能の目的と仮説を一文で書いている
  • 三段階それぞれで見る指標を決めている
  • 主に見る指標を一つか二つに絞り、ガードレール指標も決めている
  • 成功の基準、または判断の目安を決めている
  • 計測を機能と一緒に実装し、リリース直後に動作を確認した
  • 比較の方法を決め、利用者の偏りに注意している
  • 振り返りの日程を決め、予定に入れている
  • 効果がない場合の改善・縮小・廃止の判断の目安がある

よくある失敗とその避け方

リリース後に指標を探す。 成功の基準を事前に決めないと、リリース後に良く見える数字だけを拾い、効果があったと結論づけてしまいます。指標と基準は企画の段階で決めておきましょう。

利用率だけで判断する。 機能が使われていても、事業に効いているとは限りません。逆に、利用率が低くても、特定のユーザーには欠かせない機能である場合もあります。三段階の指標を合わせて判断します。

利用者と非利用者の差をそのまま効果とみなす。 熱心なユーザーほど新機能を使うため、利用者の継続率が高いのは当然とも言えます。比較の方法を工夫し、偏りを意識して解釈しましょう。

振り返りをしない。 リリースした時点で次の開発に移り、結果を確認しないまま時間が過ぎることはよくあります。振り返りの日程をリリース前に決め、事業責任者も参加する場にしておくと、確実に実施されます。

機能を減らす判断をしない。 使われない機能を残し続けると、プロダクトが複雑になり、保守の負担も増えます。効果がない機能は、改善の余地がなければ縮小や廃止を検討しましょう。

よくある質問

Q. 新機能の効果測定にはどれくらいの期間が必要ですか?

段階によって異なります。利用されているかはリリース後すぐから数週間で分かりますが、継続や事業指標への影響を確かめるには数か月かかることもあります。利用の確認と改善を早めに行い、継続や事業への影響は時間をかけて確かめる、という二段構えで進めましょう。

Q. A/Bテストができない場合、効果測定は意味がないのでしょうか?

意味はあります。A/Bテストほど確からしい結果は得られなくても、リリース前後の比較や、条件をそろえた利用者と非利用者の比較、ユーザーへの聞き取りを組み合わせれば、判断の材料として十分に役立ちます。結果の確からしさの限界を理解したうえで判断することが大切です。

Q. 小さな機能改善でも効果測定は必要ですか?

すべての改善で大がかりな測定をする必要はありません。影響が大きい機能や、開発に時間をかけた機能、事業指標の改善を狙った機能を中心に、しっかりと測定しましょう。小さな改善は、利用率など最低限の指標を確認するだけでも十分なことが多いです。どの程度の測定を行うかは、企画の段階で機能の重要度に応じて決めておくと、リリース前の準備にかける手間の配分も判断しやすくなります。

Q. 効果がなかった機能をすぐに廃止してよいですか?

まずは、効果が出ない原因が「気づかれていない」「使い始めのハードルが高い」など、改善できるものでないかを確かめます。改善しても効果がなく、保守の負担が大きい場合に、利用者への影響を確認したうえで廃止を検討します。

Otsumuに相談できること

計測の仕組みがあり、プロダクトチームで振り返りの場を持てているなら、新機能の効果測定は社内で十分に進められます。この記事の手順に沿って、次にリリースする機能から、目的と仮説、見る指標、成功の基準を一枚にまとめることを始めてみてください。それだけで、リリース後の判断が大きく変わります。

一方で、イベントの計測が整っておらず機能の利用状況が分からない、効果測定の結果を事業の判断につなげる仕組みがない、使われない機能が増えてプロダクトの方向性が見えなくなっている、といった場合は、外部の視点を入れると整理が進みやすくなります。効果測定は、計測、分析、開発の優先順位づけがつながって初めて機能するからです。

OtsumuのKPI改善コンサルティングでは、プロダクトの指標設計と計測の整備から、新機能の仮説づくり、効果の検証、機能の継続判断までを一緒に進めます。計測の実装や機能の出し分けの仕組み、改修が必要な場合は、Webアプリ開発やSaaS開発として、目的に必要な範囲で開発を支援します。

作った機能が本当に効いているのか確かめたいとお考えなら、30分の無料相談で、プロダクトの現状と計測の状況を伺い、効果測定の進め方を一緒に整理します。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆:Otsumu株式会社 / 編集日 2026.10.01

あわせて読む

次の一手を、一緒に。

事業の検証から開発・運用まで、現在の段階に合わせて支援します。

事業について相談する ↗
FROM KNOWLEDGE TO ACTION

知識を、次の一手へ。

30分の無料診断で、次の一手を整理する ↗