チームメンバーがPRDを書くようになって、ユーザー中心のプロダクト開発が加速した話
はじめに
本記事は、ストックマーク Advent Calendar 2021の10日目の記事です。
こんにちは、ストックマークのプロダクトデザイナーの西村です。
この記事は「PRDに何書くの？」「メンバーもPRD書くにはどうする？」という問いを持たれている方の学びになればと思い書いています。
なぜ プロダクトデザイナーがPRDの話？
とも思うかもしれませんが、ところで、PRDはプロダクトマネージャーだけが書くものでしょうか？ストックマークでは、PRDをデザイナーもエンジニアも書くようにもなり、PRDはチームのものになっています。
今回は、何が起きたか、どのように運用しているかに着目してお届けします。
PRDをメンバーが書くようになって良かったこと✨
背景も含めて記述することで、ユーザー理解への主体性が高まる
ユーザーの本質課題を言語化する際に、詳しく調べないと書けない。これが結果的にユーザーを理解しようとする行動につながる
メンバー個々がユーザーにとって良いプロダクトを提供するという意識が高まる
開発に入る前に問題を検出できる
他にもありそうですが…デザイナーとしては何よりユーザーを理解しようとする行動が増えたことが嬉しかったです。
PRDとは？
まずPRD（Product Requirement Document）を学ぶ上で、私たちがまず参考にさせて頂いたのはこちらの記事でした。このnoteでは詳しい説明はしませんが、重要なところを引用させていただきます。
プロダクトマネジメントの名著 Inspired: 顧客の心を捉える製品の創り方[1] によれば、プロダクトマネージャの役割は2つある。
・製品の市場性を評価すること
・開発すべき製品の定義
…
開発すべき製品の定義に関しては、製品要求仕様書（PRD, Product Requirements Document）がその役割を担う。PRDはMRDで明らかになった課題に対してのソリューションを形作るもので、製品の特徴や機能について書かれている。
まずは、チームでこの記事を読むところから始まりました。
チームでのPRDのはじまり
私たちのチームでは、立ち上がり当初からフォーマットされたPRDを書いていたわけではなく、メモ書きの延長のような資料で仕様を記述していました。
例えば、以下のような項目です。
・顧客/ユーザーはだれか
・課題は何か
・あるべき姿は何か
・どう解決するか
・UIデザイン（Figmaプロトタイプへのリンク）
必要な項目を書くようにしていました。少人数であれば、それほど大きな問題は感じていませんでした。
では、なぜ PRDを書くことにしたの？
大きくは２つです。
様々な職種のメンバーが集まり、背景の共有が不足し、認識ずれがおきたり、ユーザーが見えなくなることが起きはじめた
暗黙的な内容が記述されていないなど、振り返りできない
まずは、書いてみよう。ということで、項目を定めることから始めました。
PRDを記述する目的
まず、目的をしっかり共有
仕様として言語化し、「何を開発するのか」の認識のブレを最小限にする
振り返ることができるようにする
PRDの運用が少し回り始めたところで、プロダクトマネージャーだけでなくメンバー全員が記述するというフェーズに移りました。この時の目的は以下のようなものです。
「書いてあるものを理解するから始める」のではなく、自ら書くことで「ユーザーを理解するから始める」に変える
文字にならない暗黙的な情報があるのではという仮説から、”書いてみる” ことをメンバーでやってみよう。となったのがきっかけです。
以下では、その変遷をお伝えできたらと思います。
PRDに何を書くか？その変遷
現在、運用しているPRDのドキュメント履歴を見ると、バージョンが”16” になっていました。課題を発見しては改善してたりします。
初版のPRDは プロダクトマネージャーが記述していました。開発中に問題が起きた時や、記述するメンバーが増えるタイミングなどで変化しています。
今回は その中でも、大きな構造変更が起きた３つのバージョンを例に。どのように項目を定めたかを紹介します！
1.初版バージョン
1. どのような問題を解決するか
2. 誰のために問題を解決するか
3. プロダクト As-Is, To-Be
4. ユーザーストーリー
5. 想定する運用方法
6. スコープ（開発することしないこと）
7. 考慮事項
8. 予期されるリスクとその対応策
9. 情報設計
10. UI
11. データ設計・API
12. どのように評価するか（定量・定性）
上述の、スタートアップのための製品要求仕様書(MRD & PRD)の書き方 を参考に書き始め、項目を設定しました。この時点で、試しながら調整しながらで初版を作り、あとは運用してみて項目を調整しようというはじまり方です。
しかし、これがまた運用してみると、、 1つの項目に複数の内容が入っていたり、似たような項目があったりして、書くのが難しい。結果、サブセクションが増えたり文字数が増え、読み取る側も大変になってしまいました…
早速アップデートが入ったりしています。
例えば、
「プロダクト As-Is, To-Be」を「あるべき姿」
「考慮事項、予期されるリスクとその対応策」を統合
など…
2.少し運用してみての項目アップデート
項目も安定して、順調に運用していたのですが、開発時に考慮漏れが発生し、手戻りする事象が発生。事前に考慮可能な項目であったため、PRDの内容に追加しました。
リスクの記述に雛形を用意した
「リスクを書く」というセクションはあったが、リスクの観点が漏れてしまうため明示的に観点を表形式で記載した
リスクの回避方法や、評価方法も記述
3.エンジニアがPRDを記述する上でのアップデート
そして現在のバージョンに至ります。このタイミングでの目的は、繰り返しますが ”書くこと” です。
目的：「書いてあるものを理解するから始める」のではなく、自ら書くことで「ユーザーを理解するから始める」に変える
エンジニアが書きはじめると、項目が多く書き始めに詰まってしまうことが見受けられました。似た視点を統合し、項目数を減らすことにしました。その結果がこちらです。
1. 誰のどのような問題を解決するか
2. あるべき姿（あるべきユーザージャーニー）
[開発]
3. スコープ
4. プロダクトを実際にどのように使うのか（ユーザーストーリー）
5. リスクとその対応策・考慮事項
6. 情報設計
7. UI・インタラクション
8. データ設計
9. テストケース
10. どのように評価するか（定量・定性）
初版から２項目減りました。
現在は、エンジニア自ら 1,2 の項目から記述することをしています。
チームメンバーに合わせて、書きやすく設計しながら、本来の目的であるように情報が落ちないように、振り返りできるように設計することで、プロダクト仕様を残しつつ、チームメンバーの考え方にも影響できるというのは面白い発見でした。
コミュニケーションツールとしてのPRDの発展はまだまだ考えることも多そうです。
最後に、PRDをどう運用しているかをご紹介します。
PRDをどう運用しているか
PRDの目的を達成するために
レビューや読み合わせを行い、PRDの内容を確認するようにしています。
“仕様として言語化し、「何を開発するのか」の認識のブレを最小限にする”
PRDの項目をより良くするために
PRDの項目は一度作って終わりではありません。特別なことはしていませんが、PRDの項目の見直しは主に以下の２つのタイミングです。
開発中の突発的なイベントや思いつき
定期的な振り返り
１点目は、開発中に起きたイベントや、会話の中で良く確認されたり会話されたりするような項目があった場合に、見直しています。
２つ目は、開発チームでスプリントごとに行っているKPTAの取り組みです。KPTAから良い点も改善点も見つかり、アップデートにつながっています。リスクの項目を追加したり変更しようと言ったアクションもKPTAから出てきました。
ストックマークのKPTAについては、是非こちらの記事もご参照ください！
おわりに
PRDを書くことは目的ではなく、優れたプロダクトをチームで開発するためのツールの１つだと思います。チームで大切にしている視点を項目に入れることで、心がけを思い出す機会にもなります。
定期的に項目を見直すことは、チームのコミュニケーションをよくする上でも重要かと思います。
今後は、定性・定量な評価結果と紐づくなど、振り返った時にPRDが生きた文書として使えるようにしていけたらと思います。
ストックマークでは多様なバックグラウンドを持ったメンバーが活躍しています。
ちょっと話を聞いてみたい、もう少し詳しく知りたいなど感じたことがありましたら、是非ご連絡ください！
この記事が気に入ったらサポートをしてみませんか？