プログラミングを学んで論理思考を鍛えよう
大学などでプログラミングの授業を受けたことがある人は多いと思います。今年からは小学校でもプログラミングが必修化されたということで、学校でプログラミングを学ぶ機会も増えてきました。
実際に職業としてプログラマーになる人の割合は少ないと思いますが、それでも一度はプログラミングを学んでおいて損は無いと思いますよっと。
プログラミングは論理思考が鍛えられる
コンピューターというのは基本的にアホです。「この場合はこうしろ、そうじゃない場合はこうしろ」と、いちいち細かく指示しないと動いてくれません。前提条件が100通りある場合、その100通りのパターン全部に対して「こうしろ」と細かく指示してあげないと、指示漏れがあったときにコンピューターは困ってしまいます。
人間の場合は、「大体こういう場合はこうしてね」くらいに大雑把に指示しても、ある程度自分で判断して動くことができます。もし自分で判断できなかった場合は、「この状況のときはどうしたらいいか教わってなかったんですが、どうすればいいですか？」と聞き返すこともできます。
論理思考というのは究極的に言えば、「AならばB」という「ならば」の集合体です。「この場合ならば、こうする」を漏れなく全パターン示すことこそが論理思考というものである、と言い換えてもいいでしょう。
コンピューターに指示を与えるためのプログラミングというものはまさに、論理思考そのものです。全てのパターンを漏れなく指示することでコンピューターは動くことができる。逆に言えば、論理思考ができなければプログラミングはできないというわけです。
条件分岐
赤いボタンと青いボタンがあり、それぞれがONかOFFかによって、画面に"A"や"B"の文字を表示させるプログラムを考えてみます。
これをプログラム言語で書くとこのようになります。
if (Red == OFF && Blue == OFF)
Output("A");
else if (Red == OFF && Blue == ON)
Output("A");
else if (Red == ON && Blue == OFF)
Output("A");
else if (Red == ON && Blue == ON)
Output("B");どんなプログラミングでも、このような条件分岐（if文）をまず最初に学びます。どんな複雑なプログラムでも、どんな高機能な（例えば画像処理や動画編集などのような）プログラムでも、条件分岐は至るところに登場します。
ここで重要なのは、プログラムの書き方ではありません。ifは小文字でなければならないとか、"=="とイコール2つ並べなければならないとか、条件式はカッコ()の中に書かなければならないとか、そういうことはぶっちゃけどうでもいいです。
そんなことよりももっと重要なのは、「条件が4通りに分かれている」ということです。赤いボタンと青いボタンそれぞれにONとOFFがあるということは2×2=4パターン全てを網羅すればこのプログラムはどんなときでも正常に動作するだろう、と理解することが大切です。
プログラミングを学んでいると頻繁に条件分岐を書くことになりますが、それを繰り返し学んでいくうちに、自然と「全パターンを網羅する」という感性が身に付きます。つまり、論理思考が鍛えられるわけです。
日本語で表現すると、パターン漏れのおそれがある
あるとき、この赤青ボタンシステムのバージョンアップが必要になったとしましょう。お客様が言うバージョンアップの希望はこんな感じです。
赤いボタンを押したときは"C"と表示してください。青いボタンを押したときは"D"と表示してください。
プログラミングによって論理思考が鍛えられていると、すぐに次のような疑問が浮かぶはずです。
どちらのボタンも押していないときは"A"のままでいいのだろうか。多分そうだと思うけど念のため確認しよう。
両方のボタンを押したときは"C"と表示すべきなのか"D"と表示すべきなのかどっちだろう？
常日頃からプログラミングをしてif文を書いていると、すぐにこの4パターン全てを網羅した絵が思い浮かびます。そしてお客様が言った「赤を押したらC、青を押したらD」という日本語の中には足りないものがあることに気付きます。
プログラマー側がお客様の業務を全て理解していれば、赤いボタンや青いボタンが何のためのボタンであり、画面に表示する"A"などの文字にはどんな意味があるのか、そして今回のバージョンアップは何のために行うのかを熟知していることもあります。そのような場合は、お客様の日本語の要求が言葉足らずであっても、「足りない部分はこうすべきだろう」と想像をめぐらせることができます。
しかし実際には、プログラマー側にお客様の業務の情報が知らされていない場合もよくあります。企業秘密に関わる内容であったり、間に営業職やSE職の人を介している場合などが、それです。
とにかく、要求仕様の一部が不明なときは、聞き返さなくてはいけません。そうすることで、不明な点を明らかにしていきます。
どちらのボタンも押していないときは従来どおり"A"でいいです。
赤いボタンと青いボタンを両方押したときですが、ああ、そうそう、言い忘れてました。そのときは"E"と表示してください。
とまぁこんな感じで、お客様が言い忘れてたことを引き出すこともできます。そこに気付かせてくれるなんてアンタ有能だねぇ、今後も仕事をよろしく頼むよ。となるわけですな。
どんな職種でも最低限の論理思考は必要
で、実際にありがちな話なんですが、お客様とプログラマーの間に仲介役が居て、必ず仲介役を通さないとコミュニケーションが取れない場合があります。
仲介するのは中間業者であったり、社内の営業職やSE職だったりします。なぜ仲介役を通さずに直接やり取りできないことがあるかというと、コミュニケーションの履歴を一元管理する必要があったり、営業的な判断（お客様の要求をいくらの値段で請け負うかなど）が伴う場合があるからです。そのような場合、直接の連絡手段そのものを教えてもらえないこともあります。
そんな状況のときにありがちなのが、コレ。
客からバージョンアップの依頼があったんだけど、赤いボタンを押したときは"C"、青いボタンを押したときは"D"と表示するようにして欲しいってさ。そのプログラム、できる？
「できる？」じゃないよ。できねェよ。
お客様は確かにそのような日本語で依頼を出したんだろうけど、それをそのままプログラマーに伝えてどうするよ。ちゃんとそこで「どっちのボタンも押してないとき」「両方のボタンを押したとき」のお客様の希望を確認してから、プログラマーに知らせてきてよ、マジで。
しょうがないから再確認のメールをするわけよ。
どちらのボタンも押していないときは"A"のままでいいのでしょうか？
また、赤いボタンも青いボタンも押したときは何と表示すべきでしょうか？
そしたら返ってくるメールがコレ。
赤いボタンを押したときが"C"です
うがーー！！ 全然答えになってない！！
直接お客様に聞けば話は早いんだけど、連絡手段は知らされていない。このままじゃラチがあかないから、しかたなくパワポでわざわざこんな図まで作って再々確認のメール。
このやり取りだけでどんだけ時間を無駄にしたか。しかもパワポ作るという余計な作業まで発生したし。さらにこの怒りを鎮めるための十分な睡眠が必要だッ！ こりゃぁ3倍だ！ 通常価格の3倍で見積もるからな！ ふー、ふー、ふー…
おっとっとっと。ついつい実際に僕が遭遇したケースを思い出して我を失ってしまいましたよ。
どんな職種であっても、もっと言えばIT系の業種でなくても、「全てのパターンを網羅する」という状況はよく起こりえます。ケーキ屋がどんなケーキに誕生日おめでとうのプレートを付けるか考えるとき、清掃業者がビルの何階から上に下に掃除して進めばビル全体を掃除できるかを考えるとき、etc…。
確かにプログラマーは常日頃から条件分岐を扱っていて、パターンを網羅するのは得意なほうです。でも、それはプログラマーにしかできないことではありません。
どんな職種でも最低限の論理思考ができないと、仕事が正しく進みません。場合によっては余計な費用が発生して赤字になることさえあります。
プログラミングを一切経験していなくてもこのような論理思考が得意な人も居ます。でももし自分がこういう論理思考が苦手だと思ったら、一度初歩のプログラミングを学んでみるといいかもしれません。最終的にプログラマーになることは無いとしても、どんなときにでも通用する論理思考がきっと鍛えられるはずです。
持続化給付金の計算式がおかしい
2020年、コロナウィルスの影響により売上が激減した事業者に対して、法人なら最大200万円、個人事業主なら最大100万円の給付金が支給されるという「持続化給付金」という制度がありました。（※執筆現在、2020年4月28日）。
この給付金の計算式なんですが、少し変なところがあります。まずはその計算式を見てみましょう。
- 2020年のある月の売上が2019年同月の売上から50%以上減っている場合、給付の対象となる
- 「2019年総売上－(2020年の上記減少月の売上×12)」が給付額。ただし最大200万円または100万円
月々の売上が比較的安定している事業者の場合はこの計算式で特におかしいことは起こりません。しかし、次の例のような特殊な事業者の場合はどうでしょう。
1年のほとんどは休業状態だけど、4月だけがっつり商売をするという事業者。入学式ビジネスでもやってるんでしょうか、とにかくそんな特殊な例です。
で、去年は1000万の売上があったのに、今年はコロナの影響で10分の1の100万円しか売上がありませんでした。4月は売上90%減です。めちゃくちゃヤバいです。こんだけ激減してるんだから、給付金は満額もらえるんだろうなと思って計算してみたところ…
2019年総売上－(減少月の売上×12) = 1000万 － (100万×12) = マイナス200万円
ふぁっ！？ マイナス！？ マイナスってどういうことなの…。給付じゃなくてお金取られるの？
どうしてこんなことになるかというと、給付判定条件と計算式にそのからくりがあります。
普通に考えると、まず最初に給付判定条件があって、その給付判定条件に使った数値をもとに12倍などの計算をして給付額を決定するのが正常な計算方法だと思います（左図）。
でも実際の持続化給付金制度の計算式は、給付判定条件に使った数値以外の金額（具体的には、昨年総売上）を計算式の一部に使っています（右図）。
さっきの赤いボタンと青いボタンの例のように単純ではありませんが、この例もある意味、条件分岐の網羅性が破綻しています。論理の組み立てが不完全なのです。
実際に持続化給付金制度の申請をする場合は、こんなマイナスの給付金なんてものはありえないので、「申請できない＝給付金がもらえない」ということになると思います。
しかし、もしこの計算が自動的に行われて、申請の有無に関わらず預金口座への決済が強制的に実行されてしまうような仕組みだったらどうなるでしょうか。この例のような特殊な事業者は、去年から売上が900万円減っただけでも大変なのに、知らない間にさらに預金口座から200万円引き落とされてる…。
もちろんそんな強制決済なんてのは架空の話なので実際は大丈夫ですが、どこか別の世界線で「そういう計算と決済システムを作りなさい」ってことがあったら大惨事です。法案を通す前の段階か、遅くともそのシステムを業者が請け負う段階で「それおかしいよ」と指摘しなければなりません。
プログラマーにシステム作成の依頼が指示されてからではもう遅いんです。おそらくプログラマーは「これ、マイナスの可能性があるんじゃね？」ってことに気付くでしょうけど、それに気付いてフィードバックしても、もう何もかも手遅れです。
どんな職種でも最低限の論理思考が必要、という顕著な例の1つでした。
とりあえず学んでみよう
別にプログラミングを生業とする予定がなくても、ちょっとした趣味みたいな軽いモチベーションでいいので、一度とりあえずプログラミングを学んでみましょう。
知らず知らずのうちに自然に論理思考が鍛えられて、きっといろんなところで役に立ちますよ。