「仕様書」は，設計者とプログラマをつなぐ重要なコミュニケーション・ツールだ。それゆえ，安易な書き方をすると問題を起こす。よく議論されるのは，「仕様書の内容はどこまで詳しく書くのが適当か？」という点だろう。過剰品質を避け，効率的に書きたいところだが，きちんと意図が伝わることが大前提である。二つの実例を通して，そのキー・ポイントを紹介する。

松田 陽人（まつだ・はると）
システム・エンジニア

　今回から，題材を「仕様書」に移して設計書作成の心得を紹介していこう。

　前回までは，ユーザーからの要望聴取を基に作成する基本設計書を題材として，設計者とユーザーとのコミュニケーションを軸に展開してきた。これに対し，今回から取り上げる「仕様書」は，基本設計書を基にシステムを実装するプログラマやSEに対して，より具体的なシステムの詳細を伝える設計書である（図1）。

　このような設計書は「詳細設計書」や「プログラム仕様書」など，様々な名前で呼ばれていることと思う。また，作成する資料によって「テーブル定義書」や「画面遷移図」などの名前が付いているだろう。本連載では，プログラム開発フェーズで作成される，これらすべての設計書を包括して「仕様書」と呼ぶことにする。

図1●「仕様書」の位置づけ
図1●「仕様書」の位置づけ
本連載の前半では「基本設計書」について論じたが，後半では「仕様書」を取り上げる。これら設計書の呼び方や内容は開発現場によって様々だが，ここでは上記のような目的を持ったものとする

ガイドラインによる均一化にも落とし穴

　設計者の経験によって内容に大きな差が出る基本設計書と違って，仕様書はガイドラインやひな型によって記述内容を比較的均一化しやすい設計書である。記述内容の均一化に取り組む企業やプロジェクトは多く，その分だけミスも起こりにくいと思われがちだが，仕様書の作成プロセスにも落とし穴は存在する。それが原因となって，プログラマが仕様書の記述内容に疑問を感じたり，仕様を理解できなかったりするトラブルに発展し，開発が停滞することも少なくない。

　今回は，よく起こる問題の中から，仕様書の作成時にしばしば議論される「仕様書の適切な記述レベルとは？」というテーマを取り上げる。記述が粗すぎる仕様書は論外だが，「ユーザーの要求を技術仕様に変換できていれば実装可能」というわけではなく，また，単純に「詳しく記述すれば大丈夫」というものでもない。システムやプロジェクトの特性にも配慮する必要がある。

　こうしたポイントを，2つのトラブル実例を通して具体的に見ていこう。仕様書を巡るコミュニケーションの問題点がよく分かるのではないだろうか。また，一つでも多くの実例を知ることで，「転ばぬ先の杖」としてもらいたい。