2005年11月20日(日)

どこまで書くか設計書

テーマ:設計
先の東証のシステム障害の原因は、富士通が作成した資料の記載漏れだという。しかし、東証側も安易に賠償請求するのではなく、自らの体制をも含めた改善策を検討しており、好感が持てた。システムの開発・運用は、開発側と受け入れ側の協力なくしては、不可能だからだ。

ところで、資料の抜け漏れを無くすということは、案外難しいものである。

客観的にみて、当然書くべき情報が書かれていない場合、それを見つけるのは比較的簡単である。しかし、書く必要があるかどうか、はっきりしない情報というのもある。そのような情報が漏れているかどうかは、ただ資料を見ただけでは、判断できない。

例えば、資料の書き手が当り前のこととして省略した情報が、読み手にとって当り前でなかったということがある。書き手が完全だと思っている資料でも、読み手にとっては不完全ということになってしまうのだ。

しかも、そのようなケースでは、読み手がその不完全性に気づかないようなこともあって、始末が悪い。

システムの受託開発では、発注元の顧客の会社や業界にとっては「常識的」な知識でも、開発者が全く知らないということはよくある。そして、顧客側が作った要件書にそうした情報が記載されなかったために、トラブルが起こることも少なくない。


プログラムの設計書(仕様書)でも同じことがいえる。特に、設計書から異常系処理の記載が省略されるようなことは多いようだ。設計書に「明らかに必要な処理」の記述が欠けている場合、プログラマが適宜判断して(気を利かせて)、実装することになる。(※)

しかし、プログラマが気の利いた仕事をしなかったらどうか。異常系の処理が実装されず、異常終了したり、データファイルを壊してしまうようなプログラムが出来てしまうだろう。場合によっては、セキュリティホールにつながるかもしれない。

プログラマからすれば、設計書に書かれていないのだから、それでも正しいプログラムだと主張したいところだ。しかし、現実はそれほど甘くない。


設計書をどこまで細かく書くか、という判断は難しい。設計者が実装すべき全てのことを書くのは効率的ではない(それはコーディングを行うに等しい)。しかし、プログラマが適切に設計を補完するためには、ある程度の経験が必要なのである。

最も重要なことは、書く側が読者層をきちんと想定できるかどうかだろう。それができていれば、どの程度の情報を盛り込むべきか、自ずと決まってくる。情報を省略するにしても、適切な補足資料を用意するなどの工夫もできるだろう。

また、設計書の読者であるプログラマの側も、ただ書かれていることをソースコードに翻訳するというのではなく、設計書の「行間」を埋めて、自分が設計を完成させるのだという意識をもつべきだろう。

応援のクリックお願いします →


※@IT 情報マネジメント 「 いいかげんにして! 日本企業─中国に嫌われる理由 」によると、異常系処理の約7割は、プログラマが独断で決定するという。


■リンク
・東京証券取引所「 株式・CB売買システムの障害発生に関する再発防止措置等について


■関連記事
誰のためのコード?
嘘つきのはじまり
人間を制御するプログラム




SEのための図解技術
SEのための図解技術
posted with amazlet on 06.03.25
開米 瑞浩
翔泳社 (2003/07/16)
売り上げランキング: 39,037

AD
いいね!した人  |  コメント(0)  |  リブログ(0)

argvさんの読者になろう

ブログの更新情報が受け取れて、アクセスが簡単になります

コメント

[コメントをする]

コメント投稿

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。