重大なバグか、それとも少数派の声か？製品ユーザーからのフィードバックをどう活用するか
Seattle 2.0 Authorsによる
編集者注：この記事は元々Seattle 2.0に掲載されたもので、Seattle 2.0とそのアーカイブコンテンツの買収に伴いGeekWireにインポートされました。詳しい背景情報については、こちらの投稿をご覧ください。
ジェニファー・カバラ
Poornima は、Deploy 2010で「製品の発売を成功させるための 3 つの S」について講演します。
早期割引価格は金曜日で終了し、本日登録された方の中から抽選で、StartupToDo.com のメンバーシップや、Vanessa Fox の新刊「Marketing in the Age of Google」のサイン入りコピーなどの賞品が当たります。 今すぐ登録するには、わずか数分しかかかりません。
製品に問題がありますか、それとも単に少数のユーザーが不満を抱いているだけですか?
大規模なユーザーベースを持つ製品を開発できたなら、おめでとうございます！そのユーザーベースから製品に関するフィードバックをいただけるなら、さらにおめでとうございます！フィードバックが肯定的であろうと否定的であろうと、懸念事項を率直に伝えてくれるユーザーコミュニティを確立できたことになります。次は、それに対応する番です。これが最も難しい部分です。ユーザーのニーズに応えることは重要ですが、ソフトウェア製品の複雑さは、ユーザーを満足させるためにどれだけの機能を盛り込むかに比例します。製品が複雑になるほど、設計、実装、テストにかかる時間も長くなります。
ユーザーフィードバックの評価
ユーザーの問題を解決するためのソリューションを考え出す前に、答えるべき質問がいくつかあります。
1. この機能制限またはバグはどの程度広範囲に及んでいますか？
2. これは致命的なものですか？また、一時的な回避策はありますか
？ 3. 他の機能やユーザーワークフローにはどのような影響がありますか？
4. バグの修正や機能強化の実装にかかるコストはいくらですか（時間、費用、新たなバグの発生など）？
5. バグの修正や機能強化の実装による短期的および長期的なメリットは何ですか（関連するバグの解消、顧客サポート時間の節約など）？
バグのサイズを決定する
1番の質問に答えるには、実際にこの機能を使用しているユーザー数、またはこのバグを経験しているユーザーの数といった確かなデータが必要です。ユーザーはチケットを発行したり、フォーラムで意見を述べたりするのは簡単です。確かなデータを得るには、問題が報告された日数または週数にわたるログをgrepで調べ、エラーと例外の数を調べます。次に、データベースクエリをいくつか実行して、実際にこの機能を使用しているユーザーの数を把握します。これにより、アクティブユーザーベースの何パーセントが影響を受けているかがわかります。
大きな問題か、それとも簡単な回避策か?
2番の質問にお答えする際には、すべてのユーザー、特に声高に意見を述べるユーザーに影響があることを認識してください。実際のユーザーの割合を把握したら、短期的な回避策があるかどうかを検討しましょう。例えば、IE6を使用しているユーザーのみに影響があるでしょうか？その場合は、カスタマーサポート担当者とユーザーフォーラムに回避策をメッセージで送信してください。
問題はシステム全体にわたるのでしょうか? 修正すると新たな問題が発生するのでしょうか?
3番の質問への回答のポイントは、一つの機能の火が大火事になる前に消火することです。現在のバグの原因となっている特定の機能だけを考えるのではなく、システム全体、あるいは製品全体について考えましょう。
継続的インテグレーションの時代であっても、ユーザーの問題解決には隠れたコストが伴います。修正や機能強化によって新たな問題が発生する可能性はさておき、本来であれば他のタスクに費やせるはずだった時間を奪ってしまうこともあります。そのため、開発者やデザイナーといったリソースを過剰に割り当て、費やす前に、バグ修正や機能強化といったビジネス上の優先事項を理解することが重要です。
結果として、解決策によって製品の品質とユーザーベースとのビジネス関係が改善される可能性があるため、今すぐ調査して解決する価値があります。
Poornima から新製品または新バージョンの製品を発表する方法について詳しくは、Deploy 2010 にご参加ください。
たった3分しかかかりません。
