開発 仕事

仕様書がない！ソースが仕様です

以前のブログの写し記事で少し修正。

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

僕は以前はBtoB系のWebサービスを作成してましたが、ここ数年BtoC系のWebサービスを作成していて仕様書やエビデンスを作っていません。

というかほぼない。

何故、お客様は仕様書を求めないのか？

予算を削りたい

お客様にとって仕様書なんて見てもわからないもの貰ってもしょうがない。

貰ってもしょうがないものなら作ってもらわないで、削ってしまおうって考えがあります。

テストのエビデンスも同様です。

これは仕様書の作成やエビデンスの作成に工数が掛かるため、工数の削減を計って予算を削りたいという考えがあります。

例えば、おおまかに計算しますが以下のようなシステムがあります。

• 設計工数：1人月
• 開発工数：1人月
• 検証工数：1人月

計：3人月

※計算しやすくするために雑に算出しています。

70万(1人月)*3= 210万

210万の値段のものがもし開発工数だけになれば1/3で1ヶ月で出来、70万とになるのです。

エビデンスの作成をなしにして検証工数を0.5人月にしても1/2で1.5ヶ月で105万になります。

というか受注側の開発会社が面倒且つ値段が上がって受注しにくいから仕様書やエビデンスの説明をしないパターンが存在します。

エビデンスがないからって雑にテストを行う会社もあり注意が必要です。

テスト仕様書すらないパターンも…

危険性を理解していない

仕様書など無くとも作成した会社に改修する際は依頼すればいいという考えは危険度が高いです。

開発した人間が退職したり、開発者自体数年、数ヶ月すれば忘れている場合もあります。

お客様も同様にシステムの開発の依頼をした側も退職したり、仕様や運用の方法が引き継がれていないなどの場合もあるのです。

仕様書が無ければ開発者側の認識とお客様側の認識一致の確認が出来ない場合が多いです。

そのため、言い争いの水掛け論になることがあります。

ソースが仕様

仕様書やマニュアルなどのドキュメント類が一切ない場合、ソースが仕様となってしまいます。

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

メールでやり取りは残せとはいいますが、退職者のメールなんて残ってなかったり…

ソースが仕様となると本来はバグ修正の依頼でも改修費用が必要になる場合があります。

顧客によっては本来は伝え忘れの仕様でも「要望と違う！バグだ！」って騒ぐ人が居ますが、お客様の伝え忘れは開発に否がないパターンがあり、本来なら充分開発工数の上積みをして料金頂けます。

開発費用を削ったのに改修費用が掛かるとなると削ったのが無駄になります。

ドキュメントは証拠品

仕様書、マニュアルなどのドキュメントは証拠品です。

「このシステムはこのようなものです」って証拠のものとなります。

もし、バグが出ても仕様書と見比べて仕様書と合っていないのであれば既存バグなので開発者の製造責任で対応をして貰えることもあるのです。

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

仕様書がない水掛け論を避ける方法

仕様書がない場合、よく仕様で揉めます。

これはメール、打ち合わせ、口頭など連絡方法が様々で正確に伝わっているかの確認がしにくいのが問題です。

僕はこういったことを避けるため、いくつかの方法を取っています。

• 仕様に関わるものは、書き起こして社内で残しつつ、お客様に必ず確認をする
• 質問は出来るだけ質問表を書き起こしてお客様に回答をお願いする
• 電話や口頭での内容はメールで再確認
• 打ち合わせの際に起こした議事録は即日送付して確認してもらう

どんな仕様でもお客様が一度確認しているようにします。

まとめ

仕様書がない場合発生する問題は多々あります。

お客様的には予算を削った方がやはりいいでしょうが、開発側としては予算を無理に削り過ぎると時間、人員も掛けられないため中途半端なものになる可能性があります。

仕様書が無くとも、必ずお客様、開発側と認識が一致していることを確認し続けることが重要です。

本当はドキュメント類、人員、設備など充分に掛けられるほど予算があれば嬉しいんですけどね。