ソフト開発に関しての仕様書の書き方

質問

ソフト開発に関しての仕様書の書き方なんですが、やはり何か決まりごとがあるのでしょうか？

仕様は
・業務フロー→システムフロー
・機能一覧
・画面遷移→画面設計
・ER→DB設計
とやる必要がある。

うちの会社の人は上記のように提唱しているのですが、これは必須なのでしょうか？

なにか、ソフト開発に関しての仕様書の書き方にかんして説明しているHPなどあれば紹介してくださるとありがたいんですが。

回答No.1

mac-san · ベストアンサー

某外資系元ITコンサルタントです。

結論から申しまして、各社方法論はありますが、すべてのプロジェクトでその通りすべての成果物を作成する必要はないと思います。おっしゃられている仕様書の他に、逆にプロジェクトによって必要な資料は多くあります。

ただ、会社ごとに方法論・ルールを決めていなければ、プロジェクトによってさまざまとなり、

・チームの活動がしにくい
・ノウハウの蓄積ができない・皆に理解できない
・プロジェクトが違うとやり方が違う
・保守運用がしにくい（仕様書を整備しなおさなければならなくなる場合も多々あり）
・プロジェクトマネジメント（スケジュール管理・工数見積・人員構成・スキルマッチなど）がしにくい

など多くの問題がでてくることが予想されます。

要は仕様書は「誰が何の為にいつ何をするときに必要となる情報なのか」がはっきりしていれば、納得して仕様書を作成できますし、その中に書くべきこともはっきりするのではないでしょうか。

その点上司とよく議論して理解することが大切です。（上司が答えられないようでは・・困りますが。前の会社では新人の段階で皆、内容を理解した上で同じ方向を向くので仕事がしやすかったです。）

具体的に書けば、本を数冊分にもなりますので、抽象的ですが以上です。さらに具体的な質問でしたら、個別に回答致します。

補足

アドバイスありがとうございます。ごく一般的なものでいいのですが、
http://www.pro-system.co.jp/Prosystem/process2.htm
のようなわかりやすくまとめているHPごぞんじないですか？それか、ご面倒でなければ、あなたが現役時代にやってた方式を書いていただけるとありがたいのですが。

回答No.3

mac-san

No2さんのご紹介のあるページがいいですね。

基本がしっかり押さえ、必要な仕様書の関連図を描き、その仕様書がいつ何のために必要かを理解してください。

具体的には、プロジェクトの前に仕様書（納品成果物）のインプットとなる情報をまとめ、仕様書のフォーマットを決定しておくとスムーズにプロジェクトをすすめることができます。

例えば、現状分析をスタートとすれば、
現状分析 → 改善すべきポイント-ToBeの定義
→ 施策（業務変更・IT導入など）
→ 業務フロー ←業務実行性
→ 人・システムの切り分け
→ 業務機能一覧 ←業務工数の見積
→ システム機能一覧 ← 優先度 等
→ システム化方針 ← 投資対効果は？
Fit＆Gap
以降構築するシステムによって仕様書は異なる

そうすると、プロジェクトによって省ける仕様書、追加すべき仕様書が出てくるはずです。例えば、パッケージソフトであればデータマッピング定義書やパラメータ定義書、インターフェース定義書などが必要になったりします。

方法論は何百ページとあり、ここですべてを書けませんが、大体こんな感じです。業種によりいろいろという例で、以下ネクステック社の製造業でのメソドロジーです。

参考URL：

http://www.nextechcorp.com/02_service/method.html

補足

ご回答してくださった方々、ありがとうございます。一旦締め切ります。

回答No.2

FLA-SE

各プロジェクトによって様々だと思います。
仕様書は本当に必要なものだけ作成するようにした方が良いと思います。

質問者さんが書かれているのが絶対ではありませんし、必須でもありません。
ER図を作らずに、いきなりDB設計（項目の設計）はできませんよね？
テーブルに持たせる項目を考えるには各テーブルの相関関係が必要ですから。

ちゃんと理由がありますので、
その仕様書が無くてもシステムが作れるのかを考えてください。
一応参考になりそうなページを書いておきますね～

http://naruzo.cside1.com/kouza/kouza.php?id=c0105