- 2024/06/12 16:16
結論を追記 - 2024/06/12 20:29
より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 - 2024/06/13 20:39
結論にフロー情報・ストック情報に関する意見を追記
結論
この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。
ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォーマットだと思う。
ちなみに、この記事では「議事録などのフロー情報をそのままドキュメントとして残せば十分だ」という主張はしていない。考古学をしようとしたら「ミーティングの場で書かれた箇条書きの羅列でしかない議事録」ばかりが出てきて閉口したことは誰だってあるだろう。プロダクトや機能ごとに重要な観点を選んだ上で、それに対する選択肢とトレードオフを含め、どんな意思決定がされたのかを後世の人や数年後の自分に伝えられるようなドキュメントは依然として必要である。
課題: ドキュメントの執筆と合意形成のビルドトラップ
私は、PRDもDesign Docも、意思決定とその背景やトレードオフについて関係者間で合意するために書いていた。
- PRD
- 意思決定
要件 - 背景・トレードオフ
要求や競合事例などのプロダクトを取り巻く環境
- 意思決定
- Design Doc
理想: 完璧で網羅的なドキュメントと厳密なレビュー
あらゆる観点を網羅的に記載したドキュメントは、一見すると議論の叩き台として完璧に見える。
だが、人間の脳みそにあるワーキングメモリのサイズには限りがある。これらのドキュメントのレビュワーは、その情報量の多さにウッとなるだろう。そして、自分にとって関係がありそうな部分だけピックアップしてコメントしてから、Slackに「ありがとうございます！全体としてはめっちゃ良い感じです！」と書き込むだろう。
結局、彼らが要件や設計に致命的な欠陥を見つけるのは、きっと「これさえマージすればリリースできる！」というプルリクエストをレビューしようと実装を眺めた時か、満を持して行われたデモを見ている時か、何なら顧客からの問い合わせを確認する時だろう。
担当者もレビュワーも、きっと「あれほどたくさんの観点を洗い出したのに！」「あれだけたくさんの選択肢を綿密に洗い出したのに！」と口々に叫ぶだろう。そして次に「もっと綿密に観点と選択肢を洗い出そう！」「レビュープロセスを厳密化しよう！」と言うだろう。
現実: 増大する作業に見合わない成果
しかし、どんなに綿密に準備してレビューしても、結局そんな膨大な情報量をレビューできる人間なんてそもそも存在しない。私も「次回からはこの段階のレビューに私も混ぜて下さい！」と叫んだことはあるが、そのレビューで思うような成果を私が発揮することはついになかった。
たくさん機能をリリースしても顧客は増えないように、たくさんドキュメントを書いてレビューしても関係者間でコンテキストを共有し問題発見へ結びつけることはできない。いずれにしても、私はビルドトラップにハマっていた。
解決策
より早期に関係者と対話する
RDRAやモブプロなどを活用し、対話しながらトレードオフと選択肢を洗い出していくことで、レビューの段階でSlackのスレッドに嘘みたいな量のコメントを積み重ねなくてもコンテキストを関係者と共有できる。
重要な観点に議論を絞る
競合分析の章に大したことが書いてないPRDが生まれる原因は、その人の怠惰さではなく、あらゆる観点を網羅的に考える必要性の薄さにあるだろう。プロダクトや機能によって重要な観点とそうではない観点がある。PRDやDesign Doc、または非機能要求グレードなど、網羅的な観点が記載されたドキュメントフォーマットは大いに参考になるが、わざわざそれに従って全てを記載する必要は無い。
議論のためのフォーマットを選ぶ
例えば、アーキテクチャに関する意思決定についてはADR(Architecture decision record) が有用だ。議論のための背景、論点、決定された事項、その決定によってどんな影響がある(と当時は考えていた)のかを記すフォーマットだ。タスクのオーナーはあらかじめ「議論のための背景、論点」について列挙できる部分は列挙しておき、Googleカレンダーの予定にそのドキュメントへのリンクを貼ると良い。
まとめ
つまり、「PRD」や「Design Doc」を"書く"ことや関係者間で"合意形成"することにフォーカスするのではなく、対話的な議論にフォーカスするのが望ましい。そして、対話的な議論を重ねた結果として、意思決定やその背景がドキュメントへ記録されるのだ。
