技術知識やコーディングセンスとは別の次元の切り口で、世の中には２種類の技術者がいます。

一つはバグ・不具合の原因調査がとてもお上手な技術者。それと、そうでもない技術者です。

この「バグ・不具合の原因調査」のスキルを舐めてはいけません。

当たり前ですが自分が実装を担当しているシステムで、1つのバグや不具合が見つかれば、必ず原因の調査が入ります。

その調査について、早い人なら平均1分で原因を確定させるのに対して、下手な人は10分かかります。

私の直感では、3人月規模のシステムの場合、β版のシステムテストでバグ・不具合は100個くらい見つかりますので、早い人はこれを

{(原因調査)1分＋(修正)5分}×100個 ＝ 600分 ＝ 10時間

と、1日強で完了します。

一方で、下手な人だと

{(原因調査)10分＋(修正)5分}×100個 ＝ 1500分 ＝ 25時間

という感じで3日くらいかかります。

実際は、修正作業時にも『なぜか思った通り動かない』ことがあって、そのたびに原因調査と修正を繰り返していきますので、その差はこんなものではない、というのが現実です。β版に到達するまでの作業工程でも相当の差が生まれているはずです。

では、不具合の原因調査が早い人と遅い人にはどのような違いがあるのでしょうか？

■ 答えは20の扉というゲームに

みなさんは、「20の扉」というゲームをやったことがありますでしょうか？「しりとり」のように何人かでやる道具も何もいらない簡単なゲームです。

全員参加型のクイズの一種。出題者1名と任意の数の解答者で行う。観客が存在する場合もある。

1.まず出題者が設問として伏せた事柄を設定
ex) 「私の思い浮かべている物を当ててください」
2.残りの参加者がそれに関する質問を行う
ex) 「それは生物ですか？」
3.出題者はYesかNo、（および「YesかNoでは答えられません」）でのみ質問に対する回答を行う（補足は可）
ex) 「No　それは生物学で言う生物には当てはまりません」

以下2.3.を繰り返すことで 設問の内容を見抜くゲームである。

(出典　20の扉とは (ニジュウノトビラとは) [単語記事] - ニコニコ大百科)

私は子供の頃、父親とお風呂にはいるとこのゲームをよくやっていました。

やっていましたというか、兄も含めてやらされていまして、父親が問題を出し、私と兄で熱い湯に肩まで浸かって、当てるまで出られないという拷問のような仕打ちでした。

早く当たればすぐ出られますが、手間取るとなかなか出られず、また20問で当たらなければ最初からやり直しなので真剣です。思えばなぜ昔のお父さんはあれほどまでに、いかに熱い風呂に長く浸からせるかに必死だったのでしょうかね。。

ともあれ、このゲームは、何かを短時間で調査するセンスが試されます。

質問を無限に投げていいのであれば、どんな意味のない質問でもダラダラとすればいいのですが、20という数が決まっていますので、質問に計画性が求められます。

たとえば、「足は６本ですか？」と聞いて「はい」という回答を得たのにも関わらず、次の質問で「昆虫ですか？」と聞くのは痛いです。足が６本で昆虫でない生き物というのがほとんどいないからですね。

また、「足は６本ですか？」の答えが「はい」なのに「鳥ですか？」「爬虫類ですか？」という質問も相当意味がありません。よくそういう無駄な質問をしてしまい、兄に風呂に沈められたものです。

正解まで一直線で行くためには一つのセオリーが必要となってきます。

■序盤は可能性を絞っていく

問題の調査においては、はじめは可能性を絞っていく作業を行っていきます。

それも大きな区分から、次第に小さな区分になっていくように質問の順序を構成しなければなりません。

始めの大きな絞込としては、足の数などはかなりいいかも知れません。

「足は４本ですか？」

「足は６本ですか？」

「足は２本ですか？」

この質問をすれば大枠で、それが何もの（動物、昆虫、鳥や人間、それ以外の特殊な生き物）であるかがわかります。

仮に「足は２本ですか？」で「はい」を得たとします。

すると、鳥系の可能性が高いです。

「空を飛びますか？」

と聞いてみます。

「いいえ」と答えを得たとします。となると、この辺で「飛べない鳥」か「人間」か「恐竜」、「架空の生物」あたりに絞られます。

ここで大事なことは、この絞込作業の途中で、父親の考えそうなことを推測して

「それはカラスですか？」とか「ティラノサウルスですか？」とか当てに行ってはいけないということです。

可能性が１つとか２つとかに絞られるまで、「それは○○ですか？」と聞いてはダメで、レアな可能性も含めて徹底的に排除していきます。

つまりこのゲームのコツは本当の最後の最後まで「当てに行かない」ことにあります。

■不具合の原因調査も「当てに行かない」

始めの話に戻りますと、不具合の原因調査もこの作業手順を追う必要があります。

調査の序盤は、可能性を絞っていく作業をします。

可能性を絞るというのは、すなわち膨大な可能性の中から、「あり得ないものを消していく」作業と同義です。

何か試してみて、「これではない」と分かればそれに絡む原因をごっそり排除します。

そんなことをするとたいていの原因調査は、4~5ステップくらいの試行テストで分かってしまうのです。

それをいきなり「カラスじゃないか？」「ティラノサウルスなのか？」などとやっているから、何十回も仮説を立てないとそのものズバリの原因に辿り着かないですし、余計な試行調査の時間がかかりますし、簡単には想像できないような複合原因を見抜けないのです。

また、そのような「闇雲に当てに行って、偶然当たった(ような気がする)原因」を基にして書いた調査報告書は、信憑性・信頼性に欠けるというのもあります。その原因は確かに必要条件かもしれないですが、十分条件になっていないことがあるからです。

滅多に使わないプリンターで半年ぶりくらいに印刷をかけてみたら、うんともすんとも言わない。

このような現象の時、みなさんならどのようなテストをしますでしょうか？

ここでいきなりドライバーを再インストールするような作業が「カラスじゃないか？」という質問にあたります。

• 同じ端末から別のプリンターで印刷をしてみる
• 別の端末から同じプリンターで印刷してみる
• 文書ファイルではなくプリンタのプロパティのところから『テスト印刷』をかけてみる
• ......

環境によってテスト項目は様々だと思いますが、これらの調査が闇雲な試行錯誤とは違うことがわかりますでしょうか？一つ一つの作業を行うことで、それにまつわる可能性をごっそりと排除しています。

1回の調査で、1/3の可能性を排除できれば、5ステップで(2/3)の5乗、すなわち13.17%まで絞り込めます。

実際は後半になるほど切り捨てられる可能性は大きくなる傾向がありますので、大抵の不具合調査は5ステップもあれば十分です。

「プリンターの型番とOSで相性問題を検索する」ようなことをするのは最後の最後です。