■ 1. 記事概要
- 著者: 岩佐幸翠（kosui）、テックリード @ 株式会社カケハシ
- 公開日: 2024年6月12日
- 主張: 網羅的なドキュメントを書いて非同期レビューを行う従来のアプローチより、関係者と同期的に対話しながら観点・選択肢・トレードオフを洗い出す方が、より少ない手数でより良い答えが得られる
■ 2. 従来のアプローチの課題
- PRD・Design Docの従来の役割:
- PRD: 意思決定（要件）と背景・トレードオフ（環境要因）の記録
- Design Doc: 意思決定（設計）と背景・トレードオフ（品質・性能・セキュリティ）の記録
- 作成後に関係者へレビュー依頼し合意形成を図る
- 理想と現実のギャップ:
- 理想: 網羅的ドキュメントが議論の最適な叩き台となる
- 現実: 情報量の多さがレビュワーを圧倒し、形式的な承認に終わる
- レビュワーは自分に関連する部分のみコメントし「全体としてはいいですね」と返答する
- 致命的な欠陥はPRレビュー・デモ・顧客からの問い合わせの段階で初めて発見される
- ビルドトラップへの陥落:
- 「次はより綿密に、レビュープロセスをより厳密に」という負のループが生まれる
- 多くのドキュメントを作成・レビューしても、関係者間のコンテキスト共有と問題発見に結びつかない
■ 3. 解決策
- より早期の関係者との対話:
- RDRAやモブプログラミングなどの手法を活用し、対話しながらトレードオフと選択肢を段階的に洗い出す
- レビュー段階で大量のSlackコメントを積み重ねることなくコンテキストを関係者と共有できる
- 重要な観点への議論の集約:
- プロダクトや機能によって重要な観点は異なる
- 網羅的フォーマット（PRD・Design Doc）は参考になるが、すべてを記載する必要はない
- プロジェクトごとに本当に必要な観点に焦点を当てる
- 適切なドキュメント形式の選択:
- ADR（Architecture Decision Record）が有効な形式として紹介
- 構成要素: 議論の背景、論点、決定事項、決定による影響（当時の想定）
- タスク所有者が事前に「背景」「論点」を準備し、カレンダーのイベントにドキュメントリンクを添付することで対話を効率化できる
■ 4. 結論
- ドキュメント作成・合意形成プロセスではなく、対話的な議論にフォーカスすべき
- ドキュメントは議論の出発点ではなく終着点として機能すべき
- 対話的な議論を重ねた結果として、意思決定とその背景がドキュメント化される順序が重要
■ 5. 補足・注意事項
- 議事録をそのまま残せば十分という主張ではない
- プロダクト・機能ごとに重要な観点を選別し、選択肢とトレードオフを含めた意思決定を後世に伝えるドキュメント作成は依然として必要
- ドキュメント形式はPRD・Design Docに限定されず、ADRなど目的に応じた形式を選択すべき