5．結局、皆「漏れ抜け」を恐れる
●前回の「自転車とプログラミングと」
前回は、ずっとプログラマであった人間が、プログラマではない人のものの見方を想像して、「彼らにとってプログラミングがどういう風に見えているか」を述べました。今回は、皆が嫌がる「漏れ抜け」について持論をお話しします（先週は思っていたより筆が進みました。ただし、「漏れ抜け」という大命題ついては、とても「こうすればよい」などという策があるわけではありません。気付いた点を、淡々と述べます）。
●おことわり
プログラミングの世界では、実際のところ「職人だ」といわれることは「蔑称」です。しかも、いわれた方は「もっともなことだ」としてうなだれるよりありません。単なる悪口である「コボラー」などの呼び方とまったく違い、至らなさを痛感する呼び方です。
世の中で活躍している他分野の職人の方々に申し上げますが、この場はIT分野のコラムということで、この場限りということで勘弁していただきたいと思います。
●いつ「職人だ」といわれるか
それは、仕様要求を出す側が新たに提案したことを、下流側が「無理だ」というときです。頑としていうことを聞かない相手に対して彼らが浴びせる言葉が「職人だ」なのです。
もちろん、プログラマ側も、「無理だ」といい切るにはそれなりの理由があります。自分がこれまで経験してきた理由の多くは、大抵“インターフェイスが決まっていて動かせない”ことです。むりやり1バイトを4ビットずつに切って、「職人だ」といわれないために職人技を使ってごまかせることもありますが、インターフェイスが動かせない場合、大抵「無理だ」というよりありません。
その頑固さを見た発注側が「職人だ」といい、受ける側も至らなさを噛みしめるのです。
●「職人」の何が問題か
もちろん、「職人」が問題ではありません。そういわれる自分の力不足が問題なのです。技量のなさや権限のなさで、より幅広い対称性を作り出せないのが問題です。
大抵の場合、「職人だ」といわれたらその場はこらえて、もっと規模の小さい仕事でうっぷんを晴らすべきです（筆者は自己否定が他人より強く、「こらえ」ができたせいで、35歳を超えられたのかもしれません。適正のある人間から順に脱落していくというプログラミングの世界では、そうしないと生き残れないに違いありません）。
●「対称性」とは何か
「対称性」のおれおれ定義をしておきます。
「対称性：現在の対象範囲に対する規則を、現在の対象外にも同じに適用できること」
とします。
●「漏れ抜け」とは何か
テスト技術が進んだ現在、いまさら境界値でしくじることはないでしょうし、あったとしてもテストで取り切れると思います。ですから、漏れ抜けが発生するのは、対称性を問わなければならないような測度が（知らず知らずに）絡んできた場合があると思います。
●プログラムは永遠に「他者」
プログラムは、「ほかのエスニック」といっていいくらい人間とかけ離れています。他人より1000倍働かせても怒りませんし、間違って胸にひじが強く当たっただけで電車内で何分も説教をたれたりしません（そもそも胸があるかどうか不明です 笑）。
この他者性が、「漏れ抜け」防止に対する1つの打開策になりうるかもしれません。大体、プログラミングを含めたシステム作成過程全般にわたって、MECE（Mutually Exclusive and Collectively Exhaustive）性を備えた対象は、プログラムオブジェクト／機能以外ない可能性もあります。
本質的にMECE性のない対象について「漏れ抜け」を議論しても、実りある結果が得られるとは思えません。
プログラマに対して「職人だ」と糾弾するのは構いませんが、発注する側はどんな対象を管理するのか、きちんと自覚すべきです。
●発注する側の「職人性」
これまで、プログラムをする側の「職人性」について述べ、それと「漏れ抜け」との関連を示唆しましたが、プログラミングを発注する側の「職人性」も、プログラミングの経験の浅い人に大きく影響を与えるファクターです（経験がある人なら、話を右から左へ、という芸当もできるのですが……）。
きちんとしたトレーニングを受けず、たたき上げでリーダーになった人は、その実体験から、いの一番に、仕事を受ける側が困ることをすると、彼らは従順になるという「職人技」を会得します。これは、座学などで得た知識ではなく体にたたきこまれた技なので、当人にも自覚はないはずです。
こちらの「職人性」も、「漏れ抜け」を含め、あらゆることに悪影響を及ぼします。困ることをされては、困るからです（先ほどの「インターフェイスを動かせない」という一件も、「職人技」が発揮された可能性もあり得ます）。
●それでもわたしたちは死ぬまで生き続ける
「漏れ抜け」に関しては、はっきりいってテストしまくる以外ないかもしれません。
囲碁のコンピュータソフトなどで効果が認められているモンテカルロ法と類似性があるかもしれません。ただ、囲碁の世界と違い、プログラミングの世界では、モンテカルロ法で自動生成可能な対象がないので、プログラマが必要なだけかもしれません。
まぁ、今回はこんなところです。
次回は、「ところで自転車はどうなったんだ」について考察したいと思います（話はあと2話の予定です）。
●コラムのコメント欄の方針
コメントに対し、当意即妙の回答を、それなりのタイミングでする自信がありません。
ですので、このコラムで、
- わたしは基本的にコメントに答えない
- コメントを書く人は、回答がない前提で議論を進めていただく
とさせていただきます。