システム設計書
システム開発における設計書。
名前の付け方、内容の記述の仕方、実はこれ、ベンダーによってまちまちなんです。
名前の付け方に関して言えば、外部設計書／内部設計書というベンダーもあれば、基本設計書／詳細設計書というベンダーもあります。
場合によっては、それらを一纏めにして設計書というベンダーもあります。
内容に関して言えば、ユーザが理解しやすいように要件定義（業務の視点）からブレイクダウンしていき、システムの内部処理までを関連付けした設計書もあれば、コンピュータ／プログラムの視点を重視した設計書もあります。
対象のシステムにより記述内容が異なるので、一概にどちらが良いとは言えませんが、困るのは内容が充実していない設計書です。
ユーザの中にシステム開発に精通した人がいれば内容の不足をチェックできるでしょうが、精通した人がいないユーザはベンダーから示された設計書が全て。
でも、ちょっとまってください。
システムの検証をするときに、何を根拠に検証するんでしょうか。
そこに書かれていないことが納品されたシステムに実装されていなくても、何の証拠もないんですよ。
仕様凍結の手順を踏んでしまうと、設計書に書かれていないことは、後から『これは仕様追加です』と言われても、その内容でユーザ／ベンダー間で仕様の合意をしてしまっているのですから、ユーザには分が悪くなります。
設計段階でシッカリと打合せをし、仕様詰めをしたから大丈夫だろうと根拠のない安心をしていると、後でしっぺ返しを食らう事もあります。
また、数年後システム更改しようと思っても、システムがどの様になっているか分からなければ、何処をどう更改するのかも判断できなくなります。
要するに、設計書ってそのシステムのバイブルなんです。
システム開発をお願いしたベンダーに全てを任せるから大丈夫！
と言う声も聞こえてきそうですが、そのベンダーは『絶対』なくなる事はないでしょうか？
システム開発を担当し、そのシステムを熟知しているＳＥが『必ず』面倒を見てくれるのでしょうか？
ユーザ側も、システム開発プロジェクトに携わった人が、システムが稼動している期間『必ず』面倒を見れるのでしょうか？
社内にチェックできる人がいないユーザは、第三者の力を借りてでも設計書は整備するように心掛けるべきです。