次のプロジェクトで試してみたいこと

次のプロジェクトで試してみたいこと。

詳細設計書にはコードの使用方法などは記述せず、仕様のみを記述する。 ↓ 開発担当者に責任と自由が与えられる。レベルの低い担当者の場合、成果物の品質が低くなる可能性があるが、コードレビューやミーティングを活用し、能力の底上げをすることで全体としてのレベルを向上させる。

↓ 設計者はコードを見ずに設計書を作成できる為今までにコードを解析していた時間が余ってくる、その余った時間を設計書を作成することと同時進行で、テスト仕様書を作成する時間として費やす。開発段階で仕様に合ったテストケースが洗い出されていることで、開発者よりのテストになりがちな単体テストの漏れも減少し、バグの低減につながる。作業時間の短縮にもなる。

↓ 仕様もあまりに詳細にまでは記述しない（仕様書で全てを伝えようとするのではなく、他の方法も利用する）。最低限仕様がわかる範囲にとどめる。その代わりにテスト仕様書を漏れなく作成することに力を費やす。と同時に開発者との質問のやり取りでもカバーする。その理由は設計者の負担をできるだけ減らすことで、プロジェクトのボトルネックを設計者から開発者へ移動させることができる（ボトルネックが設計者の場合、代わりの設計者を探すのは難しいが、開発者なら比較的容易なため）。

ドキュメントのテンプレートを作る ↓ まずはプロジェクト単位でいいので、テンプレートを決め、ドキュメントの種類をできるだけ少量化する（最低限必要なドキュメントに絞る）。今までのプロジェクトでは必要のないようなドキュメントや作成しかけのドキュメントが溢れており、本当に必要なものがどれなのかすぐに把握することが難しかった。またドキュメントを常にエクセルで作成するのではなく、開発中は編集の容易なテキストファイルなどで管理し、納品時にテキストファイルを元にエクセルを作成するといった手法も有効だと思う。 プロジェクト開始時にどのようなドキュメントが必要で、どれを作成するのかを決めておくことは後々プロジェクト全体の管理に役立つ。プロジェクトに必要なドキュメントと納品に必要なドキュメントの区別もしておくとよい。