Building a great product requires tons of research and comprehensive planning. But where do you start? Product managers often start with a product requirements document (PRD).

With a product requirements document, you define the product you are about to build: You outline 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.

Gathering requirements in an agile world 

What does the requirements gathering process look like in an agile world? It sounds tricky - and it is. But don't worry. At Atlassian, we know all about creating PRDs in an agile enviornment. Here are a few things to keep in mind:

アジャイル要件 (アジャイル開発における要件) はプロダクトオーナーの最良の友です。 アジャイル要件を使用しないプロダクトオーナーは、適切なソフトウェアを実現するために細かい仕様の指定にかかりきりになります (その後は仕様が適切であることを祈るばかりです)。 一方、アジャイル要件を使用する場合は、プロダクトオーナー、デザイナー、開発チームに、顧客に対する共通認識が必要です。 ターゲット顧客に対する共通認識と共感があることで、プロダクトオーナーの隠れたアジリティが発揮されます。 プロダクトオーナーはハイレベルの要件に重点を置き、実装に関する詳細は万全の準備を整えた開発チームに任せます。これが可能なのも、共通認識があるからこそです!

Creating a shared understanding among teams

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

  • When conducting customer interviews, include a member of the design and development teams so they can hear from a customer directly instead of relying on the product owner's notes. It will also give them the chance to probe deeper while the topic is fresh in the customer's mind.
  • チームの活動として、顧客のペルソナを明らかにして活用しましょう。チームメンバーにはそれぞれ固有の視点や考え方があり、ペルソナが製品開発にどのような影響を及ぼすのかを理解する必要があります。
  • チームスポーツのように協力して、課題に優先順位を設定し、バックログのグルーミング (手入れ) を行いましょう。全員が共通の認識を持ち、プロダクトオーナーが作業に優先順位を設定した理由を理解する絶好の機会となります。

チームとプロダクトオーナーが同じ考え方を共有していれば、膨大で詳細な要件は必要ありません。

注意すべきアンチパターン

  • エンジニアリング作業を開始する前に、プロジェクト全体の細かい仕様が指定されている。
  • 作業を開始する前に、徹底的なレビューとすべてのチームからの厳格な承認が必要とされている。
  • デザイナーと開発者が要件の更新時期を把握していない。
  • そもそも要件が一度も更新されない (全員が要件を承認したため)。
  • チームが参加することなく、プロダクトオーナーが要件を記述した。 

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

1 ページにまとめたダッシュボードで要件を簡潔に管理する

When writing a requirements document, it's helpful to use a consistent template across the team so everyone can follow along and give feedback. At Atlassian, we use Confluence to create product requirements with the product requirements blueprint. We've found that the section below provides "just enough" context to understand a project's requirements and its impact on users:

1. プロジェクトの仕様の定義
We recommend including high-level direction at the top of the page as follows:

  • 参加者: 誰が関与するのか? (プロダクトオーナー、チーム、利害関係者など)
  • ステータス: プログラムの現在の状態 (目標どおり、リスクあり、遅延、保留など)
  • リリース目標: プロジェクトの出荷時期

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

3. 背景と戦略的適合性
なぜこのプロジェクトを実施するのか?企業全体の目標においてどのように位置付けられているのか?

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

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

6. ユーザーインタラクションとデザイン
チームが各ユーザーストーリーに対するソリューションを具体化した後、デザインに関する調査とワイヤフレームをページにリンクします。

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

8. 除外事項
Keep the team focused on the work at hand by clearly calling out what you're not doing. Flag things that are out of scope at the moment, but might be considered at a later time.

ProTip: The agile manifesto reminds us that we can be flexible with how we create requirements. Some teams do user story mapping exercises to identify problems and solutions. Sometimes the full product triad (product owner, developer, and designer) visits a customer and then brainstorms solutions to a particular problem that the customer mentioned.

要件の設定方法にかかわらず、要件は顧客の抱えている問題を定義し伝達する多くの方法の一つであるとチームが考えることが重要です。 プロダクトオーナーが Keynote と Powerpoint を使用して実際の経験を要件としてまとめる方法については、アジャイルデザインに関するセクションで説明しています。  

Example of a one-page PRD

Here's a look at a fully fleshed out product requirements document that we created using Confluence. Remember, no two product requirements will be exactly the same. Use this example to understand the different elements that should be included in your PRD, but not as the definitive way to do it. 

Key takeaways from the one-page approach:

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

1. One page, one source
Keeping it simple. The product requirements document becomes the “landing page” for everything related to the set of problems within a particular epic. Having something that is the central go-to location saves your team members time in accessing this information and gives them a concise view.

2. 優れたアジリティ
One of the awesome things about using a simple page to collaborate (verses a dedicated requirements management tool) is that you can be agile about your documentation! You don’t have to follow the same format every time – do what you need, when you need it, and be agile about it. Chop and change as needed.

3. 適度なコンテキストと詳細
We often forget how powerful a simple link can be. We embed a lot of links within our product requirements documents. It helps abstract out the complexity and progressively disclose the information to the reader as needed. Linking detailed resources may include such things as:

  • フィーチャーの背景、検証、コンテキストを知るための顧客インタビュー
  • 類似するアイデアを提案しているページやブログ
  • これまでの話し合いでの資料、技術文書および図
  • 製品デモのビデオや、外部ソースからの他の関連するコンテンツ

4. ストーリーの活用
多くの顧客もこれを行っています。ストーリーの大筋が決まり、JIRA Software に課題として入力した後、要件ページ内からその課題にリンクします (これによって課題からページへのリンクも作成され便利です)。 このように Confluence と JIRA Software の間で双方向の同期を行うことで、それぞれの課題の現在のステータスを要件ページからすぐに確認できます。

5. 集合知
Capturing product requirements in Confluence makes it easy for other people in different teams to contribute and make suggestions. I’ve been amazed at the number of times someone from another team jumped into the conversation with a comment providing great feedback, suggestions, or lessons learned from similar projects. It helps a large organization feel like a small team.

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

7. コラボレーション!
The most important aspect of all this is getting everyone involved. Never write a product requirements document by yourself – you should always have a developer with you and write it together. Share the page with your team and get feedback. Comment, ask questions, encourage others to contribute with thoughts and ideas. This is especially important for distributed teams who don't often get a chance to discuss projects in person.

課題

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

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

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

作業に取り掛かろう!

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

プロジェクトの要件を適切に設定した後、前述のセクション 4 のユーザーストーリーを開発チームの課題管理システムの対応するストーリーにリンクすることをお勧めします。このようにすることで、開発プロセスの透明性を向上できます。各作業のステータスがわかりやすくなり、プロダクトオーナーのほか、マーケティングやサポートのような下流チームの意思決定に使用できる情報量が増えます。

ヒント:プロジェクト要件からのユーザーストーリーと不具合の管理を別のシステムで行わないようにしましょう。2 つのシステムで管理しようとすると余計な問題が生じ、時間を浪費することになります。 

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

関連する製品
プロジェクト / 課題管理
Create and collaborate