バグを仕分けする三つのI/O

 ソフトウェアにおけるバグはいくつかのグループに分けて対処法を考える必要がある。一つは、正常なインプットに対して異常で均一なアウトプットを返すもの。
 二つ目は正常なインプットに対して均一でない、正常と異常のバラツキのあるアウトプットを返すもの。三つ目は、異常なインプットに対して正常なアウトプットを返せないもの。
 少なくともぼくのいる環境において、多くの場合、一番と二番のバグの違いが発生する理由というのはとくに意識されることもなく考慮されることもない。ログ上一番と二番のバグの違いがあることに気づく人もいるにはいるが。
 多くの場合、バグを解消するためには、バグとして出てきた一つ一つのアウトプットそのものは大して役に立たない。 せっかくアウトプットの均一性という観点に着目したとしても、その気づきを生かすことができなければ、障害報告書なるドキュメントに大量の文章を書く作業が積み上げられるだけで先に進むことはない。現象そのものに着目することで得られる「改善策」は多くの場合効率的でも強靭でもない。
 アウトプットが均一でないとすれば、その原因はインプットが均一ではないか内部プロセスにおいて均一な処理ができていないかのいずれかの問題があるはずだ。それに対してアウトプットが常に異常な均一値であるならば内部プロセスにおいて何らかの問題があるということに原因は絞り込まれる。実はこうした場合のほうが対応はしやすい。異常なアウトプットと正常なアウトプットが50:50であるより、100:0のほうがマシである。
 アウトプットそのもの、現象そのものに着目すると、平均値や期待値に目が行ってしまう。上の例で言うと50%の成功率と0%の成功率となるので50%の成功率に賭けたくなってくるのが人情だ。
 だがそれは錯覚だ。錯覚に陥ってしまうのは現象そのものに目を向けているからだ。問題を解決しようとする人間は、現象そのものに着目してはならない。
 現象そのものに着目することの弊害は、対応策がどうしても出口を絞る方向に流れる、つまり「異常アウトプットを外に出さない」ということだけに行ってしまうからでもある。
 つまり、自工程内での歩留まり悪化という問題を下流工程に連鎖させないということに注力してしまう。この試みそのものは正当性のある対応なのでおおっぴらに批判しがたく、そのことが結果として工程(プログラムの起動から終了までの処理)の効率を低下させる問題が積み重なって、スループットやパフォーマンス問題を作り出していく。正しい行為がより誤った原因の特定しづらい問題を作り出してしまう。