こんにちは。株式会社ゼストでWebアプリケーションエンジニアをしている海老原です。
技術選定、プログラム設計、毎日のコードレビュー。ソフトウェア開発の現場は、常に判断と議論の連続です。その中で、結論は出したけれどなんだかモヤモヤする、という経験をしたことはありませんか？それ、もしかしたら誤謬を含んでいたかもしれません。
"誤謬"とは、パッと聞く限りではもっともらしく聞こえるが、よく整理すると正しくない議論や推論のことです。例えばこのようなもの。
「世界のどこかに青色のイチゴは存在するでしょう。みなさんの中に、青色のイチゴが存在しない根拠を説明できる人はいますか？いないですね、それなら私の主張は正しいことになります。」
うーん、そうかも？でも、なんだか騙されてる気がしますね！
この記事では、このような誤謬を60パターン紹介している本、「誤謬論入門」の中から3つをピックアップして、エンジニアや開発チームに置き換えて解説していきます。
ちなみに青色のイチゴの例は本の中で「無知に訴える論証」という誤謬として紹介されています*1。反論がない、もしくは反論をしようとしないことを根拠に正当性を主張することが「無知に訴える論証」です。"沈黙は肯定とみなす"は論理的には間違っているんですね。
誤謬のパターンを知ることで、日頃議論している中で「本当にそうなの？」「なんだかズレてる気がする」とモヤモヤしたときに、論理的に間違っているかどうか、間違っているとしてどのように間違えているのかを整理しやすくなります。
まずは誤謬の紹介に入る前に、前提になる言葉や考え方を見ていきましょう。
議論の標準形式
誤謬を理解する第一歩は議論を標準形式に再構成することです。本記事では簡略化したものの説明に留めるので、詳しい解説を知りたい方はぜひ本を読んでみてください。
- 〜だから（前提）
- 〜だから（前提）
- したがって（結論）
標準形式ではこのように、前提を積み重ねてそこから結論を出すという形に整理されます。重要なのは、議論の中で明言されていない要素も明示することです。例えば、「明日は朝イチで対応が必要です。トムは朝早く起きられますよ("は"を強調して発声)。」を標準形式にすると、このようになります。
- 対応は朝早い時間にする必要がある。（前提）
- トムは朝早く起きることができる。（前提）
- [トム以外は朝早く起きられない、もしくは困難だ。（暗黙的な前提）]
- [したがって、トムが対応するべきだ（暗黙的な結論）]
言葉には出していないものの、"は"を強調したことで暗黙的に提示したい主張が確かにあるため、標準形式に再構成する過程でこれを明示して整理していきます。*2本記事では例文中に登場しない前提や結論は[]で囲って表現することにします。
それでは準備が整ったので、誤謬を見ていきましょう。*3
■ 1. 衆人の意見に訴える誤謬
「みんなが使っているのだから、それは良いものだ」
これは、技術選定において周囲の評判やトレンドに判断を委ねてしまうときなどに起こるパターンです。「多数派論証」「バンドワゴン効果」とも呼ばれます。
例文
「このライブラリはGitHubのスター数が2万もあるんです。多くの人が支持して使っているんだから、我々のプロジェクトで使ってもきっと良い選択のはずです！」
論理の構造（標準形式）
この主張を標準形式に再構成すると、次のような構造になります。
- このライブラリは多くの人に支持されている。（前提）
- [多くの人に支持されているライブラリが悪い選択のわけがない。（暗黙的な前提）]
- したがって、このライブラリは我々のプロジェクトにおいても良い選択だ。（結論）
何が間違っているのか
この主張の問題点は、暗黙のうちに置かれた2つ目の前提にあります。 「多くの人が支持していること」と「このプロジェクトにとって良いこと」は、論理的には別のパラメーターです。前者を根拠にこの結論を出すことはできません。
このように、単に多くの人が受け入れているという理由である主張を受け入れさせようとすることを「衆人の意見に訴える誤謬」といいます。*4
大きな数字や「みんなが言っている」というような言葉が出てきたら注意して考えた方が良いかもしれませんね。
■ 2. 不当な選択肢
「Aか、さもなくばBか。二つに一つだ」
複雑なトレードオフを単純化しすぎて、選択肢を極端な少数に絞ってしまうことです。「誤った二分法」とも呼ばれます。
例文
「新機能の実装を優先してスパゲッティコードを量産するか、それとも綺麗なコードを書くためにリリースを3ヶ月遅らせるかのどちらかだが、リリースを遅らせることはできない。」
論理の構造（標準形式）
この主張を標準形式に再構成すると、次のような構造になります。
- 選択肢は、「スパゲッティコードを受け入れる」か、「リリースを大幅に遅らせる」かの2つしか存在しない。（前提）
- リリースを遅らせることは許容できない。（前提）
- [したがって、スパゲッティコードを受け入れるしかない。（暗黙的な結論）]
何が間違っているのか
この推論の誤りは前提の1つ目にあります。選択肢がAかBしかなくAでないならBである、というような形式の前提を「選言的前提」と言いますが、ここでは、本当は2択ではないのに2択であるとして選言的前提をおいていることが誤りです。実際には開発スコープの中で削れる部分を探したり、主要な機能だけを切り出して段階的にリファクタリングするなど、選択肢はまだまだあるはずです。
極端な少数択が頭に浮かんだときには、一度立ち止まって本当にその2つしかないのか、選択肢は網羅されているのかを検討したいですね。
■ 3. 論点先取の定義
「本当の〇〇ならば、こうするはずだ」
議論の中で、自分の主張を守るために言葉の定義を変更してしまうことです。
例文
Aさん：「エンジニアなら、難しいアルゴリズムも即座に自力で実装できるものだ」
Bさん：「でも、あの優秀なシニアエンジニアは、既存のライブラリを使って効率的に済ませていますよ」
Aさん：「だとしたら、彼は"本物"のエンジニアではないね」
論理の構造（標準形式）
- エンジニアはアルゴリズムを自力実装できるはずだ。（前提）
- あるシニアエンジニアはアルゴリズムを自力実装しない。（前提）
- [（本物の）エンジニアはアルゴリズムを自力実装する。（定義的・暗黙的な前提）]
- だから、そのシニアエンジニアは（本物の）エンジニアではない（前提）
- [したがって、「エンジニアはアルゴリズムを自力実装できる」という主張は守られた（暗黙的な結論）]
何が間違っているのか
ここでの問題は、反論（Bさんの指摘）が出されたときに、結論を守るために「エンジニア」という言葉の定義を勝手に書き換えてしまっている点です。誤謬の名前にある「論点先取」とは、結論としたい主張を前提にすることによって、論理的な正当性なしに結論を真とすることです。本来は「これまで見てきたエンジニアはアルゴリズムを自力実装していた。」というような経験を前提とするべきですが、自分がしたい主張の根拠としては弱く疑わしいため、「本物はこうだ」と言って結論自体をこの議論での定義的な前提とすることで結論が妥当であるかのように思わせています。
例文では「本物の」とあからさまな表現をしていますが、これが隠されていることもあります。議論の対象になっているものの定義が書き変わっていて、それによって結論が影響を受けている場合にはこの誤謬を疑ってみても良いかもしれません。
まとめ
今回紹介した3つの誤謬をおさらいしましょう。
- 衆人の意見に訴える誤謬：隠れた前提（人気＝最適）を疑う。
- 不当な選択肢：前提の選択肢（A or B）に漏れがないか疑う。
- 論点先取の定義：結論を守るために定義が書き換えられていないか疑う。
誤謬論は、思考の誤りを見つけるための指針です。誤った判断をしないために、知っていて損ナシな知識だと思います！
