ベン図で見る問題への対処について

<!-- ----------------------------------------------------------------------------------- -->

# 目次
1. この記事で言いたいこと
2. はじめに
3. ベン図について
4. 問題の定義について
5. ベン図で見る問題とその対処方法の関係について
6. 要素2つ以上の問題について
7. 参考：論理的な主張について
8. おわりに
9. 複雑な問題への対処方法について(追記_2025/01/18)

<!-- ----------------------------------------------------------------------------------- -->

# 1. この記事で言いたいこと

* 問題は、最小の要素毎に分解して、分解した要素それぞれに対して対処を行いましょう
* ベン図で考えると、問題の全体図を掴みやすく、整理が簡単になるので、積極的に使っていきましょう
* 必要条件・十分条件、逆・裏・対偶だけでも十分問題解決の方法を考えることができます
* 問題の抽象化や具体化は、問題の内容を掴むために有効な手法ですが、対処すべき問題とは異なることに注意

<!-- ----------------------------------------------------------------------------------- -->

# 2. はじめに

別の記事を出すつもりでしたが、こちらの筆が乗ったので、こちらを先に出すことにしました。

みなさんは問題解決の方法に悩むことはありませんか？

自分は、自分が持つ引き出しの少なさや自分の能力不足から、問題への対処方法の視野が狭くなりがちで、「どうしたら良い解決ができるのか」「他の人が自分では考えもつかないような発想で問題を解決しているが、どんな思考回路を再現すれば似たような考えにたどり着くのか」と頭を悩ませる日々です。

個人的には、「自分はどんな選択をして良いのか」が把握できていないことが一番の問題だと感じていて、「引き出しを増やすこと」を目的に、自分では考えつかなかった発想を聞いた際には「なぜそれを考えたのか」を、その人に聞いてみることにしています。

自分が聞いた中で一番ためになっているのは、「『人』、『物」、『金』というリソースをいかに使うか」という発想でした。要は、自分が動くだけでなく、自分が周りに働きかけて動かせる範囲のリソースまで考えて問題への対処を考えろ、という話です。

そういう目線に立って、他の人の解決手段を見てみると、解決手段がある程度整理されて頭に入るようになったため、自分にとってこの考え方は一定の成果を上げていると感じています。

そんな中で気になる対処法も見えてきました。

例えば、複雑そうな問題を分析せず「こういうものだ」と決めつけて対処してしまい、「早まった一般化」「間違った類推」「例外の撲滅」「疑似相関」「前後即因果の誤謬」「因果関係の逆転」「論点先取」のいずれかに陥った例や、問題を過小評価または過大評価してしまい、バグを新たなバグで覆い隠してしまう、といったトラブルに発展する対処法です。

じゃあ、どうすれば良いのかと言いますと、わかりやすい形にかみ砕いて、論理的な構造から対処法を検討すれば良いわけです。人間は誤謬を起こしてしまう生き物ですから、気を付けていても間違いを100%なくすことは不可能です。とはいえ、90%とか99%のように削減することは可能ですから、文章のような全体像の分かりづらいものの代わりに何らかの絵を描いて、目で見て理解すれば良いわけです。

自分はここで「ベン図」と呼ばれる絵を描いて、論理構造を見直すことにしています。

というわけで、簡単なベン図と問題を対応させることで、対処法をどのように考えれば良いのか、記載していきたいと思います。

<!-- ----------------------------------------------------------------------------------- -->

# 3. ベン図について

まずはベン図のおさらいからしていきましょう。

![ベン図で見る問題への対処について-全体集合U.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/0534e027-1201-d516-c3d0-d25e3aa19aa4.png)

ベン図は上記のような、全体集合Uの中に集合を配置して考えていきます。
全体集合Uは、すべての集合を表すため、どんな集合も表していることになります。
なので、全体集合Uの中に集合Aが存在すると考えてみます。

<br>

![ベン図で見る問題への対処について-集合A.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/c4e38462-ce1f-5382-248b-1ffa8c50d188.png)

全体集合Uの中に集合Aを配置してみました。
ベン図は、こんな感じで全体集合の中に集合があると仮定して考えていきます。

上記の図では集合が1つですが、実際は2つ以上の集合を表す図を描き入れることで、集合の関係性を考えていきます。

## 演算子について

全体集合Uに集合Aと集合Bを配置して、いくつかの論理演算を表現してみました。

![ベン図で見る問題への対処について-集合の関係.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/be6a356a-5b22-7c5a-8cce-cb291adb41e4.png)

補集合(NOT)、否定
$$ \lnot A $$

和集合(OR)、選言、論理和
$$ A \lor B $$

積集合(AND)、連言、論理積
$$ A \land B $$

差集合
$$ A - A \land B $$

対称差(XOR)、排他的論理和
$$ A \oplus B $$

直和(A+B)、空集合
$$ A + B \ ( または空集合\varnothing ) $$

含意(内包、外延)
$$ B \subset A $$

3つ以上の集合を示すベン図は、複雑であるため割愛します。どのようなベン図になるか、調べてみてください。
論理の関係は、上記のベン図の関係を見て考えていくことがあります。
また、記号論理学では演算子を使って論理の関係を示していくので、ベン図一覧の下に記載した演算子一覧についても見慣れておく必要があります。

## 必要条件と十分条件について(修正_2024-11-26)

必要条件と十分条件とは、集合の「含意(内包、外延)」の関係に関する命題の特性です。
命題の要素が必要条件なのか、十分条件なのかは、真となる命題と問われている条件の主語によります。

言葉の定義が大変ややこしいため、別の解説サイトも見ながらじっくりと考える必要があります。
必要条件と十分条件の判定は、以下の通りです。

### 1. 必要条件か十分条件かのどちらかを満たす

$$ 例 : 命題「A \Rightarrow B」は真であるが、命題「B \Rightarrow A」は偽である。 $$

$$ B \subset A となり、BはAであるための必要条件であって、十分条件ではない。 $$

$$ また、AはBであるための十分条件であって、必要条件ではない。 $$

したがって、AとBのどちらを主語にするかで必要条件なのか、十分条件なのかが変わります。

### 2. 必要条件でも十分条件でもない

$$ 例 : 命題「A \Rightarrow B」も命題「B \Rightarrow A」も偽である。 $$

この場合は、必要条件でも十分条件でもないです。

元の命題の集合A,Bのうち無関係の部分があることを示唆しますが、空集合なのか、積集合や和集合なのかまでは判別できません。

### 3. 必要十分条件である

$$ 例 : 命題「A \Rightarrow B」も命題「B \Rightarrow A」も真である。 $$

この場合は、必要十分条件です。したがって、同値(言い換え)となります。

### 追記_2024-11-26
自分が勘違いしていたため、大幅な内容変更を行いました。
必要条件と十分条件は、

$$ 「A \Rightarrow B」,\ 「B \Rightarrow A」 $$

の2方向からの大小比較が必要です。
両方真となれば必要十分条件、両方偽となれば必要条件でも十分条件でもありません。

片方のみ真のときがややこしく、

$$ 例 : 命題「B \Rightarrow A」は真であるが、命題「A \Rightarrow B」は偽である。 $$

であれば、

$$ A \subset B となり、AはBであるための必要条件であって、十分条件ではない。 $$

$$ また、BはAであるための十分条件であって、必要条件ではない。 $$

となります。
したがって、主語にAを置くのかBを置くのかによって、必要条件を問われているのか、十分条件を問われているのかが変わります。

ちなみに、片方のみ真のときの必要条件と十分条件の含意関係(集合の大きさ)は、

$$ 十分条件 < 必要条件 $$

が常に成り立ちます。

## 逆・裏・対偶について

**ここでは、ベン図に絞って紹介します。実際にはベン図に限らず有効です。**

逆・裏・対偶は、演算子で表現可能なすべての集合に対して、有効な真偽判定方法です。
「命題を立てたものの、元の命題のままだと主張に誤りがあるのか判別が難しい」と感じたときに、下図の通りに命題を変更して、命題の対偶を考えることで、元の命題の真偽が分かりやすくなることがあります。
成り立たない例外があるため、条件を絞る必要はありますが、命題から例外を省けているのであれば必ず対偶が成り立つため、とても強力です。

![ベン図で見る問題への対処について-逆裏対偶.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/fdbbf6de-bdec-d113-5ce1-7b70ada58057.png)


## ベン図のまとめ

ここまでベン図とベン図を考える際に必要となる考え方を示しました。
ここで紹介したことは、問題解決の方法を考える上で、かなり役立つ考え方だと思うので、しっかりと復習しておくことをオススメします。

<!-- ----------------------------------------------------------------------------------- -->

# 4. 問題の定義について

次に、「問題とは何か」から定義します。

一般的に問題とは、「あるべき姿(理想)と現状に、差がある状態」を言います。
ビジネスでは「問題をどのように設定するかが、成功するか失敗するかの肝だ」とか言われていたり、ソフトウェアの技術者であれば「要件定義が重要だ」なんて言われていますが、要は「問題をどう定義するか」という話に帰着します。

ただ、そういう多くの人が悩むことは、自分よりも詳しい人が本を出しているので、ちゃんとした専門書を買ってもらうことにして、ここでは「設計上の問題にぶち当たったときに、どう対処すれば良いか」を考えていきたいと思います。
なので、「社内政治における上司とのやり取りのノウハウ」だとか、「設計以外の複雑な問題」だとかに悩む人達には申し訳ないのですが、本記事ではなく別のサイトを参照してもらえればと思います。

では、この記事で何を書くのかを具体的に言いますと、「バグにぶち当たったとき、どのように考えて対処すべきか」という話になります。
したがってここからは、設計の考え方やバグ取りの考え方を持ち出して、**自分がすべての問題に対して有効な手法だと思っていること** をベン図とともに解説していきたいと思います。

<!-- ----------------------------------------------------------------------------------- -->

# 5. ベン図で見る問題とその対処方法の関係について

では、問題をベン図にあてはめて考えてみたいと思います。

突然ですが、ここで問題です。
```
Q1.
集合Aで表される問題Aが発生したと考えます。
この問題Aに対処するための対策はどのように考えるべきでしょうか？
```
以下にベン図を示します。

![ベン図で見る問題への対処について-ベン図で示す問題1Q.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/0049f51e-f44d-91dd-a636-8b6010a5518b.png)

みなさんはどのように考えましたか？
私の答えはこうです。
```
A1.
問題Aに対して、必要十分な対策Aを取るべき。
```
以下にベン図を示します。

![ベン図で見る問題への対処について-ベン図で示す問題1A.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/fcc0c2b9-3ea1-084e-d056-a8a8753d9005.png)

ここで、「『問題A』ならば、『対策A』である」を命題と定義します。
この命題について、ベン図の関係を詳しく見ていきましょう。

### 問題Aが対策Aの必要条件であって、十分条件ではない場合

問題Aと対策Aの関係が以下のような関係となります。

![ベン図で見る問題への対処について-ベン図で示す問題1の解説1.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/dcf97830-561b-1eca-62db-4d18b4f44555.png)

ベン図に記載した通り、問題Aに対して対策Aが十分ではありません。
対策Aによって問題Aの一部の対策が行われましたが、問題Aの大部分が残っていると考えられます。
このとき、対策Aを実施した人が問題Aを過小評価していると、「問題Aに対して十分な対策Aを実施したのに、問題が残っている！！別のバグだ！！」と考えてしまい、問題解決が迷宮入りします。

可能であれば、まずは問題Aの全容を把握し、問題Aのすべてに対策可能かどうか判断して、問題Aに対して十分な対策Aを実施する必要があります。

### 問題Aが対策Aの必要条件ではなくて、十分条件である場合

問題Aと対策Aの関係が以下のような関係となります。

![ベン図で見る問題への対処について-ベン図で示す問題1の解説2.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/b6cdf311-ff58-dae7-386e-daab7889741e.png)

ベン図に記載した通り、問題Aに対して対策Aが過剰です。
問題Aの対策が行われたため、問題Aは解決していますが、対策Aが大きすぎるため別の問題を生み出すことが考えられます。
一番最悪なのは、対策Aによって新たなバグを生み出してしまうことです。このときに生み出されたバグは厄介です。対策Aを消すと問題Aが復活します。対策Aの過剰な部分を打ち消す対策を行うと、問題Aが復活したり、対策Aが発端のバグへの対策Bを実施しても対策が不十分でバグが残っていたり…などと、バグの無間地獄が発生してしまう可能性があります。

こちらも、可能であれば、まずは問題Aの全容を把握し、問題Aのすべてに対策可能かどうか判断して、問題Aに対して十分な対策Aを実施する必要があります。

### 問題Aが対策Aの必要条件でも十分条件でもない場合

問題Aと対策Aの関係が以下のような関係となります。

![ベン図で見る問題への対処について-ベン図で示す問題1の解説3.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/dbbbd549-c03c-832b-c4ac-6eeaf93349ee.png)

見てわかるとおり、問題Aに対してトンチンカンな対策Aを実施しています。
問題Aの全容を把握し、問題Aのすべてに対策可能かどうか判断して、問題Aに対して十分な対策Aを実施すべきです。

### 問題Aが対策Aの必要十分条件の場合

問題Aと対策Aの関係が以下のような関係となります。

![ベン図で見る問題への対処について-ベン図で示す問題1A.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/fcc0c2b9-3ea1-084e-d056-a8a8753d9005.png)

図を見ていただければわかる通り、問題Aと対策Aが同等です。問題Aの対策漏れもなく、対策Aも過剰ではないので、バグが残らないと考えられます。

というわけで、必要十分条件を満たす対策Aを実施するのが最も良いと考えているわけです。

問題に対しての焦点を合わせる…これ、大事。

<!-- ----------------------------------------------------------------------------------- -->

# 6. 要素2つ以上の問題について

またまた突然ですがここで問題です。

```
Q2.
あなたが仕事をしていると、問題Cが発生しました。あなたならどう対処しますか？
```

前の章で「必要十分な対策を行え」と言っているわけですから、「対策Cを実施する」と考えた人もいるのではないでしょうか？
しかし、今の章が **「要素2つ以上の問題」** と銘打っているわけですから、そんな簡単なわけがありません。
状況を整理するために、以下にベン図を記載します。

![ベン図で見る問題への対処について-ベン図で示す問題2Q.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/54320384-e772-8588-a1a1-000f9621272a.png)

この問題Cに対する必要十分な条件が対策Cだとすると、以下のようになると考えられます。

![ベン図で見る問題への対処について-ベン図で示す問題2A.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/0402f9f5-53a4-34e4-22a5-36ae60202ce7.png)

どうでしょうか？対策Cで問題なさそうでしょうか？
では、もう少し問題Cを詳しく見ていきましょう。問題Cだと思っていましたが、調査したところ以下のようになることがわかったとします。

![ベン図で見る問題への対処について-ベン図で示す問題2Q-1.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/09f404cb-0d22-ddcc-c82d-02ecd7ac4c29.png)

もう一度質問です。問題Cに対する対策は、対策Cで必要十分でしょうか？

<br>

はい。
では、私の答えを言います。

```
A2.
対策Cで必要十分な対策ですが。。。
```

確かに対策Cで必要十分な対策となりますが、「問題A」または「問題B」のどちらかに関わるものを取り除いた時を考えてください。
ソフトウェアの開発を行ったことのある人であればわかると思いますが、プログラムのコードというのは様々な場所にコピペして流用していきます。このとき、「問題A」または「問題B」のどちらか片方のみを採用することも多いと思います。そうすると、「問題A」または「問題B」のどちらかが別のプログラムで再現することになるため、対策Cも一緒にコピペしていくことになります。
このとき、「対策C」というのは、「問題A」または「問題B」のどちらか片方に対して、必ず過剰な対策となります。移植先で過剰な対策が悪影響を及ぼすことがあるので、対策Cというのは **正しいものの微妙な対策方法** となります。

対策Cは、一番工数の少ない対策であると考えられますが、流用時に問題Aと問題Bの重なっている場所をもう片方の対応漏れと誤認識してしまう、対策Cの過剰な対策への対策が必要となるなど、対応箇所の修正時にミスりやすい問題があります。
この場合、個人的には対策Aと対策Bに分割できるようにしておけば、どちらか片方のバグの発生要因をつぶした時に、片方の問題と対策を削除するだけで良くて、もう片方まで修正する必要がなくなると考えています。
したがって、私の答えは以下の通りです。

![ベン図で見る問題への対処について-ベン図で示す問題2A-1.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/a7d7c096-7d6c-c53e-aa1f-8bae0d7ee3fb.png)

このように、問題Cが問題Aと問題Bによって構成されているとわかったとき、対策は対策Cで行うのではなく、問題Aに対策A、問題Bに対策Bを行って、全体として対策Cを行う、という手段が最も良い対策だと思います。

## その他気になること

みなさんは、「要約して問題のポイントを考える」ということをしたことがありますか？
「難しい問題であるほど、要約が重要になる」と言われていますが、要約の使い方を間違えている人もいるのではないでしょうか？
ここでは、要約について触れていきたいと思います。

要約というのは、「情報を削って最終的に言いたいことのみ抽出する『不可逆変化』」です。
情報をそぎ落とすことで、元の問題の外延の外延の外延の…と包含関係の外に問題の意識を持っていって、抽象的な命題に変更し、元の問題の必要条件であることを確認します。これが、要約で行われている操作です。
したがって、要約で導き出した命題は、元の命題とは **別物** となります。ここが重要です。何回も言います。**別物** です。**元の問題ではありません。**

ですが、人によっては「要約して元の問題とは別の情報になった命題」に、無関係で余計な情報を付加する人がいます。これは全く論理的ではありません。問題の芯を捉えているとも言えません。
個人的に、この誤りを口で解説するのがめちゃくちゃ面倒臭いと思っているので、本当に止めてほしいです。
(「要約の意味がわかっているのか」、「要約の使い方がわかっているのか」、「要約した情報から元の情報へは戻せないことをわかっているのか」など、基本的な言語の扱い方から聞いて前提を擦り合わせないと、間違いが指摘できないため)

![ベン図で見る問題への対処について-要約について.drawio.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3774480/194073e9-2a73-e69c-2ca6-b154515b8e5a.png)

ベン図を見ればわかる通り、問題とは程遠い対策を行うことが多いです。要はあてずっぽうと変わりません。
問題は、緑色の円の部分でしかなく、N回目要約とは別物です。対策は、N回目要約の一部にかかっていても出来ず、問題に対して効果が無ければいくら増やしても無駄です。
このことをちゃんと考えて、要約を使っていきたいですね。

<!-- ----------------------------------------------------------------------------------- -->

# 7. 参考：論理的な主張について

「論理的な主張」と言うと一般的には「説得力のある主張」と解釈され、「常識が通用する意見」や「感情的に納得できる意見」がもてはやされる。
これに対して、形式論理学の世界では「言語の形式的な関係が正しい主張」のことを「論理的な主張」と定義している。この論理学の世界では「言語の形式的な関係が正しい主張」が「妥当性」のある「説得力のある主張」なのだ。
少なくとも論理学の上に立つ広義的な自然科学に端を発する学問分野は、形式論理学における「論理的な主張」を背景に成り立っている。

<br>

話が脱線するが、高校数学で習う「命題と論理」という分野は、論理の仕組みの一部を使って数の世界を表している。これを一般化すると集合論という話になる。
集合論を起点とした数学の上に成り立つ物理学やその上に成り立つ、化学、生物学、地学は、数学の世界に限定されてなお広大な論理の中で成り立つ学問であると言える。
これに対して、論理学はより一般的な言語の関係を見る学問である。(ここで言う「一般」は、数学で例えるなら「特殊解」と「一般解」という単語の「一般」の意味が近い。「汎用的な」も近いかも？)
数学から逆輸入された「記号論理学」を筆頭とした現代論理学や、集合論が完成する前に組み立てられた古典論理学、論理の矛盾を使って相手を騙す「詭弁」、形式的な関係に誤りが生じることを分析した「誤謬」などを扱うのである。

<br>

論理学には、主張の方法がいくつか存在する。例えば、包含関係を表す「必要条件・十分条件」や「逆・裏・対偶」、命題の関係性を表すブール代数、三段論法に代表されるようなトートロジー(恒真式)などである。
これらは、命題の真偽を判定する「命題論理」と、述語という変数で表現される「述語論理」に分類することができる。
また、包含関係を表す「必要条件・十分条件」や「逆・裏・対偶」などは命題の真偽を判定する主張であるが、ブール代数や三段論法などは2つ以上の命題から新たな主張を生み出す方法である。

<br>

一般に、「論理的な主張」が行われる際には、前提条件(命題)が共有されていて、その条件を使って主張が組み立てられる。(数学に例えるなら「公理」から「定理」を導出することに近いかも？)
まず、「必要条件・十分条件」や「逆・裏・対偶」を使って前提条件(命題)が正しいことを確認し、ブール代数を使って新しい前提を生み出し、結論までの筋道を組み上げていくのだ。
このとき、論理の形式的な関係に不足する「事実情報」を追加することもあるため、実際には「事実情報、前提条件(命題)のいずれか」から2つ以上を選んで結論が生み出される。
2つ以上を選ぶ理由は、結論が「組み合わせることで新たに生み出される命題」であるからで、前提条件や事実情報という命題の一部が継承されるからだ。(ここで言う継承は、クラスの継承みたいな働きがイメージとしては近いかも？)
つまり、議論や会話で主張を行うのであれば、ブール代数や三段論法の形式を取らざるを得ないということになる。

<br>

議論や会話で主張を行うときによく用いられるのが三段論法だ。三段論法とは、「前提Aと前提B(と前提C、D、E…)から結論が導かれる」というもの。
しかし、しばしば「前提Aと結論のみ」で主張が行われて、議論が進むことがある。
このとき、これを主張と言い張るのであれば、意識無意識に関わらず、三段論法が成り立つように、もう一つの前提が付加される。
これを「隠れた前提」と言って、「前提Aと結論のみ」の主張の中に、三段論法が成り立つように「隠れた前提B」があると、勝手に決まってくるのだ。
つまり、「前提A(と前提B)から結論が導かれる」のである。ただし、隠れた前提Bは、前提Aと結論から推論可能な範囲に限定される。

<br>

これはしばしば問題を引き起こす。
みんながみんな論理的な思考ができるわけではないからだ。大抵の人は、三段論法を頭の中で思い描けない。
また、形式的な繋がりのある範囲であれば、どんな前提でも当てはまってしまうのだ。論理的な思考ができる人達の間でも意見が異なるだろう。
すると、省略された前提Bの解釈が人によって分かれてしまう。
「前提A(と前提C)から結論が導かれる」や「前提A(と前提D)から結論が導かれる」などとなりがちだ。
これが「認識の違い」や「前提条件の違い」、「常識の違い」などと一般的に言われるすれ違いである。

<br>

また、三段論法の前では「言葉にしていないのだから、前提Bなんて言っていない！！」という言い訳は通用しない。
主張した時点で発言していない前提Bが、三段論法が成り立つように勝手に決まってくるからだ。それは、「前提Bである」と発言したことと同義なのである。
隠れた前提Bを受け入れて主張を通すのか、隠れた前提Bを拒絶して主張を取り下げるのか、二者択一の選択が発言者に突き付けられるのである。発言者にはそれ以外の選択肢が論理的に存在しない。
したがって、自分が発言するときには必ず「前提Aと前提Bから結論が導かれる」と、丁寧に発言することを心掛け、意図しない隠れた前提の発生を防ぐべきだ。

<br>

工学をベースにした製造業やIT企業に勤める社会人であれば、問題解決の際にしばしば論理的な主張が必要になる。問題解決に悩む人は、ぜひとも論理的な主張を心掛けていただきたいものだ。

<br>

以下に、自分が参考にしているサイトのリンクを示す。

<br>

自分が何か忘れたときに参考にするサイト、好き
論理的な主張の入門に使えると思います
http://ronri2.web.fc2.com/index.html

最近になって見つけた良さげなサイト
http://la-ad.net/logical-thinking/preface.html

ここも良いサイトです
https://www.nakanihon.co.jp/gijyutsu/Shimada/easylogic/index.html

感情というのは、自分の昔の記憶から想起されるものであって、相手起因ではないという主張。
とはいえ、人の中には「感情が発露された場面を見なければ相手がどう思っているか理解できない人」がいるので、感情自己責任論という考え方を自分に浸み込ませた上で、「不当な扱いにキレる演技」を磨くべし。
…悟りの境地では？
http://kanjo.g1.xrea.com/

『名言と愚行に関するウィキ』復刻版
高校倫理を勉強していたときに見つけて、論理に興味を持つきっかけとなったサイトの一つです。
元のサイトは消えてしまったのですね。。。
https://note.com/totutohoku/n/n109a57daa709

ふろむださんのブログも高校倫理を勉強していたときに見つけて、論理に興味を持つきっかけとなりました。
個人的に、「上司が部下の仕事をわざと上手く行かなくなるように根回しして、自分の言うことを聞かせるように立ち回ってくる話」の紹介と、上司がそれを行える立場だと認めた上で納得できない部下側ならどう立ち回るべきかを説いた話は、何年も前に読んだのにも関わらず、いまだに印象に残っている記事です。
https://www.furomuda.com/

<!-- ----------------------------------------------------------------------------------- -->

# 8. おわりに

いかがだったでしょうか？

問題というのは基本的に2～3個の要素から成り立っています。しかし、ベン図を見てもわかる通り、論理の構造的に3つでも人間にとって非常に難しい問題となります。したがって、たいていの人が問題を過小評価して、1つの問題だと勘違いして対処しがちです。これを「いかに論理的な構造に分解して対処するか」が、問題解決の肝になります。「困難は分割せよ」というのは「論理的に単純な構造へ分割せよ」ということなので、論理的に破綻する構造へ無理矢理分解することではないんですね。

問題というのはこの記事に記載した通り、場合分け可能な単純な問題の組み合わせのことなので、王道の問題解決の手法というのは、**「如何に問題を分析して、本質を見抜いて、分解して、対処するのか」** という話になります。

「問題解決の手段は無限にある」と言われていますが、問題解決の手段としてのベストは「王道の解決方法」になります。しかし、時間的な制約や人の制約、物の制約などの問題から、「王道の解決方法」が選択できない場合があります。こういうときには例外的な対応が必要になるので、「問題解決の手段は無限にある」(人、物、金を使った力技)がベストなわけですね。

この記事を読んで物足りないという人は、ぜひ現代論理学の一つである「記号論理学」を勉強してみてください。また、詭弁の考え方やその対処方法、ディスカッションやディベートと呼ばれる議論のやり方についても学んでみると良いでしょう。

**レスバは議論ではないということがはっきりとわかります。**

今回記載した内容は、プロのエンジニアであれば誰でも無意識のうちに頭の中で一瞬で計算を行っていて、アウトプットしています。したがって、この記事を読んでベン図を勉強した人が目指すべきレベルとしては、会話の中で淀みなく答えられるように **1秒以内に結論を口から出せるレベルまで落とし込むこと** が求められます。

頑張りましょう。

<!-- ----------------------------------------------------------------------------------- -->

# 9. 複雑な問題への対処方法について(追記_2025/01/18)

前の項目までは、次のことを話していました。

* 問題は、問題の構成要素(最小のもの)になるまで分割し、分割した問題それぞれに対して対処を行いましょう
* 対策は、各問題の要素に対して、焦点を合わせて考えましょう
    * 問題の過小評価や過大評価は対策の失敗を意味する
* 集合の考え方や命題の判定方法を上手く利用しましょう
    * 必要十分な対策が最も良い対策です
    * 構成要素が3つぐらいまでなら、どうにか分解することができます

では、構成要素が`4つ以上の問題`の場合はどうでしょうか？

問題の要素を推定することさえ難しくなり、分割が困難になると思います。

世の中の問題は、構成要素が少なければ反対概念と矛盾概念に分割できますが、構成要素が多い場合は矛盾概念と区別が出来なくなっていきます。さらには、答えの出ない問題も登場し始めます。

矛盾概念と区別が出来なくなった複雑な問題の場合、世間一般ではどのような回答が行われているのか。

みなさんも聞いたことがあると思いますが、「ケースバイケースだ」という返事が返ってくるでしょう。

この回答は、巨大な問題を一つの問題だと捉えて思考が止まっているから出てくる答えです。

<br>

ケースバイケースなのであれば、各ケースの問題だけでなく、当時の状況まで知っておくべきでしょう。

問題というのは、状況によって対策の優先順位が変わってくるからです。すると、「問題に対する切り込み方が状況によって変わってくる」ということになり、同じ問題に対する対処だとしても当時と今とで異なるパターンになることもあるわけです。

つまり、「今回、この問題は当時の状況からこういう風に対処したけども、次に同じ問題が発生した場合は、同じ方法が使えるのか、または別の正規な方法を使わなければならないのか」といった考慮事項が当然存在しているはずで、それらのパターンにおいて、発生した場合の緊急度・重要度の分類が可能なはずです。

したがって、「当時の状況まで知っておく」というのは、対策を考える上で必要な作業となります。

仕事において、「対策は、後回しにすればするほど、後で痛い目を見る」というジンクスがありますから、発生可能性が高く、優先度の高い状況から対策を練って対処し、「そもそも『複雑な問題が発生するような状況』が`可能な限り`起こらないように立ち回っていく」というのが、「ケースバイケースだ」と思ったときの対処方法ではないでしょうか？

しかし、

「『ケースバイケースだ』と言うのであれば、具体的によくあるケースを頻度順でTOP3まで教えてください」

と`ケーススタディ`の立場から具体的な例をヒアリングしても答えは返ってこないでしょう。

そういった対応が個人的に「『ケースバイケースだ』と言って、煙に巻くような回答になっていて嫌だな」と思ったので、「要素毎に分割できない複雑な問題への対処方法」について、自分が考えたことを紹介したいと思います。

※以下に示すことは、すべて根本的な対策とはならないことに注意が必要です。

## 場合分けをしよう

複雑な問題の場合、特殊解であれば何とか導出出来ることがあります。

なので、問題に対して「対策しておいた方が良いこと」「絶対にやらない方が良いこと」を探します。

イメージとしては、問題という大きな砂山に棒を立てて「しておいた方が良いこと」「やらない方が良いこと」を、棒が倒れないように取り除いていくゲーム、でしょうか。

答えの出ない問題は、そうやって切り崩していくと、無視できるレベルまで問題を最小化することが出来ます。

## 問題に対しての対策を頻度順で考える

人間がなんとか分割できる問題は、要素が3つ以下の問題であるという話をしました。

では、複雑な問題に対する対策について、頻度順に上から3つ～5つ程度、機械的に選択すれば、問題の大部分をカバーできるのではないか、という発想です。

問題のすべてを網羅できるわけではありませんが、かなり効果的な手法だと思います。

## 地道にケースを集める

狭義の意味での「ケースバイケース」になると思います。

一言で言えば、「ケーススタディをしましょう」ということです。

起こった問題に対して、行った対策の反省や改善点を見出し、状況を精査して、別の状況に応用したり、「似ているけれど全く異なるケースである」と見抜いたりするために、一つ一つのケースを記録してまとめていく、という手法です。

ケーススタディの結果が、「文字に起こされて全体に共有されている」、または「会社の仕事のシステムに組み込まれている」のであれば、効果的な手法になります。

しかし、共有が上手くいっていない職場で地道に行うのは、網羅するまでに数十年とかかってもおかしくないため、ものすごく根気のいる作業となります。当然、生産性は最低です。

利点は「地道に仕事ができる」という点でしょうか。

欠点は「運に左右される」という点です。

なぜならこれは、`文字に起こされない限り`、自分が当事者にならなければ学ぶことが出来ないからです。お鉢が回ってこなければ一生対処方法を学ぶことが出来ないでしょう。

下手をすれば特大の爆弾が回ってきたときに、仕事の失敗の責任を取らされてクビが飛ぶことになります。そういった意味でお祈りをするしかありません。

つまり、「共有が行われていない職場では、自分に主導権がない」ということになります。

<!-- ----------------------------------------------------------------------------------- -->

# おまけ

* 反対概念と矛盾概念
    * 反対概念 : 同一の類概念に属する概念のうち、その内包上最も対立度ないし差異の大きな概念
        * 要は白と黒のように間に灰色を認める概念のこと
        * 真空、温度、色など
        * ⇒人間は快・不快の2原色に記憶が紐づいて多彩な感情が生まれている…？
    * 矛盾概念 : 二つの概念が内包で排除し合いながら、両者で合して一つの外延をなしている場合の二つの概念同士のこと
        * 要は白か白以外かのように間に他の概念を認めない
        * ⇒つまり、矛盾概念に3つ目の要素を加えた場合、反対概念として扱う必要がある(扱いが変わる)
        * 表と裏の関係、電気信号のON/OFFなど、Aと非A
* 全称命題・特称命題
    * 言葉の意味について
        * 全称：「すべての」を表す
            * $$ \forall A $$
        * 特称：「ある(限定)」を表す
            * $$ \exists A $$
    * 使いどころ
        * 肯定命題(肯定文)や否定命題(否定文)と絡めて考えます
            * 全称肯定命題(A) : 「すべての『前件』は、『後件』である」
            * 全称否定命題(E) : 「すべての『前件』は、『後件』ではない」
            * 特称肯定命題(O) : 「ある『前件』は、『後件』である」
            * 特称否定命題(I) : 「ある『前件』は、『後件』ではない」
* 三段論法
    * 基本
        * 基本的な形(一例)
            * 前提1                      : AはBである
            * 前提2                      : BはCである
            * 前提1と前提2から導かれる結論 : AはCである
        * 演繹法のこと
        * **必ず前提を2つ以上組み合わせて、結論(主張)が生み出される**
        * 恒真式となるため、1つ以上の前提と結論から別の前提を導き出すことが可能
    * 応用
        * 隠れた前提(一例)
            * (隠れた前提1                      : AはBである)
            * 前提2                            : BはCである
            * 隠れた前提1と前提2から導かれる結論 : AはCである
        * 三段論法の性質から、前提2と結論を使って「隠れた前提1」を導き出すことができる
        * **前提2と結論のみの主張でも、結論が成り立つように隠れた前提1まで主張したことになる**

<!-- ----------------------------------------------------------------------------------- -->