はじめに
この記事は、ミロゴス Advent Calendar 2023 12日目の投稿です。
現在においても、様々なしがらみから複数社が関わる比較的大きなシステム開発プロジェクトは存在します。
当社も御多分に洩れずです。
そのような開発プロジェクトにおいては、ステークホルダーとの合意形成が特に重要となります。
その際に役立つプロダクト要求仕様書（PRD - Product Requirements Document）と呼ばれるものについて書きたいと思います。
本記事ではPRDの概要、12/19予定の記事では、PRD作成の手順やいくつかの具体例を提示できればと思います。
プロダクト要求仕様書とは
PRDは、プロダクト開発を始めるにあたって、どのようなものを作るのかを定義したドキュメントです。
主にプロダクト開発の責任者となるプロダクトマネージャーやプロジェクトマネージャーが主導して作成し、開発の基本方針として示すものです。
PRDの目的
PRDはプロジェクト全体の要件と期待値を定義し、ステークホルダーが一貫した理解を共有するために以下のような目的のために存在します。
共通言語の提供
PRDは、プロジェクト関係者が共通の言語でコミュニケーションを取るための基盤を提供します。
異なるバックグラウンドや専門知識を持つ関係者でも、PRDを通じて統一された理解を築くことを目的とします。
プロジェクトの方向性の確立
PRDはプロジェクトの目標や方向性を具体的に示すため、関係者がプロジェクトの全体像を理解しやすくします。
プロジェクトメンバーが目標に向かって一丸となって働けるようにします。
変更管理のための基準
PRDは変更が発生した際に、それがプロジェクト目標や要件にどのような影響を与えるかを明確にするための基準として機能します。
変更が発生した場合、プロジェクトメンバーはPRDを参照して影響を素早く確かめられるようになります。
PRDの有用性
PRDは完成したドキュメント自体が有用なものですが、これを作り上げるために素案を元に各ステークホルダーの意見を汲み取り、利害関係の調整と合意形成をはかる過程そのものが大きな価値になります。
プロダクト要求仕様書の内容
PRDの項目
PRDに記載される内容は組織やプロジェクトの特性によって違いがありますが、一般的に記載される内容には以下のようなものがあります。
プロダクトの概要・背景
そのプロダクトは何を為すべきためのものなのか、必要となる背景は何なのかについて記載します。
プロダクトビジョン・コンセプト
プロダクトが実現する世界観、生み出す価値について記載します。
プロダクトの概要・背景に書かれた問題点や新たな発想を元に、プロダクトが体現する事象を端的な言葉で表現します。
さらに、そのビジョンを実現する主な特徴を数個コンセプトとして記載します。
製品原則（プロダクト・ プリンシプル）
プロダクトビジョン・コンセプトをもとにして、プロダクトが特に重視して実現・遵守すべき事項を記載します。
特にプロジェクトやシステムの実装には、QCDをはじめとして多くのトレードオフが発生します。
製品原則は、要求にトレードオフが発生した際の判断の拠り所となります。
スコープ
プロダクトおよびその開発プロジェクトが実現対象とすべき対象範囲について記載します。
プロジェクトは有限の活動であり、その範囲内で実現できる内容には限りがあります。
やるべきことと共にやらないこと、対象外とすべき事項も明確にしておきます。
想定ユーザーとユースケース
プロダクトを使用するユーザーやその周囲を取り巻くステークホルダーを明確にします。
ユーザーが達成しようとしている目的や重要度をユースケースとしてまとめ、「誰が、何を、何故」行うのかを明確にします。
市場・競合分析
プロダクトを取り巻く環境やニーズを明らかにし、市場優位性を確保してプロダクトがビジネスの成功に寄与することを明確化します。
機能要求
プロダクトが実現すべき主な機能について記載します。
具体的なソリューションに寄りすぎず、主としてユースケースを果たすためには何が必要かという観点で記載します。
具体的なシステム仕様は後のシステム開発プロセスの工程で定義します。
UX要求
使いやすさ（目的の達成のしやすさ）を実現するためのユーザー体験に関する要求事項について記載します。
プロダクトの特性に応じて、ユーザーの体験上何を重要視するのかを明らかにします。
効率性の追求なのか学習のしやすさなのか、アクセシビリティにどの程度配慮するのか、機能性と速度どちらを重視するのか、などです。
ユーザーインターフェイスのデザイン方針に影響を与えます。
非機能要求
セキュリティやプライバシー、パフォーマンスなどシステムの特性として満たすべき機能以外の要求について記載します。
RASISなどのシステム評価指標、CIARAなどの情報セキュリティ要素の観点も含めて、どの程度のレベルを実現するのかを検討します。
プロダクトの特性やプロジェクトにかけられる費用や期間の関係で、この項目にもトレードオフが多く存在するため認識の共有が大切です。
開発計画
開発体制、マイルストーンなど開発に関する計画事項をまとめます。
複数社や複数チーム体制で開発を行うような場合はアーキテクチャーや開発上の方針を定めてある程度の統制をとる必要があります。
販売計画
マーケティングや販売戦略など、プロダクトを広め、販売し、ビジネス価値を生むための計画事項をまとめます。
PRDの本文記述に関する留意点
記述の観点
PRDにはステークホルダーが期待する結果や成果物に関する情報を含めることが重要です。
これによってステークホルダーがプロジェクトの進捗や成果を評価する基準が明確になります。
期待値を具体的に記述することで、コミュニケーションが円滑になり、開発チームが期待通りの成果を提供しやすくなります。
また、期待値が変更された場合には、変更がプロジェクトに与える影響を正確に把握できるようになります。
これらの項目をPRDに含めることで、プロジェクトの目標達成に向けてより効果的なシステム要件定義と開発が可能となります。
柔軟性
プロジェクトはその規模や内容に応じて異なる特性を持つため、項目や記述のテンプレートは変更や追加に柔軟に適応できるようにする必要があります。
新規に開発するプロダクトであれば、プロダクトビジョン・コンセプト、ユーザー分析、市場・競合分析や販売計画を厚めにし、よりプロダクト・ソリューション・フィットやプロダクト・マーケット・フィットを果たすことを重視すべきでしょう。
既存システムのリプレイスのような開発であれば、既存業務性の維持を前提として弱みを潰しつつ新たな強みを追加補強する形で製品原則、機能要求、UX要求、非機能要求を整理し直すことに重点を置くことになるでしょう。
明確さ
各項目の内容は、誤解を避けステークホルダーが内容を理解しやすくするように明確かつ具体的に記述する必要があります。
特に同じ単語でもそれぞれの立場で違う捉え方がされるような用語や、個社特有の表現や文化によって一般的な使い方ではない用語は避けるか十分な補足を行うべきです。
ステークホルダーとの関係性
PRDはプロジェクトのステークホルダーと十分に共有されるべきです。
ステークホルダーがPRDを理解し、フィードバックを受けられ、議論がより促される媒体として機能させる必要があります。
共有や読み合わせを積極的に行い、そこで生じた議論や意思決定については理由を明確に残すことで、変更管理のトレーサビリティーを向上させます。
定期的な更新
プロジェクトが進行するにつれてPRDの内容にも変更が入ることがあります。
ドキュメントは定期的に更新され、最新の情報を反映するように管理されるべきですが、プロジェクト全体の拠り所となるPRDは特にその重要性が高くなります。
このあたりは、ADR（Architecture Decision Record）のようなアプローチとも絡めて変更判断のトラッキングができるようにしていくとよさそうです。
おわりに
今回はPRDについての概要編として項目のアウトラインや記述の留意点について触れました。
PRDで検索をかけるといくつかの情報が見つかりますが、それらも取り込み解釈して自社用にまとめなおしたものを元に本記事を作成しました。
ミロゴスでの実際の記述・運用は、NotionのWikiとデータベースを使って行っています。
次回の記事では、実践編としてその構成や内容など開示できる範囲でお伝えできればと思います。