■
■テストの役割=進捗管理＋設計戦略（An Agile Way 2005,8.25）
先に述べた「設計書のページ数」という単位は、３つの条件をどれも満たしていない。すべての設計書を否定するつもりはないが、設計書は内部の中間生産物であることが多いし、１００％終了という判断もしにくい。特に、「誰も待っていない」設計書は顧客価値と結びつかない。（書いても読まれることのないドキュメントを、ぼくは、WOD=Write-Only-Documentと呼んでいる。)
あははは（乾いた笑い）
いや，WOD書く仕事ばっかりやってます．
■ソフトウェア設計とは何か？
上の話の起源ネタ．
ソフトウェア設計ドキュメントは，コーディング前に記述するのではなく，コーディング後に記述した方がずっと正確になります。これは，プログラマであれば誰でも知っていることです。この理由は明らかでしょう。コードに反映された設計のみが，ビルド/テスト・サイクルを通じて洗練されてきた唯一の最終設計なのです。このサイクルを通じて初期設計が変更されない確率は，プロジェクト中のモジュール数やプログラマ数の逆数と相関関係があります。つまり，この数値は急速にゼロへと近づいていくのです。
ああ，まさに実感．
ただそうなると，設計ドキュメントはいつどのタイミングでこさえればいいのか，という話になる．コーディングするにしても「全体構想」みたいなものがないとモジュールを設計（コーディング）するというのは難しい（何をどうしていいのかイメージが持てない）
作業の流れとしてはあらかじめ修正入るということを前提として，
- 設計ドキュメント（ドラフト版）を書いてコーディングに必要な情報，プログラムの全体構想，作る（予定）のモジュールの仕様を定義．
- 1で作ったドキュメントに対して「仕様レビュー」を行う．
- コーディング
- テスト，とにかくテスト
- テストした内容を記録する
- 3から5を繰り返す
- 最終形（あるいは安定版）のソース内容をもとに，修正結果をフィードバック
- 設計ドキュメント正式版を作る．詳細設計レベルまで記述する．
- 「詳細仕様レビュー」を実施．
みたいな流れになるのか．
(1)はカレーを作る話にたとえれば，肉や野菜を準備するぐらいのイメージで．ここではモジュールの処理フローなど，詳細仕様については記述しない．後の工程のコーディング・テスト後のソースから起こすものとする．
この流れだとソフトウェア修正内容をドキュメントに反映させるといった「後戻り」工程は少なくなりそうだし，後段の「詳細設計レビュー」も実のあるものになりそうだ．
