■□■━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
中小企業経営者のための
「サルでもわかる」やさしいIT・情報システム用語解説
第 10 号（2005/6/14）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━■□■
こんにちは、インフォバリューの福島です。
今回は、「バグ」についてです。
■今日の用語■■■■■■■■■■■■■■■■■■■■■■■■■■■■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
バグ（bug）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□（>_<）小難しい定義 □□□□□□□□□□□□□□□□□□□□□□□
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
プログラム中の誤り部分をいう。プログラムにバグが存在すると、様々な不
具合や誤動作を起こす原因となる。プログラムは十分なテストを行い、バグ
を極小化することが必要であるが、バグを完全に排除することは非常に困難
であるため、プログラムのリリース後のメンテナンスやアフターフォローが
重要となる。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
□（^_^）やさしい解説 □□□□□□□□□□□□□□□□□□□□□□□
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━ プログラム中の虫 ━━━━━━━━━━━━━━━━━━━━━━
バグを直訳すると何でしょうか？
そう、バグとはプログラム（→第９回）中に潜んでいる「虫」なのです。
理想をいうならば「虫」がいないプログラムを作るべきではありますが、よ
ほど単純なプログラムではない限りなかなかそれは困難なのです。
前回提示したプログラムの例は非常に単純化してますのでほんの数行しかあ
りませんが、実際のプログラムは何万、何億行であるのが普通です。
そうなると、プログラムを作るのは人間ですのでバグを０にするのは至難の
業です。
━━ バグの原因 ━━━━━━━━━━━━━━━━━━━━━━━━━
バグの原因は、主に、
１）単なる記述ミス
２）予想外の事象への未対応
などがあります。
１）単なる記述ミス、はどんなに大規模なプログラムであっても、何として
でも０にすべきですし、０にすることは全く不可能ではありません。
問題は、２）予想外の事象への未対応、の方であり、これはなかなか０にす
るのは困難なのです。
例えば、実際運用してみると、
・ユーザーが予想もしなかった操作を行った
・LAN（→第３回）の調子が悪くデータベース（→第５回）に接続できなかっ
た
・金額は億単位まで扱えることを想定していたが、それを上回るなど想定範
囲外の値が入力された
など様々な「予想外の事象」が発生します。
こんな時にもバグが発生します。
「出版」に例えると、誤植はしっかりと校正すれば０にすることは可能でしょ
う。しかし、説明不足であったり、読者の個人的な価値観の影響などで、意
図していたことと違うように解釈されてしまった、というようなことはなか
なか０にすることは困難でしょう。
文章作成がうまい人が、ロジカルに文章を組み立てて、誤解釈されないよう
な文章を書けるのと同じように、スキルが高く経験豊富な開発者は様々な予
想外の事象を、事前に予想しバグを極小化しますが、それでも人間である以
上限界があります。
━━ バグ許容度 ━━━━━━━━━━━━━━━━━━━━━━━━━
そこで、システム構築を考える場合、システムの種類によるバグの許容度を
事前に把握する必要があります。
例えば、金融系のATMなどは、バグがあったらシャレになりませんよね？
大ニュースになってしまい、信頼性はがた落ちです。
そういったバグを許容できないようなシステムは、通常、開発期間を２年、
３年と長い期間取り、入念なテストを行い、バグを限りなく０に近づけた上
でシステムを導入します。
しかし、それとは逆に、多少のバグはあっても良いが、とにかく早く導入し
たいという場合もありますよね。
例えば、競合企業への対応や、新事業へのスピーディーな参入、急な制度改
正への対応、組織変更への対応などの際です。
基本的にバグ許容度が低い、前者のようなパターンは、
・対消費者のシステムであるとき
・お金を扱うシステムであるとき（これを「勘定系システム」といいます）
・会社の基幹的部分を担うシステムであるとき（これを「基幹システム」と
いいます
などがあります。
━━ プログラムのメンテナンス ━━━━━━━━━━━━━━━━━━
いずれの場合も、システムのリリース後のメンテナンスが重要です。
もし、プログラムにバグが発生した場合は、速やかにプログラムを修正し、
正しくシステムが運用されるようにしなければなりません。
システム運用後にバグが発見された場合は、情報システム担当者に速やかに
通知があるような仕組み作りも必要です。通知を怠ると、データベースに不
整合が生じ、システム担当者が気がついたときにはもはや復旧不可能となり
致命的な打撃となる可能性もあるためです。
また、システム開発をアウトソーシングした場合は、このようなアフターフォ
ローを、迅速かつ柔軟に対応してくれる開発会社を選定する必要があります。
開発会社によっては
「それは仕様です」
「環境に問題があります」
「開発担当者が不在でわかりません」
と一点張りで、まともなフォローが望めない会社もあります。
確かに不具合ではなく仕様であるのに、ユーザーが勘違いしているというケ
ースもあるかもしれませんが、それはそれとして、誠意ある対応をしてくれ
る開発会社を見極めましょう。
一方、パッケージソフト（※）を使用している場合は、アウトソーシングし
ている場合と違い、「迅速かつ柔軟な対応」は期待できません。しかし、多
くの場合、開発・販売会社のサポート窓口から、バグを修正したプログラム
を入手することが出来ます。ぜひ問い合わせてみましょう。
ともかく、「バグ」は、開発会社・ユーザー共になくしてしまいたい厄介者
ですね。
（※）次回は、「パッケージソフト」について触れたいと思います。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■このメルマガは？■■■■■■■■■■■■■■■■■■■■■■■■■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
このメルマガでは、中小企業経営者の方々を想定して、IT・情報システム用
語をやさしく解説いたします。また、新人情報システム担当者、新人システ
ム・エンジニア、新人コンサルタント、学生の方々もお読み頂けます。
中小企業経営者の方々にとって、情報化は大きな問題でしょう。
しかし、「IT」等と言っても、よくわからない・・・。SCM、CRM、DSS、EC、
EDI、ERP、TCP/IP、SMTP、POP3等と、アルファベットの組み合わせがいっぱ
い出てきてわけわからない・・・。本当は、企業のトップとして旗振り役で
なければならないのに、若い奴らに任せている。
そんな、中小企業経営者の方々のために「少しでもお役に立てたら」という
思いで発行してます。
本メルマガは、「小難しい定義」と「やさしい解説」の２部構成です。
「小難しい定義」は、どこにでもありそうな、いわゆる用語説明です。
一方、「やさしい解説」は、小難しい表現（IT用語）を一切使わない解説で
す。また、「やさしい解説」中でやむなく使用したIT用語については、別の
号で別途解説していきます。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■編集後記■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
今日は、経営者仲間と情報交換・・・・・というより、単なる飲み会で、品
川に行く予定です。
しかし、品川へはお客さんもいないし、余程のことがなければ行くことはあ
りませんが、たまに品川に行くたびに驚くのが、めざましい発展です。新幹
線も停車するようになりましたしねぇ。
１０年ちょい前、大学生だった頃、通学で毎日品川へ通ってました（そこか
ら歩いて白金へ・・）。その頃は、何にもなかったのですが・・・。
そういえば、私が住んでいる横浜市の「戸塚」の隣の駅である「東戸塚」で
すが、学生時代東戸塚のファーストフード店でアルバイトをしてました。そ
の頃は、ほんっとに何にもなかったのですが、最近は妙にこじゃれた西武や
ダイエーが出来て、ずいぶんと発展してしまいました。
その一方で、私の出身地である福岡県の大川市（家具の街）は、帰省するた
びに廃れてきてます。
私のように故郷を捨てて出て行ってしまう人が多いからですよねぇ・・。
こまったもんです。
では、また。
■□■━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
発行元：有限会社インフォバリュー
http://www.infovalue.co.jp/
発行者：代表取締役 福島雅規
melmaga@infovalue.co.jp
※ご意見、ご希望、ご相談等、お気軽にお寄せください
配信中止はこちら http://www.infovalue.co.jp/melmaga.htm
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━■□■
|
