PRD（プロダクト要求仕様書）をエンジニアが書く！エンジニアとPdMの分業体制
クラウドセキュリティ製品 Cloudbaseでプロダクトマネージャーをしている大峠 (@0meo)です。
Cloudbaseでは、ソフトウエアエンジニアが “プロダクトエンジニア” として機能設計の上流から関わります。
本記事では、弊社が1つの機能を開発着手可能にするまでに実施するドキュメンテーション手法のノウハウと、プロダクトエンジニアとPdMが分業しながら権限委譲を進めた過程についてご紹介します！
この記事を書いた人
大峠 和基（おおたお かずき）
Cloudbase 株式会社 PdM
筑波大学大学院卒。学生時代からスタートアップ企業で研究論文の執筆や特許の出願に関わる。自動生成動画AIのサービスを開発して起業し、未踏事業スーパクリエータ認定及び未踏アドバンスト事業イノベータ認定を受ける。 2023年1月よりCloudbaseにジョイン。プロダクトマネージャーとして、データ分析やユーザーヒアリングを基にした、製品のロードマップ策定や機能設計に幅広く従事。
Cloudbaseのプロダクト組織について
分割手法のコンセプト
「新しい機能を開発してください！！」
さて、このとき皆さんが開発着手するためには何が必要ですか？一般的にはPdMがPRD (Product Requirements Document)を用意することが多いと思います。PRDは日本語でプロダクト要求仕様書のことで、以下のような内容を含みます。
1. 概要
2. 背景
3. 製品原則
4. スコープ
5. 対象ユーザー
6. ユースケース
7. 市場分析
8. 競合分析
9. 機能要求
10. UX要求, UIモックアップ
11. 技術的要求 (システム要求、セキュリティ要求、プライバシー要求、パフォーマンス要求）
12. リリーススケジュールおよびマイルストーン
https://www.slideshare.net/takoratta/qiita-increments
PRDは組織によって書くべき内容は変化しますが、上記の項目に従えば、プロダクト（1つの機能も “小さなプロダクト” とみなしましょう）に対して3つの観点が含まれていることが分かります。
Why: なぜこの機能を作るべきか
What: この機能はどんなものか
How: どうやって機能を実現するか
Cloudbaseでは、1人のPdMが1本のPRDを書き切るのではなく、PRDを分割するという手法を取っています。
Why: Experimental Design Document (実験設計書)
What: Requriements Document (仕様書）
How: System Design Document (システム設計書)
Experimental Design Documentは実験設計書のことで、「仮説、背景、根拠、提案機能のイメージ図、ユーザーストーリー、計測指標」を含みます。実際に使用しているテンプレートを以下に示します。
Requriements Documentは一般的に馴染みのある仕様書です。「UI、ユーザーフロー、詳細な挙動、データ、ログ、リリースフローやFeature Flag」などの内容を含みます。
System Design Documentはシステム設計書のことで、コーディングやコードレビューを行う前に実装の方針を議論します。
このように、PRDに記述されうる情報を「Why・What・How」で分割し、それぞれを順番に執筆および議論していくという手法で進めています。
分割手法のメリット
PRDという確立されたフレームワークを崩すことに疑問が生じるかもしれませんが、この分割手法にはいくつかのメリットがあります。
手戻りを防げる
PRDを一通り書いた後にレビューをしたとしましょう。このとき、「なぜやるか、その根拠は何か」のWhyの部分で議論が発生したとします。仮に議論によって結論が変わってしまった場合、その章以降の執筆分はやり直しになってしまいます。なぜなら、Whyが変わればWhatも変わり、Why・Whatが変わればHowも変わるからです。
これらをシーケンシャルに議論 & レビューをしていくことで手戻りを防げます。
また、戦略レイヤーから戦術レイヤーへと遷移していくにつれ細かい議論点が増えていきますが、「これは後方のドキュメントで考えることにして後回しとし、まずは上流の議論を整理しよう」と現在のレイヤーにフォーカスして論点を整理することができるのも良いポイントです。執筆者だけではなく、ドキュメントをレビューするレビュワーにとっても、スコープが切られているためにレビュー時の認知負荷が小さくなるというメリットがあります。
途中まで進めても良い / 途中で辞めても良い
「とりあえずExperimental Design Documentを書いて仮説や価値の妥当性を検証してみるが、そこから先は検証の結果によって、よりリソースを投下するかどうか考える」「Requriements Documentまでを書いてソリューションを明確にはするが、実装に踏み切るかどうかは社内のリソースやロードマップを鑑みる」という判断を早いタイミングで行うことができます。
Experimental Design Documentの時点で「そもそもここに課題は存在しないのではないか？この課題を解決することに価値はないのではないか？」ということに気付いてそれ以降を取りやめることができれば、多くの工数を救うことができます。また、一旦Requriements Documentを書いておき仕様の理想形を作り上げておくことで、別機能の設計時などに技術負債を産まないよう考慮しながら開発を進めることもできます。
関心を分解できる
「関心のある人が関心のあるドキュメントだけを見れれば良い」という状態を実現できます。例えば、データアナリストや営業、カスタマーサクセスの方々にとっての主たる関心はExperimental Design Documentの部分です。その機能がどんな背景によって作られ、何の価値があり、プロダクト組織として何を検証したいのかを知ることができます。Biz組織のメンバーにとっては訴求点をどこにおくかのヒントにもなるでしょう。QAエンジニアにとっての主たる関心はRequriements Documentの部分です。前後のドキュメントもコンテキストを知る上で参照はするでしょうが、特に読み込むべきドキュメントはどれかと言われるとQA項目を作る際のマスターになるRequriements Documentでしょう。コードレビューを行う別チームのエンジニアや、後から関連領域の新規機能開発をするエンジニアが見るべきはSystem Design Documentになるかと思います。
組織に多様な役割のメンバーが増えていくに従って、「主たる関心の内容はこのドキュメントを見れば良い」とドキュメントが分割されていることのメリットを実感できる機会は増えていくと感じています。
執筆者とレビュワーを分けることができる
PRDを3つに分けることで執筆者とレビュワーを分担することができます。例えば、Cloudbaseでは以下のような分担をしていました。
執筆者とレビュワーの担当分け（過去のもの）
例えば機能の「Why」部分にあたるExperimental Design Documentはチームメンバー全員でレビューしますが、仕様にあたるRequriements Documentは実装担当のエンジニアがレビューする、といった具合です。
執筆を分担し、適切なメンバーのみがレビューすることで最小工数でドキュメンテーションを行うことができます。
進捗管理や工数管理がしやすい
機能ごとにどこまでドキュメンテーションが終わっているか、実装着手までにどれくらいかかるのかを把握することが簡単です。
進捗管理の例
System Design Documentまであることが実装可能な前提ですので、例えば実装未着手のSystem Design Documentの数が少なくなっていれば、手を動かすエンジニアへの作業依頼が滞ってしまうなということに早めに気付くこともできます。
2週間1スプリントのようなスクラムを組んでいる場合、「次のスプリントでPRDを書き切る！」よりも「次のスプリントでRequirements Documentを書き切る！」の方が細分化されたタスクとして表現できるため、より作業量の見積もりと実績の精度が向上するでしょう。
並列度とリファインメント
さて、上記の「分割手法のメリット」では、ドキュメンテーションの工程を直列で表現し、前段のレビューが終わらなければ後段のドキュメントに進めないことを示していました。しかし、実運用においては必ずしも直列ではありません。
並列度
機能や施策によっては、Why・What・Howの解像度が十分に高いことがあります。その場合、ドキュメンテーションのレビュー工程を直列に行うのではなく、Experimental Design DocumentとRequriementd Documentをそれぞれ別の担当者が同時に執筆を進めたり、前段のドキュメントのレビューを待たずして後半のドキュメントの準備を始めることができます。
例えば背景や課題に対する解像度が十分に高いという前提のもとで、定量・定性的根拠の改めての洗い出しや計測指標の設計を行いつつ、ソリューション部分の仕様書やUI Mockを同時に作っていく、というイメージです。もしくは、仕様書の設計をしながらも、システム設計を同時に固めていくというようなこともできるかもしれません。重要なことは、前段ドキュメントのレビューが終わり承認が得られるまでは前提条件が固まらないので、後段ドキュメントの内容がひっくり返る可能性がなきにしもあらずである、という認識を揃えることにあります。
このような形で並列度を上げる試みができるようになれば、ドキュメンテーションのスループットを上げることができ、短い期間でPRDの内容を完成することができます。
リファインメント
その機能に対するWhy・What・Howの解像度が比較的低い際には、一度レビューを終えている場合でも、後段のドキュメントを再度修正するということもあります。
例えば、Requriements Documentで良いソリューションを磨き込んだ後、System Design Documentを検討した際に実装上困難な都合があることが分かり仕様を変える、というケースがイメージしやすいかと思います。また、ソリューションを考える中で「前段のWhy部分とずれたソリューションができてしまった。これはWhyに合わせて適切なソリューションとなるよう調整するべきか、それとも実はWhyの部分の議論が甘かったのではないか」という議論が発生することもあります。
1工程ずつレビューを行うことで手戻りを防ぎ、個々の関心レイヤーにおいて最適な結果を出すというのがこの手法のコンセプトですが、必ずしも手戻りを許さないというわけではなく「リファインメントが発生することもある」という認識は持っておいて良いでしょう。
CloudbaseにおけるPRD体制: プロダクトエンジニアが上流に関わる
これまでPRDを3つに分割することで享受できる、様々なメリットついて解説しました。上記で述べたように、Cloudbaseではドキュメンテーションにおいて以下のような分担をしていました。
表: 執筆者とレビュワーの担当分け（過去のもの）
このような体制が敷かれる以前は、機能を量産してしまったことによって後から悩まされる「仕様負債」が課題になっていました。これらのドキュメンテーション手法が浸透するにつれ、後から不要になってしまうような開発機能が発生しづらくなったと感じます。実際に最近入社したメンバーやトライアルワークをされた方からも「スタートアップのこの初期のフェーズで、ここまでドキュメンテーション体制が整っていることはすごい」と言われることが多いです。
ところで、Cloudbaseは事業上以下のような特徴を抱えています。
クラウドやセキュリティに関するドメインであるため、エンジニアがドメインエキスパートを兼ねている
SIerやオフショアなどの外注を使っておらず、内製化100%である
PdMが1名以下である
このような特徴によって、組織の初期フェーズからエンジニア側がより上流に関わっていくという力学が発生していました。
そこで、社内に対して「全員PdM宣言」というものを行いました。これはソフトウェアエンジニアに対して “プロダクトエンジニア” として、ジュニアPdMないしはTech PdMとしての期待値があることを明確に示し、今までPdMが担っていた、本来PdMが担うべき役割を権限委譲していきましょうという宣言です。以前から実態としてはエンジニアがPdMやTech PdMのような振る舞いをしていましたが、宣言によって明示的に定めました。
この宣言以降、役割分担は以下のように遷移しています。
表: 執筆者とレビュワーの担当分け（現在のもの）
まず、PdMはRequriements Documentを書かないという取り決めになりました。通常、PdMが責任を担うPRDのうち、 “Requirements” に該当する部分をPdMが書かないのは大胆でUnlockな体制かと思います。代わりにエンジニアとデザイナーがオーナーを持ち、PdMが議論への参加やレビューを行います。
また、背景仮説部分に相当するExpeirmental Design Documentについても、実装担当のエンジニアが書くことが増えました。ここに関しては完全にPdMが書かないということではないものの、エンジニアが書く場面が増えている状態です。今では、エンジニアがジュニアPdMレベルの仮説検証を自分たちで回せるような状態を作ってみる、という試みを行っています。
これらの担当分けがうまくいった現在では、PdMとプロダクトエンジニアは以下のような棲み分けができています。
PdM: 全体のプロダクトビジョン・NSMに責任を持ち、ロードマップやバックログといったツールでリソース配分を行う
プロダクトエンジニア: 1機能に対して仮説や根拠の議論、仕様設計やUI設計、システム設計にまで責任を持ち、検証とデリバリープロセスを回す
このように段階的な権限委譲が可能になったのも、元々PRDを3つに分解する手法を取っていた体制が大きく寄与した結果であると考えています。
各種ドキュメントを公開します！
ここまでご説明してきた、「Experimental Doc」「Requirements Doc」「Design Doc」を公開します。
まとめ
本記事では、一般的なPRDをWhy・What・Howからなる3つのドキュメントに分解することで、関心事によりフォーカスしながら手戻りを防ぐことのできるドキュメンテーション手法を紹介しました。提案手法を使うことによって、ドキュメンテーションの担当者を細かく分担したり、それによってドキュメンテーション工程のスループットを上げることもできます。
また、このドキュメンテーション手法の責任範囲を徐々にソフトウェアエンジニア側に任せていくことによって、ソフトウェアエンジニアが “プロダクトエンジニア” として、プロダクト開発の上流から関わることができるようになったという弊社の体制事例をご紹介しました。最終的には、PdMとプロダクトエンジニアが協調しながらプロダクト開発を前に進めていけるような役割分担が実現しています。
さて、このように素早く正しく価値を届けていきたいと考えている私達と一緒に、最高の価値提供をエンジニアリングで実現していきませんか？私達の実現したい世界のうち、達成状況は現状5％ほどの感覚で、クラウドセキュリティという広い領域において挑戦したいことがたくさんあります。
そこでCloudbaseでは、ソフトウェアエンジニア・プロダクトエンジニア・PdMを募集しています。エンジニア組織だけではなく、チーム間の連携を分担するなど様々な形でのPdM組織のスケールへも念頭に置いています。
上記の内容に興味を持たれた方、より深く話を聞いてみたいと感じた方、弊社CTOの宮川がカジュアル面談を実施していますので、ぜひ下記のリンクよりお問い合わせください！
この記事が気に入ったらサポートをしてみませんか？