Facebookの機能要望から製品の優先順位を決める方法

Facebookの機能要望が製品開発チームの判断を誤らせる理由

Facebookの公開コメントからは、ユーザーの反応をすばやく得られます。ただし、それをそのままソフトウェアの開発ロードマップに反映すると、次のようなリスクが生じます。

• コメント数とアカウント数の違い：1人がまったく同じ変更を求めて、複数の投稿に何度もコメントすることがあります。スプレッドシートの行数をそのまま数えると、要望の規模が実際より大きく見えてしまいます。
• 本人確認ができていない：ソーシャルメディアの公開プロフィールが、自社のソフトウェアのデータベースに自動的に結び付くわけではありません。公開コメントだけでは、書き手が現在の顧客なのか、以前のユーザーなのか、それとも製品を一度も使ったことのない人なのかは分かりません。
• 課題ではなく解決策が示される：ユーザーは通常、要望を出すきっかけとなった実際の業務上の障害を説明するよりも、特定のツールやボタンを求めます。
• 背景が不明確：ソーシャルメディアには、公開の場で投稿することを好む人や、その時点で不満を感じている人が集まります。公開された文章からは、同じソフトウェア機能について、声を上げずに困っているユーザーや、問題なく使っているユーザーがほかに何人いるのかは分かりません。

製品について適切に判断するには、ソーシャルメディアのフィードバックを、最終的な多数決ではなく、最初の手がかりとして扱います。何を開発するかを決める前に、公開コメントを収集し、トピックごとに整理してください。自社の投稿、動画、共有リンクから公開コメントのスレッドを収集する必要がある場合は、ApifyのFacebook Comments Scraperを実行してください。生データのエクスポート、日付の欠損への対応、ユーザーの感情とトピックの分類コードを分ける方法については、関連記事のFacebookコメントを顧客フィードバックとして分析する方法で詳しく解説しています。

提案された機能からユーザーの根本的な課題を明らかにする

ユーザーが「エクスポートボタンを追加してください」や「ダークモードが必要です」と書くとき、示しているのは手っ取り早い解決策です。こうした解決策の要望をそのままデザインやソフトウェア開発のチームに渡すと、根本的な課題を解決せず、ソフトウェアを複雑にするだけの、まとまりのないツールを作ってしまうおそれがあります。

課題を検討する手順

提案された機能からユーザーのニーズを明確な文章にするには、タグ付けしたフィードバックの各グループについて、次の3つの手順を行います。

1. 求められているツールを特定する：コメントで言及されているボタン、設定、機能を正確に記録します。
2. 障害について仮説を立てる：ユーザーが投稿しようと決める前に、日常業務のどの手順がうまくいかなかったのか、または問題を起こしたのかについて、得られた情報を基に推測します。この推測は確定した事実ではなく、インタビューで検証する仮説として扱います。
3. 望む成果を明文化する：ユーザーが何を達成したいのか、その目標が業務にとってなぜ重要なのかを、平易な文章で書きます。

背景にあるユーザーの目標に注目すると、異なる複数の機能提案が、同じ日常的な課題を示していると分かることがよくあります。逆に、まったく同じボタンを求める10人が、それぞれまったく異なる作業を終えようとしている場合もあります。

正確な記録の維持とプライバシーの保護

コメントから根本的な課題を整理する際は、元の記録を変更せず、出典データを明確にたどれるようにします。ソーシャルメディアのコメントを調査用ファイルに保存する際は、次の点を守ってください。

• ソーシャルメディアのプラットフォームが発行した元のコメントID文字列を保持します。
• 会話の背景を確認できるように、投稿の完全なリンクを保持します。
• 不要な個人情報を収集せず、元の本文を安全な非公開ファイルに保存します。

議論が続いているスレッドから最新のコメントを取得するには、対応している公開コンテンツのリンクを使って、Facebook Comments Scraperを実行してください。公開データのスクレイピングツールが返すのは、取得可能な公開記録のうち、実行時に指定した上限までのデータです。コメントや返信の行がないからといって、会話が終わったことや、誰も返信しなかったことの証明にはなりません。

アカウント数の集計と顧客であることの確認

ソーシャルメディアのフィードバックを検討する際に最もよくある誤りは、コメントの各行を別々のユーザーからの要望として扱うことです。熱心な1人のユーザーが、1つの機能案について3つのスレッドに計5件のコメントを投稿する一方で、あまり発言しない5人のユーザーが、それぞれ異なる投稿に短いコメントを1件ずつ残すこともあります。

ソーシャルメディアのデータをアカウントごとにまとめる方法

ソーシャルメディア上で要望がどの程度広がっているかを測るには、比較する前に、投稿者のプロフィールごとにコメントをまとめます。

エクスポートしたコメントの行を確認する際は、公開されている投稿者IDとプロフィールリンクのフィールドを調べます。公開プラットフォームでは、技術的な理由でこれらのフィールドが空欄になったり、値が設定されなかったりすることがあります。コメントの記録を、次の2つの主要なグループに分けてください。

1. 識別可能なアカウント：明確な公開投稿者IDまたはプロフィールリンクを含む行。
2. 投稿者不明のコメント：投稿者のプロフィールに関するフィールドが空欄の行。

単純な割り算で、重複を除いたアカウント数の比率を計算します。

重複を除いたアカウント数の比率 = 識別可能なアカウント数（重複を除く） / 分類済みコメント総数

たとえば、あるトピックのグループにコメントが合計12行あり、投稿者IDが重複を除くと4つで、投稿者情報が空欄の行が0行なら、そのデータセットが表しているのは4つの異なるアカウントです。別々の12件の要望ではありません。

あるカテゴリに識別可能なアカウントが3つあり、投稿者不明のコメントが1行ある場合、重複を除いた人数が4人であるとは保証できません。その空欄の行は、既知の3つのアカウントのいずれかに属するかもしれませんし、新たな4人目のコメントかもしれません。確認済みのアカウント3つと、投稿者不明のコメント1件として記録します。

ソーシャルメディアのアカウントと社内記録を結び付ける

ソーシャルメディアの公開ユーザーが現在の顧客であると決め付けてはいけません。本人の明示的な同意に基づく確認を行わずに、ソーシャルメディアの公開アカウントを社内のアカウントデータベースや製品分析データに結び付けることはできません。たとえば、ユーザーが調査参加への同意フォームに記入したり、サポート対応中にアカウントのメールアドレスを確認したりする方法があります。アカウントの所有者が、この同意に基づく確認手順を完了していない限り、ソーシャルメディアのフィードバックはすべて、ユーザーの身元が未確認の情報として扱います。

社内データでソーシャルメディアのフィードバックを裏付ける

ソーシャルメディアの公開コメントは最初の手がかりになりますが、ソフトウェアについて判断するには、チームが管理する社内の一次データによる裏付けが必要です。深刻な不具合を詳しく説明したコメントであれば、たった1件でも直ちに検討する理由になります。ただし、より広範な機能変更には、明確な社内の証拠が必要です。

社内データで行う3つの重要な確認

1. サポートチケットの記録：顧客向けヘルプデスクのデータベースで、関連する問題を検索します。顧客であることが確認できているユーザーが、この具体的な業務手順についてサポートチケットを送信したり、支援を求めたりしていますか？
2. 製品分析ログ：分析ツールでアプリケーションの利用ログを確認します。全体の利用数を調べ、ユーザーがどこで離脱したり、エラーメッセージに遭遇したりしているかを確認します。
3. 参加に同意した顧客へのインタビュー：調査への参加に同意し、顧客であることを確認できている人と直接話します。特定の新しいボタンが欲しいかを尋ねるのではなく、日々の業務について自由に答えられる質問をします。

適合性、工数、回避策を評価する

ソーシャルメディアのフィードバックと社内データを併せて検討する際は、画一的な採点式に頼らず、次の5つの実務的な要素を評価します。

• 課題の深刻さ：この問題は重要な業務の完了を妨げていますか？ それとも軽微な不便でしょうか？
• 製品との適合性：この問題の解決は製品戦略に沿っていますか？ それとも、チームを無関係な市場へ向かわせることになりますか？
• 既存の回避策：ユーザーは現時点で、標準設定や既存のソフトウェアツールを使ってこの問題を解決できますか？
• 見積もり工数と技術的リスク：修正には、どれほどの開発時間、継続的な保守、システムの複雑さが必要になりますか？
• 証拠の確かさ：未確認の公開コメントと比べて、確認済みの顧客から得た証拠はどれほど強いものですか？

具体例：3つの機能要望を順に評価する

サービスチーム向けのスケジュール管理ツールを開発する、架空の業務ソフトウェア企業TaskFlow Proを例に考えます。この具体例に登場する名称、数値、チケット件数、技術的な見積もりはすべて、評価方法を示すための架空の調査結果です。

定期的な確認作業で、製品マネージャーはFacebook Comments Scraperを使ってTaskFlow ProのFacebookページから公開コメントを抽出し、タグ付けしました。チームは、公開スレッド全体から、次の3つの異なる要望カテゴリを特定しました。

1. UIのカスタムカラーテーマ
2. Google カレンダーとの双方向同期
3. モバイル向けの完全なオフラインモード

手順1：重複を除いたアカウント数を数える

製品マネージャーはタグ付けしたコメントファイルを開き、トピックごとのアカウント総数を計算します。

• UIのカスタムカラーテーマ：コメントは合計12件ですが、投稿者IDを見ると、重複を除いたアカウント数は4つしかありません。1人のユーザーが3つの投稿に計6件のコメントを残し、別の1人が4件のコメントを残していました。
• Google カレンダーとの双方向同期：6つの異なるアカウントから、合計8件のコメントがありました。
• モバイル向けの完全なオフラインモード：コメントは合計5件で、3つの異なるアカウントからのコメントと、投稿者不明のコメント1行でした。

コメントの総数だけで評価すると、「UIのカスタムカラーテーマ」（12件）は、「Google カレンダーとの同期」（8件）の1.5倍、「モバイルのオフラインモード」（5件）の2倍以上の規模に見えました。

重複を除いたアカウント数を数えると、状況は違って見えます。

• UIのカスタムカラーテーマ：4つの異なるアカウントから12件のコメント。
• Google カレンダーとの同期：6つの異なるアカウントから8件のコメント。
• モバイルのオフラインモード：確認済みのアカウント3つからのコメントに、投稿者不明のコメント1件を加えて、計5件。

手順2：社内データとインタビュー結果を確認する

次に、製品マネージャーは社内のサポートファイル、集計済みのアプリケーションログ、調査参加に同意した顧客の記録を確認します。

#### カテゴリA：UIのカスタムカラーテーマ

• 目指す成果：見た目の個人的な好みに合わせてダッシュボードの色を変えること。当初の検討では、チームはユーザーが予定の枠を読み取りにくいのではないかと推測していました。その後の顧客インタビューで、ユーザーは単に見た目を自分好みに選べるようにしたいと考えていたことが分かりました。
• サポートチケット：過去90日間に、アクセントカラーを選べるようにしてほしいという顧客からのチケットが2件ありました。
• 製品ログ：集計済みのアプリケーションログでは、主要なダッシュボード画面での日々の利用は安定しており、異常なユーザー離脱は見られません。
• 回避策：ブラウザーの標準設定とコンピューターの画面表示オプションが問題なく機能します。
• 工数と適合性：開発作業は2日ですが、作業員の派遣速度を改善するという四半期目標との適合性は低いと評価されました。

#### カテゴリB：Google カレンダーとの双方向同期

• 目指す成果：現場スタッフがTaskFlow Pro以外で私用の予定を記録した際に、二重予約を防ぐこと。
• サポートチケット：過去90日間に、TaskFlow Proと外部カレンダーの間で生じたスケジュールの不整合を報告するサポートチケットが47件ありました。いくつかのアカウントから複数回の追加報告があったため、この47件は、アカウントを持つ31の異なる組織から寄せられたものでした。
• 製品ログ：連携設定ページへのユーザーアクセスの集計値が多く、多数のユーザーが外部カレンダーのプレビューボタンをクリックしています。
• 回避策：ユーザーはシステム間で時刻を手作業で転記しており、再入力のミスが頻発しています。
• 工数と適合性：開発作業は2週間で、スケジュールの正確さという中核的な目標によく合致しています。

#### カテゴリC：モバイル向けの完全なオフラインモード

• 目指す成果：地下室や遠隔地の農村部で、入力したデータを失わずに現場サービスのフォームを完成させること。
• サポートチケット：携帯電話の圏外でモバイルフォームを送信した際に作業の詳細情報が失われたという、緊急のサポートチケットが、12人のアカウントマネージャーから19件寄せられました。
• 製品ログ：システムログには、農村部のサービス提供地域でネットワーク接続が切れたことによる、モバイルフォーム送信の失敗率14%が記録されています。
• 回避策：作業員は紙にメモを取り、電波が届く場所に戻ってからアプリケーションに入力しているため、事務処理に遅れが生じています。
• 参加同意に基づくインタビューでの確認：ソーシャルメディアのコメント投稿者のうち2人が、調査参加への同意フォームを通じて、現在利用中の顧客アカウントを確認し、追加のインタビューに参加しました。その結果、日常の業務手順に深刻な遅れがあることが確認されました。
• 工数と適合性：ローカルのオフラインストレージとデータ復旧エンジンの構築には、8〜12週間の複雑な開発作業が必要です。モバイル利用の信頼性を高めるという長期目標を達成するうえで、極めて重要な取り組みです。

手順3：判断をまとめた表

チームは、これらの調査結果を実務用の比較表にまとめます。

手順4：バックログでの具体的な対応

製品マネージャーは、これらの結論を明確な次の行動に落とし込みます。

1. Google カレンダーとの同期：次の開発サイクルで開発するように予定を組みます。チケットを寄せた31のアカウント保有組織と、調査参加に同意した協力者の中から、テストに同意した確認済みの顧客アカウント15件を選び、小規模なテストグループとして初期プロトタイプを試してもらいます。
2. モバイルのオフラインモード：焦点を絞った調査段階を開始します。完全なオフラインシステムを開発する前に、問題が発生している顧客アカウントの現場スタッフにインタビューを行い、ローカルへの下書き保存など、より単純な部分的解決策を検証します。
3. UIのカスタムカラーテーマ：社内の調査項目を終了し、今後のデザイン検討に備えて提案を保管します。

繰り返し実施できる検討手順を作る

ソーシャルメディアのコメントスレッドによってチームの活動が本来の目的からそれるのを防ぎ、寄せられる公開フィードバックを一貫して評価するために、次の4つの手順を繰り返します。

1. 定期収集：主要なブランド投稿やリリース告知に対して、公開データ収集ツールを定期的に実行します。エクスポートした元の記録は、非公開の調査用フォルダーに保存します。
2. グループ化とアカウント数の集計：公開コメントを、その背景にあるユーザーの根本的な課題ごとにまとめます。識別可能なアカウントを重複を除いて数え、発言の多い1人のユーザーによって判断が偏るのを防ぎます。
3. 社内での確認：公開コメントのトピックを、サポートチケット数、製品ログのイベント、顧客インタビューのフィードバックと照合します。深刻なデータ消失や業務手順が機能しない問題についての詳細な報告なら、たった1件でも直ちに検討する理由になることを忘れないでください。
4. バックログでの振り分け：評価した各課題を、3つの明確な対応のいずれかに振り分けます。証拠の確かさが高い項目はプロトタイプを作り、深刻だが複雑な項目はユーザー調査を始め、適合性の低い提案は保管します。