Kosuke Moriです。Twitterは @kossmori が働くアメリカのスタートアップでは、どんな会話においても ”Is there a design doc?” (デザインドックはないの?) という質問が連発します。
会話のコンテクストを合わせるため、取り組みの背景を理解するための必須資料として位置づけられています。
デザインドックは技術詳細を書いた仕様書ではありません。 取組みに関わる Why, What, How と、ハイレベルな実装戦略、主要な設計上の決定、決定の際に考慮されたトレードオフに重点を置いて文書化したもので、それをもとにエンジニアは必要に応じてTech docを書き、デザイナーはデザインを始めます。
どれほど重要なのか
デザインドックはこれから行う取り組み (実験、実装、プロジェクト、プロセス改善) の基本的な要点をまとめたドキュメントで、オーナーはプロダクトマネージャーです。
プロダクトマネージャーとしての考えをチームに伝え、合意形成をとるための必須ステップで、多くのアメリカのスタートアップでは、これを書くことが全ての取り組みのスタート地点です。デザインドック無しには何もプロジェクトが動きません。
私もプロダクトマネージャーとして過去4年半、週に1つ以上はデザインドックを書いていて、これまでで250以上書いたことになります。
デザインドックを中心としたワークフロー
ワークフローはプロダクトマネージャーがデザインドック(Ddoc)を書き、チームにシェアすることから始まります。
「まだまだ超ドラフトのデザインドックだけど (ちょっとTech doc要素もいれちゃった)、ユーザーストーリーと過去の学びをまとめ始めたよ…..(省略)……もろもろ他の情報は自分の落書きノートでまず言語化していって、そのなかで必要なものは少しずつデザインドックに書き写していくよ 🙂」(超絶意訳)
デザインドックをチームにシェアし、取り組みに関わるメンバーや他のステークホルダーがドキュメント上にコメントや解答、その他の提案を繰り返し行っていきます
デザインドック上でのプロダクトマネージャーとエンジニアのコメントのやり取り例
例えば、「これ含めたら追加で5日かかるからやめたほうが良いよ」 → 「じゃあもしこの代替案Bだとしたら? 」→ 「それなら割と軽いから追加1日で済むね 」→ 「OK,インパクトも小さいからまずはスコープ絞った方で実験しよう」的な会話がデザインドック上でなされることになります。
他のプロダクトマネージャーとの意見交換の例
この繰り返しを経て初期のドラフトから洗練されたものへとアップデートされ、プロダクトマネージャーが最後の意思決定をする流れになります。その過程でプロダクトマネージャーとエンジニア、ビジネスサイドと技術サイドの合意形成がなされます。
なぜ重要なのか
1つ目の利点は、ドキュメント上で議論を重ね、フィードバックを得ながら合意形成をして、実際に取り組むものを定めていくことで、取り組みの目的に対する明確な方向性を示すとともに、ビジネスチームと技術チームの間に共通の理解を生み出すことができることです。
デザインドックの存在意義
Define (明確化)
新しいシステム、プロセス、または機能について、あなた以外のメンバーが実装またはサポートするための作業ができるように、取り組みの詳細を明確化すること
Align (合意形成)
なぜ、何をするのか、何を変えるのかについて、様々なステークホルダー間の合意形成を促進し、議論を円滑にすること
Record (記録)
チームやステークホルダーが、いつ何をどう決めたのかを思い返すためのリファレンス
合理的なコミュニケーション
2つ目は、人と人とのコミュニケーションは常に不完全だからです。
デザインドックの基本構成
デザインドックの基本構成以下にデザインドックの基本構成を紹介します。
例として、私がこのNoteを書くに至った私の考えをデザインドックとしてまとめながら、各要素の役割を説明してみようと思います。
構成要素1: Goals (この取組みのゴール)
このセクションには、この取り組みで何を達成しようとしているのか、この機能によってどのようなユーザー課題を解決しようとしているのかをまとめます。
「なぜやるか」だけを明らかにすることと、定量的に評価できる内容にすることが重要です。
ゴールでは「何をやるか」を主張してはいけません。そして、スコープクリープを避けるため、できるだけ狭いゴールであるのが望ましいです。
構成要素2: Non-goals (あえて含めないと決めたこと)
このセクションには、プロジェクトにあえて含めないと決めたこと、スコープ外のことはなにかを明記します。これを明記することで、関係の薄い議論を避けることができます。
そのほかには、検討の余地がある魅力的なスコープ拡張でありながら理由があってスコープから外したもの、フォローアップとして検討している取り組み、間違いなく後で対応することになるが今は受け入れてもよいコストやリスクなどを「あえて含めないと決めたこと」として明記しましょう。
構成要素3: Background (バックグラウンド)
このセクションは、この取組みを検討するに至った全ての「なぜ」を説明する場です。
———–続きはこちらのリンクから———–