テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。

「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。

この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文や文章の筋道を組み立てる」ことに役立つ推論の形を見ていきます。

はじめに

どちらが「論理的」だと感じますか?

図1-1、PさんとQさん、どちらが「より論理的」だと感じますか? その理由は何ですか。

図1-1 食堂で注文を話し合うPさんとQさん

「論理の言葉」を覚えたら

“実践編”のテーマ

論理スキル”実践編”では、”入門編”で出てきた「基本的な論理の言葉」を基にして、文や文章の論理構造を読み取ったり、筋道立った文を作ったりするための「推論」の形を見ていきます。

不具合/故障のチケットやテストサマリレポートを書きあぐねた経験はありますか。テストベース(要件定義書、機能仕様書、ユーザーストーリー、etc.)や返ってきたチケットを読んで、「どんな場合にどうなるのかわからないな?」「何故この対応でよいと言えるんだろう?」などと感じたことはありますか。

ソフトウェアの世界でも、(長めの)文/文章を読み書きする機会は多くあります。こうした困りごとをなくすためにも、論理の言葉の使い方、使われ方の感度を研ぎ澄ませましょう。

●入門編:テストエンジニアのための論理スキル[再]入門
記事一覧はこちら|Sqripts

推論: 話の筋道をつくる、読み取る

推論とは

何か言いたいことがある時、最終的に言いたいこと(結論)と、その結論の前提があります。結論も前提も何かしらの主張や判断ですが、ここではざっくり「文」と呼びます(本連載では、文脈によって「主張」「判断」「文」を使い分けます)。

前提となる文(主張/判断)をつなげて組み立て、結論となる文(主張/判断)を導くことを推論(inference)と言います。(図1-2)

1-2 “推論”とは

推論では、前提(根拠)から結論までのつながり、話の筋道が重要です。(図1-3)

  • 前提が、結論(言いたいこと)の根拠になっている
  • 前提から結論までのつながりに無理や飛躍がない
図1-3 推論で大事なこと

その話の筋道を組み立てたり、話の筋道をチェックしたりするのが、推論の形

そこで活躍するのが、“入門編”で見てきた論理の言葉です。

形が整っていれば自動的に「正しい筋道、正しい推論」となるわけではありませんが、形がよくない立論は言っていることが正しくてもよい主張とは言えません。(「「真」と「妥当」」の節参照)

推論の種類と、”実践編”で扱う推論

推論には種類がいくつかあります。(図1-4)

図1-4 演繹と帰納とアブダクション

演繹(えんえき)

演繹(deduction)とは、ひとつ以上の前提から結論を導き出す推論の形です(図1-4は「前提から結論」をいくつか組み合わせた複合的な形になっています)。

何かを根拠とともに主張する時、正しいと広く受け入れられた事柄に基づいて個別の事例を論じる時、などに使われます。

前提がすべて正しいなら、結論が正しいかどうかは形から判定できます。

帰納(きのう)

帰納(induction) とは、個別の事例から一般的/普遍的な前提(各事例に共通する規則・法則、性質・特徴など)を導き出す推論の形です。

ソフトウェアのテストで、「画面AでPという操作をしたら故障Xが起こった」「画面Bで操作Pをしたら故障Xが起こった」……「どの画面でも、操作Pをしたら故障Xが起こる(のでは?)」と仮説を立ててテストを広げていくのは帰納的な推論の働きです。

有限個の事例に基づいているため、この推論から導かれる「事例に共通すること」は必ずしも正しいとは限りません(“当てはまらない例外”があり得る)。

アブダクション、レトロダクション

アブダクション(abduction)、またはレトロダクション(retroduction)とは、個別の事例から、その事例(結論)に至る前提や理由を導き出す推論の形です。

アブダクション的な推論として、デバッグがあります(故障から、その故障を引き起こす原因である欠陥を推定する)。また、欠陥の 原因分析でもこの種の推論が働きます。

この推論から導かれる「前提と当てはまる推論」も、必ずしも正しいとは限りません(デバッグでも、原因を特定したと思ったら違っていた、やり直し。ということは多々ありますね)。

“実践編”で取り扱う推論の種類

“実践編”では、前述のうち演繹的な推論/思考を形成する推論の形を取り扱います。

帰納やアブダクションでも必要になる、思考の基盤です。

演繹的な推論にもいくつか種類がありますが、本連載では「ふたつ以上の前提(主張/判断)から、結論となる主張/判断を導く」形式を主に取り扱います。

「真」と「妥当」 ~正しさの留意点

正しい推論であるためには、ふたつのことに留意する必要があります。(図1-5)

図1-5 真と妥当

「真」であること ……内容の正しさ(真偽)

前提が間違っていたり、結論が間違っていたりしていては、正しい主張とは言えません(当然ですね)。正しい前提に基づいて、正しい結論を導出するものである必要があります(図1-5の上の文が真です)。

「妥当」であること ……話の筋道の正しさ(妥当性)

前提や結論が真でも、適当に(自分に都合よく)理屈をつけるのでなく、話の筋道が「よい形」をしている必要があります(図1-5の上の文が妥当です)

「よい形」とは:

  • 論理の言葉を適切に(意味と働きに即して)使っていること
  • 文(主張)と文(主張)とのつながりの中で矛盾や飛躍を生じていないこと

真偽も大事だが、話の筋道も大事

前提や結論が正しくても、非妥当な(よい形でない)推論は間違った推論です。

次のa, bどちらも、①②③それぞれは正しいとしても、①②から③を主張することは妥当ではありません。

  • (a) ①イヌはイヌ科の動物である。②イヌは哺乳類である。∴③イヌ科の動物は哺乳類である。
  • (b) ①ネコにはしっぽがあるか、またはにゃあと鳴く。②うちのネコはにゃあと鳴く。∴③うちのネコにはしっぽがない。

一方、前提や結論は間違っていても、妥当な(よい形をしている)推論は作れてしまいます。

  • (c) ①哺乳類は空を飛ぶ。②イヌは哺乳類である。∴③イヌは空を飛ぶ。
  • (d) ①ネコには縞模様があるか、または単色である。②うちのネコには縞模様がない。∴③うちのネコは単色である。

両方揃って、初めて正しい推論と言えることになります。

内容の真偽はその内容を吟味しないと判断できませんが、筋道の正しさは形から判断できます。本連載で取り上げる「推論の形」はその筋道の正しさを確保する役に立ちます。

なお、「よい形」を作れていない推論や、内容に誤りがある推論の特徴を「誤謬(ごびゅう)」と言います。これらについてはシリーズ後半の記事「気をつけたい落とし穴」で取り上げる予定です。

冒頭の“問題”

「食堂で注文を話し合うPさんQさん」は「「論理的」ってどういう感じのこと?」を感じてもらいたくて考えたもので、考え方の正誤や優劣を論じるものではありません。

Pさんの主張を整理・補足すると、①初めての店では外れのなさを優先して注文する。②唐揚げは大体どの店でもおいしい(から、外れがない/少ない)。③唐揚げ定食を注文する。

となっていて、①と②から③が無理なく出てきます。

Qさんの方はどうでしょうか。

①初めての店では(その店の「推し」として)「本日のおすすめ」を頼む。②さらに煮魚定食はこの店で一番安い(から、懐に優しい)。③煮魚定食を注文する。

Qさんの主張には、それが嫌いな食べ物でも頼むの?とか、「本日のおすすめ」がメニューの中で一番高かったらどうするの?という疑問が生じます。前提①②と結論③の間に飛躍がある感じがします。

(本“問題”は、『論理的思考の技法Ⅰ』を参考にしました)

(注:「食事の注文は論理的に考えてなされなければならない」と言っているわけではありません!)

(注:どちらの「注文の論理」も、ありだと思います)

(注:何にせよ心地よく選んで心地よく食事を楽しみましょう!)

クイズ

次の主張は「よい形」をしていると思いますか。

(『例解・論理学入門』を参考にしました)

(解答は次回に)

問1

Aさんの性格を考えると、①Aさんはギャンブルに手を出すと破産する。

しかし、②Aさんはギャンブルには手を出さない。

従って、③Aさんは破産しない。

問2

その時代、①家柄がよくて、裕福ならば、誰でも結婚できた。

②彼の家柄はよかった。

しかし、③結婚できなかった。

従って、④彼は裕福ではなかった。

参考文献

  • 鈴木美佐子 『論理的思考の技法Ⅰ〔第2版〕』法学書院 2013
  • 弓削隆一, 佐々木昭則 『例解・論理学入門』 ミネルヴァ書房 2009

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

  • TopeconHeroesダーヤマ, 『分かりやすいプレゼン資料 1秒で伝わるビジネスイラスト集』 インプレス 2016
    • 人物画(シルエット)をお借りしています。
  • Loose Drawing
    •  人物画をお借りしています。

SHARE

  • facebook
  • twitter

SQRIPTER

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

gst lab.

記事一覧

gst lab.所属

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

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

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

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