ここに挙げる文章は『デバッグ上の注意』というテキストです。
１０年以上も前、ソフトウェアの開発中に私が作ったものです。
Ａ４の紙、一枚に印刷できるように書いてあります。
誰にでもすぐに読めるところが、この説明文の最大の特徴です。
ソフトウェア開発にはデバッグという仕事があります。
デバッグとは、コンピューターソフトのベータ版（例えば開発中のゲームソフト）をテストプレイして、
バグ（ソフト上の間違い）を出してもらう作業です。
その作業者に最初に読んでもらう説明が、この紙に印刷した『デバッグ上の注意』でした。
当時、ソフトウェア開発の教科書を読みながら研究し、また、
開発現場の経験から必要に迫られて作った文章ですので、
どのソフト開発現場でも役に立つと思います。（紙、一枚にまとめるのに苦心しました）
『デバッグ上の注意』は大変参考になりますので、ここに公開することにしました。
デバッグ上の注意
１．デバッグする時は、必ずバグ表を手元に置きます。
２．バグが発生した場合は、必ずバグ表に書き込みます。
（バグはバグ表を元にして修正されます）
３．バグが発生しても、直接プログラマのところに行かないで下さい。
（プログラマのところには、数人のデバッグ者のバグ表があり
修正が順番待ちになることが、ほとんどです）
４．バグ表を、清書しないで下さい。
（まとめると、バグが解らなくなることがあります、念のため）
細かい注意点
１．どんな、小さなバグでも書き込む。どんな、大きなバグでも書き込む。
２．おかしいと思ったら、どんな事でもバグと思え。
３．バグを出すように実行にする。
（人はシステムに慣れてしまうと、本能的にバグを出さなくなります）
４．機種によって、出るバグと出ないバグがある。
その他
１．直らない、バグもあります。
（使いづらさ、仕様で決定した物、ハードウェアの仕様等）
２．デバッグは、大変な作業です。計画的に行って下さい。
デバッグはいつ終了するのか
バグの発生率は、開始日直後から上昇して、ある時期頂点に達して、それから
下降を始めます。発生率が横這い状態になった時点で、デバッグを完了させるのが
良いとされています。
バグの哲学
バグの無いシステムは、この世に存在しない。
−以上−