はじめに
この記事は、ミロゴス Advent Calendar 2023 19日目の投稿です。
12日目の投稿では、プロダクト要求仕様書（PRD - Product Requirements Document）の概要編をお届けしました。
今回は詳細編として、ミロゴスにおけるPRDの整備方法や過程をお伝えします。
Notion Wiki & データベースの活用
PRDは開発以外のステークホルダーも目を通す場所ですので、全員のアクセスのしやすさと編集・管理のしやすさが必要となります。
ミロゴスでは、開発目的にはDocbaseやClickUpのDocs、グループ間のドキュメント共有にはGoogleドキュメント、社内のナレッジ蓄積ではNotionが使われています（元々はDocbaseを全社的に使用していて、途中からNotionに切り替わりました）。
現在はPRDの内容の管理や検索性から見て、ページとデータベースの中間の特性を持つNotion Wikiが適していると判断し、これを用いて構築しています。
併せて、PRDを仕上げていく過程の記録等も含めて情報を残していくことや、PRDを起点としてビジネス要求やシステム要求を管理するNotion DBも設置することで情報の追跡性をあげています。
PRDのページ配下の構成は以下のようになっています。
イントロダクション、Why、What、Howにわけ、PRDの各項目を1ページとして該当する区画に割り振っています。
PRDの作成手順
現在ミロゴスではあるプロダクトのリニューアルに取り組んでいるので、それを例としてPRDの作成手順を示します。
リニューアルであること、予算獲得活動の資料範囲で市場・競合分析や販売計画は盛り込まれていたことから、PRDの見出し項目は調整しています。プロジェクトの目的や規模によってこの辺りは適宜カスタマイズしてください。
コンセプト・プロダクトジョン / 製品原則
まずは何よりも事業の方向性と現状の課題を抽出し、それが解決した上でプロダクトが体現する未来=ビジョンを定めます。
同時にビジョンを達成していく上での重視する観点をコンセプトとしてまとめます。
続いて、各コンセプトの出発点になった既存システムの仕様と問題点から、目指すべき状態の観点= 製品原則を定めます。
コンセプトから地続きの方が内容を参照しやすいことから同一ページに記述しています。
対象ユーザー
ミロゴスはセプテーニホールディングス配下にある会社です。LINEのプラットフォームを活用してのサービスを展開しています。LINE公式アカウントを持つ企業様、その企業様のアカウントと友だちになっているエンドユーザー、企業様とミロゴスを繋いでくださる代理店企業様、開発に協力してくださるベンダー様など多くのステークホルダーが存在します。
それらの関係性を図に表し、どのような利害関係があるのかを明らかにします。その上で、開発するシステムが特に対象とすべきユーザーは誰なのかを定めます。
直接システムに関わるユーザーのみだけではなく、その周辺も捉えておくことで、どのような背景や目的からシステムが使われるのかをできるだけ正確に判断できるようにします。
スコープ
リニューアル（リプレイス）開発の場合は、特にどの範囲を開発するのか、有限のプロジェクト活動においてその前後の状態がどうなるのかをある程度明らかにしておく必要があります。
開発（再構築）方針やアーキテクチャー基本方針など、開発のHOWとも関わる部分なので、相互に検討しながら精度を上げていきます。
更にシステム特性からみた除外事項や成果物、開発に複数社が絡む場合は受け入れの基準を定めておきます。
各社調整が必要で一度には定義しきれない部分も出てくるので、検討を進めながら埋めていきますが、ある程度の観点は初期に定義しておいた方が議論しやすくなります。
機能要求
プロダクトが備えるべき機能を書きます。
ある程度の論理構成が見えている場合は、構成図やドメイン単位の概要・制約事項なども記述しておきます。
最後にビジネス要求、システム要求のNotion DBのビューを貼っておいて、連動できるようにしています。
UX・セキュリティ・パフォーマンス要求
非機能要求系の元になる内容は1ページにまとまっていた方が見通しがよいのでまとめて記述しています。
細かい非機能要件というよりは、それを決定していくための基本方針となる内容の記述レベルにとどめています。
例えばセキュリティ要求であれば以下のような内容を記述しています（各項目から抜粋）。
- アクセス制御・認証
- システムへのアクセスは、ユーザーの役割に基づいた最小の権限に基づいて行われるものとする。
- サブシステム間のアクセスは、経路・方式を厳密に定義し、インターネット上から不用意にアクセスされないよう対策する。
- データの暗号化
- システムに保存される機密データは適切な暗号化アルゴリズムを利用して暗号化するものとする。
- 脆弱性対策
- システムにおける脆弱性の評価及び修正を定期的かつ継続的に実施する。
- 機械的な第三者脆弱性診断を継続する。
- ミドルウェア類は定期的かつ継続的に実施する。
- SBOMへの対応準備を行う。
- システムにおける脆弱性の評価及び修正を定期的かつ継続的に実施する。
- ログ管理および監査
- システムおよびアプリケーションは適切なログを生成し、これらのログは機密性、整合性、可用性を担保した上で保管する。
- 個人情報保護
- 本システムは個人情報および個人関連情報を扱うため、個人情報保護法に準拠して必要なセキュリティレベルおよびデータ管理レベルを提供する。
開発（再構築）方針
リニューアル（リプレイス）開発においては、どのように開発を行うべきかの方針をいくつかの大方針から決定する必要があります。
この分野に関しては、IPAのシステム再構築を成功に導くユーザガイドが観点として参考になります。
ソフトウェア・アーキテクチャー基本方針
インフラやプログラミング言語、フレームワークの選定や利用方針、システム関連系の方式など、各開発会社や開発者に守ってもらう基本的な方針を定めます。
開発の規模や関係会社の数によっては、内容が多岐に渡ったり、会社の得意不得意によって調整しなければならない事項が多くなるので、議論のための観点出しを重視しつつ定めていきます。
開発計画（体制・人員・工程）
体制や工程の定義、会議体の設定など、ステークホルダーを含めたプロジェクトの進行計画を定めます。
特に規模が大きくなる場合は、プロジェクトをいくつかのフェーズに分け、フェーズ毎に重視すべき点やチェックポイント・ふりかえり機会を設けたり、会議体を調整したりできる余地を残しておきます。
ビジネス要求への紐付け
システム開発を円滑に進めるにあたっては、システムを必要とする背景が含まれるビジネス要求をとりまとめたもの、その要求に基づいてシステムが果たすべき振る舞い=システム要件をとりまとめたものが必要になります。
PRDは何らかのビジネス要求に基づいて定められるものであり、また、PRDの詳細化はビジネス要求を明らかにしていく過程でもあります。
この関係を追跡可能にし参照しやすくするため、ミロゴスではNotionのデータベースを活用しています。
- ビジネス要求ID：固定のIDを自動付与するNotion DBの機能を利用しています。
- 分野タグ：開発するシステムにいくつかの業務分野があるため、それを整理するためのタグを付与しています。
- タイトル：タイトルです。
- 主なステークホルダー：その要求に関する主なステークホルダーを設定します。
- 出自：要求の出元になった情報への参照や内容を記載します。PRDの見出しリンクが出自になる場合もあります。
- （要求区分フラグ）：要求のレベルを分けるためのフラグです。チェックボックスで選択します。
- 経営・ビジネス要求：
- 業務・ステークホルダー要求：
- 実現手段・ソリューション要求：
- 優先度：要求の実現優先度を選択します。
- システム化要求：Notion DBには他のDBへのリレーションを設定することができ、相互に行き来ができます。ビジネス要求に基づきシステムが果たすべき要求を更に詳細化します。
これらの項目は、IPA ユーザのための要件定義ガイドやBABOKなどの内容を参考に定義しています。
システム要求への紐付け
ビジネス要求を元にシステムの振る舞いに関する要求への詳細化と関連付けを行なっています。
- システム化要求ID：固定のIDを自動付与するNotion DBの機能を利用しています。
- 分野タグ：開発するシステムにいくつかの業務分野があるため、それを整理するためのタグを付与しています。
- 要求区分：機能要求か非機能要求かの選択です。
- 要求種別：非機能要求時のRASIS特性選択です。
- 優先度：要求の実現優先度を選択します。
- タイトル：タイトルです。
- ビジネス要求：ビジネス要求DBへの紐付けです。要求の出自として扱います。
おわりに
PRDの詳細編として、Notionでの管理方法や作成の手順から要件定義への繋げ方について触れました。
システム開発の保守運用やリプレイス時に困ることは、システムの意図や方針、意思決定過程が残されておらず不透明であることです。
PRDは開発プロジェクト以後の保守運用や次の大きな改修が必要になった際にも、それらを残すための手段のひとつとして有用なものになります。
ちょうどいいレベル感とメンテナンス性を確保したPRDを目指して、今後も改善を重ねていきたいと思います。