アジャイル問答：ドキュメントと動くソフトウェア
- アジャイルでは、ドキュメントより動くソフトウェアを重視すると言いますが、そのソフトウェアが正しいことを証明するための有効な方法は？
確かに、ドキュメントよりも動くソフトウェアを重視しますが、まったくドキュメントが無いわけではありません。私の考える不要なドキュメントは、主に、システムの中身、モジュール構造などを表した内部設計仕様書です。ソフトウェアの内部構造については、リファクタリングを実施するので、頻繁に変化してしまうということもあり、それが動くソフトウェアを重視する理由の一つです。
ただし、ソフトウェアそのものの、振る舞いであるとか、動きの機能については、資料が必要だと思っています。所謂、外部設計仕様書です。これは、リファクタリングでは変更されない部分になります。そして、この部分は、お客様の合意が必要な部分であり、お客様がソースコードを読めればドキュメントでなくても良いですが、そういう場合は非常に稀です。お客様とコミュニケーションするための資料なのです。
そして、この外部設計仕様書に沿ったシステムができているかどうかが、ソフトウェアが正しいことの証明ということになります。そのためには外部設計仕様書に対応したテストケースが必要です。そのテストケースに対応したテストコードを準備することで、単体テストレベルだけでなく、ユーザから見た機能といったレベルでのテスト駆動開発も可能だと思います。
その外部設計仕様書が正しいかどうかは、お客様しか判断できません。そして、その外部設計仕様で本当に業務が回るかどうかは、当のお客様でさえ、ドキュメントの内容だけでは判断しかねると思います。これは人間の想像力には限界があるので仕方ないこと。だからこそ、動くソフトウェアを早めに提供して、その動きを触ってもらい妥当性を検証してもらうことが良い、という考え方がアジャイルなのでしょう。
よって、ドキュメントよりも動くソフトウェアを重視する、ただし、ドキュメントをないがしろにするわけではない、ということになります。
まとめると、以下のようになります。
- 外部設計仕様書
- お客様との認識違いを避ける為に必要。ただし、最初から間違いない完全な仕様まで記載できるとは限らないので実物（動くソフトウェア）を見て判断してもらうのが良い。
- 内部設計仕様書
- 開発者のメモ程度の効力。コーディングしてから期間が開いている場合や他の人がそのソースを見る時にあった方が便利だが、プロセス上作成を明示する必要は無い。
ここで言う内部設計仕様書は、小規模なPJでも大規模なPJでも不要だと思っています。小規模PJであれば、何も考えずに不要で、大規模なPJで不要にするためには、１つ鍵が必要です。それが、“アーキテクチャ”になる訳ですが、それはまた別のお話。
