最近の開発で仕様書等のドキュメント類を書くことが少なくなりました。

私は主に業務系のWebサービスを作成してましたが、最近はオープン系のサービスも受け持つことも多いのですが、仕様書やテストのエビデンスがオープン系のお客様の場合は求められることが少ない・・・
というかほぼない。
何故、お客様は仕様書を求めないのか？

予算を削りたい

お客様にとって仕様書なんて見てもわからないもの貰ってもしょうがない。
貰ってもしょうがないものなら作ってもらわないで、削ってしまおうって考えがあります。
テストのエビデンスも同様です。

これは仕様書の作成やエビデンスの作成に工数が掛かるため、工数の削減を計って予算を削りたいという考えがあります。
例えば、おおまかに計算しますが以下のようなシステムがあります。
開発工数：1人月
検証工数：0.5人月
設計工数：0.5人月
ドキュメント作成工数：0.5人月
管理工数：0.5人月

計：3人月
※開発工数を基準に他のも算出しています。

1人月×50万 = 150万
150万の値段のものがもし開発工数だけになれば50万と1/3になるのです。

危険性を理解していない

ドキュメントなくても作成した会社や人に聞けばいいと思っているのはとても危険です。
会社なら開発した人間が退職したり、開発者自体忘れている場合もあります。
また、お客様も同様にシステムの開発の依頼をした側も退職したり、運用の方法が引き継がれていないなどの場合もあるのです。

そのため仕様がソースベースとなってしまうことがあります。

ソースが仕様です

ドキュメント類が一切ない場合、ソースが仕様となってしまいます。
その場合、開発側も運用するお客様もバグや特殊なケースが発生すると仕様なのか要望だったのか等も一切わからなくなります。

メールでやり取りは残せとはいいますが、退職した方のメールなんて残ってなかったり・・・
ソースが仕様となると修正を依頼する毎に改修費用が必要になる場合があります。
開発費用を削ったのに改修費用が掛かるとなると削ったのが無駄になります。

ドキュメントは証拠品

ドキュメントは証拠品です。
「このシステムはこのようなものです」って証拠のものとなります。
もし、バグが出ても仕様書と見比べて仕様書と合っていないのであれば既存バグなので開発者の製造責任で対応をして貰えることもあるのです。


長く使うシステムであればあるほど最初にケチって費用削減を行ってもその後の運用コストを考えて、初期費用が高くなっても出来るだけドキュメントを含めて完全な状態の貰うのがベストです。


«前の記事：それは罠だ！JavascriptにはJScriptという方言がある！エンジニアに嫌われる営業：次の記事»