プロダクトマネージャーの必須スキル: デザインドックの書き方 - Design Doc

私 (@kossmori) が働くアメリカのスタートアップでは、どんな会話においても ”Is there a design doc?” (デザインドックはないの?) という質問が連発します。

会話のコンテクストを合わせるため、取り組みの背景を理解するための必須資料として位置づけられています。

6月21日 追記: なんとNote 公式に取り上げられてしまった！思った以上に反響あり驚きました。 質問等ありましたら、お気軽にご連絡ください(@kossmori)。フォローいただけたら次を書く力になるのでとても嬉しいです。よろしくお願いします。

どれほど重要なのか

デザインドックはこれから行う取り組み (実験、実装、プロジェクト、プロセス改善) の基本的な要点をまとめたドキュメントで、オーナーはプロダクトマネージャーです。

プロダクトマネージャーとしての考えをチームに伝え、合意形成をとるための必須ステップで、多くのアメリカのスタートアップでは、これを書くことが全ての取り組みのスタート地点です。デザインドック無しには何もプロジェクトが動きません。

私もプロダクトマネージャーとして過去4年半、週に1つ以上はデザインドックを書いていて、これまでで250以上書いたことになります。

デザインドックを中心としたワークフロー

ワークフローはプロダクトマネージャーがデザインドック(Ddoc)を書き、チームにシェアすることから始まります。

「まだまだ超ドラフトのデザインドックだけど (ちょっとTech doc要素もいれちゃった)、ユーザーストーリーと過去の学びをまとめ始めたよ.....(省略)......もろもろ他の情報は自分の落書きノートでまず言語化していって、そのなかで必要なものは少しずつデザインドックに書き写していくよ 🙂」(超絶意訳)

デザインドックをチームにシェアし、取り組みに関わるメンバーや他のステークホルダーがドキュメント上にコメントや解答、その他の提案を繰り返し行っていきます

デザインドック上でのプロダクトマネージャーとエンジニアのコメントのやり取り例

例えば、「これ含めたら追加で5日かかるからやめたほうが良いよ」 → 「じゃあもしこの代替案Bだとしたら? 」→ 「それなら割と軽いから追加1日で済むね 」→ 「OK,インパクトも小さいからまずはスコープ絞った方で実験しよう」的な会話がデザインドック上でなされることになります。

他のプロダクトマネージャーとの意見交換の例

この繰り返しを経て初期のドラフトから洗練されたものへとアップデートされ、プロダクトマネージャーが最後の意思決定をする流れになります。その過程でプロダクトマネージャーとエンジニア、ビジネスサイドと技術サイドの合意形成がなされます。

なぜ重要なのか

1つ目の利点は、ドキュメント上で議論を重ね、フィードバックを得ながら合意形成をして、実際に取り組むものを定めていくことで、取り組みの目的に対する明確な方向性を示すとともに、ビジネスチームと技術チームの間に共通の理解を生み出すことができることです。

デザインドックの存在意義

1. Define (明確化)新しいシステム、プロセス、または機能について、あなた以外のメンバーが実装またはサポートするための作業ができるように、取り組みの詳細を明確化すること

2. Align (合意形成)なぜ、何をするのか、何を変えるのかについて、様々なステークホルダー間の合意形成を促進し、議論を円滑にすること

3. Record (記録)チームやステークホルダーが、いつ何をどう決めたのかを思い返すためのリファレンス

合理的なコミュニケーション

2つ目は、人と人とのコミュニケーションは常に不完全だからです。

デザインドックの基本構成

以下にデザインドックの基本構成を紹介します。例として、私がこのNoteを書くに至った私の考えをデザインドックとしてまとめながら、各要素の役割を説明してみようと思います。

続きをみる