単純ミスの恐怖

単純なミスって結構多いですね。
例えば、レポートのタイトルとか、日付とか。
特に以前書いた文章を雛形にしたときなんかは特に多いです。

それから、プログラミングに多いのが、関数の仕様違いによる想定外の誤動作。

例えばround関数。
四捨五入には、以下の二種類が存在するのをご存知でしょうか。

①JIS Z 8401 規則B による丸め：端数が0.5未満なら切り捨て、0.5以上なら切り上げて丸める。
②JIS Z 8401 規則A による丸め（偶数丸め、最近接丸め、JIS丸め、ISO丸め、銀行丸めともいう）：端数が0.5未満なら切り捨て、端数が0.5より大きいならは切り上げ、端数がちょうど0.5なら切り捨てと切り上げのうち結果が偶数となる方へ丸める。
というものです。

この四捨五入を行う関数にround関数というのがあります。
ExcelやJava、Oracleでround関数を使うと①の四捨五入なりますが、VBでround関数を使うと②の四捨五入になります。

これがうっかり間違ってしまうと潜在バグとしての地雷に変化します。

よくあるのが、「エクセルのシートに計算式を埋め込んでいたが、処理が多くなったのでVBA化した場合」にそのまま計算式を移行したために地雷化するケース。

お金を扱うケースでは１円でも計算が合わなければ徹夜してでも原因を追求します。
お客様から「決算処理で１円合わないぞ！」って怒鳴られて、「明日の朝までに原因を調べて報告しろ！」なんてことがありますが、泣きそうになりながら原因を調査すると、「こんな所にround関数が…」ってことがあるわけです。

round関数の仕様を国際標準化して欲しいと恨みがでますが…。

同じ関数でも、言語や使用環境が異なると違った動作をするものがあります。
ダウンサイジングや機器の新設に伴う改修作業の時には注意が必要ですね。

東証のシステムがダウンしたり、航空管制システムがダウンしたりと、マスコミを騒がせる色々な故障がありますが、不具合の原因って案外単純なものだったりするんですね。

最近のエンジニアに多いのが、トランザクションの使い方が分かってないこと。
排他制御だとかトランザクション管理、あるいはセッションの管理、リソース管理といった所に単純なミスが見られます。

これは些細なバグですが、システム全体がダウンする大きな故障原因になるんです。
しかも目立たないから困ったもんです。

昔、３ヶ月から半年に一度、システムがダウンするという現象がありました。
お客様からはクレームの嵐で、現地調査でも社内調査でも、使用方法やロジックに不具合らしいところはないし、プログラムをトレースしても、さっぱり原因が判らない。

最後にはメーカーの製造工場まで行って原因調査を行いました。
調査の結果、メーカーから提供されていた共通関数内部で、数バイトのメモリ空間を確保したまま解放をしていなかったことが原因で、連続使用を続けている間にメモリ空間が圧迫されダウンするというものでした。
答が分かれば簡単なことです。でも調査に１ヶ月かかりました。
新製品というのは、どうしても初期不良がありますからね。

皆さんも気をつけてください。
大きな事故の原因は、結構単純ミスだったりしますから。