あれれ…^^;のバグ取りＳＯＳ
バグとは、データやシステムに有る害虫です。
バグ（害虫）の多くは、あなた自身の不注意や知識不足によって発生します。
その意味で、”他人が意図して送り込んで来るウィルス”とは区別されています。
バグは、自分自身を疑わなければ発見出来ないので、ウィルスよりも厄介かも知れません。
勿論、バグを恐れていては、コンピュータの運用は出来ません。
しかし、バグが有る事を念頭に照査を行えば、品質向上にもつながります。
データ作成に自信が無い人も、バグ取りの手法さえ覚えれば一人前。
データ作成に過剰な自信を持つ人よりは、良い結果を得られること請合いです。
（そもそもデータが完全でも、システム運用での問題が有れば誤作は発生します。）
自分を疑う術無くして、良い結果は出せないのです。
バッチシステムを使った計算が、うまくいかない原因には、次のことが考えられます。
１．文法バグ（データの様式に間違いが有る）
２．論理バグ（データの設定に間違いが有る）
３．システムバグ（システムそのものに欠陥が有る）
４．運用間違い（システムの運用方法に間違いが有る）
５．操作間違い（システムの運用手順に間違いが有る）
番外：ワーニング（ｗａｒｎｉｎｇ）
バッチデータの作成後は、最低限、これだけの事に注意しながらシステム運用を行います。
”計算が異常終了する”とか”出力結果がおかしい”場合は、上記のいづれがか原因です。
（コンピュータが壊れていたから…という原因は、かつて聞いた事がない。
コンピュータが壊れていれば、まず、計算そのものをかけられないはずです。）
１、文法バク
（１）症状と原因
このバグは、システム計算の異常終了という形で現れます。
主に、データ作成者の不注意が原因で発生します。
例えば、ＤＡＴＡとタイプするところをＤＥＴＡとタイプしていたり、
必要なキーワードが不足していたり、定型様式に準じていなかったりです。
どちらかと言うと、初歩的なミスが大半を占めるため、
”文法エラーくらいは、取っておいて下さい。”というのが決り文句です。
（２）対処法
初歩的なミスならば、システム側から何が間違いなのか通知する事が可能です。
システム計算が異常終了した際に、
”ＳＹＮＴＡＸ”
と表示されれば文法エラーです。
問題は、どの構文に間違いが有るのか？なのですが、これは、あなたが調べます。
仮に、作成したデータが１０００行有れば、全てを疑う必要が有ります。
当然、この辺りの構文が疑わしいのでは…という絞り込みが必要になります。
絞り込みの手法
①エラーメッセージを検討する
親切なシステムは、画面に ”この文法が悪い”と日本語メッセージを表示します。
しかし画面表示だけがエラーメッセージではありません。
場合によっては、特殊な拡張子の付いたファイルに英数字だけで作成されています。
その意味を理解する努力が有れば、文法バグの８割は解決出来ます。
②データのトレースを行う
どこで計算が止まったか？を知れば、その近辺の構文に問題有りと判断出来ます。
しっかりしたシステムは、ログ（計算の流れ）を出力するので調査しましょう。
（一般にログは、特殊な拡張子の付いたファイルに英数字だけで作成されています）
③枝葉を取り除く
１０００行のデータも、よく見れば
”幹と枝葉”
に分けられます。
（多分、幹が３割、枝葉が７割といったところでしょう。）
最低限必要なデータだけ残して、計算をかければ、３割の部分だけに集中出来ます。
３割の部分に問題が無くなれば、後は、１割ずつ枝葉を増やして計算を繰返します。
どこかの枝葉を付けたとき、計算が異常終了すれば、その１割に原因が有る訳です。
ここまでやれば、文法バグの退治は大丈夫。
逆に、ここまでやっても、計算が通らない場合は、その他のバグも疑いましょう。
大まかに言うと、幹の部分の計算が通らない場合は、システムバグを疑いましょう。
枝葉の部分の計算が通らない場合は、論理バグの可能性も疑いましょう。
本当に厄介なのは、論理バグとシステム運用問題なのです。
バグ・メニューへ戻る
２、論理バク
（１）症状と原因
このバグは、システム計算は正常なのに ”結果がおかしい”という形で現れます。
（システム計算が正常ならば、結果が正しいなどと、夢々思わないで下さい。）
しかし、文法バグが無いのに、システム計算が異常終了する場合が問題です。
その場合にも、論理バグの可能性が有るからです。
例えば、コーナーＲ３５を３０と設定しても、システムはそれが正しいと解釈します。
（人間の常識ではＲ３５が一般的でも、実際、Ｒ３０が必要なことも有るのです。）
ところが、コーナーＲ３５を３５０と設定するとどうでしょう？
システムは、数値だから正しいと判断して計算を続行しますが、
計算が進むと、コーナーＲが大きすぎて、外形が成り立たない場合が有ります。
成り立たない物を、資料として出力出来ないので異常終了するしかないという訳です。
これも、どちらかと言うと、初歩的なミスが大半を占めるのですが、
”論理バグは、充分照査して下さい。”としか言えないのが実状です。
論理バグの大半は、人間の思い込み・勘違いにより発生しているからです。
（正しいと信じていることを、間違いだと認識するのは容易ではない。）
（２）対処法
システム計算が正常に終了していれば、資料の出力は可能になっているはずです。
出せる資料は全て出して、全てを照査することが肝要です。
（効率の良い照査は下記参照）。
しかし、後者の異常終了を論理バグだと特定する事は、本当に困難です。
私の経験上では、行き詰まった場合の論理バグ率は、６割以上だと思います。
（システムバグ：１割？、運用間違い：３割？、文法バグ：行き詰まらない？）
①ログファイルのワーニングを照査する
②枝葉を細分化する
③類似工事のデータと比較する
④問題箇所のデータを再作成する
他にも、全ての可能性を全て疑い、得られる助言には全て耳を傾ける。
出来るという自信と、出来ないという挫折感を感じつつ全力を尽くしています。
でも、人間が成長する時とは、こんな時かも知れませんね。
効率の良い照査
①照査の順番
重点的なところから、一つずつ、確実に固めていく。
橋梁で言えば、”線形”を固めておかないと、後の照査は全て無意味になります。
大まかには、”線形”、”主材”、”２次部材”の順番。
”主材”と”２次部材”は、時として重ね合せての照査も必要です。
②照査のポイント
構造物には必ず ”取合い”が有ります。
逆に考えると、線形が正しければ、それを利用して作られる他の資料の線形は正しい。
同じような発想が出来る資料が無いか、事前に検討しておく事が肝要です。
また、同じような資料が有る場合に、どちらに主眼を置いて照査するか？
一般に、システムで出力出来る資料は膨大です。
全てを事細かに照査していて納期が近付くと、照査漏れの発生率が大きくなります。
人間が照査するのだから…と言う前に、照査漏れくらいは防ぎたいものです。
③修正のタイミング
私自身、照査している資料全てが満点だったことは、有りません。
出力結果の不良原因が分かれば、まず、元のデータにフィードバックが必要です。
しかし、その際問題になるのが修正のタイミングと再照査です。
構造物に ”取合い”が有る以上、何かを修正すると必ず何かに影響が出ます。
特に、”一貫”と言われるシステムは、想像すら及ばない事に影響が出ます。
私は、”修正は、全ての資料を照査後一括して行う方が良い”と考えています。
”間違いに気付けば即修正”は、聞こえは良いけど ”泥縄”と考えています。
ここまでやれば…という評価が難しいのが論理バグの対処です。
論理バグはシステム運用問題と連動している事も多く、その判断すら容易ではありません。
システムに長けた人でも、実ジョブの知識が不足していれば、良い結果は出せません。
言われた事をやれば…と思う前に、言われた事の重大さも考える必要が有るようです。
バグ・メニューへ戻る
３、システムバク
（１）症状と原因
このバグは、システム計算の異常終了と出力資料の不良の両面で発生します。
システムが運用条件を保障しているのに、正しい結果が返って来ない状態です。
システム開発時のテストと運用実績の量が少ないと頻発するバグです。
一般に商品と名が付けば、めったに表面化することは無いのですが、出ると大変です。
そのために、システムサポートと呼ばれる方々が居られるくらいなので…。
（つまり、このバグが表面化すると個人の力では解決不可能という意味。）
ただし注意すべき点は、システムバグと運用間違いを混同しないことです。
解釈にもよりますが、”マニュアルに出来ると書かれていないこと”が問題になります。
”システム ＝ 何でも出来る”と考えるのは、”車 ＝ ベンツ”と同じ考え方です。
（２）対処法
まず、”明らかにこの近辺のデータがおかしい”という絞り込みを行います。
それから絞り込んだ項目について、マニュアルの記述を詳細に検討します。
すると、出来ると書かれて無いのに、常識的に出来ると思っている事が見えてきます。
（出来ると書かれている事が出来ないのならば、システムバグの可能性が有ります。）
出来ると信じていた事の根拠が見つからない場合、システムサポートに確認します。
私の実績では、この時点でシステムバグの確率が１０％、他の要因が９０％です。
（本来、商品にシステムバグなんて無いのです。）
バグ・メニューへ戻る
４、運用間違い
（１）症状と原因
これは一般にバグには分類しませんが、計算が異常終了する際に考慮すべき問題です。
システム制限や改訂情報を無視すれば、当然、思った結果は得られません。
データ作成者のマニュアル理解不足に起因するのですが、マニュアルは曲者です。
（何かの一節に ”マニュアルはシステムを作った人の覚書き”というのが有りました。）
実際にマニュアルを作ってみると、全ての事柄を想定して対処法を書くのは不可能です。
だからと言って、マニュアルを読まない、理解する努力をしないのは論外です。
教えてもらうだけでシステムの運用が出来るのなら、あなたでなくとも良いのです。
（２）対処法
①マニュアルはいつでも開ける状態にすること。
確かなシステムならば、改訂・バージョンアップも頻繁に発生します。
最低限、何が変わったかの情報は、自分なりに整理しておく必要があります。
データ作成時には、思い込みで作業を行わないことが肝要です。
②他の工事の正しいデータを参考にする。
自分の作成手法と異なる部分が有れば、原因の把握を行います。
他の工事とまったく同じ手法を用いて異常終了が起これば、原因の絞込みも容易です。
また、案外、”そう言えばあの時も同じ事で…”というのもよく有る話です。
③データ作成時に ”これで良いだろうか？”と疑問を持っておくこと。
疑問が有れば、原因の絞込みもスムーズです。
何も考えずにデータ入力出来るのならば、単価の安い業者に任せましょう。
バグ・メニューへ戻る
５、操作間違い
（１）症状と原因
これも一般にバグには分類しませんが、データに絶対の自信が有る場合には疑いましょう。
データを修正したのに結果が直らないとか、先程まで流れていた計算が流れなくなった…。
システムと言っても、それはパソコンなりＥＷＳなりの上で動作します。
（コンピュータの基礎知識無しに、システム運用が出来ているのなら、まさに奇跡です。）
コンピュータの基本的な操作や資料整理まで、指示してくれる人は居ません。
（２）対処法
①フォルダー・ディレクトリ内の情報は、更新日付順に並べる習慣をつける。
ファイルを修正すれば、更新日付も変わるのが常識です。
ＵＮＩＸならば、ｌｓ －ｌｔ ｜ ｍｏｒｅ は、必須です。
②ファイル修正を行えば、必ず、最新リストの出力をする。
修正しても、最後に登録を忘れると、何ら結果は変わりません。
最新リストと修正前のリストは、必ず、比較する習慣をつけましょう。
③不要なファイル・資料は、削除する習慣をつける。
勿論、バックアップを取っておく事は常識です。
古い資料を保管するのなら、古い資料には ”旧”と書いておきましょう。
④計算の手順は、マクロ化するなり紙に書き出して張り付けるなりする。
物事には手順が有るのです。
知っていても出来ないのならば、出来るような工夫をしましょう。
バグ・メニューへ戻る
番外：ワーニングの話
システム計算を行うと、いたる場面でワーニング（ｗａｒｎｉｎｇ）の文字を見かけます。
”警告”という意味なので、一般に、プログラミングの世界では、嫌われます。
しかし、バッチ計算では、”注意”といった意味合いが強いようです。
”ワーニングは問題ない” と誰もが言うために、案外、見逃され気味です。
”そこへその数値を設定しても良いけれど、普通はそんな値ではないですよ？”
と注意してくれている訳で、実際、論理バグの大半は、これが原因です。
エラーやアボートといった言葉だけではなく、
ワーニングにも要注意！！
バグ・メニューへ戻る
実用メニューに戻る
メニューに戻る