社会ルールと書いていますが、国のルールでも会社内のルールでも学校内のルールでも何でもよく、ある種のコミュニティにおけるルールの総称としての「社会ルール」と思ってください。

とかくルールと言うと合理性に欠けると思えるものが世の中には多くあります。考えた人間が頭が悪いのか、あるいは何かの悪意で制定されたのか、あるいは作られた時から現実が変化したのにルールが追随せず形骸化したのか、等々、邪推をしたくなるほど変なルールが満ちあふれています。

一部には前記の邪推に当たるルールもあるかもしれません。しかし、一定規模の集団に適用するルールは、それ単体での合理性を考えるだけでは不十分です。運用の経済合理性も一緒に考えるべきだからです。

たとえば、集団内にグループAとグループBがあったとします。グループAの人には意味があってグループBの人には意味のないルールがあったとします。ルールの合理性だけを考えるとグループAの人にだけ適用して、グループBの人には適用すべきではありません。ただこうするとルールの運用時に適用するか否かの条件判定が必要になります。この条件判定のコストが高い場合、全員に同じルールを適用するのはひとつの合理的判断です。

条件判定自体が面倒という側面もありますが、条件判定が増えるとエラーが増えるという事実もコストに効きます。エラーが起きうることにはエラー処理が必要です。エラー予防のためにルール制定、と言い出すと泥沼です。

集団の規模が拡大するとグループA,B,C,...と分類数も増えますし、分類の基準も増える傾向にあります。それぞれに条件判定を入れていくと条件判定のコストも上がります。いくつかまとめて同じルールを適用した場合との経済合理性を考慮して、特定の人たちには意味がないけど同じルールを守ってもらう、ということが多々あります。

こうして、個々の人を取り出してみると、非合理、非効率、無意味、理不尽なルールが押し付けられたりします。

似たような話はプログラミングの世界にもあります。何と呼んでもいいですが、ここでは抽象化層と呼ぶことにします。抽象化層を通すことで、呼び出し時に余計な手間が増えたり、実行効率が悪くなることは多々あります。個別に取り出すと、抽象化層をすっとばした方が速くていいと思えるような時もあります。しかし、全体を見ることなく各論で思いつくままに抽象化層に穴を開けていくとプログラムは崩壊します。

ここで話を終わらせると、ああ、かつては非合理なルールなんて片っ端から変えてしまえと過激な発言をしていた(本当はしていないけど)アリエルCTOも、理不尽に見えるルールも受け入れろと大人の発言をするようになったものだ、と思われるかもしれません。

で、話は終わりません。

プログラミングで抽象化層の設計は実に難しい点です。どういう切り口でどういう粒度で設計するかがプログラミングそのものと言えるぐらいです。抽象化層という言葉がピンとこなければ、API設計でもクラス設計でもモジュール設計でも何と呼んでも構いません。呼び出しの手間(ルールで言えば運用の経済合理性)と効率性(ルールで言えばルール自体の合理性)のバランスを取るのは本当に難しいのです(少なくともある一定以上の複雑さのあるソフトウェアでは)。どれぐらい難しいかと言うと、誰がやっても最初から完璧にはできない、と断言できるぐらいの難しさです。

抽象化層は時間とともに分厚くなるのが世の常です。各論で見れば非効率になりがちです。非効率だけならまだマシな方で予期せぬ副作用が起きるようになると事態の悪化は止まりません。

社会ルールも分厚くなりがちです。時間とともに合理性(運用の経済合理性も含めた合理性)を失うこともあります。プログラムと同じでルールがおかしければ正すべきです。運用の経済合理性は見えにくいので、正すのは容易ではありません。でも最適解を考え続けようと思います。ぼくが考えるのを諦めた時、面倒なので全員同じ適用でいい、理不尽でもみんな受け入れればいい、と考えるユニフォーム論者になる時です。