仕様書は後ろから

開発会社の方であれば、仕様書は作成すると思います。受託開発のころ、元請けの会社の方が仕様書をきり、それに沿って開発をしたりしていたのですが、開発を進めていくうちに徐々に問題が出てきます。

via A pile of paper on Flickr - Photo Sharing!

よくありがちなのが、納品物に対する仕様書を盾にして意見が押し付けられることです。読み違いや勘違い、前提知識など様々な要因があるのですが、仕様書は絶対と言わんばかりの態度をとられます。

そして、さらによくありがちなのが仕様書の間違いです。しかしこれは前者の逆でありながら、スルーされることが多いようです。絶対なのか、または逆なのか…勝手に解釈を加えて欲しいのか否か、よく分かりません。

後、もう一つありがちなのが、最初の方の仕様こそきちんとしているのですが、後の方（システム的には重要視される部分）になるとドキュメントが希薄になっていくという現象です。開発のスケジューリングの問題なのかも知れませんが、差別化要因を生む箇所にこそ、力を注がないといけないのですが、そうでないことが多いようです。

ということで、解決策は以下に。

つまりWebシステムで言えば、会員登録やショッピングカート、商品登録等の作業はありがちなものです。多少の入力項目の違いや、機能の誤差はあるとしても、全く別物ということはまずありません。もし全く別物だとしたら、それは差別化要因を生み出す部分でしょう。

そう考えると、会員管理システムなどはごく簡単な内容で、後で補正がきくようにだけしておくのが無難です。その他、特にワークフローに関わる部分だけつめていけば、会員の管理項目に必要なものも事前に分かってきます。

仕様書は大抵1番からはじまって、終わりに会計や販売管理をはじめとしたバックオフィス系の内容がきているかと思います。それを全くの逆にして、最初のやる気を最後の重要部分にまわすようにして、販売管理や会計の部分から仕様を作り上げていけば、もっと中身の濃い仕様書が作成できるのではないでしょうか。