設計ドキュメント
先日、縁あって某大手企業のシステム開発時における、基本設計フェーズでの開発標準
に記載されている作成ドキュメントのフォーマットを目にする機会がありました（開発
会社ではなくユーザ企業）。
機能要件定義書から始まって、テーブル定義や、バッチ処理、インプット、アウトプット
定義まで含めて、約15種類のドキュメントの作成が指定されいます。さすが、大手。す
ごいなぁと感心ひとしきり。基本設計でこれだけ作成する必要があるのだから、詳細設計
移行、試験まであるとすると、どれだけのドキュメントを作成しないといけないのか、想
像しただけで気が遠くなります。
加えて、これだけのドキュメントを作成する規模のシステムだと考えると、これらのドキ
ュメントを技術者一人でこなすわけもなく、手分けして作業を行う必要性があるわけで、
よく、整合性がとれるなぁ、と思うし、実際はどう手分けするかはわかりませんが、例え
ばドキュメント単位で手分けするとなると、テーブル定義担当は、ひたすらテーブル定義
を行うわけで、機能や画面が分からない中で、何を基準にテーブル定義を進めてゆけるの
かとても疑問。
これらを作り、実際にプログラミングまで行う開発会社はすごいなぁ、などと思っていた
のですが、ふと、気づいてはいけないことに気づいてしまいました。
これって、本当に設計書なのか？
基本設計を行う過程で作成され、次設計フェーズに引き継ぐためのドキュメントなんだろ
うか？開発会社は本当に基本設計時にこのドキュメント作成しているのか？
精度にもよるのでしょうが、もしかしたら発注者（ユーザ企業）から求められて、開発後
に整備して納品するドキュメントなのではないだろうか。何故なら、開発側からユーザ、
運用側に引き渡すための引継ぎドキュメントと言った方がしっくりくる内容だったので。
もしそうだとしたら、引継ぎ書類を設計書と言っていること自体が、動かないコンピュー
タ問題の原因のひとつに感じます。だって、設計という行為にたいするお金がついていな
いのだから。