水野祐＋平林健吾 Edit × LAW 第13回「GitLaw」

第13回「GitLaw」

水野祐

佐藤雅彦、菅俊一、石川将也著『差分』（美術出版社、2009年）

　「コードは法である」と論じた、ローレンス・レッシグの主著『CODE　インターネットの合法・違法・プライバシー』（山形浩生・柏木亮二訳、翔泳社、2001年）を引くまでもなく、法とソースコード・プログラムの近似性は指摘されているところである。筆者もまた実務において、法律や契約などの法の設計・デザインは、人や企業から成る社会関係を正しく動作させるためのプログラミングであるとの実感をもって、契約書をドラフトしている。Google Docsでクライアントと一緒に契約書を「コーディング」していると、そこには確かに新しい感覚が存在する。

　近年、ソフトウェア開発者に人気があるソースコード共有サービスが「GitHub」である。GitHubは、2008年にローンチした、Gitというヴァージョン管理システムを利用し、プログラムの差分情報のやり取りを行うことで、「ソーシャル・コーディング」とも呼ばれる分散的な開発スタイルにフィットするサービスであり、そのサービスを運営管理する企業でもある（余談になるが、先日来日したGitHubのGovernment EvangelistであるBen Balterは、GitHubのことを「プログラマー用の・・・・・・・・SNS・・・である」と端的に表現していた）。
　GitHubのすばらしさについて、筆者に語るべき立場にない。本稿で筆者が取り上げたいのは、法律文書の管理・公開にGitHubが利用され始めていることについてである。

■

　たとえば、筆者が知るかぎり、Tumblrはかなり初期からGitHub上で利用規約やプライバシーポリシーなどのヴァージョンを管理・公開していた。
　また、Twitterは、2012年から、Innovators Patent Agreement（IPA）という、社員の発明による特許を発明者の許諾なく「攻撃的」な訴訟などに使用しない旨のオープンな職務発明に関する契約をGitHub上で公開している。

　日本では、2012年に、山口情報芸術センター（YCAM）に附属する研究開発チームであるYCAM InterLabが、アーティストやエンジニアなど共同開発を行うクリエイターとの間で締結する共同開発契約書の和英ヴァージョンをGitHub上で公開した、「GRPContractForm」というプロジェクトがある。この契約書では、YCAMと国内外からクリエイターが共同開発した、フィーや費用分担、作品の取扱い方法から、テキスト、写真を含む画像、音楽を含む音声、映像、ソフトウェア、ハードウェアなどの成果物をオープンソース化することなどまでを盛り込んでいる。

　また、2014年には、IAMAS小林茂教授がリードして、ハッカソンやメイカソンの主催者と参加者との間で締結する参加同意書や、ハッカソンやメイカソンで生まれた成果物をその後企業が利用する場合の企業と個人との間の契約書などのひな形をGitHubで公開するプロジェクトを行った。

GitHubのIAMASアカウント上で公開されている、「ハッカソン／メイカソン参加同意書および終了後の確認書」のひな形（スクリーンショット）

　上記はいずれも筆者が関与した事例であるが、2015年3月には、1200万DLを超えたゲーム「BrainWars」を開発・運用するゲーム・スタートアップ企業であるトランスリミット社が就業規則その他社内規程をGitHubで公開したことも話題となった（ブログ・エントリーの内容がすばらしいので、ぜひ読んでみてください）。

　このように法律文書をGitHub上で公開することにより、別の企業が「フォーク（Fork／分岐して別ヴァージョンを作る）」してカスタマイズして利用することも可能になる。また、社員が「プルリクエスト（Pull Request／気に入らない文言や条項に変更要求を送る）」して、それを企業が「マージ（Merge／承認を受け入れて採用すること）」すれば、企業にとってもそこで働く社員にとっても双方にベターなものを作成することもできる。
　テキストのヴァージョン管理システムとしてはウィキペディアなどにも採用されているwikiが先行しており、テキスト管理においてはwikiに一日の長があるとも思われるが、Gitはテキストとソフトウェアなどの他の分野と統合的に管理が可能な点で可能性がある（と筆者は考えている）。 *1

■

　すでに企業のマーケティングは、広告などによりいかにユーザー・消費者をアピール・扇動するのかという「アテンション」型から、企業とユーザーとの間の信頼関係をいかに築くのか、という信頼関係ベースのものへと緩やかに移りつつある。さらに進んで、ドク・サールズが『インテンション・エコノミー』（栗原潔訳、翔泳社、2013年）で描くように、やがて企業のマーケティングが、現在のように「アテンション」型ではなく、ユーザーの志向が重視される「インテンション」型に変化していけば、企業と私たちとの契約形態は企業が用意した、一方的で、修正不可能な契約（シュリンクラップ契約、クリックラップ契約などの附合契約と言われる）から、ユーザーごとにカスタマイズされる契約形態に移行する可能性がある。企業も事務管理上のコストとしてできなかったこれらの契約形態が、テクノロジーを利用することで可能になる。上記のGitHubにおける法律文書の利用の例は、筆者にはこのような流れの端緒とも見える。

■

　Gitのヴァージョン管理の機能に着目し、これを法律の制定・改正・廃止に敷衍する動きが「GitLaw」である。法律の制改廃についても、ソフトウェアと同様に、ソーシャル・コーディングできるのではないか？というのが、GitLawの基本的なコンセプトである。

GitLaw（スクリーンショット）

　この動きはまだアイデア段階であるが、2011年にLaw Factoryが行ったフランス国会の290の法案のヴァージョンをシステム（GitHubとは別のもの）により管理し、立法過程を可視化した彼らのプロジェクトを先例として挙げる。どの法案がいつ、どの議院で、どのくらいの期間議論されたか、どの議員がどのような修正を加えたか、その修正が最終的な制改廃止にどのくらい寄与したかなどを可視化することができる。
　すでに、企業や自治体がGitHubの公式アカウントを取得し、ソースコードを公開する動きが始まっている。「オープンデータ」や「オープンガバメント」といった流れにおいても、GitHubが注目を浴びている。GitHubを活用したオープンデータについては、フィラデルフィア市の試みが有名であるが、日本でも、和歌山県がGitHubの公式アカウントで行政関係のソースコードを公開して注目を浴びている。

和歌山県のGitHubアカウント「wakayama pref org」（スクリーンショット）

　このようなオープンデータの流れのなかで、GitHubにソースコード以外にも、法律や条例、そして各種政府系の文書など、法律文書が公開されるイメージは容易につくだろう。

　このような法律のヴァージョン管理については、もちろんオープンデータの観点からも評価できるものであるが、その可能性はそこに留まるものではない。可視化されたビッグデータの分析や、一般市民による立法過程への参画、つまり一般市民が法律の「編集」に加わるなど、立法手続の抜本的な変革につながる可能性もあるだろう。

■

　たとえば、いま話題の憲法の議論についてGitHubでヴァージョンや差分を管理したら、どういうことが起こるだろうか。 *2 読者のみなさんのなかにも、世間を騒がしている法律について、プルリクエスト（Pull Request）したり、マージ（Merge）したり、したくなる方がすでにいるはずだ。そして、それは民主主義の原則からすれば、あながち間違ったことでもない。私たちは「法律をソーシャル・コーディングする」ことができる時代に生きている、はずなのだ。そして、私たちは可視化された差分から最適な「解」を選ぶことだって可能なはずだ。近い将来、「ディフ（Diff）」や「プルリクエスト（Pull Request）」、「フォーク（Fork）」、「マージ（Merge）」などのGitHub上の主要な概念は、プログラムに限らず、契約や法律においても重要な概念となる可能性だってある。

　やがて、私たちは、個人同士または企業間の契約や、国と私たちの契約たる法律を、私たち自身で主体的に設計・デザインすることができるようになる。このようなリーガルデザインの考え方は、民主主義における社会的な意思決定プロセスを再生させるための有効な武器になりうると個人的に期待している。

［Edit×LAW：第13回　了］

注
*1│ヴァージョン管理システムの比較
Gitとwikiの違いについての考察や、GitHubに関する技術的または文化的な考察については、DOTPLACEで連載しているドミニク・チェンによる「読むことは書くこと Reading is Writing」の第17回、第18回、第19回が必読である。

*2│GitHub上で憲法のヴァージョンや差分を管理する
この観点から、東浩紀編『日本2.0　思想地図β vol.3』（ゲンロン、2012年）における「憲法2.0」はクリエイティブコモンズ・ライセンスの付与やwikiでの公開も含めて先例と言える。

Edit × LAW⑬「GitLaw」 by 水野祐、Tasuku Mizuno is licensed under a Creative Commons 表示 2.1 日本 License.