はじめに

先日、Encraftという株式会社ナレッジワークが主催しているイベントにオンラインで参加し、TestDesignDocというドキュメントについて紹介がありました。現職では、TestDesignDocのようなドキュメントは作成していませんが、スクラムチーム全員でDesignDocをブラッシュアップしています。
現職のDesignDocを見返すことで、得た気づき（DesignDocに書いてあってよかった記述）を紹介します。

DesignDocについて

以下のような見出しの内容が記述され、適宜Refinementを行い、ブラッシュアップしていきます。まず文書名～用語の定義までPOが先行して整理、記述します。それらが整理された後、デザイナーに共有して、画面デザインを書き起こします。POが考えるソリューションを仕様に書き起こながら、エンジニアと協議が必要な内容尾論点を追記していきます。
スクラムチームメンバーが全員参加するRefinementで、POやデザイナーが作成した内容をたたき台として、論点についてディスカッションし、仕様を決めていきます。

• 文書名

• 関連するユーザーストーリー

• ユーザーの課題 ／ プロダクトの問題点

• 用語の定義

• 仕様

• 画面デザイン

• 論点

• 議事録

QAエンジニアもRefinementに参加し、すでに挙がっている論点について意見を言ったり、新たな論点を提示し、ユーザーに提供する内容の解像度を高めていきます。次の見出しから、これらの記述内容のうち、どの記述内容がスクラムチームが開発するにあたって、効果的だったかをランキング形式で紹介します。

書いてあることで開発に効果的な記述 第3位

第3位は「用語の定義」です。
Refinementでスクラムチームメンバー全員で論点について議論をします。用語が定義されていないと、参加者それぞれの解釈で議論してしまい、結論を出すまでに余計に時間がかかったりします。用語の定義を行い、それらについてチームメンバー全員が共通理解をもつことで、議論中に用語のすり合わせをする機会がぐっと減ります。

書いてあることで開発に効果的な記述 第2位

第2位は「ユーザーの課題 ／ プロダクトの問題点」です。
この記述も、仕様（ソリューション）の前提となる内容です。何を問題としてとらえているのかの認識が一致していないと、ソリューションとなる「仕様」の正しさをスクラムチーム全員が判断できない状態になってしまいます。仕様について議論する際には、「ユーザーの課題 / プロダクトの問題点」についてチーム全員で認識が一致しているのが望ましいです。
議論していく中で、
『ほかにもAという課題もありますが、それは今回解決しなくても良いのですか？』
『A、Bという課題が記述されていますが、どちらの課題のほうが問題だと思いますか？』
のような問いをスクラムチームになげかけて、課題の優先順位を決めたりすることができます。つまり、開発スコープを決めるためにも必要な情報であるため、第2位としました。

書いてあることで開発に効果的な記述 第1位

第1位は「論点」です。
ここでいう論点は「議論の中心となる問題点」という定義としています。

要はRefinementで議論したいことです。論点だけ記述しているわけではなく、論点に対して、参加者から挙がった意見も議事録として残しています。もちろん議論した結果、決定事項も記述しています。
開発を進めていく中で、「仕様」、「デザイン」、「スコープ」になった理由、背景を確認したくなるタイミングは必ず起こります。決まったことだけ書くのではなく、結論に至った背景を残しておくことで、後から見返した時に、検討漏れなのではなく、議論した結果、そのような選択をとっている（仕様にした）と納得感を得ながら進めることができます。

おわりに

DesignDocで基本となる記述は「開発スコープ」や「仕様」、「デザイン」だと思います。しかし、人は忘れるのが常であります。自分自身もよく忘れたり、勘違いをすることがあります。その度、関係者に質問、確認をすることは、時間を余計にかけていることに繋がります。後から見返すことを前提としてドキュメントを残しておくことが開発スピードを上げるための一つの要素なのかなと思いました。

このようなDesignDocの構成になっているのは、スクラムチームでの継続的な振り返りによるものであり、継続的な改善を進めるスクラムチームメンバーを尊敬しています。

見る人によっては「Refinementの議事録じゃないの？」という風に思う方がいるかもしれません。DesignDocとRefinement議事録が一つのドキュメントにまとまっているため、DesignDocというドキュメントの扱いとしています。