依頼内容が曖昧で情報が散らばっていたら→デザインドックを書いて認識合わせをする
課題を依頼されたときに「けっきょく何を達成できたらいいんだっけ？」と困ってしまうことがあります。もしくは、自分が誰かに依頼したときに相手がそう感じているかもしれません。
とあるプロジェクトで、ある機能を実装して現状を改善することになりました。
方向性ややりたいことはわかるのですが、具体的なタスクやゴールが曖昧で、どのように進めていくと完了できるのかわからなくなってきました。依頼相手も具体的な実装方法や懸念点までは想像ができないようでした。
そこで、以前読んだプロダクトマネージャーの必須スキル: デザインドックの書き方 - Design Doc｜kosuke moriという記事で紹介されたいたデザインドックを思い出して試してみることにしました。
書き出していくと、自分がわかっていることや「こうしてみよう」と考えていること、そして「聞かないとわからないこと」や「調べてみないと判断できないこと」が出てきました。
そこまでできてしまえば「書き出してみたんですが認識合わせさせてもらってもいいですか？」と相談ができますし、話し合いながら調整をしていき、お互いの認識が一致した最新のドキュメントが出来上がります。そして実際に進めていき、新たな情報があればドキュメントを更新して、また認識合わせをすることができます。
デザインドックとは？
デザインドックについて調べてみるとGoogleやスタートアップなどでよく使われているようでした。
元々はソフトウェア開発に使用される開発者向けのドキュメントのようですが、プロダクトマネージャーが合意形成のために使うツールとしても使われているようです。
このドキュメントの立ち位置としては、ソースコードなどの具体的な成果物だけではわからない背景を記録するもの。
たとえばその課題やプロジェクトが必要になった背景やゴール、関係者が話し合って決定したやること・やらないことなどです。
「簡潔に記録する」「結果だけでなく理由も残す」「関係者の間に置いて常に更新する」という点が大切になりそうです。
デザインドックのテンプレート
用途に応じて使いやすいように調整していくのがいいと思いますが、プロダクトマネージャーの必須スキル: デザインドックの書き方 - Design Doc｜kosuke moriで紹介されていた項目が汎用的で使いやすかったです。
- この取り組みのゴール（Goals）
- あえて含めないこと（Non-goals）
- 背景（Background）
- ユーザーストーリー（User Stories）
- 取り組みの成功を決める指標（Success Metrics）
- もっとも検証したい仮説（Biggest hypotheses）
- 取り組みが失敗する原因（Risk/Pre-mortem）
- 機能要件（Functional Requirements）
- 検討した代替案（Alternatives Considered）
- 取り組みの結果レポート（Results）
これらの項目ごとに、どのような観点で書いていくとよさそうかまとめています。
1. この取り組みのゴール（Goals）
- この取り組みは誰にとって、なぜ必要になりますか？
- その人はどのような役割を担っていますか？
- その人を悩ませているのは何ですか？
- その人が喜ぶのはどんなことですか？
- その人に届けられる最も重要な価値はなんだと思いますか？
2. あえて含めないこと（Non-goals）
- この取り組み内にあえて含めていないスコープ外のことは何ですか？
- 現時点であえて受け入れるコストやリスクは何ですか？
- この取り組みの完了後にやるべきことはありますか？
3. 背景（Background）
- この取り組みを始めるきっかけになった出来事は何ですか？
- この取り組みの実行を決めた理由は何ですか？
- 現状ではどのようにしていますか？
- 参考にできるデータや情報、過去の経験などはありますか？
4. ユーザーストーリー（User Stories）
- この取り組みを成功させるには誰に価値を届ける必要がありますか？
- その人は、この取り組みにどうすれば前向きに反応してくれて、何をもって良い悪いを判断すると思いますか？
- その人にどのような体験を届けるべきですか？
5. 取り組みの成功を決める指標（Success Metrics）
- 具体的に何が達成できたら成功と言えそうですか？
- 何を測定して、どのような結果になったら成功と失敗を判断できそうですか？
6. もっとも検証したい仮説（Biggest hypotheses）
- 原因と結果：いま困っているのは具体的に何がどのようになってしまうからだと思いますか？
- 理想：その問題をどのような結果に変えていきたいですか？
- 変数：改善するにあたって自分たちがコントロールできるものは何ですか？
- 施策：私たちが次のとるべき行動は何ですか？
- 仮説：if-thenを使って「もし（施策）をしたら、（理想的な結果）が起きるだろう」のように表現できますか？
7. 取り組みが失敗する原因（Risk/Pre-mortem）
- 何ができないと困りますか？
- どのような状態が起きると困りますか？
- どのような想定外が起こりそうですか？
- どのような数値や結果を下回ってしまうと失敗と言えそうですか？
8. 機能要件（Functional Requirements）
- 具体的に何を構築しますか？
- どのような機能が必要ですか？
- どのようなデータが必要ですか？
- どのような成果物ができますか？
9. 検討した代替案（Alternatives Considered）
- 採用したアプローチ以外にどのような選択肢が考えられますか？
- その選択肢を採用しなかった理由は何ですか？
10. 取り組みの結果レポート（Results）
- この取り組みの開始日と終了日はいつですか？
- ゴールは達成できましたか？
- どのような結果やデータが得られましたか？
- 今回の結果から何がわかりましたか？
- これからも継続するべきことはありますか？
- これから改善していきたいことはありますか？
まとめ
- 課題に対する合意形成をとるためにデザインドックを使う
- 項目に沿って書き出していくと、不明点が浮かび上がり、コミュニケーションのきっかけになる
- デザインドックには原因や背景、話し合った内容を簡潔に記録する
- デザインドックを見ながら話し合い、リアルタイムで更新する
- 汎用的なテンプレートから始めて、使いやすいように調整していく
Discussion