辺境の論理と社会システムの動的均衡――「外部」に対峙する機能的周縁の構造

「辺境」という概念についてGeminiとしばらく対話してみた結果、次のような論が生成された。

序論：システムの自己矛盾と「辺境」の定義

あらゆる社会システム（中央）は、内部の秩序を維持するために、システム外の混沌や脅威（外部環境）と接触し、それに対処するインターフェースを必要とする。本稿では、このインターフェースの役割を担う領域を 「辺境」 と呼ぶ。

ここで用いる「辺境」とは地理的な周縁ではなく、本論に固有の暗喩的用語である。それは、中央の慣習や価値観（共感、議論、非暴力など）が通用しない「外部」の論理に直接晒され、それに対抗するために中央とは異なる、時には中央の倫理と相反する慣習を内面化せざるを得ない機能的領域を指す。システムが健全に存続するためには、この「辺境」が不可欠であるが、同時に辺境の論理が中央を侵食し、システムの根幹を破壊しかねないという本質的な緊張関係を抱えている。

本論I：辺境の理論的構造――複雑性の縮減と潜在的例外

辺境の構造と機能は、以下の三つの理論的視点から整理できる。

第一に、ニクラス・ルーマンの社会システム理論における「複雑性の縮減」である。システムは、外部環境の無限の複雑さをそのまま受け入れることはできない。辺境は、外部の予測不能な事態を、システムが処理可能な形式（厳格なルール、コード、あるいは法的執行力）へと翻訳・縮減するフィルターとして機能する。

第二に、メアリ・ダグラスが提示した「汚穢（場所をわきまえない物質）」の視点である。辺境で実践される慣習（暴力の行使、非人間的な厳格さ）は、中央の純粋な価値観から見れば排除すべき「汚れたもの」として忌避される対象である。しかし、この「汚穢」こそが、中央の「清浄」な秩序を維持するための実力行使を担うという聖性を帯びた矛盾を内包している。

第三に、カール・シュミットが論じた「例外状態」の現代的解釈である。辺境は、法が一時的に停止する緊急事態にのみ立ち現れるのではない。有形力の行使や生命を左右する判断といった、中央の日常主義とは相容れない論理を、平時においても「潜在的かつ継続的」に訓練・維持する点に、辺境の真の機能がある。この「異なる論理の潜在能力」こそが、外部の危機に対する最後の防衛線となる。

本論II：同化の不可能性――中央による価値観強制の帰結

中央はその権力をもって、辺境に対して中央の価値観（寛容、曖昧さ、倫理的純粋性）を強制し、同化を試みることがある。しかし、この同化はシステムにとって致命的な帰結を招く。

辺境の論理が中央に同化され、その特殊な専門性や厳格さが失われたとき、中央は外部の脅威や複雑性に対して無防備な状態で直接晒されることになる。例えば、軍事組織に「暴力の否定」という中央の価値観を完全に強制すれば治安維持能力は崩壊し、ソフトウェア開発から「非情な厳格さ」を排除すれば信頼性は失われる。つまり、中央による辺境の同化は、システムが外部に対抗するための「牙」を自ら抜く行為であり、短期的には倫理的な充足をもたらしたとしても、長期的にはシステムの自死を意味する。中央は辺境を支配下に置くことはできても、その論理を中央の価値観で塗りつぶすことは、システムの存続という目的からして許容されない。

本論III：具体例に見る辺境の慣習と摩擦

辺境の論理が中央の価値観と生み出す摩擦は、実社会の多岐にわたる。

軍事・警察という暴力装置は、その典型である。これらは「非暴力を維持するための暴力」という二律背反を抱え、端的な指示や絶対的な服従といった、中央の「対等な対話」とは相容れない非日常的な慣習を平時から維持する。

看護や医療の現場における「確認の論理」もまた、鮮明な辺境の事例である（参考事例：https://togetter.com/li/1664897 ）。人体に致命的な影響を及ぼしうる処置を行う看護師の世界では、ミスを徹底的に排除するための厳格な確認作業が絶対視される。中央の論理では「相手を信じる」「立場を尊重する」ことが徳とされるが、医療という辺境では「人は間違える」という前提に立ち、相手の作業を執拗に再確認する。この慣習は中央の価値観からは「相手を疑う不作法」や「自尊心の侵害」と映り、強い摩擦を生む。しかし、この辺境の論理を中央の「思いやり」で同化し、確認の手を緩めることは、医療事故という最悪の形での外部の流入を招くことになる。

ソフトウェア開発における「厳格さ」も同様である。コンピューターという曖昧さを許さない外部の論理に即して構築されるコードや、エラーに対する端的な指摘は、情報処理の信頼性と検証可能性を支える。しかし、この厳密さが中央の人間的な配慮や共感という価値観を一方的に排斥し自己目的化するならば、そのソフトウェアは良質なユーザー体験を損なうのみならず、今日の社会におけるソフトウェア企業の影響力を通じて社会そのものを揺らがせるだろう。

結論：動的均衡とシステム存続の条件

社会システムが外部の脅威に対処しつつ、その倫理的アイデンティティを保ちながら進化を遂げるためには、中央と辺境の「継続的な摩擦」を維持し続ける動的均衡が必要である。辺境を一掃すればシステムは外圧に屈し、辺境が中央を呑み込めばシステムは本質を失う。

この均衡を維持するための条件は、以下の二点に集約される。

  1. 中央による継続的な包摂：中央は、辺境の専門性を認め、同化や排除をせず、その特殊な慣習を機能的な必要性に基づいて許容し続けなければならない。中央は自らの価値観を強制することの危険性を認識し、あえて「異なる論理」を内包し続ける度量が求められる。

  2. 辺境のメタレベル内省：辺境の構成員は、自らの方法論（暴力や厳格さ）を自己目的化せず、それが奉仕すべき究極的な目的（生命の保護、普遍的な権利、公共の福祉）を常に参照し、自らの行動を客観的に検証するメタレベルの視座を持たねばならない。

システムはこの摩擦と内省のプロセスを通じて、崩壊のリスクを抱えながらも、より強固な、あるいはより柔軟な構造へと更新され続けるのである。

新型コロナウイルス接触確認アプリのソースコードを請求してみた

公共 FLOSS

厚生労働省の「新型コロナウイルス接触確認アプリ」が公開された。

かねて話題になっていたように、ある程度匿名性を保ったままbluetoothで他のデバイスが近隣に留まったことを認識する方式らしく、割と安心できそうかと思う。

またITMediaの記事によればCOVID-19 Japanという有志によるオープンソースプロジェクトを元にしているそうだ。 ただし、記事を読む限りでは完全にオープンソースプロジェクトそのままというわけではなく「COVID-19 Radar」の技術を核として厚生労働省がベンダーに開発を委託したとある。

そうなると、いくつか気になる点がある。

  • 「COVID-19 Radar」のソースは公開されているからプライバシー等への懸念がある場合にはそれを読んで確認すれば良い、というような意見もあるが、「COVID-19 Radar」と「新型コロナウイルス接触確認アプリ」がその点において同一であるという確証はない。 利用規約には「COVID-19 Radar」のgithubリポジトリへのポインタとそのライセンス上の要請に従う旨は書いてあるが、修正の有無や修正版のソースの所在は明確でない。
  • 有志が集ってTech Giants各社が支援してオープンソースで作り上げたという折角の良い話なので、オープンソースライセンスへの尊重は守りたい。

そういうわけなので、「新型コロナウイルス接触確認アプリ」のソースコードを請求してみた。 「COVID-19 Radar」はMozilla Public License 2.0で公開されているので、「新型コロナウイルス接触確認アプリ」のうち「COVID-19 Radar」を元につくった部分については利用者がソースコードを得られるはずだ。

アプリ内には特にソースコード取得方法については言及がなかったので、問い合わせ窓口として記述されているメールアドレスに開示請求メールを送った。しばらく返事を待ってみようと思う。

追記

こういう、ほぼそのまま使い物になるOSSプロダクトに手を入れてリリースするっていう場合、ロゴやプライバシーポリシーをOSSにしないで済ませるためのメインラインのごく近くを走り続けるforkみたいなのを想像する。ただ、COVID-19 Radarのリポジトリを見ると既に厚生労働省のロゴやプライバシーポリシーが入っているのでそうではないらしい。

更に追記

更新が少し遅くなったが、その後問い合わせ窓口から次のような返信を貰った

本アプリにつきましてはオープンソースで開発をしており、[Covid-19 Radar]としては既に各種情報は公開済で誰もが確認できる状況になっております。 今後開発元であった[Covid-19 Radar]から国に主幹が移管されていきますが、今回のアプリケーションとしての公開方法や場所については現在検討中となります。

この返信自体に疑いを持つ人もいるようだが、ひとまず個人的には信頼できると感じている。

巨大数論の面白み ―― 現代思想 「巨大数の世界」

数学 読書感想

現代思想 2019年12月号 特集=巨大数の世界 ―アルキメデスからグーゴロジーまで―

現代思想 2019年12月号 特集=巨大数の世界 ―アルキメデスからグーゴロジーまで―

『現代思想2019年12月号　特集＝巨大数の世界』を読んだ。かのフィッシュ氏による巨大数論解説に始まり、巨大基数や組合せ論や、古代ギリシャ以来もしくは仏教における巨大数、巨大数や数学的実体の存在論、永遠についての時間論、はたまたジンバブエドルなどを網羅している。巨大な概念を愛好する向きにはたまらない一冊である。またそれらのトピックが単に巨大であるという理由で任意に集められたわけではなく一定の相互関係を持っている点は注目に値する。

思想史ないし数学史の延長上における巨大数の位置付けは「情報社会にとって『数』とは何か」という大黒岳彦氏の論で述べられていて、これも大変勉強になった。現代の、なかんずくヒルベルト以降の数学が経験的世界から離陸して形相を契機とするようになったというのは確かにそうだし、その流れの中で数学が閉じた自己言及的円環をなす過程で数学基礎論が生まれたというのはきっとそうなのだろう。これに対して一般に巨大数への関心が質料的契機を持つというのもまた間違いない。

一方で巨大数論のファンとしてはやはり、フィッシュ氏の意味での巨大数論が興味深いのは円環を経験的世界にある意味で接地させる奇妙なバイパスとして機能している点にある。 大きな数が面白いのはそれが経験的世界から見て著しく大きいからに他ならないが、その大きな数を競うというアマチュアの遊びが比較的すぐに純粋数学の自己言及的円環を成立させる要たる基礎論の言葉によって理論化されるというのは感動的というほかない。これは純粋数学の力強さを象徴するようでもあり、離陸した円環が落とす影が経験的世界において意味を持つ(おそらくは論で言うところの「下への超越性」によって)ことが、プラトン的な数と経験的世界の紐帯をほそぼそと復活させるようでもあり、そうして興味深いとともにアマチュアの営みがそこへ繋がることがいささか小気味よくもある。

巨大数論の面白み

私にとっては巨大数論の面白みは「寿司 虚空編」004 p.11の「ωだ」の一言に集約される。まさにこの1コマを見たために巨大数論のファンになった。

「ω」だ 小林銅蟲, 2015, 寿司 虚空編 004, p.11

この感動を伝えるには、まず巨大数論のある種の退屈さを述べなければならないだろう。

巨大数が数学の主流から見てトリヴィアルであるのは確かである。任意に大きな自然数は存在するのだし、純粋数学の円環の一部としての必然性も無しにたかが大きな数を作って何が面白いのだろうか。実際、私は現在の日本の巨大数論が生まれた場のすぐ近くまで寄りながらさしたる関心を払わなかった記憶がある ―― 本書におけるp.19「巨大数論発展の軌跡」によれば、現在の日本の巨大数論は2ちゃんねる数学板の「一番でかい数出した奴が優勝」スレに始まっているそうだ。私も同時期に数学板に出入りしていたからこのスレタイは見覚えがあるが、敢えて深く読み込もうとは思わなかった。

一方でそこには素朴な楽しみがあったはずだ。p.82「歴史的に見た巨大数の位置付け」やp.109「巨大数の経験」で仏典の例が挙げられているように、大きな数はそれが擬似的に経験の限界を超越するゆえに人の興味を引く。こうして生まれた大きな数を挙げる遊びが、まさに遊びであるがためにその後につながっていく。

任意に大きな自然数は存在するが、この遊びで勝つためには有限の手続きでその数を述べられなければならない。また、グラハム数Gを挙げることは容易だがこれはG+1に負ける。しかしまたG+1+1+1と後者を挙げていく戦略はもちろんG+Gに負ける。そしてそれらのどれよりもGGが強い。 こうして、大きな数を挙げる遊びはより急速に増大する関数を構成することにすぐさま帰着する。そして、後者から加法を、加法から乗法を、乗法から指数を構成していく過程は空集合から順序数を構成する過程と同型となり、言われてみればほとんど当たり前なのだが、このように巨大数を挙げたり２つの巨大数を比較することは順序数のそれと対応付けられるようだ。そして遂に、現在の巨大数論の先端はωを超えてε0に対応する関数に至る。 巨大数論はそれがアマチュアの遊びに由来することによってむしろ必然的に、順序数や、計算可能関数や、ラムダ計算といった非自明な説明を必要とする。

つまりは、p.14の対談における鈴木真治氏のコメントにまったく同感で、たかだか有限の数――それも大きなものを挙げて勝つという他愛もない遊び――が超限順序数のような無限の世界のものと結びつくというただその一点が何とも愛おしくてならない。

転職エントリ(1年後)

日記 来るべき世界

Nianticに転職して1年あまりが過ぎた。

2018年の9月からNianticで働いているのだが、そういえば転職エントリーを書きそびれていた。 転職して以来、相変わらずサーバーサイドの開発をしていている。なお、開発しているのはIngressでもPokémon GOでもハリー・ポッター：魔法同盟でもない。

Nianticとの関わり

Ingressは2014年12月から続けていて、Pokémon GOも日本での正式リリース日からぼちぼちやってきているものの、それにしてもNianticで働くようになるとは思ってもみなかった。 Pokémon GOがなんかえらく流行り始めたときも、自分とは関係ない話だと思いつつGoogle Maps時代の知り合いが何人か関わっているのを思い出して無責任に祝福していたぐらいである。知り合いへのご祝儀のつもりでポケコインを1万円分ぐらい買って、行動圏内にルアーモジュールを設置しまくったのを覚えている。

転職後に変わったことといえば、Ingressのイベントに参加するようになったりPokémon GOのプレイ頻度が増えたことぐらいだろうか。やはり社内でこれらの話題に触れる機会が増えると自然と関心が湧いてくるので。最近もField Test福井に参加してきた。

転職時に思ったこと

こうしてみると以前からNianticに若干の縁はあったのだが、もちろん転職時には他の会社も検討した。検討してみて、いくつかの点に魅力を感じてNianticを選ぶことになった。たとえば、東京オフィスにいる人達の半分くらいは顔見知りで、彼らと一緒に働くのは楽しそうだと思ったこと。色々と興味深い解くべき技術的課題を持っていて面白そうだったこと。 なかんずく、見知らぬ土地に出かけたり歩いたり、人と関わることを促進するような未来像・理想を語っていること。こういう性質はひょっとしたらエコーチェンバー現象を抑制する1つの解になるかもしれない。

1年経ってみた感想としても、こういう自らミッションステートメントを掲げてきちんと計画して、真面目にミッションに向けて取り組んでいる組織ってのはやはり良いもんだと思う。

もとより私はオフラインのように豊穣でオンラインのように便利で安全な世界ってものを望んできた。 リンク先の文書を書いたときに比べれば、なるほど状況はやや変わっていて最早オンラインとオフラインを分けることが無意味になってきてはいる。何しろ今日では常時のインターネット接続が実質的な基本的人権とすらなりつつあるのだから。それにしても、「ネットワーク化済み実在とネットワーク未接続実在」とでも読み替えればもうしばらくは通じるだろう。 いずれにせよNianticの語る未来像は私が望むそれと通じるし、前掲記事中でも触れられているARのような技術は当然にその有力な構成要素であると思われる。

これまでの私の経験則によれば、こういうなんとなく自分の好みな方向の美意識や社会的問題意識に基づいた未来像に協力しておくと、そのうちに自らリードしたいと思うようなすごくのめり込めるものに行き当たって、しばらくは楽しめるはずだ。そういうわけで、当面はこういう未来像を実現する上で私ができる役割を果たしてみたいと思ったのだった。

念のため: この記事は筆者の個人的な経験および意見について述べており、筆者の雇用主とは一切関係ありません。

福井行

日記

IngressのField Testがあるので福井に行ってきた。 Field Testは国内でも数か所で実施されるのでどこに行こうか結構迷ったのだけど、結果としては福井で正解であった。なんだか、自分でも思った以上に福井と縁があったので、終始それを感じて楽しめたのである。

さて、まず福井につくなり駅の階段で迎えてくれるのが永和システムマネジメントの広告である。Rubyといえばesm, esmといえば福井が本社なので、最初からそこはかとない安心感と親近感を覚えさせてくれる。

次に、階段を降りたところにいるのが見慣れた恐竜博士の像。ながらく表参道で働いていたのだけれども、昼休みによく歩いたあたりに福井のアンテナショップがあって、その前にも恐竜博士がいたものだった。見慣れた姿を本場で見ることができて感激する他ない。

聞けば、福井駅には恐竜博士があと3体いるそうな。改札口をでたところにも確かに居た。他にもえちぜん鉄道福井駅にもいるのを後に発見するが、残り1体は所在がわからなかった。

さて、メインのField Test中にポータルを周る際には福井のエージェントのかたがたとご一緒できて(途中ではぐれたけど)、とてもありがたかった。なんとかメダルを獲得できたけれども、時間内に3000m歩くという項目はかなりギリギリだった。記録上は3017mとなっている。

天気にも恵まれて適度に曇って暑すぎず、良いIngress日よりだったように思う。FT福井の中の人には改めて感謝したい。

FT福井の翌日、この日は当初からあちこち見て回るつもりでいた。さて福井といって思い出すのは福井県民が活躍する『ミカるんX』であろう。いやかなり偏った見解かもしれないけど、あの作品のファンなので。そういうわけで聖地巡礼としてソースカツ丼を食べて、恐竜博物館に行かなければならない。

恐竜博物館については良い評判を聞いていたものの、実際にはその期待をもはるかに上回った。常設展示場にはいるとすぐに圧倒的な物量の化石骨格標本が目に入る。よく見渡せば古生物学だけに限らず地質学全般の展示もあり、標本の種類も解説も凝っており、完全に堪能しようと思ったら1日ではまるで足りないことが分かってくる。 残念ながらそこまで時間はないのでめぼしいところだけ見たものの、ぜひまた来たいものである。

Ingressポータルを巡りながら勝山駅まで歩き、えち鉄で福井に戻る。

ソースカツ丼はヨーロッパ軒を薦められたので、その晩に行ってみた。

時間管理研修の話

ある社内研修の一コマだった。 私は受講対象者ではないんだけど、良く覚えていない謎の理由によりオブザーバーとして参加していた。 ちょうど講師が「重要でなく緊急でもないもの」「重要でないが緊急のもの」「重要だが緊急でないもの」「重要で緊急のもの」って例の話*1をしていたときだった。話がだいぶすすんでそろそろ次の話題に行こうかというところで、はたと気づいた。私を含めて参加者の半分ぐらいがラップトップを開いてメールやSlackをチェックしながら聴いている。これはどうしたことだろう。

この手のメールチェックってのは往々にして「重要でないが緊急なもの」か「重要でも緊急でもないもの」だ。少なくとも私がやってたのはそうだった。 そこで、その場で参加者に訊いてみた。「私も含めてみんなメールチェックしてたけど、それって重要で緊急なものですか?　もしそうだったらお忙しいところ参加頂いていて大変申し訳ないんだけど、全員がそうって訳でもないんでは?」 すると、全員が「重要でないが緊急なもの」をやっていた。

一方で研修なんてものはおおよそ緊急でなく、でも会社はそれが重要だと思ってなけなしの研修予算と研修時間枠を使って投資している。つまりこれは「重要だが緊急でないもの」だ。 仮に参加者が「こんな聞き飽きた話はくだらねー」と思っていたとしても、会社はそう思ってないのだから、ならば速やかに「この研修くだらねー」という適切なフィードバックを与えるのは重要な仕事だ。

なんということだろう。我々は「重要でないが緊急なもの」より「重要だが緊急でないもの」を大切にしよう、という話をまさに聞き、うんうんそうだよなと思いながら、最後の最後まで疑問を持つことなくその逆をやっていた。つまり今まさに間違った優先順位を付けて、「重要だが緊急でないもの」について成果を出してなかった。

おそらくこれこそが、「重要だが緊急でないもの」に時間を割こうという話なんだろう。この話はきちんと説明されれば当たり前のことを言っている。漫然と聞いていたら誰もそこにさしたる疑問を抱かない。ただし、それを我がこととして引きつけて考えるには集中が必要だ。どんなに当たり前の話に聞こえたとしても、それを理解するの思考リソースを割く必要を感じなかったとしても、受講した時間から真に価値を引き出すためにはそれを真剣に考えることが必要だった。

「バックグラウンドで思考する」ってやりかたもあるが、そのために必要なフォアグラウンドタスクはアルキメデスの昔から典型的には入浴とか散歩とか落ちものゲーとかそういうやつで、メールチェックや定例会議ではない。 「重要だが緊急でないもの」にきちんと取り組むには、「重要でないが緊急なもの」を明確に排除して存分に取り組む時間を意識的に作らねばならない。

我々は、図らずもその意味を研修の中で実証したのだった。

*1:ビジネス書で引用されすぎていてどこが元ネタなのかよく把握してなかったんだけど、今調べた限りでは『7つの習慣』なのかな?

ブロックによるRuby内DSLの起源

ruby

言語内宣言的DSLを構築するRubyの能力がいつからできたものなのか、ふと疑問に思った。

この手の記法で一番古くからあるものとして思いつくのはTk bindingだが、これはいつ頃からあったんだろう。 そう思って古いRubyを見てみた。fj.sourcesにて最初に世界に向けて流されたというruby 0.9.5を見てみると、sample/tkhello.rbに次のような例が既にある。

TkButton.new {
   text 'hello'
   command proc{print "hello\n"}
   pack('fill'=>'x')
}

MatzがLispを意識していて1LispでDSLが盛んに構築されていたことを考えると、これはMatz単独の発明ではないかもしれない。でも、この時点で既にブロックというRubyの機能を用いて宣言的にものを記述するという発想はあったことは分かる。

たとえブロックという制御構文を自作するための記法があったとしても、宣言的語彙を構築するという意思がなければAPIはこんな感じの筈だからだ。

TkButton.new {|btn|
   btn.text = 'hello'
   btn.command = proc{print "hello\n"}
   btn.pack = {'fill'=>'x'}
}

ChefやVagrantfileやRSpecといった現代のDSLを知っているとすこし物足りないのは確かであるものの、基本的な形はRubyが最初に一般に投稿された1995年の時点で完成していたことが分かる。

ただし、この発想が更に一歩進んで臨界点を超えて広まり出すにはRakeを待つ必要がある。そして、最後の部品である表現能力のさらなる探索はRSpecによってもたらされたと言うべきであろう。

  1. そもそもRubyにはMatzLispというあだ名があったわけだけど、割とあとのほうになるまで、nilが空配列と同等に扱われるケースが広く残っていたりというあたりが思い当たる。↩