個人開発のマーケティング入門⑨：使ってくれた人の声を、次の改善と紹介につなげる

※本記事にはアフィリエイトリンク（広告）が含まれます。Amazonのアソシエイトとして、ゲームのタネは適格販売により収入を得ています。

作品を使った人から、感想や不具合の連絡、機能の要望が届くことがあります。返事をして終わったものの、次に何を変えればよいか決められない。そんなときは、声を受け取った後の流れを整理してみます。

最終回では、利用した場面を確かめ、改善することを選び、変わったことを伝える方法を考えます。すべての要望を実装する必要はありません。作品の目的と自分が対応できる範囲を踏まえ、次の判断につなげます。

第8回では、数字から分かることと分からないことを分けました。今回は、短編探索ゲームと、画像の幅をまとめてそろえるツールを架空の例として、利用者の話でその続きを確かめます。

感想の前後に、何をしようとしていたかを聞く

第3回では届けたい相手と価値を探しました。今回は、使った後の声から、対応することを選びます。「使いにくい」「もっと機能がほしい」という言葉だけでは、どこで困ったかは分かりません。直近の利用場面に戻り、何をしたかったか、どの操作で止まったかを確かめます。

質問は説明用の案です。一度にすべて聞かず、相手が話せる範囲で確かめます。良かった点も、「便利でしたか」と答えを促すより、「どの作業に使いましたか」「前の方法と違ったところはありましたか」と具体的な経験を聞きます。

入口は、既存の問い合わせ先や短いフォームなど、自分が確認できる場所から選べます。感想を集めるためだけに、大きなコミュニティを新設する必要はありません。不具合の確認では、版、端末、操作の順番、表示された内容など、原因を調べるために必要な情報を絞って聞きます。

Hadesは、声をきっかけにした変更を更新履歴で示した

Supergiant Gamesの初代Hadesは、2018年に早期アクセスで公開され、2020年9月に正式版へ移行しました。開発元のFAQでは、制作途中から遊べる形にし、作品の設計方針を保ちながら、コミュニティの反応を受けて発展させる構想だったと説明しています。Hadesの開発元FAQ

2019年12月の公式更新履歴には、コミュニティの声をきっかけにした変更を「📢」で示す説明があります。セーブスロットを選ぶときのマウス操作の改善や、一部の言語での表示改善などにも、この印が付いています。Hadesの早期アクセス中の更新履歴

参考にしたいのは、寄せられた声と、実際に変わったことの関係を伝える方法です。要望をすべて採用したという意味ではなく、こうした運用だけが売上や評価を生んだとも判断できません。制作途中の作品を継続して更新する体制と、完成した短編作品を一人で支える場合では、できることも違います。

自分のゲームなら、確認できた修正を更新履歴へ残し、どの問題に対応したかを知らせる案が考えられます。具体的な利用者の名前を出さなくても、改善した内容は伝えられます。

本人の言葉と、こちらの解釈を分けて残す

受け取った声は、要望の文言をそのまま作業名にする前に、場面と問題を整理します。例えば「自動保存を付けてほしい」という要望の背景には、保存操作が分からない場合も、途中で内容が消えた場合も考えられます。必要な対応は同じとは限りません。

本人の言葉、実際に確認した動作、こちらが考えた原因を別々に残します。同じ話題の声をまとめるときも、違う端末や版で起きた問題を、同じ不具合と決めつけないようにします。

反応をくれる人が、利用者全体を代表するとも限りません。よく使う人の要望だけでなく、初めて使った人や途中でやめた人の場面も、話を聞ける範囲で確かめます。声が来ないことだけで、問題がないとは判断しません。

Notionは、分類した声を開発計画へ結び付けた

情報をまとめて共有するツールNotionは、2021年の公式記事で、サポートチームが利用者の声を保存・分類し、開発計画と関連付ける社内の仕組みを紹介しています。機能の要望も記録し、どの計画に関係する声かをたどれるようにする例です。Notionによる利用者の声の整理方法

これは同社が当時紹介した運用で、現在も同じ構成とは限りません。また、要望の記録が、そのまま実装の約束になるわけでもありません。個人開発で参考にするなら、専用の大きな仕組みを再現するより、受け取った声と自分の判断を後から照合できる形にします。

普段使う表に、受け取った日、利用場面、確認できたこと、対応の状態、判断の理由を残す方法があります。「確認中」「説明を直す」「機能を直す」「今回は見送る」など、自分が追える区分で構いません。共有する場合は範囲を決め、問い合わせの本文や個人情報をそのまま公開しないようにします。

件数だけで決めず、影響と作品の目的から選ぶ

声を整理できたら、何から対応するかを考えます。次の観点で比べてみましょう。

1. 利用への影響はどれくらいか。起動できない、作業結果が失われるなど、目的を果たせない問題か。
2. 最初に届けたい相手と、作品の目的に関係するか。どんな利用場面を良くしたいのか。
3. 何を変えればよいか確認できているか。調査や修正、動作確認にどれだけ時間が必要か。

報告が一件でも影響の大きい問題はあります。反対に、似た要望が多くても、今の作品の方針とは合わない場合があります。件数は手掛かりとして残し、重大さ、影響する環境、対応の見通しと一緒に判断します。

例えば短編探索ゲームなら、物語の構成を大きく変える前に、進行できない問題がないかを確かめます。画像ツールなら、形式を増やす要望と、対応済みの形式で保存に失敗する報告を分けて調べます。必要な調査が残るなら、修正する予定とは区別して記録します。

Steamの公式コミュニティ運用ガイドも、すべての会話へ返事をすることに力を使い切らず、話を聞き、共通する問題を製品の改善へつなげる考え方を示しています。Steamworksのコミュニティ運用ガイド

意見が違うからと議論に勝とうとしたり、都合の悪い感想を隠したりするより、確認できた事実と対応を整理します。批判と、嫌がらせや個人情報の投稿などへの対処は分け、その場所のルールに沿って扱います。

対応状況と、確認できた変更を伝える

返事をする場合は、受け取ったことと、対応が決まったことを分けます。「確認します」と「次の更新で直します」では、伝える約束が違います。

再現できていなければ、今分かっていることと、追加で必要な情報を伝えます。実装を決めていなければ、検討の材料として記録したことを伝えます。見送る場合も、作品の方針や今の対応範囲など、説明できる理由を簡潔に添えます。期限が決まっていないことへ、公開日を約束する必要はありません。

修正したら、対象の版と環境で動作を確認し、変わった内容と必要な操作を知らせます。確認した範囲も残します。連絡を受け取った相手へ確認をお願いできる場合でも、返答を強いたり、修正したからと良い評価への変更を求めたりしないようにします。

回答する時間は、第7回の予定に含められます。同じ質問が続くなら、個別の返事に加えて、紹介ページや使い方の説明を直す候補です。対応できる窓口を増やしすぎず、確認する場所と時間を決めておきます。

改善した内容と、役立った場面を次の紹介に使う

声を受けて変えたことは、次に伝える題材にもなります。第7回の相手に合わせた紹介を使い、既存の利用者への変更案内と、初めて見る人への紹介を分けます。

例えば画像ツールの保存に関する説明を直したなら、利用者向けには「保存方法の説明を更新しました」と知らせる案があります。初めて見る人には、画像を選び、幅をそろえて保存するまでの実際の流れを見せる案が考えられます。確認していない利用増や、誰にでも使いやすくなったという効果は付け加えません。

良かったという声も、どんな場面で役立ったかが分かれば、紹介文を見直す手掛かりになります。「まとめて幅を指定できた」という経験と、「誰でも作業時間を半減できる」という宣伝は別です。実際の発言から、一般的な効果へ広げすぎないようにします。

利用者の言葉や画像を掲載するなら、掲載先、文面、名前の表示、画像の範囲について本人に確認します。問い合わせへの返事と、広告や紹介への掲載許可は別に扱います。許可が取れない場合も、個人を特定しない形で課題を整理し、自分が確認した機能や操作を説明できます。

次の一件を、改善と紹介の記録につなげる

最後に、自分の作品で扱う一件を選び、次の欄を埋めてみてください。

改修をしたら、第8回の方法で、変えた箇所と反応を分けて確かめます。新しい利用場面が見つかったら、第3回の相手の想定や、第4回の紹介文へ戻れます。告知の予定は第7回で調整し、使う人の声を次の判断へつなげます。

この連載は今回で最終回です。まず一件の声から、次に何を確かめ、何を伝えるかを選んでみてください。公開後に学んだことは、今の作品だけでなく、次の作品を誰へ届けるか考える材料にも残せます。

第8回：見られた数から、使われた数へ。反応をどう確かめるか

連載目次：個人開発のマーケティング入門

顧客の理解と改善を、入門書でも学ぶ

使う人の話を聞き、作品や伝え方を見直す前提を学びたい場合は、マーケティングの入門書を探す方法もあります。目次や試し読みで、顧客の理解、価値の伝え方、施策の振り返りを扱っているか確認してみてください。

Amazonでマーケティング入門書を探す（広告）

リンク先は書籍の検索結果です。目次や試し読み、刊行年、価格を確認し、目的に合う本を選んでください。