簡潔な製品要件ドキュメント

大量の細かい製品要件ドキュメントを書くのが好きな人などいません。こうしたドキュメントを好んで利用する人も実はいません。

Dan Radigan Dan Radigan
Browse topics

優れた製品を開発するためには研究の積み重ねと包括的な計画が必要ですが、どこから始めたら良いでしょうか。プロダクトマネージャーは PRD (製品要件ドキュメント) から始めることが多いようです。

製品要件ドキュメントとは開発対象となる製品の目的、機能とその実用性、動作を大まかに定義付ける文書です。

アジャイルな製品要件ドキュメント|アトラシアンアジャイルコーチ

次は PRD を関係者と共有し (意見を求め) ます。関係者とは製品の開発、立ち上げ、マーケティングを援助するビジネスチームと技術チームを指します。

関係者から賛同が得られたら、PRD は製品の目的達成に必要な指示を明示する羅針盤となると同時に、ビジネスおよび技術チーム間の共通認識を確立します。

アジャイル界の要件を集める

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

アジャイル要件があればプロダクト所有者は鬼に金棒です。アジャイル要件を使用しない場合、プロダクト所有者は適切なソフトウェアを実現するために細かい仕様の指定にかかりきりになります (指定後は仕様が適切であることを祈るばかりです)。一方、アジャイル要件は、プロダクト所有者、デザイナー、開発チームが共有する顧客に対する共通認識に応じて決まります。ターゲット顧客に対するそうした共通認識と共感によって、プロダクト所有者にはハイレベルの要件に重点を置き、実装に関する詳細を万全の準備を整えた開発チームに任せる余裕が生まれます。これが可能なのも、共通認識があるからこそです!

チームのメンバーの共通認識を確立する

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

  • 設計および開発チームにも顧客インタビューに同席してもらいましょう。プロダクト所有者のメモに頼ることなく、顧客の話を直接聞けるだけでなく、トピックに対する顧客の関心が高いうちに、踏み込んだ話を聞く機会にもなります。
  • チーム単位で顧客のペルソナを作り上げ、利用しましょう。各メンバーは独自の視点とインサイトを持ち、製品開発に対するペルソナの影響を理解する必要があります。
  • 課題を選別し、チーム活動のバックロググルーミングを行いましょう。メンバー全員が同じ認識を持ちながら、プロダクト所有者が課題を優先順位付けした理由を理解する機会になります。

試してみますか? Confluence に申し込みまたはログインする >>

顧客からの有益な情報を記録するために顧客インタビューテンプレートを作成する。チュートリアルに従って、効果的な顧客インタビューに取りかかる。

注意すべきアンチパターン
  • エンジニアリング作業が始まる前に、プロジェクト全体の仕様がごく細部まで指定されている
  • 作業開始前に、徹底的なレビューとチーム全員から断固たる承認が必要である
  • 要件が更新されても設計者と開発者の耳に入らない
  • そもそも、要件がまったく更新されない (前述したとおり全員が承認済みであるため)
  • プロダクト所有者がチームの協力なしに、要件を記述する

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

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

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

1. プロジェクトの詳細を定義する
ページの最上部に以下のようなハイレベルの方向性を示すと良いでしょう。

  • 参加者: 関与者として、プロダクト所有者、チーム、各種関係者を含めます
  • ステータス: プログラムの現在の状態を目標どおり、危険な兆候あり、遅延、繰延などに分類します
  • ターゲットのリリース: リリース予定日を明確にします
アジャイル要件|アトラシアンアジャイルコーチ

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

3. 背景と戦略的適合性
実行する理由、企業全体の目標との適合性を説明します。

アジャイルな製品要件|アトラシアンアジャイルコーチ

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

5. ユーザーストーリー
関連するユーザーストーリーを記述またはリンクします。また、顧客インタビューにもリンクし、関連するスクリーンショットを織り込みます。ストーリーを完結させるだけの詳細を記載し、成功基準を示します。

アジャイルな要件ストーリー|アトラシアンアジャイルコーチ

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

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

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

プロからのヒント:

要件作成をどれほど柔軟に行えるかについてはアジャイルマニフェストを思い出しましょう。ユーザーストーリーマッピングを行って問題と解決策を見つけ出すチームも中にはあります。製品開発を担う三本柱 (プロダクト所有者、開発者、デザイナー) が総出で顧客を訪問し、顧客が訴える特定の問題の解決策についてブレインストーミングを行う場合もあります。

要件を見つけた経緯にかかわらず重要なのは、顧客の抱えている問題を定義し伝達する多くの方法の一つとしてチームが要件を認識することです。プロダクト所有者が Keynote と Powerpoint を使用して実際の経験を要件としてまとめる方法については、アジャイルデザインに関するセクションをご覧ください。

1 ページにまとめた PRD の例

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

製品要件ドキュメントの例|アトラシアンアジャイルコーチ
製品要件ドキュメント|アトラシアンアジャイルコーチ

試してみますか? Confluence にサインアップまたはログインする >>

ログインしたら、製品要件のブループリントを選択し、以下のチュートリアルを参考にしながら、独自の要件を設定し始めましょう。

PDR を 1 ページにまとめる方法のメリット:

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

1. 1 つのページ、1 つのソース
シンプルにしましょう。製品要件ドキュメントは特定のエピック内において、一連の問題に関連するすべての「ランディングページ」になります。拠り所となる中心的な場所を設けることで、チームメンバーがこの情報にアクセスする時間を短縮し、全体像を簡潔に表示できます。

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

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

  • 背景、検証、機能に関する詳細なコンテキストを提供する顧客インタビュー
  • 類似のアイデアが提案されていたページやブログ
  • 過去のディスカッションや技術ドキュメントと図
  • 製品実演ビデオや外部ソースからの他の関連コンテンツ

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

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

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

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

課題

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

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

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

作業に取り掛かろう!

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

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

プロからのヒント:

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

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