ところで、資料の抜け漏れを無くすということは、案外難しいものである。
客観的にみて、当然書くべき情報が書かれていない場合、それを見つけるのは比較的簡単である。しかし、書く必要があるかどうか、はっきりしない情報というのもある。そのような情報が漏れているかどうかは、ただ資料を見ただけでは、判断できない。
例えば、資料の書き手が当り前のこととして省略した情報が、読み手にとって当り前でなかったということがある。書き手が完全だと思っている資料でも、読み手にとっては不完全ということになってしまうのだ。
しかも、そのようなケースでは、読み手がその不完全性に気づかないようなこともあって、始末が悪い。
システムの受託開発では、発注元の顧客の会社や業界にとっては「常識的」な知識でも、開発者が全く知らないということはよくある。そして、顧客側が作った要件書にそうした情報が記載されなかったために、トラブルが起こることも少なくない。
★
プログラムの設計書（仕様書）でも同じことがいえる。特に、設計書から異常系処理の記載が省略されるようなことは多いようだ。設計書に「明らかに必要な処理」の記述が欠けている場合、プログラマが適宜判断して（気を利かせて）、実装することになる。（※）
しかし、プログラマが気の利いた仕事をしなかったらどうか。異常系の処理が実装されず、異常終了したり、データファイルを壊してしまうようなプログラムが出来てしまうだろう。場合によっては、セキュリティホールにつながるかもしれない。
プログラマからすれば、設計書に書かれていないのだから、それでも正しいプログラムだと主張したいところだ。しかし、現実はそれほど甘くない。
★
設計書をどこまで細かく書くか、という判断は難しい。設計者が実装すべき全てのことを書くのは効率的ではない（それはコーディングを行うに等しい）。しかし、プログラマが適切に設計を補完するためには、ある程度の経験が必要なのである。
最も重要なことは、書く側が読者層をきちんと想定できるかどうかだろう。それができていれば、どの程度の情報を盛り込むべきか、自ずと決まってくる。情報を省略するにしても、適切な補足資料を用意するなどの工夫もできるだろう。
また、設計書の読者であるプログラマの側も、ただ書かれていることをソースコードに翻訳するというのではなく、設計書の「行間」を埋めて、自分が設計を完成させるのだという意識をもつべきだろう。
応援のクリックお願いします → 
※＠ＩＴ 情報マネジメント 「 いいかげんにして！ 日本企業─中国に嫌われる理由 」によると、異常系処理の約７割は、プログラマが独断で決定するという。
■リンク
・東京証券取引所「 株式・ＣＢ売買システムの障害発生に関する再発防止措置等について 」
■関連記事
・誰のためのコード？
・嘘つきのはじまり
・人間を制御するプログラム
SEを極める 仕事に役立つ文章作成術
百戦錬磨のプロマネが伝授するドキュメント作成の極意
百戦錬磨のプロマネが伝授するドキュメント作成の極意
posted with amazlet
on 06.03.25
福田 修 日本情報システムユーザー協会
日経BP社 (2005/11)
日経BP社 (2005/11)
SEのための図解技術
posted with amazlet
on 06.03.25
開米 瑞浩
翔泳社 (2003/07/16)
売り上げランキング: 39,037
翔泳社 (2003/07/16)
売り上げランキング: 39,037