資料ダウンロード
記事をテーマ・カテゴリで探す

機能改善の効果を確かめる方法|リリース後に見る3つのこと

公開 2026-10-07更新 2026-10-07読了 約5分執筆:アーコレ運営|株式会社Covvy CEO 古沢
機能改善の効果を確かめる方法|リリース後に見る3つのこと
目次

機能をリリースしたあと、チームは何を見て「改善できた」と判断しているでしょうか。機能を公開できたことも、顧客に利用されたことも大切です。その先で、顧客の仕事がどう変わったかまで確かめると、チームには次に直すところが見えてきます。この記事では、リリース後に確認したい3つのことと、結果を次の対応につなげる方法を紹介します。

この記事の要点
  • 改善した機能が、必要としていた顧客に届いたかを確かめる
  • 改善した機能が、実際の業務で使われたかを確かめる
  • 顧客のもともとの困りごとが減ったかを確かめる
リリース後に確かめる3つのこと。届いたかは対象の顧客が知っているか、使われたかは実際の業務で使っているか、困りごとが減ったかは手間やミスが減っているかで確認します。

チームはまず「誰の、どんな困りごとを減らす改善か」をそろえる

チームは最初に、対象の顧客や担当者、利用する場面、減らしたい困りごとを書きます。「レポート機能を改善する」より、「月末の報告担当者がデータを転記する手間を減らす」と書くほうが、何を確認するか決めやすくなります。

Googleの研究チームも、大規模なWebサービスでユーザー体験を測る方法をまとめた論文で、製品の目標から測る内容を決める手順を示しています。チームは手元にある数字を並べる前に、顧客に起きてほしい変化をそろえます。

チームは、契約プランや担当する業務など、機能を利用できる条件も考えて、対象の顧客を決めます。特定の担当者が使う機能を全ユーザーの利用率で評価すると、必要としている人の変化が見えにくくなります。

チームは改善前の作業時間や手順、確認に使う記録も残します。確認日は、顧客がその業務を行う時期に合わせます。月末に使う機能なら、リリース翌日の利用数だけでは判断できません。

改善した機能が、必要としていた顧客に届いたか

チームは告知を送ったあと、対象の担当者が機能を知り、使える状態になっているかを確認します。契約の窓口と日々の利用者が違う場合は、誰まで情報が届いたかを見ます。権限や初期設定が必要な機能では、その準備も確認します。

要望を出した顧客に使い方を案内し、次に使う機会を聞くところから始めても構いません。「まだ使われていない」という結果でも、顧客が機能を知らなかったのか、準備が済んでいないのかで、次の対応は変わります。要望を出した顧客への返信の書き方は、機能要望にどう返信する?検討中・見送り・代替案の文例で扱っています。

改善した機能が、実際の業務で使われたか

次に、対象の顧客が、チームの想定した業務で機能を使ったかを見ます。画面を開いた回数だけでなく、必要な操作を行った記録や、途中で止まった箇所を確認します。割合を出すなら、対象の範囲をそろえ、人数や社数も一緒に残します。

使っていない顧客には、使う機会がなかったのか、操作で困ったのかを聞きます。具体的な出来事を尋ねる聞き方は、ユーザーインタビューで何を聞く?機能要望の背景を確かめる30分の進め方で扱っています。月1回の業務なら、毎日の利用は必要ありません。顧客が次の業務でも使うかは、その機能の役割に合わせて見ます。

操作回数が減った場合も、すぐに悪い変化とは判断できません。手作業をまとめて処理できる改善なら、少ない操作で仕事が終わることもあります。チームは回数と、顧客が終えたい仕事の両方を見ます。

顧客のもともとの困りごとが減ったか

チームはここで、最初に決めた困りごとに戻ります。手間を減らしたかったなら作業時間や手作業の残り方、間違いを減らしたかったなら、やり直しの発生を見ます。英国政府のサービス設計ガイドも、利用者に作業を試してもらう調査の方法として、作業を完了できたか、かかった時間、途中でやめたかを測り、繰り返して比べる手順を紹介しています。

顧客には「前回と比べて、作業はどう変わりましたか」「今も手で行っている部分はありますか」と聞きます。チームが数字と実際の作業を合わせて見ると、利用数だけでは分からない課題を探せます。

ただし、前後で数字が変わっても、業務量や他の変更が影響した可能性は残ります。チームは改善の効果と断定せず、比較した条件と分からない点も記録します。たとえば、処理する件数が少ない月と多い月では、作業時間の総量だけを比べても判断しにくくなります。原因を厳密に確かめるには、比較実験(A/Bテスト)のような別の設計が必要です。

チームは確認した結果から、次の対応を決める

3つを確認したら、チームは何を追加で確かめ、どこを直すかを決めます。届いていなければ案内や導線を、使われなければ利用条件や操作を、困りごとが残れば解決方法を見直します。数字だけで原因を決めつけず、顧客の話も合わせて判断します。同じ英国政府のガイドも、アクセス解析だけに頼らず、利用者の声や問い合わせ窓口の記録など複数の情報を使うよう勧めています。

結果は、元の要望と結びつけて残します。「確認できたこと」「まだ分からないこと」「次の対応」「担当者」「次に確認する日」が分かれば、チームが続きを進めやすくなります。

使う機会がまだ来ていない場合や、記録が足りない場合は「確認中」とします。成功か失敗かを急いで決めず、次に何が分かれば判断できるかを具体的にします。

よくある質問

Q

利用者が少なくても確かめられますか?

A

対象の顧客の業務と利用状況を、1件ずつ確かめるところから始められます。少人数の反応を全顧客の傾向とみなさず、誰について確認できたかを残します。

Q

リリース前の数字が残っていない場合は?

A

問い合わせや業務記録から比較できる材料を探します。顧客の記憶は手がかりになりますが、実測値とは分けます。材料がなければ改善幅は判断できないため、現在の状態を記録し、次の変更に備えます。

Q

NPSが上がれば、改善の効果があったと言えますか?

A

その数字だけでは、今回の機能が役立ったかは分かりません。対象の顧客が機能を使ったか、どの作業が変わったかを別に確かめましょう。

まとめ

まずは直近の改善を1件選び、対象の顧客、改善前の状態、確認する時期をそろえます。そのうえで、届いたか、使われたか、困りごとが減ったかを確認し、次の対応まで残しましょう。

要望の背景と、その後に分かったことを結びつけると、次の優先順位を考える材料になります。

確認した結果を次の計画に反映する方法は、プロダクトロードマップの作り方で扱っています。

要望管理を仕組みにするなら、アーコレ!

収集・AI分類・優先順位付けを、ひとつのツールで。