どのドキュメントがいらないのか
はじめに
「文書化する事の意味を考えろ」
去年ある人に厳しく言われた言葉です。ムダに作るな、必要なものを省くなと。アジャイル開発をするにあたり、不要な設計書は省いていこうと考えています。しかし、完全に省いていいのかという疑問が残ります。先日TLでも話題に上がったこちらの記事（アジャイル開発におけるドキュメンテーションの実際(1) ―― 本当に必要ですか？ そのドキュメント｜Tech Village （テックビレッジ） ／ CQ出版株式会社）を見ましたが、ドキュメントは最後に作っていいのか、とモヤモヤしています。モヤモヤの原因を探るため、自分が設計書を作成する目的から、どうすれば削減する事ができるか考えてみます。
前提
実装する前に作成するべきドキュメントについて考えています。
設計書の目的
- 作業を依頼するため
- こんな内容で実装して欲しいという内容を記述します。
- 例）外部設計書、内部設計書
- 事前合意を取るため
- 外部仕様決定時において顧客と合意を取るため。またはコーディングする前に設計者と合意を取る（上位資料の仕様を組んでいるか）ため。
- 仕様を判別するため、
- テスト仕様書を作成する時、「あるべき姿」が記述してある設計書からテスト設計を行います。また、後々の不具合か、仕様変更かの判別にも利用します。
- 設計時の意図を知るため
- コードを見れば実装かはわかります。しかし、なぜこの実装にしたのかはわかりません。業務上の制約なのか、技術的な制約なのか、特に保守運用に有効です。
私が利用ドキュメントを作成する目的は上記の通りです。
どこが省けるか
- 作業を依頼しない
- 設計した（脳内）人間が実装する事になれば仕様書を作成する必要はありません。
- 事前合意をもっとラフなものにすればよい
- 何を持って受け入れてもらえるかの条件を確認し、条件を文書化する。
- 仕様をテスト仕様書に求める
- 以前の案件でドキュメントはいいからテスト設計をして、仕様を定義する事で顧客と合意形成をした事があります。
- 機能は意図をWikiにまとめる
- 機能概要をWikiにまとめておき、実装上特殊な事をしている場合、Wikiに特記事項としてまとめます。
本当に全部省けるのか？
概要を Wiki にまとめ、振る舞いをテスト仕様書にまとめてしまえば設計書はいらないような気がします。しかし、それなら誰もがやっているはず。
- 作業を依頼しない
- その人が継続してアサインできるか？
- → 実現できそう
- 事前合意をもっとラフなものにすればよい
- システムが求められる品質によりでは？
- 機能の振る舞いをテスト仕様書に求める
- そのテスト仕様書のインプットは？
個人的結論・システムの背景に依存する
求められる品質によって必要な仕様書を判断する必要があると思います。テスト戦略（勉強中）に基づき、どんなテストレベルを用意するか次第な気がしてきました。極端な事を言ってしまえば「DBの内容を画面に出すだけ」という本当にこれだけの受入条件ならドキュメント、テストは軽微なものになります。
