白か黒かを確実に判断する方法
「答え」＝「目的のもの」を見つけるためには
必要条件（ゆるい条件）
を重ねていくと効率がよいでしょう。
必要条件というのはあてはまる範囲が大きい条件ですから、必要条件を多く積み重ねていくのはいわば「大→小」の流れとなります。同じく必要条件と十分条件を使って「正しさ」を判定する方法もあります。ここでのキーワードは「小→大」です。
社会で生きるみなさんにとってはいわずもがなでしょうが、実生活は白黒の判断がつくことばかりではありません。むしろそのどちらでもないグレーゾーンの存在を認め、そのなかでどう折り合いをつけていくかが大人のたしなみだともいえるでしょう。
でも、だからこそ白か黒かの判断を確実にできることはとても大切だと考えます。
とくに私のいる論理性の塊で構築されるソフトウェア開発の世界や社会インフラに根差しているからこそ守るべき品質の観点に立った立場からすると、白黒をハッキリさせないあいまいな態度というのはそれだけで信用を失墜させかねません。
みなさんも商品・製品を購入する際に欠陥の有無もそうですが、なにより「自分たちが利用するにあたって不満を感じること」が一番嫌ですし、そういう商品や製品を良いものだとは思いづらいですよね。
ゆえに私のような立場にいるとどうしても「何をもって正しいといえるのか」をハッキリさせることは、自分自身がその世界で生きていくためにもとても重要なポイントとなってくるのです。
本来は白黒の判定ができることもグレーゾーンのように考えてしまったり、逆にグレー
ゾーンの事柄を白か黒かのいずれかに勘ちがいしてしまったりすると、大人としてうまく対処することはできないでしょう。
白黒の判断をすべきではないグレーゾーンの事柄を見極める最初の一歩は、その事柄が「命題」であるかどうかを判断できるようになることです。
白黒の判断ができないグレーゾーン
「富士山は日本でいちばん高い山である（＝真）」
や
「日本の人口は２億人である（＝偽）」
のように、客観的に真偽（正しいか誤っているか）を判定できる事柄を「命題」といいます。ここでは客観的にであるかどうかがとても重要になります。つまり、誰がから見ても同じ答えに行き着くものということです。
「命題」というのはちょっと間き慣れない単語かもしれません。
命題は「proposition」の訳語です。「propose」はプロポーズ…「提案する」という意味なので「命題」というのは「このことは正しいでしょうか？」と提案された内容を指します。
論理的に正しいか正しくないかを判断する事柄は、前提として客観的である必要があります。
たとえば、「カレーは美味しい」や「蝶は美しい」「自分は正しい」といった事柄は趣味趣向という主観的要素が入っていて正しいか正しくないかの判断ができないため、命題ではありません。これはわかりやすいですよね。美味しいや美しいといった『形容詞』はそもそも主観表現としてしか用いられませんので、形容詞を使った時点で100%命題になりえません。
ある事柄が正しいか正しくないかを判断をしようとする際には、その事柄が感情や趣味
趣向の要素を含んでいないことを最初に確認しておくことがたいへん重要です。
たとえば、
「頑張って仕事すれば、必ずいつかはうまくいく」
という言葉は一見「命題」のように見えますが、何をすることが「頑張る」ことになるのかは人によってさまざまです。頑張る量だけを見れば正しくも見えるのですが、頑張り方が間違っていれば一生上手くはいきません。客観的には判断できないので、これは命題ではありません。
このような命題とはいえない事柄については、白黒の判断をしないようにしましょう。
命題でない事柄＝グレーゾーンの事柄ということです。
命題が誤っていることを示す
ある事柄について、それが命題である（グレーゾーンの事柄ではない）ことを確認したあとは、その事柄が正しいか正しくないかを判断していきます。
命題（客観的に正しいか正しくないかが判断できる事柄）が正しいことを示すのは難しいことが少なくありません。ですが、命題が誤っていることを示すのは意外と簡単です。
命題が誤っていることを示すためにはあてはまらない例（反例）をひとつ挙げるだけで充分です。
たとえば、あなたが営業部に属していて、営業部には40人の社員がいるとします。このうち39人は電車通勤で、残りの１人のみ自転車通勤だとしましょう。このようなとき、
「わが社の営業部員なら、電車通勤である」
という命題は誤っています。なぜなら、たった１人とはいえ反例（例外）があるからです。ある命題について反例がひとつでも見つかれば、その命題は誤りです。
同じく「１年は３６５日である」という命題は、閏年（１年が３６６日の年）という反例があるためやはり誤りです。
このように、ある命題について反例が見つかれば、その命題は「偽である」と断ずることができますが、反例が見つからないからといってその命題を正しいと断言することはできません。なぜなら、「反例が見つからない」というのは単に「これまで見つかっていない」というだけで、本当に反例がないことの証明にはならないからです。
この点はJSTQBにあるソフトウェアテストの７原則でも同じようなことが言われているので、私と同じＩＴ業界の方でしたらご存じかもしれませんね。
命題が正しいことを示す
前述のとおり、一般的に命題の正しさを断定するのは簡単ではありません。
会議などでも、人の意見の誤りを指摘するのは比較的簡単ですが、人の意見…だけでなく自分の意見ですら正しいと判断するのは難しいものです。
しかし、冒頭にもありました『必要条件』とさらには『十分条件』をきちんと理解していれば、ある種の命題についてその正しさを自信をもって判断できるようになります。
これはベン図で説明することが可能です。
みなさん覚えてますか？ベン図。
小学校でも使いますし、中学入試でも出てきますし、高校数学でもお目見えするので、知らない人はいないかもしれません。
たとえば、次の図をみてください。
「川越市在住 ⇒（ならば）埼玉県在住（である）」は正しい命題であり、範囲が小さいほうの条件Ｐ（川越市在住）を「十分条件」、範囲が大きいほうの条件Ｑ（埼玉県在住）を「必要条件」といいます。ここで
川越市在住……範囲が小さいほうの条件を「小」
埼玉県在住……範囲が大きいほうの条件を「大」
と呼ぶとすると「小ならば（⇒）大」の命題は正しいことになります。
すなわち、
「小→大」の流れになっている命題は真
なのです。
逆に、「埼玉県在住 ⇒（ならば）川越市在住」は正しいとはいいきれません。埼玉県に在住していても、川口市やさいたま市、所沢市や飯能市在住かもしれないからです。つまり、
「大ならば（⇒）小」という命題は誤り
です。一般に、「ならば（⇒）」を含む命題の真偽については次のようにいうことができます。
「十分条件ならば（⇒）必要条件」はつねに真
「必要条件ならば（⇒）十分条件」はつねに偽
ただ誤解していただきたくないのは、先ほども言いましたように「形容詞」を用いた表現は絶対に使えないということです。それはグレーゾーン以上にも以下にもなりません。
ですので、その大前提を無視して
「自分は正しい、ならば（⇒）人間は正しい」
と言われても当然あてはまりません。逆もまた然りです。
「正しい」という言葉自体が形容詞であり、とても主観的な判断しかくだせないからです。もちろんグレーゾーンのことなので、中には本当に正しいものもあるのかもしれません。しかし、それをすら証明する手立てはそうそう見つからないことでしょう。
ソフトウェア開発のSE・KA・Iでは
実際問題として、ソフトウェアテストの世界においてはこの理論から
「全数テストは不可能」
という基本原則に基づき、数少ないテストケースから論理的に設計や実装されたプログラムに問題がないことを証明しようとする技術が確立されています。
同値分割や境界値分析などがいい例ですよね。
ですので、この必要条件と十分条件の関係性を正しく理解し、使いこなせるようにならないと設計のレビューやソフトウェアテストでのテストケースを洗い出す業務はできません。
やったとしても、抜け漏れや誤りだらけになっていることでしょう。
その証拠に、次工程以降で発見された欠陥や問題のなかには、まず間違いなく前工程までのあいだに発見しておかなければならない観点の欠陥や問題が含まれているはずです。
裏を返せば、それくらい属人的なスキルやノウハウに頼りきりで、何一つ論理性が伴わない仕事の仕方をしているということです。
慣れるまでは非常に面倒ではあると思いますが、お客さまに、利用者に、あるいは社会に責任をもって製品やサービスを提供する側として、こうした考え方はしっかりと身につけたうえでソフトウェア開発に従事していただければと思います。
また、ソフトウェアテストそれ自体が
「設計通りに実装されていること」
を証明するための実証・検証業務となります。とても正確性を求められている工程と言っていいでしょう。そう、まさに白黒つけようという工程にほかなりません。
当然ながら、そのようななかで検証内容に
「○○が正しいこと」
といったテストケースとなっていると、具体的にどのような確認を行えば正しいのか白黒つけられなくなります。「正しい」の定義なんてそれこそ十人十色。テストケースを記述した人の「正しい」と実際にテストする人の「正しい」は一致しませんし、そのテスト結果を見て承認するお客さまの「正しい」もまた異なったものとなっていることでしょう。
それぞれがそれぞれの考える「正しい」で解釈してしまうため、作成もテスト実施も、そのレビューも「OK」と判断されてしまいます。
しかし、その解釈の中身は全く異なっているために、後々になってから問題が勃発することになります。まさにグレーゾーンなわけです。どんなに優れたテストツールを用いても、どんなに実績豊かなテスト手法を用いても、このような考え方を許容しているプロジェクトでは必ず「欠陥」や「問題」の積み残しが出てきます。
このように、ソフトウェア開発の世界では日頃から「論理的に物事を考える」ことが常態化することを求められています。そうでなければいずれ大きな障害を生み、社会インフラに多大な迷惑をかけてしまうことになりかねません。
いいなと思ったら応援しよう！
