この記事は、dev.toに公開されているMike Bifulco氏とCharlie Gerard氏によって書かれた英語記事を日本語訳し、加筆修正を加えた記事です。
製品開発の際、ユーザーが体験する課題を追跡し改善するための実践的な手法として、「フリクションログ」があります。関係者全員がよりよい製品を手にできるよう、その目的は以下の通りです。
- エンドユーザーと開発者には、価値の高い製品が提供される
- 製品を開発するチームは、満足度の高いユーザー層を獲得できる
- 営業スタッフは、より価値を示しやすくなる
Stripeでは、私たちDevRelチームがフリクションログを活用し、製品に関するフィードバックをプロダクトチームと共有しています。Stripeの製品を使ってサービスを構築する開発者の声になることが、私たちの使命の一部なのです。つまり、製品を実際に使う開発者と、その製品を作るエンジニアリングチームの間を行き来し、橋渡しをする役割です。
また、Stripeでは全従業員がフィードバックに積極的に関わることを奨励しています。新入社員研修の際に、製品へのフィードバック方法や、フリクションログの作成プロセスを学びます。
フリクションログの構成
コンテキスト
最初に、機能のレビューを行う人物(ペルソナ)と、その人がどのような目的で製品を使おうとしているかをコンテキストとして説明します。ペルソナとは、製品を利用する際の立場や経験を簡潔に表した架空の人物像のことです。例えば新しいAPIエンドポイントについてのレビューで、初めてその機能を使う場合は、その旨をペルソナに含めます。以下の質問に答えることで、適切なコンテキストを書けます。
- その機能の経験度は?
- どんなことを実現しようとしていたのか?
- フリクションログは、その機能のどの部分に関するものか?
以下は、新しいプリンターのセットアップに関するフリクションログのコンテキストセクションの例です。ペルソナと利用目的が簡潔に記載されています。
長所と短所
次に、経験した長所と短所をまとめます。機能や体験の中で気に入った点、有用だった点は長所として、一方で改善の余地があると思った点や期待はずれだった点は短所として箇条書きで明確に記載します。
3. 詳細な経過
最後に、製品や機能を実際に使用した際の詳細な経過を記述します。この部分には特に構造は定められていません。機能を使用しようとした際の体験を、自由に書き留めてください。チームにとって有益な情報は何でも構いません。スクリーンショット、操作の様子を示すGIF、リンクなども活用できます。
フリクションログを書く人によって、ツールの使い慣れ具合、スキルレベル、構築しようとしているアプリケーションは異なります。些細なフィードバックでも、製品改善の助けとなるはずです。
参考までに、このセクションはこのように書かれています。
優れたフリクションログを書くためのフレームワーク
フリクションログを書く際は、単に体験を記録するだけでなく、建設的で具体的なフィードバックを心がける必要があります。そのためには、いくつかの原則やベストプラクティスに従うことが重要です。以下のフレームワークは、優れたフリクションログを作成するためのガイドラインとなります。
1: 最初に想定のサイズ(S/M/L)を共有する
フリクションログの分量や深堀りの程度を事前に決めておくことで、適切な内容を書くことができます。サイズは小、中、大の3つに分類され、以下のような指標を目安にすることができます。
| フリクションログのサイズ | 概要 | 例 |
|---|---|---|
| Sサイズ | フリクションログのサイズが小さく、負担なく合理的な時間で完了できます。 | 特定の機能やUIについての簡単なフィードバック |
| Mサイズ | フリクションログのサイズが中程度。読むのに時間がかかるかもしれませんが、過度に長くはありません。 | 新機能の導入フローの詳細なレビュー |
| Lサイズ | フリクションログのサイズが大きく、把握するのに時間がかかります。通常は、ある機能に関する些細な混乱ではなく、より包括的なユーザージャーニー全体をキャプチャしています。 | 製品の主要なユーザーフローの包括的なレビュー |
サイズを事前に共有することで、書く側は適切な分量と深さを意識でき、読む側も見積もりがたてやすくなります。
- Sサイズのログは、特定の機能やUIに関する簡単なフィードバックを行う際に適しています。短時間で書くことができます
- Mサイズのログは、新機能の導入フローなどの詳細なレビューを行う際に適しています。ある程度の分量がありますが、過度に長くなりすぎない範囲で収まります
- Lサイズズのログは、製品の主要なユーザーフローの包括的なレビューを行う際に適しています。ユーザージャーニー全体をカバーするため、かなりの分量となり、読み込むのに時間がかかります。
2: ジャーニーを明確に
フリクションログでは、ユーザーがどのようなジャーニーを辿り、どのようなステップを踏んだのかを明確にする必要があります。またペルソナ(「Webでの決済は初めて」「自社製品の3回目のメジャーリリースだが、今回はカナダでの決済にも対応する必要がある」など)に関するコンテキストも重要です。さらに、読み手が理解しやすいよう、分かりやすい言葉で簡潔に記述する必要があります。可能な限り、プロダクトチームやステークホルダーが自力で調査する必要のない言葉を心がけましょう。
3: 良かった点と課題の両方を強調する
製品の改善機会を共有することは大切ですが、うまくいっている点も同様に伝えることが重要です。これにより、エンジニアリングチームとの信頼関係が築けるだけでなく、製品をできる限りよいものにするという共通の目標を確認することができます。
4: 具体性を心がける
ジャーニーや実際の経験を伝えるのに役立つ場合は、スクリーンショット、動画、その他の視覚資料を提供しましょう。長文のフリクションログには、開発者のスクリーンキャスト動画へのリンクを含めるのも有効です。
5: 客観性を保つ
フィードバックを記述する際は、感情的な言葉遣いは避け、客観的な問題の記述に徹する必要があります。「ステップ6と7の間で混乱し、何を見落としたのか確認するためにドキュメントページへ戻った」と書く方が、「この作業に2時間も無駄にした、ひどい!」よりも建設的です。
6: フィードバックを広く共有する
Stripeでは、フリクションログが完成すると、社内の全従業員が閲覧できるメーリングリストに共有されます。さらに対象のフィーチャーやプロダクトを担当するチームにも直接共有されます。誰もがフィードバックを見ることができるので、影響を受ける幅広い層の人々との建設的な議論につながる可能性が高まります。
フィードバックに積極的に反論する人もいるかもしれません。しかし、それは問題ありません。むしろ良いことです。様々な経験と背景を持つ人にフリクションログを晒すことで、提案される製品への変更はより大きなユーザーベースを考慮することができるのです。
7: フォローアップを欠かさない
フリクションログに関連する改善策を立案する可能性のある人々に、直接フォローアップすることも大切な実践です。オープンな対話を継続することが重要なのです。これにより、フィードバックが誠実に与えられ受け取られ、結果として意味のあるソリューション(すぐには実装されないかもしれませんが)につながります。
ここが肝心です。 優れたフリクションログを作成するための全ての努力は、会社の構築する製品に実際に影響を与えなければ無駄になってしまいます。まずはフリクションログから新機能のリクエストやバグ報告が生まれることを確認することから始めましょう。その後はそれらがチームのバックログで熟慮され、適切に優先付けされるよう努めましょう。
最後に、製品へのアップデートがリリースされた際には、その変更点を全世界に伝えましょう。ドキュメントやリリースノートの更新、影響を受けるユーザーへの直接的なフォローアップなどが考えられます。これは、チームがユーザーのために真摯に改善を重ねていることを示す良い機会です。常にフィードバックを待っていること、ユーザーのためにものを構築していることを伝えましょう。こうすることで、愛着と忠誠心が育ち、優れたプロダクトチームの目指す有益な循環が生まれるのです。
フィードバックを行う上での注意点
フリクションログは本質的に詳細なフィードバックです。役立つものとなり、良い形で受け取られるよう、以下の点に気をつける必要があります。
情動的知能（EQ）の重要性
情動的知能とは、自己認識、社会的認識、共感力、人間関係のマネジメント能力のことを指します。この能力が高いほど、自身や他者の感情を正しく理解し、適切に対処することができます。
フリクションログの作成は個人的な体験に焦点を当てますが、対象となるフィーチャーや製品には、多くの時間と労力が注がれていることを忘れてはいけません。他者の立場に立ち、思慮に欠ける言葉遣いは避けましょう。例えば「これまで使った中で最悪のAPIだ」といった一般論は建設的なフィードバックになりにくいです。代わりに「このAPIの利用で私が苦労したのは、X、Y、Zの理由からです」と、個人的な経験に基づいたフィードバックへ変えましょう。そうすることでチームが改善に向けた行動を起こしやすくなります。また、フィードバックの対象に対して「あなた」を使うのも避けた方が良いでしょう。「あなたが実装したこのエンドポイントはわかりにくい」ではなく、「このエンドポイントが私にはわかりにくかった」と書きます。これにより、実装者個人ではなく、その機能自体にフォーカスを当てられます。
信頼関係が大前提
どのようなフィードバックを行う際も、信頼関係は極めて重要です。一般的に同僚は自分の成功を望んでおり、ユーザーにとってよりよい体験を提供することが共通の目標となっています。ですので、フィードバックを善意から送られたものとして真摯に受け止める必要があります。ただし、会社の協力文化が十分でない場合や、最近入社したばかりの場合は、この信頼感を持つのが難しいかもしれません。そういった場合は、フリクションログを取り入れる前に、まずはチームメンバーと親しくなることが重要です。必要に応じて、フリクションログについて詳しく話し合う機会を設け、あなたがどのような心理状態でそのログを書いているのかを理解してもらいましょう。
フィードバックを出すのは難しく、受け取るのはさらに難しい
この記事の前半で、情動的知能を発揮し他者の立場に立つ必要があると説明しました。しかしフィードバックがポジティブでない場合、この行為は難しいプロセスになるかもしれません。 しかし覚えておいてほしいのは、フィードバックを受け取る側がさらに難しいということです。受け手側にいる際は、内容から距離を置き、これを改善の機会ととらえる必要があります。最初はこの作業に馴染めないかもしれませんが、経験を重ねれば徐々に慣れていくはずです。実践を積むことで、自身のレベルアップだけでなく、全てのユーザーにとっての恩恵にも気づけるようになるでしょう。
まとめ
まだプロダクト開発プロセスの一部としてフリクションログを活用していない場合はぜひ導入を検討してみてください。フリクションログを導入するメリットには、次のようなものがあります。
- 製品のボトルネックや弱点を特定でき、改善の機会を見つけられる
- ユーザーの声に耳を傾け、フィードバックに基づいて積極的に製品を変更することで、ユーザーの信頼と忠誠心を高められる
- フリクションログを活用することで、信頼とフィードバックの文化を育み、同僚間のコミュニケーションにおける情動的知能を促進できる
- 長期的に見れば、フリクションログを使った継続的な製品改善により、時間とコストを節約できる
フリクションログ作成のためのテンプレートをGitHubで公開しているので、ぜひfriction-logging-toolkitをご利用ください。また、frictionlog.comには、フリクションログに関する優れた記事、例、リソースが豊富に掲載されています。