仕様書の重要性
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　更新　2021/05/17(月)　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(C)文責　炭本　治之

　■仕様書をつくることの重要性・メリット
　　１．システム開発の発注側のメリット

　　　(1)納品されたプログラムに，要件定義書や仕様書と異なる部分があれば，
　　　　作り直しを要求することができる

　　　(2)仕様書を読めば，プログラム内部で何をしているかが即座に分かる。
　　　　プログラムを機能強化・修正する場合でも，容易に作業を進めることができる

　　２．システム開発の受注側のメリット

　　　(1)何をつくるかが確定する
　　　(2)大まかなスケジュールを立てることができる
　　　(3)利用者が，納期前に，仕様変更や使用追加をしてきた場合に，
　　　　 それは仕様書にないので，その部分をつくるには新しい契約が必要ですと言える

　■仕様書を作らないでプログラム開発するとどうなるか
　　具体的に何を作るかを定義した書類(仕様書)がないままで，メール連絡や口頭指示だけで，
　　プログラムソースを開発すると，後々必ずトラブルが起きます。

　　以下は実際にあったトラブルの例です。

　■事例１：仕様書を作りようがない
　　テーブル設計の仕事で「客先で」勤務を開始。
　　勤務初日に，客先の上司が，次のように指示。

　　「介護施設にWebアプリを売り込みたいので，その設計をして欲しい」

　　では，介護施設に売り込むWebアプリとは，どんな機能を持つべきなのか，
　　どのような要件を満たすべきか？

　　そのための資料がまったくなかった。

　　客先の上司は，いわゆる管理職で，自身は何もしない。
　　技術者がどんな仕事ぶりでどんな成果物を提出するかを見ているだけでした。

　　私は，こんな設計でどうかと，推測で設計するしかありませんでした。

　　私は，その契約は1ヶ月で中断したのですが，2ヶ月たっても仕様書は未完成だった
　　ようです。

　　なぜなら，3ヶ月目からはプログラムソースの開発が始まったのですが，
　　設計書に書いていないことが多すぎて，

　　　「何を作ったらいいか分からない」

　　と，エンジニアから苦情が出ていたからです。

　　プログラム製造担当のエンジニアは，土曜日も出勤して頑張ったそうです。
　　しかしそれでもプログラムを作れなかった。

　　他社にプログラム製造を外注したら，その他社も3ヶ月しても納品できなかった。

　　その後，そのシステム開発がどうなったか，私は知りません。

　■事例２：仕様書はないけれどプログラムを修正せよ
　　勤務初日に，客先(販売会社)の上司が，次のように説明。

　　「このシステムは既に営業職20人が使用している。」

　　「バグがあるので調べて直して欲しい。」

　　「仕様書はない。プログラムソースを調べるしか方法がない。」

　　営業職は，最初にどのプログラムを使ってシステムにログインするのか？
　　顧客から注文があったときは，どのプログラムを使うのか？

　　仕様書も，操作マニュアルもないから分からない。

　　プログラムソースを開いてみても，どんな処理をしているかがコメントで
　　書かれていない。

　　そのプログラムが何をしているか，ソースを解析するしかないのですが，
　　それは長い時間がかかる。

　　解析するうちに次のようなことが分かりました。

　　(1)SQLが暗号化されていて，何をしているのか解析できない部分がある

　　(2)トランザクション制御がでたらめ。
　　　その意味を理解せずにbegin〜endが使用されている。

　　(3)営業職20人がデータベースを同時使用するシステムなのに排他制御がない。

　　販売会社にもエンジニアはいるのですが，トランザクション制御も排他制御も
　　知らない20代の若手でした。

　　その販売会社はその後会社自体がなくなっています。

　■事例３：仕様書はないけれどSQLの速度改善をせよ
　　市役所，県庁，国のシステムでは，100万件，1000万件といったレコード数の
　　テーブルを扱います。

　　その場合，検索にかかる時間が長いというトラブルはよくあります。

　　条件を入力して検索すると，検索結果が返ってくるまで10秒，20秒，30秒と
　　待たされる。

　　ひどい場合は，1分，2分，10分と待たされる。

　　その待たされる間は，利用者の業務はストップしてしまうわけです。

　　検索にかかる時間を短くする方法の一つに，SQLのSELECT文を改良するというのが
　　あります。

　　同一の結果を取得するのであっても，SELECT文はいろいろな書き方ができるものです。

　　この書き方だと，結果取得に1分10秒かかるけれど，
　　別のこの書き方だと，2秒で結果取得する，ということがあります。。

　　複雑なSELECT文では500ステップ以上の長さがあって，階層構造も3階層，4階層の
　　深さがあります。

　　そこで，まずSELECT文を調査しますが，

　　　「ここのテーブル取得は不要ではないか？」

　　　「ここの列の取得は不要ではないか？」

　　と不審な処理を発見することがあります。

　　その処理は無駄なことをやっているんじゃないか？

　　そのため検索に時間がかかるんじゃないか？

　　実際に，その処理をはずしてみると検索時間が短くなる。

　　しかし，仕様書がなければ，つまり，どんな検索をするかが定義されていなければ，
　　その処理をはずしていいかどうか判断できません。


(終わり) ページの先頭へ