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