ドキュメントを書くために設計書を作る
私はドキュメントを書く前に、設計書を書いて書く内容をまとめています。
設計書、開発の時には必須で作成しますが、ドキュメントも同様であった方が色々と便利なのではと思ったのが発端です。
設計書を作成することの利点としてはいくつかありますが、大きくは下記2つだと思っています。
ドキュメントの目的を把握しやすくなる
他のメンバーにタスクをパスしても、文脈が理解できるようになる
ドキュメントはできれば少ない方が読む方の負担は減ります。そのため、無駄なドキュメントは極力作らない方が良いでしょう。設計の時点で、ドキュメントの目的を見直すことで、本当に必要なドキュメントなのかを判断することができます。
また、ドキュメントは最後まで書き切ることが一番難しいです。どうしても書ききれなくなった場合、必要なドキュメントは他のメンバーにパスして続きを書いてもらうことがあります。その際に、設計書があることでスムーズな引き継ぎが可能となります。
それでは、実際にどのように書いているのかを説明します。
設計書の構成
構成としては、最低限下記を書いています。
それぞれ説明します。
タイトル
設計書のタイトルをつけます。
タイトルは分かりやすく動詞を使って記載する必要があります。読み手がタイトルだけで何をすべきなのかを理解できるようにすることが大切です。
読む側の手間を省く努力が必要です。
なぜ必要か
このドキュメントがなぜ必要かを記載します。
ドキュメントは書こうと思えば無限に書けるのですが、無駄なドキュメントはなるべく書かない方が望ましいです。
そのために、「なぜ」の部分を明確に言語化し、ドキュメントの必要性を判断します。この部分の認識が甘い場合、もう少しチームで議論したり、そおそもドキュメント自体書かないという動きになるかもしれません。
新規追加/既存の修正のどちらか
ドキュメント作成において、新規に作成するドキュメントか、既存のドキュメントを修正するものなのかを記載します。
この作業は、単純にドキュメントの重複を防ぐためです。
概要
概要にはドキュメントの内容を詳細に記載します。
新規ドキュメントの場合はドキュメントの構成や、手順が必要な場合は手順も箇条書きで書くとわかりやすいです。
既存の修正の場合は、修正箇所を明確に記載する必要があります。
完了条件
ドキュメントの完了条件を記載します。どこまで対応すればドキュメントリリースして良いよ、という条件を書きます。
その他添付資料
伝えておくべきことや、補足資料があれば記載します。
まとめ
以上です。設計書は作成に時間がかかってしまいますが、その分とても優秀なコミュニケーションツールとなります。時間がかかってでも丁寧に書くことをお勧めします。
サンプルとして、今回説明した内容をもとに、実際に設計書を作りました。
それでは、良いドキュメントライフを。