「case文」を、心の片隅に。プログラムを書かない人も、知っておいたほうがよいであろうこと。

日々の暮らしの中で、われわれは、複数の組み合わせのあるテーマに直面する。そして、その中の、相反するふたつに集中して議論することがある。

ふたつに集中しても、それ以外の組み合わせがなくなるわけではない。にもかかわらず、1か0か。イエスかノーか。オールオアナッシングの二択へと向かう。さいきん、そうした議論をしばしば目にする。

たとえば、慣行となっているものーーー決まりや、方法や、手順などーーーを、変更する話が持ち上がったとする。社内規程の変更や仕様の変更をイメージしてもらえばわかりやすいかもしれない。シンプルに考えれば、組み合わせは４通り。

(1) 変更して、良い結果を得られる。
(2) 変更しないほうが、良い結果を得られる。
(3) 変更したために、悪い結果になる。
(4) 変更しなかったために、悪い結果となる。

(1) と(2) の議論に集中しすぎるあまり、 (3) (4) が忘れ去られることがある。(3) と(4) の議論に集中しすぎるあまり、 (1) (2) が忘れ去られることがある。

もう少し、組み合わせが多いテーマについても考えてみよう。

リアルな生活の中では、４通りでは済まないことなど山ほどある。むしろ、そのほうが多いだろう。

たとえば、「疾病A」と「疾病B」があるとする。次のような、組み合わせが考えられる。

(1) Aという病気で、Bという病気ではない。
(2) Bという病気で、Aという病気ではない。
(3) Aという病気、且つ、Bという病気である。
　　(3.1.1) Aという病気の後に、Bという病気にもなった（因果関係なし）。
　　(3.1.2) Aという病気の後に、Bという病気にもなった（Aが原因でBを発症） 。
　　(3.2.1) Bという病気の後に、Aという病気にもなった（因果関係なし）。
　　(3.2.2) Bという病気の後に、Aという病気にもなった（Bが原因でAを発症） 。
(4) Aという病気ではなく、Bという病気でもない。

プログラムを書く人は、こうした組み合わせを、意識にのぼるかどうかは別として、気に留めている。コードを書く「手で」考えている、といった方がよいかもしれない。Select caseや、match - caseで表される複数の条件分岐処理が必要であるのに、二択を書いていては、バグにつながる。

このことを、プログラムを書かない人たちも、心に留めておいて損はない。
多数の組み合わせがあるにもかかわらず、その中の二つだけを見て、それ以外を忘れてしまっては、人間関係のバグにつながる可能性があるからだ。
ヒトは多様だ。100人いれば100通りの生き方、考え方、生活がある。
リアルで親しい人から、ネット上の匿名の知人まで、関わる人すべてを、2択のどちらかに当てはめようとすれば、軋轢が生じがちになる。

「case文」を、心の片隅に。