帰納的な推論と発見的な推論(アブダクション)は、
私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。
それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。
＜実務三年目からの発見力と仮説力 記事一覧＞※クリックで開きます
今回は帰納的推論で「発見」をするために参考になる方法（見方考え方）を紹介します。
再現・枚挙的帰納
第2回で紹介した枚挙的帰納の例(A)、(B)（第2回の図2-3を図3-1として再掲）、それぞれでどんな風に推論しているか、コニャン君の脳内を覗いてみましょう。
【注意】以下に再現する“推論の筋道”は、「こういう形/流れもある」を示すもので、誰でも・どんな場合でもこのような流れを辿る、と主張するものではありません。
(A)の形の場合
図3-1 (A)、コニャン君の思考の筋道は図3-2のようになるでしょう。
こうした思考を支えるのが、前回解説した自然の斉一性や因果性という概念でした。
プログラム(ソースコード)に混入する欠陥は自然現象ではありませんが、筆者の経験によれば、斉一性に似たような状況が生じることがあります。
- ある箇所のある処理で生じたエラー（誤り。勘違い、思い込み、考慮不足、仕様の誤読、etc.）は、他の似たような箇所での同じような処理でも生じがち。
- ソースコードのコピペも欠陥を伝播しがち。
- 複数の箇所から呼び出されるモジュールに欠陥があると、特定の条件を満たしたら同じような故障が各地で発生することが起こりがち。
【訂正】この(A)、第2回では「共通項Pを見つける」例と述べましたが、「特殊文字を入力すると(共通項P)、フリーズする(共通項Q)」形と言えますね。間違えました。
(B)の形の場合
(B)は、共通項Pだけでなく共通項Qも見つけ、両者の関係性を見つけるのに、ちょっと“手数”がかかるでしょう。
（図3-3。図3-1との対応の参考として、吹き出し中に丸数字をつけています）
発見＝観察＋推論の方法
「実験的探究の4方法」
図3-1 (A)(B)のような推論の方法は、何といっても観察
――起こっている事実を見落とさず、適切な詳しさで見る―― に支えられています。
（観察については後ほど触れます）
そして、よい観察に基づいて“共通項”（中でも因果関係）を見つけるための方法を、19世紀イギリスのJ.S.ミルという哲学者が考えました。
自身の著作の中では「実験的探究の4方法」と題されていますが、「ミルの帰納法」「ミルの方法」などとして知られます。
（解説している方法は5つだが、ひとつは2方法の組合せ）
- 一致法
- 差異法
- 一致差異併用法
- 剰余法
- 共変法
本記事では、「ソフトウェアの動作確認やテストで、故障や不具合に遭遇した局面」や「デバッグ中に原因を探る局面」を想定して、結果から原因を探る場合に焦点を当てて説明します。
以降の解説では、
- 前件(先行する事象群)：
故障や不具合の発生に先立つ環境・設定、データ、状態、コード中のロジック、入力・操作、などを指します。 - 後件(後続する事象群)：
ソフトウェアの実行が引き起こす出力・表示、状態(の変化)、データの変化、など（故障や不具合自身を含む）を指します。 - (前件や後件の)要素：
前件や後件中の互いに識別可能なものごとを指します。
J.S.ミルの帰納法
一致法：多くの事例の「共通点」に着目する
- 着目する事象a（ソフトウェアの故障や不具合など）を生じる事例をふたつ以上集める。
- ①前件の中に全事例で共通する要素がひとつだけある(要素Aとする)。
- ②要素Aだけが全事例で一致している。
- ③要素A以外の前件の要素が異なると、事象a以外の後件は異なる。
①②③が共に満たされるなら、その要素Aが着目する事象aの原因（または、原因の不可欠の一部分）である、と考えることができます。
【特徴】
- 「ある要素がなくても着目する事象が生じるなら、その要素は原因から取り除いて考えてよい」という考え方に基づく(消去法)。
- 着目する事象を含む事例をいくつか集めれば適用できる。
- 「特定の要素を取り除いて結果を見る」といった実験ができない場合に適している。
- 後述の差異法の前段階として原因の候補を絞るのに適している。
【注意点】
- 事例は「前件では要素Aだけが共通、後件では事象aだけが共通している」こと。
他の要素や事象が共通していると、因果関係が絞り切れない。
（別の方法の適用などにより、さらに絞り込むことが必要） - 事例は多いのが望ましい。
（少ないと、原因の絞り込みができなかったり、偶然の結果を原因と間違えたりするおそれが大きい） - 前件の要素Aと事象aがともに、隠れた他の原因から生じている場合(結果の共存)を識別できない。
- 事象aが、前件の要素Aではない原因による場合を識別できない。
- 事象aが多数の原因の複合により生じている場合、先行事象Aがどのように関与しているかは判らない。
差異法：異なる結果を生む「違い」に着目する
- 着目する事象aを生じる事例(積極事例)と、生じない事例(消極事例)を集める（最低、各ひとつずつ）。
- ①前件に特定の要素Aがあると、事象aが生じる。
- ②前件に特定の要素Aがないと、事象aは生じない。
- ③それ以外は、前件と後件は全く同じ。
①②③が共に満たされるなら、要素Aが事象aの原因（または、原因の不可欠の一部分）である、と考えることができます。
【特徴】
- 「ある特定の要素を除くと着目する事象が生じないなら、その要素は原因と考えてよい」という考え方に基づく(これも消去法)。
- 積極事例、消極事例それぞれひとつずつあれば適用できる。
- 別の方法で推定された因果関係を確認するのに適している。
（事象の発生原因がある程度推定できている状況で適用するのがよい） - 一致法では識別できない「事象aが、前件の要素Aではない原因による」場合を誤認しない。
【注意点】
- 条件を満たす事例を集める手間がかかる。困難な場合もある。
- 「特定の要素を取り除いて結果を見る」といった実験ができない場合には適さない。
- 原因の特定に適用する際には注意が必要。
（発生原因の推測がないと、ブルート・フォース的に手当り次第に試すことになる）
一致差異併用法：ふたつの方法の合わせ技
- 着目する事象aが生じる事例(積極事例)を2つ以上、 生じない事例(消極事例)を2つ以上、それぞれ集める。
- ①積極事例では、先行する要素Aと後続の事象aが含まれていることだけが共通している。
- ②消極事例では、先行する要素Aと後続の事象aがともに含まれていないことだけが共通している。
①②が共に満たされるなら、要素Aが事象aの原因（または、原因の不可欠の一部）である、と考えることができます。
（消極事例の前件は、積極事例のそれと同じか類似していると対比が明確になる）
図3-1(B)、図3-3「ソフトウェアXはソフトウェアZがプリインストールされている機種で故障Fを起こす」は、この考え方を用いているわけですね。
図3-3 の②’で、「他の点で、起こる機種と起こらない機種に共通項はない」ところから、「故障Fが起こる場合と起こらない場合の違い」が絞り込まれます。
（他にも共通項がある場合は、さらに絞り込みを行なうことになるでしょう）
【特徴】
- 差異法だけでは「A : a」の組を見つけられないような場合でも使える。
- 事象が起こる場合(積極事例)、起こらない場合(消極事例)の共通点と相違点を広く見渡して検討できる。
【注意点】
- 積極事例と消極事例を集める手間がかかる。
剰余法：既知の関係との差分に着目する
- 着目する事象が生じる事例を取り上げる。
- ①事例の一部の事象は、既に前件と後件の関係(因果関係)が判っているとする。
- ②事例の前件・後件から、既知の前件・後件の組(①)を全て取り除く。
②で残った前件・後件の組は、それぞれ前件(原因)と後件(結果)と考えることができます。
【特徴】
- 差異法のバリエーションと言える。
- 既知の因果関係を用いて原因探求の省力化が期待できる。
この方法を適用すると、次のような事態に遭遇することがあります。
- ある事例がある（例：A, B : a, b, c）。
- このうち、A : a, B : b は既知の因果関係である。
- そこでこれらを取り除いたら、「nil : c」になる！？
（注：nil＝空のこと、つまり前件が空）
これは、a, b, cという後件に対して、候補として考えたA, Bの他に前件がある可能性を示唆しています。
こうした事態になったら、前件の見落とし・見逃しがないか確かめるか、隠れた前件の存在を仮定して要素Cを探すか、といった方向に向かうことになるでしょう。
（この例は、決して「前件の要素と後件の要素は1対1対応でなければならない」ということではありません）
【注意点】
- この方法で残った前件の要素が後件で残った事象の原因かどうかは、別途確かめる必要がある
（差異法ほど強い蓋然性を示してはいない）。 - 前件の要素が複数残った場合(例：BとC)、BとCのどちら(または両方とも)が原因なのかは、この方法だけでは判らない。
- 【特徴】で述べた「既知の前件:後件を取り除くと、“前件が空になる”事態が生じ得る」は、注意点でもある。
共変法：特定要素の変化に着目する
- 着目する事象を生じる事例を取り上げる。
- 前件の特定の要素だけを変化させて(値、数量、設定、etc.)、後件の変化を見る。
着目する事象aの変化を引き起こす特定の要素Aがあったら、それが事象aの原因（または、事象aと何かしらの因果関係によるつながりがある）と考えられます。
【特徴】
- 前件の特定の要素の有無ではなく、要素の変化(値、数量、設定、etc.)に着目した方法。
- 一致法、差異法、剰余法といった、消去法に基づく方法が適用できない/しづらい場合に、特定の要素を変化させて原因と結果の関係を推定する役に立つ。
- 他の方法が使える場合でも、因果関係が推定された後に「原因と考えられる要素Aの変化が結果と考えられる事象aにどんな影響を与えるか」を調べる役に立つ。
【注意点】
- この方法だけでは、要素と事象の因果関係が確かめられない場合がある。
（前件の要素Aの変化が別の要素や事象を通してaに影響を与えている場合など） - 前件の要素Aを変化させた時に、後件に何の変化も見られないからといって、要素Aが結果にまったく影響を与えていないとは言えない。
気をつけたい点
筆者自身のデバッグ経験・テスト経験を振り返ると、一致差異併用法、剰余法、共変法が活躍した記憶があります。
特定の要素だけを変化させたり、特定の要素の有無だけ変えたりという実験的な操作は、ソフトウェアの場合は比較的行ないやすいからでしょうか。
ミルの方法は起こった事象からその原因を見つけようとする際のガイドとして大いに参考になるものと思いますが、適用に当たって気をつけたい点がいくつかあります。
- 5つ(4つ)の方法、どれかひとつで原因を突き止められるとは限りません。
いくつかの方法を組み合わせて使うことも考えましょう。 - いずれの方法も結論を導いた段階では蓋然的に正しいと言えるにとどまります。
結論を基にさらに調べる、原因から結果への演繹的な説明を考える、
などの作業が必要です。 - また、方法は推論を補強はしますが、保証はしません。
「○○法を使っているから正しい推論であり、結論も正しいんだ」といった考えに囚われないようにしましょう。
発見を支えるのは観察（と、仮説）
ミルの方法を活かすには・観察が大切
冒頭で触れたように、帰納的推論による発見を支えるのは“観察”（と、その補助として事実の収集、記録(記憶)）です。
- 前件(先行する事象群)や後件(後続する事象等)として取り上げる事項の焦点を絞る。
（すべてを見ようとするのはかえって見落としを招きやすい）
故障や不具合の内容に応じて、操作や入力、ソフトウェアの環境やデータ、ハードウェア環境、etc.。
生じた故障は動作か、データの変化か、状態異常か、外部への出力か、etc.。 - 同じく、粒度感にも気をつける。
大まかな原因を把握するなら、故障は概要レベルで捉え、前件や後件は大づかみに区別する、
因果関係の詳細を突き止めようとするなら、故障を詳細に記述し、前件や後件は詳細に区別する、etc.。 - 調べて見込みがなかったら、「調べ方や調べるところを変えよう」という判断も必要。
ミルの方法を活かすには・もう一点
帰納的推論による発見を支えるものには、「着目した事象にまつわる因果関係を調べるに当たり、ある程度推測を立てる」という態度もあります。
一般に、起こった事象(故障や不具合)だけから何が原因(の候補)か当たりをつけるのは困難で、
「こういうことが原因となっているのではないか」といった推測が必要になります。
これも誰しもやっていることでおかしなことではありません。
この推測（説明仮説）が原因探求の道標になります。
「なんとなく・当てもなく原因を探す」のではなくて、「ある仮定に基づいた推測に沿っている」ことを意識しましょう。
（ソフトウェアの場合、仕様や設計やソースコードに基づけば推測しやすいですが、「思いがけない遠く離れた箇所の仕様/設計/実装」が影響を及ぼす場合や、外部環境要因が干渉する場合もありますし、仕様や設計が当てにならないことも……）
説明仮説に関わる推論は、アブダクションの回で取り上げます。第5回以降をお楽しみに。
★
次回は帰納的推論にもある“落とし穴”を紹介する予定です！
参考文献
- 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979
- 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008
- 藤野登 『論理学 伝統的形式論理学』 内田老鶴圃 1968
- J.S.ミル(著), 大関将一(訳) 『論理学体系 : 論証と帰納 3』 春秋社 1958
- 米盛裕二 『アブダクション 仮説と発見の論理』 勁草書房 2007
図版に使用した画像の出典
- Loose Drawing
- 人物画をお借りしています。
- 品質探偵コニャン：Produced by Sqripts. No Unauthorized Reproduction.
