ヒューマンエラーをなくそう

ヒューマンエラーとは、人間のミスの事です。例えば、新幹線がコンピューターの故障で遅れる場合は、コンピューターのエラーが原因ですが、人間がコンピューターの操作を間違えた結果遅れた場合はヒューマンエラーが原因という事になります。

ヒューマンエラーは当然、間違えてしまった人の責任ですが、「間違えてはいけません」と説教するだけでは再発防止にはなりません。ましてや、日勤教育のような罰を与える事でヒューマンエラーが減るかというとそんな事はなく、むしろミスを隠そうとして取り返しのつかない事になる場合があります。

ここでは、ヒューマンエラーをどうすれば起こらなくするかについて見て行きましょう。

”カズというサイン”とは
「キングカズは、ブラジルでプロのサッカー選手を目指している子供達にサインボールをプレゼントした。カズは２００個ものボールにKAZUというサインを入れていたのだ」というエピソードの改変コピペで、例えば「イチロー選手は、シアトルでメジャーの選手を目指している子供達にサインボールをプレゼントした。２００個ものボールにKAZUというサインを入れていたのだ。」と、誰であろうとサインは必ずＫＡＺＵになっている、というジョーク（インターネットスラング）があります。

どうやら最初にコピペした人が、KAZUの部分がローマ字であったために見落としたのだと思いますが、名前にカズのつかない人がＫＡＺＵと他人の名前のサインをしたという事で別な意味で面白くて広まったりもしました。（同様のコピペに「お前ら実際に球場行って、門倉の練習や試合を生で見て言ってんの？」というものもあります）

以前、北海道日本ハムの公式ホームページのニュースのコーナーで、「キャンプインのお知らせ」という話題があったのですが、その次や、次の次のお知らせの表題が、しばらく「キャンプインのお知らせ」になっていた事がありました。という私も、他のページをコピーした後、<TITLE> </TITLE> タグの中を変えるのを忘れる事がよくあります。大抵は、Googleのウェブマスターツールで警告が出るので気がつくのですが。

このような現象を、ここでは「カズというサイン」と呼ぶ事にします。

プログラムにおいてのカズというサイン
これと同様な事がプログラミングでもよく起こります。たとえば、

というフォームの入力チェックのプログラムの場合、名前とメールアドレスの入力を必須にしたかったのに、$emailが空であっても「名前を入れてください」というメッセージを表示してしまいます。

プログラムというのは同じ部分の繰り返しですから、似たような部分は前に作ったものをコピーして違う部分だけを変えて作る事がよくあります。しかし、よほど気をつけていないと、あるブロックをそっくりコピーして中の変数名を書き換えるつもりが、１箇所だけ変数名を書き換えるのを忘れてた、なんて事になってしまいます。そうなると、変数が思わぬ値に書き換わってしまいます。

変数名の直し忘れは、たとえ変数名が必須の言語であったとしても、前に使っていた変数を直さずに使ってしまうわけですから、未定義エラーにもならず、発見しにくい間違えに発展します。特に変数関係の間違えは、実行しても即誤動作にはつながらず、本稼動してから変数が期待通りの値になっておらず、ユーザーが思わぬ損害を受けてしまう場合もあります。

また、例にあるような入力エラーを示すメッセージの間違えは、入力エラーをしなければ発見できないため、作った本人が発見しにくい間違えの１つでもあります。作った本人はどうしても入力必須の所は入力してしまうし、違うエラーメッセージが出ていたとしても脳内変換して正しいものと読み替えてしまったりもします。

カズというサインを防ぐ
この現象を防ぐためには、エディタの一括変換を使います。といっても、一括変換では、コピー元や思わぬ場所まで変換してしまう恐れがあるため、変換する前に一工夫します。

現在プログラミング中のウィンドウとは別に、新規作成のウィンドウを作成します。



このように、「新規作成」で作った無題の窓に、改変したい箇所だけコピペします。あとは、改変した変数名をエディタの置換で変更します。これなら、コピー元やその他の無関係な場所まで改変してしまう心配がありませんし、部分的に改変し忘れる心配もありません。

この方法を使う場合の注意点としては、部分一致しないようにする、という事です。例えば、$ondoという変数名を$ondo2置換する際に、もしこの範囲内に$ondorugoという変数名があると、$ondo2rugoになってしまいます。部分一致する変数名は一括変換の範囲には入れないように注意しましょう。

もう１つの注意点は、変数名だけでなくコメントや出力メッセージも書き換える必要がないかどうか調べた方が良いです。例えば、温度を抽出している箇所を改変してレス番を抽出しようとする箇所で、コメントが「//温度の抽出」となっていると、コメントと実際が矛盾してしまいますし、レス番の指定が違うのに、エラーメッセージで「温度の指定に誤りがあります」と出てしまうと、「温度は合ってるのに、おかしいなぁ」って事になってしまいます。

メッセージの一括置換では、半角／全角の違いはもちろん、大文字／小文字や、日本語表記／ローマ字表記の違いにも注意しましょう。でないと、カズをイチローに置換してもKAZUという文字が残っていた、という事にもなりかねません。

無事改変が終わったら、無題からコピーして、元のプログラムの方にペーストすれば無事完了です。

先祖がえりとは、プログラムが以前の状態に戻ってしまう現象を言います。例えば、

バージョン1.00を改良して1.01を作り、
バージョン1.01を改良して1.02を作り
バージョン1.02を改良して1.03を作ったとします。

ところが、ある日、セカンドＰＣ（とか、ノートＰＣとか）に入っているバージョン1.01を改良して、バージョン1.04を作ってしまったとします。そうすると、バージョン1.02、1.03の間で改善されたバグが、また復活してしまう事になります。この現象を先祖がえりと呼びます。

先祖がえりが発生する原因
1人の人間が１つのＰＣでプログラムするなら問題はないのですが、仕事を家に持ち帰って、職場のＰＣや自宅のＰＣで作業したりしているとよく発生します。また、複数の人間が同時に同じプログラムの別々の不具合を修正した場合、Ａという人間がバグａを直し、Ｂという人間がバグｂを直していると、バグａのみが直っているバージョンと、バグｂのみが直っているバージョンが作られ、バグａｂともに直っているバージョンが存在しない事になってしまいます。

その後、なんとかバグａｂともに直っているバージョンが作られたとして、その後にＣさんがバグＦＩＸ前のソースを元にバージョン２を作ってしまうと、以前は直っていたはずのバグａ、バグｂがまた発生してしまいます。

先祖がえりを防止する
先祖がえりのほとんどの原因は、同じプログラムのソースを、それぞれの人がそれぞれの端末のハードディスクに入れている事によります。この状態では、誰かがあるバグを直したとしても、別の人が他のバグに気がついて直すと、両方が直ってるバージョンが存在しない事になってしまいます。


それを防ぐには、まず複数の人が同じプログラムのバグを直そうとしないという事が第一です。次に、直し終えたら、最新バージョンをファイルサーバーに置くようにするという点です。

BさんはＡさんが作業を終えるまで、また、ＣさんはＢさんが作業を終えるまで待ちます。そうすれば、同時に同じプログラムを改変される事はありません。また、それぞれがバグを直し終えた段階で最新版をファイルサーバーにアップする事で、ファイルサーバーが常に最新版という事になり、先祖がえりを起こす心配もなくなります。

この場合、それぞれが端末のハードディスクにコピーせずに、ファイルサーバー上で直接上書き保存する事で、さらに先祖がえりを防ぐ事もできるかもしれませんが、そうするともしＢさんが何らかのミスをしてソースの一部（もしくは全部）を削除してしまった場合、Ａさんの労力までもがパーになってしまいます。安全のためには、面倒でもいったん端末にコピーしてから作業をし、完成後にファイルサーバーに戻す方が良いでしょう。

もちろん、sambaサーバーはRAID-1でミラーリングするなどして、データーの消失だけは避けるようにしておきましょう。

業務プログラムでよくやってしまうのが、表記を統一してないというミスです。

例えば、「商品コード」「商品名」「数量」「単価」「金額」という売り上げの一覧を表示させてから、プリントしたら「商品No.」「品名」「数量」「価格」「金額」になっていた、という事があります。同様に、日時売り上げ表と月次売り上げ表、入力画面と入力確認画面など、同一のシステム内で表記が統一されない、という場合がよくあります。

商品コードと商品No.と品番、などはプログラムを作る側としては同じようなものだし、複数人でプログラミング作業をしている場合には、えてして類義語というものは脳内変換を起こしてしまう場合があります。なので、画面に表示する場合と印刷する場合で表記が異なってしまったりします。

製造業などで、ある製品の部品の一部を作る場合、その部品を製造している会社にとっては「製品」であっても、発注元からみれば「部品」だったりします。例えば、電車で使うモーターを作る会社にとって、エナメル線やボルトなどは部品でありモーターは製品ですが、発注元から見ればモーターは部品の１つにすぎません。

なので、作ってる側は「商品No.0001」と呼んでいるモーターが、発注元では「品番 XA136510SDX」と呼ばれ、別のコードがつけられている場合も少なくありません。だったら、発注元に合わせろと言うかもしれませんが、複数のメーカーにモーターを出荷している会社では、メーカーごとに品番が異なったりして、統一できない場合がままあります。この場合、商品Noと呼べば自社番の事で、品番と呼べば発注元がつけている番号の事だ、という風に、区別している場合があります。

価格にしても同様です。定価の事を「価格」と呼び、卸単価の事を単に「単価」と呼んでいる所もありました。

というように、プログラマーの脳内で類義語を変換したりはせず、同一システム内では呼称を統一する必要があります。特に、別の顧客向けに作ったプログラムをコピーして流用する場合には、呼称には十分注意する必要があります。

見積書、納品書などの印刷物を作る際に、自社名というのが入ると思います。

自社名というのはプログラムする人間にとっては見慣れない文字列の集まりです。人間というのは文脈で文章の意味を判断しますので、多少の入力ミスなどがあっても脳内変換をかけて補完して読もうとします。しかし、固有名詞には文脈というものがなく、またしばしば既存の英単語や既存の日本語のどの言葉にも当てはまらない文字列になっていたりします。

例えば、「あたさたえご株式会社」という会社があったとします（※これは、今適当にキーを入力してできた名前ですので、実在の会社とは一切関係ありません）。これをプログラマーが見て「あさださえこ株式会社」と解釈して、自社名にそう印字したとします。

帳票と言うものは自社名が違っていると書類として意味の無いものになってしまいます。特に見積書や請求書などの法的に有効な書類となるべきものであればなおさらです。そのため、作った帳票は作り直しになるばかりか、名前を間違えられた客はたいそうお怒りになると思います。

Windowsパソコンには「コピペ」という便利なものがあり、固有名詞はどんなに見間違いがないと自信があっても、コピペを使って入力するべきです。例えば、お客様であれば契約時に交わしたメールなどがあればそれを、もしくは、相手のホームページがあればそこから名前をコピペします。

もちろん、相手のホームページやメールのフッダが間違っているかもしれませんが、それならば「それを見て作ったから」ととりあえずは弁明ができると思います。

名前というのは、とかく間違えやすく、かつ、間違えると大変失礼であるという性質上、入力はより慎重に行うべきです・・・という私も、ひらがなやカタカナで自分の名前を書いた際に、正しく読んでもらえたためしがありません。