フィードバックループとは、意思決定とその後起きる結果を結びつけるものです。チームが体験に手を加え、その結果に関する根拠を集め、それを活かして次の一手を決めます。コメントを集めるのはループのほんの一部にすぎません。その情報を実際のアクションへと繋げるルートが必要です。
プロダクト開発の例としては、リーン・スタートアップの「構築・計測・学習」アプローチが挙げられます。また、情報を解釈して対応する担当者がいれば、カスタマーサポートや日々の運用業務、継続的なリサーチもループに貢献できます。
期待する変化を明確にする
たとえば、配送時の破損を報告する手順をシンプルにするチームを考えてみましょう。リリース前に、「改善」とは何を意味するのかを定義しておく必要があります。必要な情報をスムーズに送信でき、受付確認が届き、いつ対応してもらえるかが分かる、といったことです。
報告件数が増えたというだけでは、良し悪しは判断できません。手続きが分かりやすくなったのかもしれませんし、破損そのものが増えた可能性や、混乱による重複報告の可能性もあります。これらをしっかり見分けられる指標やリサーチ方法を選び、比較対象となる適切なベースラインを残しておきましょう。
フィードバックにはコンテキスト(文脈)が不可欠です。利用したバージョンや利用状況、そしてそのコメントが計測対象と同じ体験部分に向けられているかを記録しておきます。これがないと、集まった声を加えた変更に結びつけるのが難しくなってしまいます。
対応の責任者とルートを決める
誰が内容を確認し、緊急の課題にどう対処し、得られたインサイトをどう優先順位に反映させるかを決めておきましょう。すべての提案をそのまま機能化する必要はありません。根本にあるニーズや、他のデータとの関連性を探ることが大切です。
ユーザーや顧客が返信を期待している場合は、現実的に可能な対応を伝えます。報告を受け付けたことの連絡、調査状況の説明、解決の報告は、それぞれ異なる対応です。運用上対応できないのであれば、個別のアップデートを約束するのは避けましょう。
変更を加えた後は、適切な反復的なリサーチや運用の指標を通じて結果を検証します。ある問題を解消する修正が、別の困難を生み出してしまうこともあります。特に、別のチームや別のユーザー層にしわ寄せがいく場合は注意が必要です。
だからこそ、実用的なループには「記憶」が欠かせません。観察、判断、アクション、そしてその後の結果を端的に記録し、ナレッジマネジメントを通じて繋げておきます。そうすれば、新しいコメントが入るたびに初めて直面したかのように振り回されることなく、過去の試行錯誤から学びを活かすことができます。
