github という公的なインフラを使うために必要なこと

馬しか見たことない人に、これと自動車を両方見せて「どっちが欲しい」と聞いたら、どちらを選ぶだろうか？

理性的な人だったら、自動車が平らな道しか走れないことを一番気にするだろう。

ボストンダイナミクスの四足自走機械は、馬が走れる道ならほとんどそのまま進める。道が舗装されてなかったら、自動車で行ける範囲は本当に限られている。どうみても、四足自走機械の方がずっと実用性が高い。

「道を舗装して、トンネルや橋を作って道を平らにすればいいんですよ」なんて言ったら、「たかが乗り物のためにどうしてそんな手間をかけなきゃいけない？」とあきれてしまうだろう。

私は、今、github を中心に仕事が回る職場で働いている。実際使ってみて、この github というものは非常に便利だと思うのだが、過去の自分にこれを勧めてみたらどういう反応するか想像してみると、これと同じ反応になると思う。

私が働きはじめたのはワープロが普及する前で、最初の5年くらいは、書類を全部手書きしていた。その後の技術変化には全部、それなりに適応してきたけど、最初の刷り込みは大きい。

github は便利だけど、組織の構造というか指揮命令系統を変えないとこれは使えない。過去の自分は「たかがワープロのためにどうしてそんな手間をかける必要がある？」と言うだろう。

ワープロで文書を作成し、そのファイルをメールで送信したりファイルサーバに置くのは、紙でやってたことの延長だ。同じことだけど随分便利になっている。昔の自分は、その方が自然で使いやすいと言うだろう。

四足自走機械が、馬より安くて燃費がよければ、同じように、人は喜んでそれを使っただろう。道を平らにしてまで車輪自走機械に乗り換える必要性なんか感じなかったはずだ。

ワープロやメールなどの初期のITは、全部紙でやってたことのシミュレーションだ。同じことをやってもコンピュータ上のシミュレーションでやるといろいろ便利になる。最初にそれをやるのは正しいし、それは大きな進歩だ。

しかし、技術の自然な利用法という観点で見ると、エンジンやモーターのように動力源が回転するのであれば、タイヤのように回転する部品で推進力にする方が自然だと思う。機構も単純になるし、部品も少なくなる。

コンピュータやネットの自然な利用法は github だ。蟻塚に無数の蟻がたかって蟻塚が成長するように、リポジトリに人が集まって、自然にソフトウエアが成長するイメージ。

工場や物流センターを作るとしたら、自社の敷地内部の設計より立地が大事だと思う。インターからの距離が重要だ。公道である高速道路網とどのようにつながっているかが重要だ。

それと同じように、ある程度の規模のアプリケーションを作るとしたら、内部の設計より、github との距離が重要だ。今、アプリケーションを書くなら、自分で書くよりはるかに多くのオープンソフトウエアを使うことになる。高速道路網に依存した物流センターを作るようなもので、公的なインフラとの連結が重要なのだ。

そして、幹線でなく支線との連結の方がより重要だ。

幹線となるような著名なオープンソフトウエアは、大なり小なり特異な事例であって、普通でないリーダーが率いていたり、特殊な企業が特殊なビジネスモデルのために金を出している。そういうものと普通の会社の業務用アプリケーションとはあまり関係ない。

しかし、多くの幹線ソフトウエアの回りには、プラグインという支線となるソフトウエアがあって、本来は、こういうものに注目すべきだ。大半の支線のソフトウエアは普通のプログラマが数人で開発している。それが何千何万と集って github の中にインフラを形成している。

9割はうまく開発されているが、バグだらけだったり、おかしな方向に進化したり、突然消えるプロジェクトもある。そういうダメなソフトを避けたり、問題を自力でカバーするのが、内製するプログラマの腕の見せ所で、そういうノウハウを得るためには、自分たちが github を日常的に使っていることが非常に有利になる。というか、そういう経験がない人は、何をどう使っていいのかわからないだろう。

四足自走機械と車輪式自走機械を比較検討するとしたら、両者のスペックでなく、道路網の整備状況を見なくてはならない。道路が無い所にトラックだけ入れても何もできない。

それと同じように、github を使うということは、指揮命令系統がない仕事の仕方を導入しないといけない。それをしないと、既に構築されている巨大な公的インフラが見えてこない。

指揮命令系統がない仕事を構成しているのはプルリクエストだが、それを担保しているのは「いつ何どき誰がフォークしてもよい」という暗黙のルールだ。たとえば、Ruby on Railsのリポジトリには、今日現在、12953のフォークがある(右上のForkという欄)。この12953人の誰もが「今日から俺のリポジトリがRuby On Railsの本家である」と言ってもよいのだ。もし、それに同意する人が本家より多ければ、そのリポジトリが本家になる。

12953人のほとんどは勉強のためにフォークを作成していると思われるが、ごく稀に、自分たちが必要な特別の Ruby On Rails が必要なので、フォークしてそれを維持している人がいる。

もし、本家が迷走して、おかしな方向に行ったら、そのどれかが本家をのっとるだろう。

そういう分裂はほとんど起こらないが、それは、本家がまともな運営を強いられているからだ。幹線が幹線の行くべきでない方向に進むと、そこから別の幹線が生えてきて、最初の幹線をしぼませてしまう仕組みが、 github にはある。この方法は、特定の会社が「我々が責任を持って正しい方向に幹線を進めますので信頼してついてきてください」と言うより、ずっとうまくいくのだ。他の会社が幹線を作れないと、その幹線はたいてい、利益誘導のために、違う所へ行ってしまう。よくても寄り道をする。

誰でも幹線をフォークでできることが幹線を正しい方向に維持して、それがあるので、多くの人が支線をつなげ回りに物流センターがたくさんできる。安心して支線や自社設備を作れるので、スピードが速い。

指揮命令系統がないことが信頼性を担保しているというこの仕組みが、インターネットにとって自然なのだ。エンジンで走るならタイヤで駆動力を得るが自然であるのと同じように自然なのだ。

それが自然であることの証拠をもう一つあげるなら Twitter だ。

Twitterにも、指揮命令系統がないことの強さがある。ただし、その強さは、今の所、破壊力としてあらわれることの方が多い。Brexitをはじめとする、昨今の社会的大事件は、全部、指揮命令系統のない運動が、指揮命令系統のある組織を打ち負かしたことから起きた。そうなるのは当然で、力学に近い絶対的な法則だ。インターネットでは何事もシェアすることが自然なのだ。摩擦が少ないだけ、力が無駄なく伝わる。

ワープロが手書き書類をよくシミュレートしたように、コンピュータは紙をよくシミュレートする。だが、一つだけ重要な機能が抜けている。ネット上の情報は「なかったこと」にはできない。組織というものは全て、いざということに紙を燃やすことで「なかったこと」にすることに依存している。そこだけが抜けているので、本来は、コンピュータで紙をシミュレートするべきではなかったのだと思う。

「なかったことにする」というのは、めったに使われないが、核兵器やフォークと同じように抑止力として社会が回るために重要な機能だったのだ。

ボストンダイナミクスの四足自走機械は、災害現場などのごく特殊な場面のみで使うべきもので、他は全部車輪自走機械を使うほうがいい。

同じように、コンピュータとインターネットは、情報をシェアするために使うべきで、紙のシミュレートをしていいのは、ごくごく特殊な状況のみなのだ。

たとえ、そのために、指揮命令系統という長年人が慣れ親しんだものを捨てなくてはならないとしても。

大量生産の時代には、本来それに向いてない製品を扱う業種も、自動車や家電の会社を真似ることを強いられた。

これからは、本来 github に向いてない製品を扱う業種も、github のやり方を強いられる。Twitter のスピードに勝てるのは github だけだからだ。そして、ソフトウエアでないものをユニットテストしたりプルリクエストするためにAIが使われていくと思う。

当ブログの関連記事

• ビットとアトムのはざまで - アンカテ

一日一チベットリンク→China Bans Lady Gaga - Stereogum