Quick PRDのルール
Quick PRDには以下の内容を書いてもらうようにしました。
（1）プロパティ
- 提案したい機能名
- かかりそうな時間（提案を実装し、リリースするまでの見積もり）
- 対象となるプラットフォーム（ウェブ/iOS/Android/デスクトップ）
-
起案内容
- プラットフォーム差を埋める
- プラットフォームらしさを活かす
- ユーザー課題を解決する
- リリース予定日
（2）必須項目
- どんな課題を解決したいのか
- なぜその課題を解決したいのか
- どんなユーザーが課題を抱えているか
- 追いたいKPIはなにか
（3）オプション項目
- 目標または仮説は何か
- プロトタイプ（画像や動画など）
- その他
少しの時間で書けることと、課題の根拠を明確にしてもらうことを大切にしています。また、Quick PRDで提案するときは多くの時間をかけずに、最大でも1か月程度の時間でリリースまで持っていけるようにしましょうとお願いしました。
Chatworkではドキュメント管理システムとしてアトラシアンのConfluenceを使っています。Quick PRDのテンプレートをConfluenceに用意し、コピーして記入したうえで、同じくアトラシアンのチケット管理システムであるJiraを使って起案してもらう形で運用することにしました。
起案された内容はチャットに通知されるので、まずプロダクトマネージャーが目を通します。そして毎週開催されるQuick PRD定例ミーティングで複数人のプロダクトマネージャーが中身をレビューし、起案された内容を承認、疑問点があれば起案者に確認する形をとりました。
プロダクトマネージャーが提案を承認したあとは、Jiraからチャットに自動的に「承認しましたよ」と投稿される仕組みを用意しました。
承認後に実施するタイミングに関しては以下の形をとりました。
- あらかじめ、いつリリースするかは決めない
- 着手は開発側で空いた時間ができたタイミングで実施してもらう
- 着手やリリースのタイミングでJiraのチケットにラベルを付ける
緩めのルールにしておくことで、Quick PRDの存在自体がエンジニアやデザイナーのプレッシャーにならないようにしたいと考えてのことでした。
Quick PRDの成果
Quick PRDの形で要望をあげてもらえるようになったことで、ユーザー目線で客観性や説得力を持たせることができ、課題に対する解決策の意図がセットになることでプロダクトマネージャーとのコミュニケーションコストが下がり、要望の優先度判断や必要性の判断ができるようになりました。
また、提供するプラットフォームごとにある差分を埋めるような提案、プラットフォームらしさを活かす提案もQuick PRDで提案してもらう形をとりました。各プラットフォームの “らしさ” を一番よく知っているのはそれぞれを担当するエンジニアです。不自然さもユーザーにとってどんな問題があるのか？を元に書いてもらうことで、説得力を持たせられるようになりました。
Quick PRDの仕組みができた2018年10月末から2019年6月末までの約半年の間に起案された数は59件でした。起案数としてはなかなかの量になったと考えています。
成果の一例としては、まだ読んでいないチャットの数がいくつあるのかを簡単に分かるようにしたり、チャットごとに読んでいないメッセージの数の表示方法をすべてのプラットフォームで統一するような対応をしたり、ビデオ通話機能を使っているときに誰が画面共有しているのかを簡単に確認できるようにする対応を入れたりしました。ひとつひとつの施策は小さいですが、こうした細かな改善が着実に進められるようになったのは大きな成果です。
プロダクトマネージャーが考えたロードマップに沿って実施されるプロジェクトだけでなく、細かなブラッシュアップやロードマップからこぼれ落ちてしまう小さな課題に対してもアプローチできるようになり、ユーザー課題の解決につながるリリースを素早く実施できるようになりました。
