良く仕様書をどう書いたら良いの？と言われます。
非常に荒っぽいアドバイスが、仕様書よりも先に、マニュアルを書きましょうと言います。
（要件定義はある程度済んでいるとします）
そう言って、ソフトウェアのマニュアルなどを例にして、こういうのを書いてくださいなどと説明します。
マニュアルを見れば、どんな製品なのか、どんな機能なのか、どんな画面なのか、ボタンを押したらどうなるのか、全部乗っているはずです。
そして、当然、判り易いように、言葉だけではなく、図があるわけです。
マニュアルは、基本仕様書の一部、機能仕様書と外部仕様書を含んでいます。
基本仕様書の一部とは、機能概要、機能構成、ハードウェア構成、運用の前提条件などですね。
普通のマニュアルには書いてあります。
ただし、性能や品質の要件などはマニュアルには書いていないことが多いので、ここが仕様書との違い、＋α分になります。
マニュアル＝仕様書ではありませんが、仕様書＝マニュアル＋αですので、マニュアルを作った後に、α分を足せば良いだけです。
【仕様書を書くには何が必要か？ではなく、マニュアルを書くのに何が必要かを考える】
最初に、唐突にマニュアル書けと言っても、書けません。
情報不足ですから。
ですから、逆に「マニュアルを書くために必要なのは、何なんだろう？」「何を相談すれば良いんだ？」となれば、要件定義に必要なものが判ります。
マニュアルが上手く書けなければ、要件定義が上手く行ってない訳です。
その場合は、要件定義に戻ればいいわけです。
ゴールから考える方法ですね。
【マニュアルファーストのメリット】
①マニュアルは、どのみち書かないといけない。 仕様書は書かなくても何とかなる？ かもしれません。
冗談抜きで、仕様書をほとんど書かないで、プログラマに丸投げの人が日本には居ますが・・・・
ソフトを多くの人に使ってもらうなら、マニュアルがないといけません。
つまり、マニュアル書きからは逃げられない。
どのみち書くのでしたら、先に書いた方が、結果的に得になります。
②仕様書を見たことがある人は少ないけど、マニュアルを見たことがある人は多い。そのため、マニュアルの方が、イメージしやすい。
仕様書書いてといったら、ほとんどの人がイメージできず悩んでしまいます。
難しく考えすぎるんですね。
対して、マニュアルはイメージしやすい。
③マニュアル程度できれば、お客やプログラマなど他者と議論できる。
完璧なマニュアルではなく、マニュアル案程度ができれば、他社と議論が出来ます。
そして、本格的なマニュアルが出来れば、本当の利用者などに意見を聞くことが出来ます。
担当の人の意見・ＯＫ＝本当の利用者の意見・ＯＫではありません。
そのため、出来る限り早く、本当の利用者の意見・ＯＫを貰う必要があります。
仕様書を見ても、普通の人は判らないので、マニュアルを見せて、ＯＫ・意見を貰うことが重要なんですね。
ＰＳ
ゲームの場合、マニュアル＋攻略本が限りなく仕様書に近くなります。
ゲームを作った後に、マニュアル・攻略本を作るのはあまり良くありませんね。
