PRD (製品要件ドキュメント) の作成方法

優れた製品を開発するためには、研究の積み重ねと包括的な計画が不可欠です。では、具体的にどこから始めればよいのでしょうか? プロダクト マネージャーは PRD の作成から取り掛かることが多いようです。

A product requirements document defines the product you are about to build: It outlines the product's purpose, its features, functionalities, and behavior.

Next, you share the PRD with (and seek input from) stakeholders - business and technical teams who will help build, launch or market your product.

Once all stakeholders are aligned, the PRD serves as a compass, providing clear direction toward a product's purpose while creating a shared understanding among business and technical teams.

アジャイル界で要件を収集するプロセスは油断ならないように思え、実際にそうですが、心配は不要です。アトラシアンはアジャイル環境で PRD を作成するあらゆるノウハウを蓄えています。注意が必要なのは次の数点です。

アジャイル要件は製品所有者にとって一番の味方です。アジャイル要件を採用しない製品所有者は、適切なソフトウェアを提供するために細部まで仕様を決めることに追われてしまいます (そして、正しく仕様化できたことを祈ることになります)。

一方、アジャイル要件は、製品所有者、設計者、開発チームの間で共有される顧客に関する共通の理解にも左右されます。ターゲットとなる顧客に対する理解と共感を共有することで、製品所有者にとって隠れた余地の可能性が広がります。

製品所有者はより高いレベルの要件に集中し、実装の詳細については準備万端の開発チームに任せることができます。これもまた、理解が共有されているから成せることです。

この共通認識を高く評価しているものの、どのようにすればよいのかわからない場合は、次のヒントを参考にするとよいでしょう。

• 顧客インタビューの場には、デザインチームと開発チームのメンバーを同席させ、プロダクト所有者からの情報に頼らずに顧客の意見を直接聞けるようにしましょう。また、この機会に、顧客の関心が強いうちに深く調査できます。

• チームの活動として、顧客のペルソナを明らかにして活用しましょう。チームメンバーにはそれぞれ固有の視点や考え方があり、ペルソナが製品開発にどのような影響を及ぼすのかを理解する必要があります。

• チーム全体で作業項目の優先度を決めて、バックログ グルーミングを行いましょう。全員が共通の認識を持ち、製品所有者が作業に優先度を設定した理由を理解する絶好の機会となります。

お試しになりたい場合は、Confluence に登録またはログインしてください >>

カスタマー・インサイトを記録するために顧客インタビュー・テンプレートを作成してください。次に、チュートリアルに従って、効果的な顧客インタビューを開始してください。

• インサイトに富んだ顧客インタビュー ページの作成

• 顧客インタビューピラミッドによる情報の有効活用

これまでに、エンジニアやデザイナーと、ユーザーストーリーについて話し合いました。議論を重ね、さらにいくつかの側面を検討する必要があるという結論に達しました。 仮定事項を具体化し、全体の構想における位置付けについてよく考え、未解決の疑問を管理する必要があります。次に何をすればよいのでしょうか?

要件ドキュメント作成するときに、チーム全員が同じテンプレートを使うとフォローとフィードバックがしやすくなり便利です。アトラシアンでは Confluence を使って、製品要件ドキュメント用テンプレートに準拠した製品要件を作成しています。プロジェクトの要件とそのユーザーへの影響を理解するには、以下のセクションがあれば「充分」です。

1. プロジェクトの詳細を定義する

ページの最上部に以下のような大まかな指示を含めることをお勧めします。

• 参加者: 誰が関与するのか？ (プロダクトオーナー、チーム、利害関係者など)

• ステータス: プログラムの現在の状態 (目標どおり、リスクあり、遅延、保留など)

• リリース目標: プロジェクトの出荷時期

2. チームの目標とビジネスの目標 要点を簡潔に述べます。無駄なく十分な情報を提供します。

3. 背景と戦略的適合性 プロジェクトの実施理由を説明します。企業全体の目標との適合性を説明します。

4. 前提条件

技術、ビジネス、ユーザーに関する前提条件を記載します。

5. ユーザー ストーリー

関連するユーザー ストーリーを記述またはリンクします。また、顧客インタビューにもリンクし、関連するスクリーンショットも記載します。ストーリーを完結させるために十分な詳細と成功のメトリックも示します。

6. ユーザー インタラクションとデザイン

チームが各ユーザー ストーリーの解決策を具体化した後、デザインに関する調査とワイヤフレームをページにリンクします。

7. 質問

チームが解決すべき問題を把握すると、疑問点も出てきます。そのような疑問点を管理するために、「判断または調査が必要な事項」の表を作成します。

8. 除外項目

除外事項を明確にすることで、チームが目の前の作業に専念できるようにします。現時点ではスコープに含めず、後日検討する可能性のある事項にフラグを設定します。

ここからは、Confluence を使って作成した必須要素を揃えた製品要件ドキュメントをみていきます。ただし、要件がまったく同じ製品はありません。この例は、PRD に盛り込むさまざまな要素を理解するために使用するのにとどめ、厳密に従う必要はありません。

このブログから何かしら教訓を得ようとするなら、「何を」ではなく「なぜ」を理解しましょう。「なぜ」を追及することは、チームに最適な解を探すのに役立つからです。ここでは、1 ページにまとめたダッシュボードを使用するアプローチの利点と課題について説明します。

1. 1 つのページ、1 つのソース

シンプルにしましょう。製品要件ドキュメントは特定のエピック内において、一連の問題に関連するすべての「ランディング ページ」になります。中心的な宛先を設けることで、チーム メンバーがこの情報にアクセスする時間を節約し、正確なビューを提供できます。

2. 優れたアジリティ

1 ページにまとめられた PDR を使用してコラボレーションする大きなメリットの 1 つとして、専用の要件管理ツールを使用するのと違い、ドキュメンテーションにアジャイル手法を採り入れられることが挙げられます。毎回同じフォーマットを使用する必要はありません。必要なときに必要なことをしながら、アジャイル手法に従います。必要に応じて変更を加えましょう。

3. 適度なコンテキストと詳細

私たちはシンプルなリンクが持つ威力を忘れがちです。製品要件ドキュメントに多数のリンクを埋め込むことで、複雑さを軽減し、読者が必要とするタイミングに合わせて情報を開示できます。以下は詳細なリソースへのリンクの例です。

• フィーチャーの背景、検証、コンテキストを知るための顧客インタビュー

• 類似するアイデアを提案しているページやブログ

• これまでの話し合いでの資料、技術文書および図

• 製品デモのビデオや、外部ソースからの他の関連するコンテンツ

4. ストーリーの活用

ストーリーの大筋が決まり、Jira に作業項目として入力すると、アトラシアンのページ内でその作業項目にリンクされます (これによって作業項目からページへのリンクも作成されるため、便利です)。このように Confluence と Jira の間で双方向の同期を行うことで、各作業項目の現在のステータスを要件ページから自動的に確認できます。

5. 集合知

Confluence に製品要件をまとめることで、他のチームのメンバーによる貢献や提案が容易になります。他のチームのメンバーが会話に加わり、有用なフィードバック、提案、類似プロジェクトから得た教訓を提供した回数に驚くばかりです。このような仕組みを作ることで、大規模組織が小さなチームのように感じられます。

6. 興味を引く「追加要素」

Visio、Gliffy、Balsamiq のようなツールで作成した図を使用すると、チームに問題が伝わりやすくなります。その他のイメージ、ビデオ、ダイナミック コンテンツも組み込めます。

7. コラボレーション!

最も重要な点は、全員を参加させることです。要件書は単独では作成せず、必ず開発者の協力を得て作成するようにしてください。チームとページを共有し、フィードバックを得ます。意見を述べ、質問を投げかけ、それぞれが考えたことやアイデアを提案するよう促しましょう。これは、プロジェクトについて直接話し合う機会が少ない分散チームにとって特に重要です。

どのようなアプローチにもマイナス面はあります。ここでは、私たちが経験した、また顧客において観察された 2 つの主な課題について説明します。

1. ドキュメンテーションの陳腐化

ストーリーを実装し、フィードバックを受け、ソリューションを修正すると、どうなるでしょうか? 誰かが要件ページに戻ってアップデートし、最終的な実装を反映しますか? この問題はあらゆるタイプのドキュメンテーションにつきものです。このような欠点に目をつぶる価値があるのかどうかは、常に問う価値があります。このような場合にどうするかについて、チームと話し合いましょう。

2. 不参加

「意見を出すように仕向けるにはどうすればよいのか?」、「どうすれば、イントラネットにもっと多くの仕様やストーリーを書き込んでもらえるか?」このような疑問に対し、単純な答えはありません。Wiki の定着化手法は組織によってさまざまです。役立つリソースは多くあります。奥深いカルチャーの問題もあるかもしれません。

要件設定をすばやく行うと、プロダクトオーナーが市場を分析して把握する時間を多く取ることができます。開発チームは無駄なく十分な情報を得ることで、アーキテクチャやテクノロジースタックに最適な実装を使用できます。

プロジェクトの要件を適切に設定した後、前述のセクション 5 のユーザー ストーリーを開発チームの作業トラッカーの対応するストーリーにリンクすることをお勧めします。これにより、開発プロセスの透明性を向上できます。各作業のステータスがわかりやすくなり、製品所有者のほか、マーケティングやサポートのような下流チームが情報に基づいて意思決定を行いやすくなります。

プロジェクトの要件の進化においてもアジャイルであることを忘れないようにしましょう。開発、リリース、フィードバックに伴い、ユーザー ストーリーを変更してもかまいません。常に高い品質レベルを維持し、健全なエンジニアリング カルチャーを守りましょう。そのためには、リリースする機能が減少するのも止むを得ません。