こんな仕様書は読む気がしない

ソフトウェア開発において、受け取っても読む気が失せる仕様書の例：

• 文字ばかりで図表が無い
  機械、電気、建築など他のエンジニアリングでは図面でのやり取りが普通なのに、ソフトウェア開発ではなぜ文章に頼った意思疎通が多いのだろうか？確かに文章にしなければ表現できない内容も有るけれど、UMLのような図面を使う方が一目で分かりやすいし、「全てのケースでの考慮漏れがないか？」を知るためには表を使って条件を網羅的に整理するのが確実だろう。文章だらけの仕様書は「何か記載されていない項目があるのではないか？」という疑いを晴らすことが出来ないように思う。
• 背景説明が無い
  やたらと詳細な仕様が書かれているのに、「全体構成」や「概要」が記載されていないので、一体何についての資料なのか全体像がなかなか理解できない。書き手にとっては「アタリマエ」のことだろうけど、それを読み手に伝えるのが仕様書の役割だろう。仕様書は、まず大きなところから説明を始め、その中で該当する箇所はどこなのか、その詳細説明は何なのかと徐々に掘り下げていく構成にすべきだ。
• 理由の記載が無い
  「○×は△□とする」と書かれているのは良いけれど、その仕様に決まった理由は何なのか説明が無い。こんな理由の無い仕様が困るのは、ずっと後になって派生開発を行う時に、果たして仕様を変更して良いものなのか、仕様決定の経緯が分からず、判断が付かないからだ。ハードウェアの制限、他モジュールの制約、顧客の要望、前回の開発で問題になった現象の回避、品質管理部門で決まった基準等、必ず何らかの理由が存在するはずだ。全ての仕様には必ず理由が付いているべきであり、理由のない仕様は存在してはいけないと思う。
• 関連する仕様の記載が無い
  一つの仕様書だけで完結することは少なく、幾つもの仕様書が互いに関連しながら仕様全体を構成するのが普通だろう。その関連する仕様はどれであるのか、仕様書名と仕様の番号が明記されていることが必要だ。関連する仕様書が記載されていれば、少なくともこれらの資料に絡むということが分かるし、書き手側で意識していることも明らかなので安心できる。逆に、関連仕様書が明記されていない場合、他の仕様が考慮されていない可能性が有るので、かなり不安な気持ちにさせられる。
• 文章が意味不明
  学校でソフトウェアの作り方は習っても、仕様書の書き方なんて習う人は少ないようだ。仕様書なるものにお目にかかるのは会社が初めてという人も多く、既存の仕様書などを手本に書き始めるのだけど、そもそも仕様書どころかまともな作文すら書いたことのない開発者が珍しくないので、理解不能な文章が平気で並んでいたりする。仕様書を書く前に「まずは日本語の作文から」勉強するのが筋だろう。