【第1回】見つけるための論理|実務三年目からの発見力と仮説力

帰納的な推論発見的な推論(アブダクション) は、
私たちがソフトウェア開発の現場/実務で(知らず知らずにでも)駆使している思考の形です(それどころか日々の暮らしでも使っています)。

それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。

今回は、推論の形を今一度おさらいし、本連載で取り上げるふたつの推論の概要を知りましょう。

「論理的」はつまらない?

演繹的な推論の特徴

[実践編]で見てきた論理(演繹的推論、図1-1)には、次のような特徴があります。

  • 前提に含まれていることだけから、論理の言葉の働きに従って一定の結論が導かれる
  • 前提と結論には必然的な関連がある
  • 前提が正しい(真)ならば、結論も正しい(と認めざるを得ない)
  • 前提にないこと(意外な事実、新奇な発見、etc.)が結論で出てくることはない
図1-1 演繹的推論
図1-1 演繹的推論

演繹的な推論は、既知の事実/知識や普遍的な真理に基づいて個別の場合/個別の主張を論じる場合や、主張の正しさを論証する場合に活躍します。

論証(検証)のための論理 といった形容をされることもあります。

半面、「結論で主張することはみな前提にあることばかり」「当たり前のことを言うだけ」「新たな知見を得るものではない」と批判されることもあったそうです。

[実践編]で例として出てきた
「今日は雨だからAさんは自宅にいる」にしても、
「ソクラテスと電気羊」にしても、
前提からは思いもしないあっと驚く結論を出すのではありませんから、そのような“批判”も頷けなくはありません。

前提はどこから来る?

そうした批判の詳細や当否はここでは掘り下げませんが、「前提に含まれていることを基に」というその前提は、そもそもどこからどうやって出てきたのでしょうか。

356日欠かさずAさんの自宅を見張り、天候による過ごし方の違いを観察したのでしょうか。

「すべての哲学者は電気羊の夢を見る」という前提を得るために、すべての哲学者の見る夢を調べ上げたのでしょうか。

どちらも現実的にきわめて困難、ないし不可能でしょう。

そもそもどちらの例でも、その前提は演繹的な推論では得られそうもありません。

「発見」のための論理

非・演繹的な推論

演繹とは異なる形を持つ、非・演繹的な推論があります。

非・演繹的な推論その①は、「帰納(帰納的推論)」です。

図1-2 非・演繹的な推論①(帰納)
図1-2 非・演繹的な推論①(帰納)

非・演繹的な推論その②は、「アブダクション」といいます。

図1-3 非・演繹的な推論②(アブダクション)
図1-3 非・演繹的な推論②(アブダクション)

これらの推論には次のような特徴があります。

  • 結論として、前提に含まれていない 新たな知識 を引き出す
    • (パン屋のチェーンP全体の営業終了時刻(または終了基準))
    • (特定のパンの売れ行きと近所の学校の生徒の購買傾向との関係)
  • 前提と結論との間に必然的な関連がなく、なんらかの「飛躍」がある
    • (調査した店舗が当てはまるからといって、すべての店舗がそうとは限らない)
    • (焼きそばパンが残っていたのは、近所の学校の休校とは関係ないかも知れない)
  • 前提が正しい(真)からといって、結論が正しいとは限らない
    • 正しいと言える 蓋然性(確からしさ) が相当程度にある、にとどまり、誤りがある可能性を否定できない
  • 結論が正しげに思えても、事例が追加されるなどして前提が変わると、それまでの結論が成り立たなくなる可能性をはらむ
    • (よその街の店舗を調べたら、16時以降も店を開けているかも知れない)
    • (近所の学校の休校が明けても売れ残るかも知れない)

演繹的な推論に比べると「(正しさの度合いが)弱い」半面、
新たな知見を得る際には大活躍する、発見に寄与する論理 と言えます。

帰納的推論の概略

図1-4 帰納的推論
図1-4 帰納的推論
  • 一般化
    • 複数の有限個の事例から、同様の事例すべてに共通するもの(規則・法則、性質、原因、etc.)を見出す
    • 「特殊から普遍へ」「部分から全体へ」などとも称される
  • 蓋然的
    • 有限個の事例を基に考えているので、「きっとそうだろう」「そうであるに違いない」とまでしか言えない。“間違い”の可能性が常にある
    • 結論の確からしさは前提の質と量に依存する
  • あくまで仮説
    • 「きっと」「に違いない」が示すように、結論を導いただけでは「仮説」どまり

アブダクションの概略

図1-5 アブダクション
  • 仮説の形成
    • 結果(事象や事実)を説明する仮説(因果関係、法則、理論、etc.)を考える
  • 蓋然的
    • 「結果を説明する原因/理由や、結果に至る過程(プロセス)」は仮説の域を出ないので、“間違い”の可能性が常にある
  • あくまで仮説
    • 考えついた段階では道半ば
    • 「その考えで矛盾なく整合的に説明できる」ことの論証を経てようやく仮説になる
    • 綿密な論証や、実証(実際にそうであることの確認)が望まれる

論証が控えていてこその「発見」

……ここまで読んできて、「論理の言葉なんかより、新しい知識を形成する「発見」の方が重要で、大事なのでは」と思う人もいるかも知れませんが、
三つの種類の推論はそれぞれに持ち場があり、それぞれに重要 だと考えてください。

一般化も説明仮説も、「すべての場合に当てはまるのか」「本当にその原因・過程でこの結果に至ったのか」などを確かめることで説得力が出ます。
その際には演繹的な推論が欠かせませんし、その論証で誤りがあったら、せっかくの発見が台無しになってしまいます([実践編]の「形式面の落とし穴」、「非形式面の落とし穴」を参照)。

この連載では

「一般化」を指向する推論(細部に違いのある形がいくつかあります)を「帰納的推論」として扱います。

「因果関係や結果に至る過程(プロセス)などの説明仮説の発見」を指向する推論を「アブダクション」とします。

なお、アブダクションと呼ばれる形の推論は古代ギリシアには「アパゴーゲー」と呼ばれていたようです。そのギリシア語に当たる英語として提唱者のチャールズ・パース(論理学者・哲学者)がつけた名称が「アブダクション」だそうです。

アブダクションには「誘拐」というよくない意味があるのですが、本連載ではパースの命名を尊重してこの名称を用います。

ちなみに、日本語だと「仮説形成」という語を使う人もいます。

さらに余談ながら、パースはレトロダクションとも呼んでいたそうです。日本語だと「遡及推論」とする人もいます。
「目の前の事実(結果)から“遡って”考え、原因から結果への道筋を説明する仮説を考える」ということでしょう。

(実は)(あんがい)おなじみの論理

帰納もアブダクションも、私たち誰もが生活の中で行なっている推論 です。

図1-2, 1-3を見て、 こうした推論はどちらも、日ごろからしている と感じた人も多いのではないでしょうか(そう感じてもらえそうな例を挙げました)。

また、ミステリーが好きな人はこうした思考に見覚えがあるでしょう。
名探偵が見せる「灰色の脳細胞の閃き」の多くは、帰納やアブダクションを思わせるものがあります。
(そんなわけで、この連載では「品質探偵コニャン」が随所に登場します!)

品質探偵コニャン

ソフトウェア開発で働く帰納やアブダクション

こうした思考は、ソフトウェアの開発でも行なわれています。
特に動作確認やデバッグ以降の作業で大活躍します。

また、開発終了後のプロセス改善(原因分析)などでも重要な働きをします。

図1-6 ソフトウェア開発で働く帰納、アブダクション
図1-6 ソフトウェア開発で働く帰納、アブダクション

私たちが実務でやっていることの一端を振返ってみましょう。ここに挙げた以外にも、「こんな局面でこんな考え方をしている!」と思い当たる人もいるでしょう。

いずれも、当てずっぽうや“なんとなく”で行なうことではありません

  • 動作確認や設計中のデバッグでは……(帰納的な推測)
    • 期待と異なる振舞い(インシデント)が見つかったら、
      詳細(入力やデータの内容、操作や手順、設定や構成、etc.)を確認する
    • 詳細の一部を変えて動かし、同じ結果になる場合の共通項を考える
    • (共通項がインシデントの原因かどうか、実際に動かしたり、ソースプログラムを調べたりして確かめる)
    • (共通項から、「詳細の一部を変更したらどのような結果になるか」推測する)
  • テストで故障が検出されたら……(帰納的な推測アブダクション的な推測)
    • 同じ故障を起こしている他のテストがあったら、
      詳細(事前条件、入力データ、操作や手順、設定や構成、etc.)に共通項がないか考える
    • 詳細に共通項がある他の機能/フィーチャーに同様のテストをする(類推)
    • 故障を引き起こす原因を考え(仮説)、それに基づいた詳細でテストをする(仮説の実証)
  • テストからのデバッグ(故障の原因究明、欠陥の除去)では……(アブダクション的な推測)
    • 当該の故障を起こす原因と、故障に至る過程やそうなる理由を考える(仮説)
    • 原因箇所(候補)を見つけたら、それが故障を引き起こすことを机上で、または実際に動かして再現する(仮説の検証)
    • 欠陥を修正したら当該の故障が起こらないことを確認する(仮説の実証)
  • プロセス改善時の原因分析では……(アブダクション的な推測)
    • 対策を施すべきエラー(誤り)について、そのエラーがどの工程で、なぜ発生したか(発生原因)や、なぜ検知できなかったか(見逃し原因)を、結果であるエラーから遡って推測する(仮説)
    • (通常、エラーに至るまで「原因と結果の連鎖」があるので、それぞれについて「結果を引き起こした原因」を掘り下げる)
    • 「原因」を掘り下げたら、「原因」から結果であるエラーに至る過程を机上で再現する(仮説の検証)
    • (「原因」がいくつか考えられる場合は、再発防止にとって最も重要なものを選定する)

これらの論理の仕組みや考え方、留意点を、これから見ていきましょう。

参考文献

  • 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979
  • 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008
  • 藤野登 『論理学 伝統的形式論理学』 内田老鶴圃 1968
  • 米盛裕二 『アブダクション 仮説と発見の論理』 勁草書房 2007

図版に使用した画像の出典

  • Loose Drawing
    • 人物画をお借りしています。
  • 品質探偵コニャン:Produced by Sqripts. No Unauthorized Reproduction.

SHARE

  • facebook
  • twitter

SQRIPTER

望月信昭(もちづき のぶあき)

gst lab.

記事一覧

gst lab.所属

前世紀は主にソフトウェアエンジニア/プログラマーとして活動。
今世紀はソフトウェアテストのコンサルティング、実務の支援、テスト関連技術トレーニングの企画・開発・講師/ファシリテーターといった領域で活動。近年は若年層ソフトウェアテスト技術者の育成に関わることが多い。
ISTQB-FL、テスト技法、論理スキルなど、ワーク盛りだくさんのトレーニングやワークショップを提供中。

note⇒ https://note.com/nob_mottie/

Sqriptsはシステム開発における品質(Quality)を中心に、エンジニアが”理解しやすい”Scriptに変換して情報発信するメディアです

  • 新規登録/ログイン
  • 株式会社AGEST