プロダクトマネージャーという仕事をしていると、プロダクトに対して大小様々な意思決定を行うことになります。

この意思決定の内容は「プロダクト要求」としてPRDなどの形で1つにまとめていくことになり、プロダクトマネージャーはこれに心血を注ぐことになります。

ですが、このドキュメントは(PMとして)力作であればあるほど、

• レビューコストが非常に高くなり、枝葉末節の議論に留まるか、一方的な共有会として終わってしまう
  → マイナスは防げても、10xを目指すための議論ができない🥲

• PRDの補足説明会が必須となり、結果として伝達コストが上がる
  → 資料がひとり歩きできない。後から振り返るのも困難に🥲

などのジレンマに悩まされます。

なぜこのようなことが起こってしまうのでしょうか？

PRDでは伝えきれない思考過程

PRDを作成する過程では、様々な試行錯誤や意思決定が行われています。
そして、この「過程」が「情報の非対称性」を生み出す原因となります。

このことについて、PRDの「作成者」と「読者」それぞれの視点からみていきましょう。

• PRDの作成者
  → 「結論を導くまでの試行錯誤」を経て「結論が出た後のわかりやすい説明(=PRD)」を行う

• PRDの読者
  → 「結論が出た後のわかりやすい説明(=PRD)」のみを読む

つまり、
「情報の非対称性」 = 「結論を導くまでの試行錯誤」
であり、これが読者は知ることが出来ない「暗黙知」となります。

仮に受発注なプロダクト開発なのであれば、 PRDに加えて要求仕様を作成し渡せば問題はありません。
一方で、内製開発の場合はPRDを元にプロダクトチームにて要求仕様を作成していくことになるため、「暗黙知」も合わせてプロダクトチームに伝えていく必要があります。

この「暗黙知」の伝え方については、

• 適度な贅肉をもたせたPRDを書ける器用なPM

• 圧倒的対面コミュニケーションで解決するPM

• 開発フェーズにも潜り込み、設計等の伴走もするPM

• etc…

など、各PMが得意とする方法によって解決されていることが多いのではないでしょうか？

これ自体に良い悪いはないのですが、PM毎に伝達方法が異なっていたり、コミュニケーション前提での解決としてしまうと、結果として「暗黙知」を「知識」として積み上げていくことができません。

これをなんとか解決できないかな〜と考えていたところ、エンジニアチームが活用していた「ADR」が使えそうかも？というところにたどり着きます。

ADR(=Architecture Decision Records)とは？

ADRとは、アーキテクチャに関する意思決定を記録するドキュメントです。

このADRのフォーマットとしては、いくつかの流派はありつつも基本的には以下のような構成となります。

# Title
意思決定を行う内容を簡潔に記載する

## Date
意思決定を行った日

## Status
- [ ] proposed(提案中)
- [ ] accepted(承認)
- [ ] rejected(否認)
- [ ] deprecated(廃止)
- [ ] deprecated(保留)

## Context
意思決定が必要となった背景や、決定をする目的は何かを記載する
この情報は中立的な視点での事実のみが記載されるように努める

## Decision
決定した内容を記載する

## Consequences
決定がもたらすネガ/ポジ含めた全ての結果をここに記す。

## References
参考資料や関連するPRDRなどを記載する

また、ADRは以下のルールで運用するのが良いとされています。

他にもADRのプラクティスはいくつかあるのですが、開発特有の要素はわずかであり、あくまで意思決定の記録(= Decision Records)を残すための手法であると捉えることもできそうです。

そこで、ADRのコンセプトやプラクティスはそのままに、これをプロダクトマネジメントの領域に転用させた、

プロダクト要求に関する意思決定の記録
= Product Requirements Decision Records
= PRDR

という、それらしい名前をつけて実際に運用をしてみることにしました。

PRDRを運用してみて

まだ始めて2ヶ月弱といったところですが、色々と効果が分かってきたためそれぞれ紹介をしていきます。

😄 「やらない」の意思決定が残るようになった

これが一番大きなメリットでした！

PRDRは「やらない」という意思決定についても記録をすることになりますが、実際に始めてみると想像以上に「やらない」という意思決定をしていることが可視化されました。

また、この「やらない」の意思決定には、今まで表されてこなかった生きた知識が多く含まれていることも分かりました。

そのため、とにかく「やらないの意思決定」は徹底的に残したほうがいいですよ！と、声を大にして伝えたいところではありますが、最初のうちはVOCやセールス要望などを棄却する際にPRDRを残すところからはじめるととっつきやすいかと思います。

なお、「やらない」の意思決定については、「今やらない」のか「ずっとやらない」のかを明記しておくのがよいでしょう。

😄 PMの仕事が可視化される

PMの仕事を可視化するのは案外難しいもので、特に問題領域の特定を行うフェーズにおいては、仕事時間の大半は思考に費やされます。
そのため、思考がまとまってきたタイミングではじめて何らかのアウトプットが出てくるというのも珍しくないでしょう

ですが、PRDRが組織に根付いていれば、思考フェーズからアウトプットが生まれてくるようになるため、PRDRのスペースをウォッチしておくことで他のPMは今なにを考えているのかを可視化することができます。

また、PRDRはPMの思考プロセスが色濃く出やすく、他のPMの脳内を覗き見できる感覚に近いので、これも個人的には面白いな〜と感じています。

😄 「暗黙知」を「形式知」に変換できる

知識創出のプロセスモデルとして「SECIモデル」があります。

プロダクトマネージャーは、日々のリサーチやインタビューによって多くの「暗黙知」を持っていることでしょう。

PRDRを書くことによって、この「暗黙知」の共同化および表出化につながるため、結果として新たな学びを生み出すことにつながります。
(他領域を担当しているPMのPRDRを読むと学びばかりでとてもおもしろいですよ！)

組織として新たな知識を創出していくためにも、PRDRは誰もがアクセス可能な場所にストックし、通知なども駆使して常にみえる化しておくのがおすすめです。

🙂 PRDの品質向上

PRDを作成していく過程でPRDRがどんどんと作成されていくことになりますが、PRDRの時点で適宜レビューを行っていくことで、PRDR単位で先述の「SECIモデル」を1ループ回すことが出来るため、最終的なPRDの品質の向上に寄与できるのではないかと考えています。

また、PRDR単位で細かくレビューを回したうえで、最終的なPRDレビューとすることが出来るため、結果としてレビュアーにかかるコストが下がり、質の高いレビューが出来ることも大きなメリットではないでしょうか。
(巨大なPull Requestのレビューは辛いので、小さい粒度でこまめにしましょうね、と同じようなイメージです。)

ただし、まだPRDR運用を初めて日も浅いため、もう少し運用を続けた上で、改めて評価が出来ればと思います。

🙂 振り返り可能なPRDとなる

「当時なぜそのような要求としたのか？」を振り返るべくPRDを見返しても、ここからは十分な情報が得られず、当時の議事録や開発チケット、Slackなどを懸命に漁った経験のあるPMは私だけではないはずです。

PRDRはあくまでも"軽量な"ドキュメントであり、議事録等の単純な転記であっても問題はありません。

• 定められた場所に、意思決定の記録をストックをしていく

• PRDとPRDRがlinkされる形で管理をしておく

ことが重要であり、これがきちんと運用されていればこれらの問題は解消できそうかな〜と思っているので、こちらについてももう少し運用してみて評価できればと思います。

おわりに

冒頭でも示した上図を借りると、PRDRとPRDは以下のような関係性であるといえます。

• 結論を導くまでの試行錯誤
  → 複数のPRDR

• 結論が出た後のわかりやすい説明
  → 1つのPRD

そして、この2つの資料を組み合わせて管理をすることで、「暗黙知」を減らし、「形式知」として組織に積み上げていくことができます。

もしこのnoteを読んで、「PRDRやってみてもいいかもな？」と思っていただけたのであれば、練習も兼ねて

「PRDR(=Product Requirements Decision Records)を導入する」

といったタイトルで作成してみるのはいかがでしょうか。

もし実際にやってみた！という方がいらっしゃいましたら、ぜひ感想など教えていただけると嬉しいです。