仕様書の記述を急に消してはいけない

ソフトウェア開発の現場では、学校では決して教えてくれない「作業手順の基本」なるものが少なくない。業界や開発対象にもよるので一概には言えないけれど、仕様書作成の過程において下記のルールに該当するケースが多いのではないだろうか。

仕様書の記述を急に消してはいけない。

なぜ消してはいけないのか?理由は単純で、仕様書が更新された時に「以前の仕様書に記載されていたはずの内容」が消えていると混乱が生じるからである。変更履歴に一言書いておけば良いとか、Wordの履歴管理機能を使えば良い、検索すれば別ページに移動していることが分かる、というのは書き手側の論理であって、読み手側のストレスが増えるだけだ。だから読む人に余計な負担を強いる記載方法や、誰かが承認したら消えてしまうソフトの機能に頼るのは良い方法とは思えない。一旦記載した仕様は記録として残すべきであり、いきなり消去しないことが大切だ。*1

もちろん、仕様変更や構成変更により記載を削除・移動しなければならない場面はあるが、その場合には「削除理由と共に取消線を引いておく」「別セクションに移動した旨を記載しておく」等の「削除・移動したことが明らかに分かり、かつ記録に必ず残る」方法で対処することが望ましい*2。体裁は少々見にくくなるもののこれなら確実だし、プリントアウトしても必ず出力される。仕様書を読む人のストレスはずっと抑えられるはずだ。

なお、納品先には(試行錯誤の履歴なんか載っていない)綺麗な仕様書を納品しなければならないとか、ソフトのリリースに合わせて記載内容を整理する等は良くある作業だけど、その場合も「一旦取消線で削除を予告しておき、その確認が取れた後で実際に削除する」方法なら問題無いはずだ。不要な記載ばかり残る仕様書もかえって読みづらいので、ソースコードリファクタリング同様に定期的なメンテナンスが不可欠だと思う。*3



関連

*1:こんな事アタリマエだよと思う人は、仕様書の記載消去に関連して何か痛い目にあった経験があるのでは?

*2:仕様書をTracwikiに書けば、そのような情報は全て確実にリポジトリへ集積されるのでやっぱり便利だ。

*3:実はその辺の「変更が必要になった理由」を集計してみると、面白いデータが取れるのだけど、これはまた別の話。