要約: 製品要件ドキュメント (PRD) とは、製品の目的、機能とその実用性、動作を含む特定の製品の要件を定義付ける文書です。ビジネスチームおよび技術チームが製品の開発、立ち上げ、マーケティングを行う場合のガイドとして利用可能です。
優れた製品を開発するためには、研究の積み重ねと包括的な計画が必要です。ただ、どこから始めたら良いでしょうか？プロダクト・マネージャーは PRD（製品要件ドキュメント）から始めることが多いようです。
製品要件ドキュメントとは開発対象となる製品の目的、機能とその実用性、動作を大まかに定義付ける文書です。
次は PRD を関係者と共有し (意見を求め) ます。関係者とは製品の開発、立ち上げ、マーケティングを援助するビジネスチームと技術チームを指します。
関係者から賛同が得られたら、PRD は製品の目的達成に必要な指示を明示する羅針盤となると同時に、ビジネスおよび技術チーム間の共通認識を確立します。
アジャイル界の要件を集める
アジャイル界で要件を収集するプロセスは油断ならないように思え、実際にそうですが、心配は不要です。アトラシアンはアジャイル環境で PRD を作成するあらゆるノウハウを蓄えています。注意が必要なのは次の数点です。
アジャイル要件があればプロダクト所有者は鬼に金棒です。アジャイル要件を使用しない場合、プロダクト所有者は適切なソフトウェアを実現するために細かい仕様の指定にかかりきりになります (指定後は仕様が適切であることを祈るばかりです)。一方、アジャイル要件は、プロダクト所有者、デザイナー、開発チームが共有する顧客に対する共通認識に応じて決まります。ターゲット顧客に対するそうした共通認識と共感によって、プロダクト所有者にはハイレベルの要件に重点を置き、実装に関する詳細を万全の準備を整えた開発チームに任せる余裕が生まれます。これが可能なのも、共通認識があるからこそです!
チームのメンバーの共通認識を確立する
この共通認識を高く評価しているものの、どのようにすればよいのかわからない場合は、次のヒントを参考にするとよいでしょう。
- 顧客インタビューの場には、デザインチームと開発チームのメンバーを同席させ、プロダクト所有者からの情報に頼らずに顧客の意見を直接聞けるようにしましょう。また、この機会に、顧客の関心が強いうちに深く調査できます。
- チームの活動として、顧客のペルソナを明らかにして活用しましょう。チームメンバーにはそれぞれ固有の視点や考え方があり、ペルソナが製品開発にどのような影響を及ぼすのかを理解する必要があります。
- チーム・スポーツのように協力して、課題に優先順位を設定し、バックログ・グルーミングを行いましょう。全員が共通の認識を持ち、製品所有者が作業にそのような優先順位を設定した理由を理解する絶好の機会となります。
お試しになりたい場合は、Confluence に登録またはログインしてください >>
カスタマー・インサイトを記録するために顧客インタビュー・テンプレートを作成してください。次に、チュートリアルに従って、効果的な顧客インタビューを開始してください。
- 洞察力に富んだ顧客インタビューページの作成
- 顧客インタビューピラミッドによる情報の有効活用
- エンジニアリング作業を開始する前に、プロジェクト全体の細かい仕様が指定されている。
- 作業を開始する前に、徹底的なレビューとすべてのチームからの厳格な承認が必要とされている。
- デザイナーと開発者が要件の更新時期を把握していない。
- そもそも要件が一度も更新されない (全員が要件を承認したため)。
- チームが参加することなく、プロダクト所有者が要件を記述した。
これまでに、エンジニアやデザイナーと、ユーザーストーリーについて話し合いました。議論を重ね、さらにいくつかの側面を検討する必要があるという結論に達しました。 仮定事項を具体化し、全体の構想における位置付けについてよく考え、未解決の疑問を管理する必要があります。次に何をすればよいのでしょうか?
1 ページにまとめたダッシュボードで PRD を簡潔に管理する
要件ドキュメント作成するときに、チーム全員が同じテンプレートを使うとフォローとフィードバックがしやすくなり便利です。アトラシアンでは Confluence を使って、製品要件ドキュメント用テンプレートに準拠した製品要件を作成しています。プロジェクトの要件とそのユーザーへの影響を理解するには、以下のセクションがあれば「充分」です。
1. プロジェクトの詳細を定義する
ページの最上部に以下のようなハイレベルの方向性を示すとよいでしょう。
- 参加者: 誰が関与するのか？ (プロダクトオーナー、チーム、利害関係者など)
- ステータス: プログラムの現在の状態 (目標どおり、リスクあり、遅延、保留など)
- リリース目標: プロジェクトの出荷時期
2. チームの目標とビジネスの目標
要点を簡潔に述べます。無駄なく充分な情報を提供します。
3. 背景と戦略的適合性
プロジェクトの実施理由を説明します。企業全体の目標との適合性を説明します。
4. 前提条件
技術、ビジネス、ユーザーに関する前提条件を記載します。
5. ユーザーストーリー
関連するユーザーストーリーを記述またはリンクします。また、顧客インタビューにもリンクし、関連するスクリーンショットも記載します。ストーリーを完結させるために十分な詳細と成功基準も示します。
6. ユーザーインタラクションとデザイン
チームが各ユーザーストーリーの解決策を具体化した後、デザインに関する調査とワイヤフレームをページにリンクします。
7. 疑問点
チームが解決すべき問題を把握すると、疑問点も出てきます。そのような疑問点を管理するために、「判断または調査が必要な事項」の表を作成します。
8. 除外項目
除外事項を明確にすることで、チームが目の前の作業に専念できるようにします。現時点ではスコープに含めず、後日検討する可能性のある事項にフラグを設定します。
要件作成をどれほど柔軟に行えるかについては、アジャイル マニフェストを思い出しましょう。中には、ユーザー ストーリー マッピングを行って問題と解決策を見つけ出すチームもあります。製品を中心とする 3 つの役割 (プロダクト所有者、開発者、デザイナー) の全員が顧客を訪問し、顧客から指摘のあった特定の問題の解決策についてブレインストーミングを行う場合もあります。
要件の設定方法にかかわらず、要件は顧客の抱えている問題を定義し伝達する多くの方法の一つであるとチームが考えることが重要です。プロダクト所有者が Keynote と Powerpoint を使用して実際の経験を要件としてまとめる方法については、アジャイル デザインに関するセクションで説明しています。
1 ページにまとめた PRD の例
ここからは、Confluence を使って作成した必須要素を揃えた製品要件ドキュメントをみていきます。ただし、要件がまったく同じ製品はありません。この例は、PRD に盛り込むさまざまな要素を理解するために使用するのにとどめ、厳密に従う必要はありません。
お試しになりたい場合は、Confluence に登録またはログインしてください >>
ログインしたら、製品要件のブループリントを選択し、以下のチュートリアルを参考にしながら、独自の要件を設定し始めましょう。
PDR を 1 ページにまとめる方法のメリット:
このブログから何かしら教訓を得ようとするなら、「何を」ではなく「なぜ」を理解しましょう。「なぜ」を追及することは、チームに最適な解を探すのに役立つからです。ここでは、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 のユーザーストーリーを開発チームの課題管理システムの対応するストーリーにリンクすることをお勧めします。このようにすることで、開発プロセスの透明性を向上できます。各作業のステータスがわかりやすくなり、プロダクト所有者のほか、マーケティングやサポートのような下流チームの意思決定に使用できる情報量が増えます。
プロジェクト要件に関するユーザーストーリーと不具合に関するユーザーストーリーを別々のシステムで追跡しないようにしましょう。2 つのシステムで作業を管理しようとすると余計な問題が生じ、時間を浪費することになります。
プロジェクトの要件の進化においてもアジャイルであることを忘れないようにしましょう。開発、出荷、フィードバックに伴い、ユーザーストーリーを変更してもかまいません。常に高い品質レベルを維持し、健全なエンジニアリングカルチャーを守りましょう。そのためには、リリースする機能が減少するのも止むを得ません。
