こんにちは、プロダクトマネージャー（PM）のいかりです。
今回の記事では、プロダクトに対しての社内からの不具合報告のフローを改善した話について紹介します。
「社内からプロダクト改善のために色々な声をもらっているけどどう対応しよう……」と困っているような方は何かの参考になるかもしれないので、ぜひ読んでみてください！
プロダクトを安心して使ってもらうための「不具合対応」
プロダクトの成長のためには新しい機能の提供や操作性を良くしたり、といった継続的な改善が必要ですが、一方で、快適さを脅かす「不具合」への細やかな対応も必要となります。特に、ユーザーが長い時間を過ごすプラットフォームである「cluster」では、特に重要な要素です。
clusterはPC・スマホ・VR機器など複数のプラットフォームに関わっていることや、3D空間、アバターに音声周り、ストア機能、ユーザー自身が3D空間を制作できるUGCツールなど多岐に渡る機能を提供する複雑なプロダクトです。
その影響なのか、clusterには多くの不具合が確認されていますが、対応できるものはなるべくスピーディーに対応できるよう日々改善を進めています。
clusterには複数人のPMが関わっていますが、私はそうした不具合情報をキャッチアップしたり、プロダクトに関してのコミュニケーションが良くなるように活動しています。
最近では、前任者の育休に伴い、clusterの最新情報を伝える公式バーチャルイベント「Hello Cluster」に毎週出演して、ユーザーの皆さんとコミュニケーションを取っています。
ユーザーの方々からの不具合報告もこまめに確認しながら対応していますが、今回の記事では直近で取り組んだ「社内からの不具合報告から対応までのフロー」の改善について紹介します。
社内からの不具合報告の既存の課題
クラスター社では、エンジニアがチームのミーティングをcluster内で行ったり、全社員が集まる「WinSession」という各部署の成果発表会でclusterを活用したり、社員自身もclusterを活用する場面が多くあります。そのため、clusterの不具合報告が社内から上がってくることも多くありました。
開発チームではチームごとにバーチャルオフィスをつくっていたり
バグレポートの報告フロー自体は以前からGoogleフォームで用意されていましたが、お世辞にもよく活用されている状況とは言えませんでした。また、不具合の報告自体は嬉しいのですが、報告を受けるにあたって以下のような課題がありました。
- 情報の詳細がまちまち
- 何を報告すると良いのか分かりづらかった
- 開発に関わっている社員とそうではない社員では報告の詳細度がまちまちでした。
不具合を修正するためには、まず同じ条件で不具合が再現するか確認する必要があり、それを確認してから調査を開始します。ということは、どんな端末かなど不具合の再現やcluster起因かを切り分けるために以下の項目を抑えている必要がありました。 - OS（version）
- 端末
- 通信環境
- しかし、普段から開発に関わっていない人が報告時にそれを意識するのは難しいです。
- 結果として、必要な情報を集めるために多くのやりとりが発生してしまっていました。
- また、やりとりがスムーズにいかない場合に不具合の改善が後手に回る可能性も生まれてしまっていました。
- どこで報告すると良いのか分かりづらかった
- 先述した通りGoogleフォームは存在していましたが、クラッシュレポート用のアンケートだったため「不具合の報告」とはニュアンスが違っていました。
- 「不具合かも？」と思ったら報告するチャンネルもありましたが、報告テンプレートがない事で情報が足りないことが多いというのが実情でした。
- 報告を受けてからのキャッチアップが難しい
- 不具合報告を受けた場合はPMが対応の可否を判断しますが、その場合の判断材料の収集が難しくなっていました。最終的には
- 詳しい人は誰か
- どの開発チームの領域か
- が分かれば、以下の
- どのversionから起こっているか
- 影響範囲は
- どのepic（クラスター社で採用している開発フロー）が原因か
- どうやったら仕様通りに動かすことができるか
- 解消までの見込み期間は
- あたりのレポートをエンジニアからもらえる可能性が高まるので、それを絞り込む一次情報を収集できるフォームが必要と考えました。
【改善】Slackのワークフローを使って不具合報告フォームを制作
上述した課題を解決するために、今回はSlackのワークフローを使って下記のようなフォームを用意しました。
Slackワークフローで不具合報告を受け、問題が再現できたら課題・プロジェクト管理ソフトウェアである「Jira」でチケットを作成し、調査を行った上で改善を行うというフローを整備しました。
クラスター社は基本的にリモートで働いており、社内コミュニケーションのメインツールとしてSlackを利用しています。Slackでは一日中投稿がされ常にアクティブな状態なので、多くの人の目に留まりやすい場所としてSlackワークフローを選択するのは自然な流れでした。
クラスター社のSlackには色々なコンセプトのチャンネルがありますが、フィードバックを収集するチャンネルがあるので、そちらのチャンネルにブックマークしています。
報告されたら、下図のようにチャンネルに自動的に投稿されるようになっています（PM全員にメンションがされるほか、収集された情報がそのままSlackに投稿されます）。
結果、良くなったところ
社内の多くの人に不具合報告フローの存在を周知できた
先述したように、以前までのバグレポート用のGoogleフォームは存在があまり知られていなかったため、今回のリニューアルを機に不具合報告のフローの存在を説明動画付きで周知することができました。
投稿にはスタンプも多く押されていたので、社内の人たちからの反応も良かったのではないかと思います。
数ヶ月で50件近くのバグ報告があり、1〜2割はその週に解決
上記の反応の良さを証明するかのように2023/11/24 ～ 2024/04/01の間で48回の不具合の連絡がありました。うち半数以上がバグとしての再現を確認し、調査を進め、改善に進めることができています。中には報告があった週の内に改善されたものもあります。
不具合が多くあること自体は必ずしも嬉しいことではないですが……ユーザーの皆さんが大きく困る前に社内で不具合を検知して改善に繋げられるようになったのは良いことではないかと思います。
実際にユーザーの方からちらほら報告があるタイミングの少し前に社内で不具合を検知して、スムーズに改善に進められた例もあります。
連絡の往復回数が減った
最初に書いたように不具合の改善のために必要な情報を集めることがひとつのボトルネックになっていました。フォームに必要な情報の記載が求められることで最低限の情報を一回で収集できるようになり、連絡の往復回数が減りました。
後からのキャッチアップがしやすくなった
また、不具合報告に投稿された情報がそのままSlackチャンネルに投稿されるようにしたことによって、そのままSlackのスレッドでさらに必要な情報の収集であったり、対応方針を決める議論ができるようになりました。
これによって、エンジニアが調査を進める際に必要な情報・対応方針をキャッチアップする際に見るべき場所が減り、対応がしやすくなったのではないかと思います。
まとめ
今回は「社内からの不具合報告から対応までのフローの改善」について紹介しました。
改善の効果は感じられますが、まだまだ良くできる部分もあると思うので、引き続き改善を続けていく予定です。今回の改善で、開発に関わっている社員以外もこうした活動には積極的に協力してくれることに改めて有り難みを感じました。
そこで最近では、直近のリリースや今後予定されている施策などについて、職種に関わらず知ることができるように全社向けにアピールするようにしています。下記はQAに進む前にCEOでありproducerである加藤さんの最終reviewを通った施策のお知らせになります。
開発についての情報をより知ってもらう他、PMが積極的に前に出ることで、PMが色々な声の受け皿になっていることを認識してもらい、社内からのフィードバックをよりしっかりと活かすことができるようになるのではないかと考えています。
