テスト駆動開発(TDD)が最近になってまたホットな話題になっているように感じます。
TDDではテストコードがある種の仕様書を兼ねる場合もあり、「実行可能なドキュメ
ント」と言ったりします。ですが、TDDのような開発手法を使えばソースコード以外
のドキュメントは不要であり、ましてやUMLのような「お絵かき」は生産性を落とす
だけだと言う人がたまにいます。
確かに実装レベルの仕様に関して言えば、構築するシステムの規模や性質によって
TDDの実行可能ドキュメントによる方法とUMLによる方法のそれぞれで一長一短が
あると思います。ですが、上記のような主張にはいくつかの重要な視点が欠けて
いるように思います。
それは「ドキュメントというのは実装レベルのものだけではない」ということです。
むしろ大切なのはビジネスモデリング、要求定義、設計といった実装以前の各段階
において顧客のニーズを正しく反映し、かつ前後のフェーズとの間のトレーサビリ
ティを確実にしておくことです。
TDDの実行可能なドキュメントにおいては工夫すれば要求定義、設計といった実装
以前のフェーズもある程度盛り込むことは可能だと思います。ですが、システム
構築に関連する関係者やステークホルダー全てがソースコードを読めるわけでは
ないという現実がある以上、システム構築に関わる全てのドキュメントを「実行
可能なドキュメント」のみでカバーすることは難しいと考えています。
ちゃんと書かれたTDDの本ではTDDや実行可能なドキュメントがシステム構築の
ライフサイクルにおいてカバーしている範囲についてきちんと触れられている
のですが、曲解されてしまうこともあるようです。
いかなる方法論もその手法がカバーしている範囲や対象としているシステムの
性質といったような全体像を掴んでおくことが大事なのではないかと思います。
