2015年1月23日
ソフトウェア・コモンズの経済的な失敗と、今すぐできること
(2014-12-08)by Paul Chiusano
本記事は、原著者の許諾のもと に翻訳・掲載しております。
ソフトウェア産業の発展は、ここ40年間で蓄積した技術的負債の重みに押しつぶされてきました。私たちが頼るツール、言語、ライブラリ、プラットフォームは、数千億円もの無益な生産の原因となる、大量の付随的な複雑さに悩まされています。開発者として数日、数週間、または数カ月という時間を、存在する”べき”ライブラリの実装に費やしたり、”簡単であるべき”タスクを実装するためにポンコツなソフトウェア技術を使って仕事をするような人なら誰でも、これは人間ができる最高の仕事にはなりえないと、心のどこかで理解しています。私たちが、より良い方法を知らないということではありません。次の製品をリリースする以外に、タスクに専念できる時間とリソースを十分に与えられれば、プログラマの多くはより良い状況にするためのアイデアを持つことはできるでしょう。しかし私たちは、 ソフトウェア・コモンズの経済的な失敗 のせいで、そのようなリソースを得られそうにありません。ここでは、この問題について説明し、このゲームを変えるために今すぐ始められることをお教えします(ネタバレ: Snowdrift.coop をチェックしてみてください。すばらしいアイデアだと確信したら、 彼らの開発に出資 してください)。
では、問題点は何でしょうか? ソフトウェア業界では、みんなが似たような問題を解決しています。そしてソフトウェアは(物質的なものとは違って)、共通ライブラリ、ツールといった形で、それら解決策の共有を当たり前のことにしています。この共有の簡単さは、共通の問題の解決策を向上させるために協力する人々の理に完璧にかなっています。いくつか例を見てみましょう。多くの企業は、Webサーバのソフトウェアや、SSL/TLSのような基本的な暗号化プロトコルの実装を必要とします。多数の会社と個人がこのソフトウェア技術に頼れば、共通ソフトウェアの開発プロジェクトへ適切な資金やスタッフを提供する人が利益を得るようになるのは間違いありません。そして、このように重大なプロジェクトのスタッフの大部分が、空いた時間に無給で働く少数のボランティアであるというのは、ばかげたことです。そうですよね? これは OpenSSLのようなプロジェクトでやっていること です。多くの人々やビジネスは、表面上はこういったプロジェクトから利益を得ていますが、大多数はタダ乗り状態で、開発への貢献は一切しません。これは、長い間オープンソース・ソフトウェアを悩ませてきた問題です。後で説明しますが、基本的なゲーム理論を慎重に考えてメカニズムを少しデザインすれば、より良い均衡が生まれます。そして結果的に、重要な共有ソフトウェアのプロジェクトにおいて、価値のあるリソースを得ることができるようになります。
余談ですが、空いた時間に働く個々のボランティアグループがこのような仕事を完成させることができるのは、実際にはとてもすばらしいことです。オープンソース・プロジェクトが(ビジネスのプロジェクトと同じくらい)良いものになり成功しているという事実は、情熱と才能のある人々が鼓舞されてやる気が出るような仕事にとりかかったとき、短時間で何を成し遂げられるかの証しになります。鼓舞されてやる気が出るような仕事をしていれば、あっという間にこれを達成できます。また、無料で使用可能で多くの人が信頼することができる言語、ライブラリ、ツール、プラットフォームなど、 共通ソフトウェア を構築するための 真の リソースを提供することによって成し遂げられる可能性について、私も考えさせられます。
私たちの文明のリソースの分配がどれだけ後退しているかを理解するために、いくつかのハッとするような考えを用意しました。
- Googleの開発者は昨年、OpenSSLの開発者のプロジェクトよりも多くの時間を、広告やアプリケーションのフォントサイズ、色、アイコンや、その他のささいな視覚的詳細の最適化に費やした。
- まずいローストビーフサンドイッチを提供しているレストラン Arby’sのWebサイト は、給料のいいプロフェッショナルのチームによって開発、管理された。彼らはそれを本業としている。Arby’sのWebサイト開発は1週間で、OpenSSLが1年間で手にするよりも多くの開発者向けリソースを手に入れた。
- さまざまなヘッジファンドや投資銀行が取引時間を数ミリ秒単位で短縮するために投じている資金( シカゴ・ニューヨーク間の光ファイバー・ケーブルの敷設 を含む)は、ソフトウェアが開発されて以来あらゆるオープンソース・プロジェクトの開発に費やされた時間価値の合計よりも多い。
なぜ我々の文明は上記のタスクに多くの資金を投じる一方で、基本的なソフトウェア技術への投資はほとんど無視しているのでしょうか? ソフトウェア・コモンズへの取り組みとは違い、上記のタスクへの資金の投入は、十分な報酬が得られます。Googleは、フォント選択などの最適化によって広告の売上を伸ばし、収入をさらに増やしています。Arby’sは、すばらしいWebサイトを運営することによって、まずいローストビーフサンドイッチの売上を伸ばしています(少なくとも彼らはそう思っています)。さらに、シカゴ・ニューヨーク間を直通するケーブルの敷設によって、トレーダーは他の人が機会を得る前に、わずかな裁定機会から利益を上げることができます。
それでも、ソフトウェア・コモンズに取り組む場合は、完全に市場で失敗します。これは単に人々の顕示選好の反映を意図して市場が機能するという結果を嫌う人がいる(現代社会が、 b.goodの地元食材を使ったおいしいバーガー よりArby’sのローストビーフサンドイッチにはるかに多くの金を費やすことに私が深く失望しているのと同じです)という状況ではありません。ソフトウェア・コモンズに十分に資金を供給できないのは、 スノードリフトゲーム ( チキンゲーム と呼ばれることもあります)と呼ばれる集団行動における問題が原因の大部分を占めます。
囚人のジレンマ をよくご存知の方もいるかもしれません。スノードリフトゲーム(または”チキンゲーム”)は、たとえ両者が協力することが最善策だと思える場合でも、協力しないことを選ぶ可能性があるという点で、これと似ています。細部が少し違うので、スノードリフトゲームの方がオープンソース・ソフトウェアへの出資に対する良いモデルでしょう。以下は ウィキペディアによる説明 です。
スノードリフトゲームでは、2人のドライバーが雪の吹きだまりの両側で立ち往生していると仮定します。どちらのドライバーにも、通行できるように雪かきをするという選択肢と車の中にとどまるという選択肢が与えられています。プレーヤーにとって一番見返りが多いのは、競争相手にすべての雪を取り除かせることですが、競争相手の方も自らの働きに対する見返りを得られます。
余談: 囚人のジレンマとの違いは、相手方も協力することを選ぶかどうかに関わらず、プレーヤーたちに協力に対するいくらかの見返りがあるという点です。
スノードリフトゲームでは、他人が行動を起こすのを待ち、それに便乗しようとする動機が存在します。経済界のいたるところでスノードリフトゲームが展開されています。現実世界の方が幾分面倒で、人々は型通りの合理的な行動をするわけではなく、思考を巡らせます。
-
膨大な数の企業が、 TLS/SSL のようなバグのない有効な暗号プロトコルの実装に全面的に頼っている。バグのない有効なTLSの実装こそ、雪の吹きだまりである。企業には、TLSライブラリの開発を支援する、または他社がそれをするのを”車の中で待つ”という選択肢がある。圧倒的多数が何もせず利益を得ようとする。
-
各企業が開発者の年収の1%をOpenSSLや LibreSSL のようなプロジェクトに提供するだけでも、これらのプロジェクトには、満足な数の開発者をフルタイムで雇い、はるかに高水準の質を維持するのに十分すぎるほどの資金が集まるだろう。恐らくは、 TLSを安全言語で書き換えたり 、C ABIを多言語で広く使用できるよう公開したりできるだろう。資金不足なオープンソースの世界では、この考えは常軌を逸しており、人々は常に現状維持への固執を合理的に説明するために 悪い方が良い と大声を上げる。共通TLS実装のようなプロジェクトが(極めて適切に恩恵を受け)数億円の資金を受けるかもしれない世界では、より良い技術を駆使したゼロからの書き直しが多くの意味を成し始める可能性がある。考えるだけで非常にやる気が出ることではないか?
-
このように協力することを選んでいたとしたら、恐らく企業は費用を節約できていたはずだ。 Heartbleed 以降のシステムの修正にかかった直接経費はかなりの大金(恐らくOpenSSLの1年間の開発資金以上)で、間接経費も膨大だった(ユーザの秘密情報がまた流出した可能性があると告げることで、さらなる顧客の信用を失った)。
しかし、これはTLSに限ったことではないと思います。私たちが(a)自由に許諾を与えられ実用的な用途に使えるようにする必要があり、(b)共通ソフトウェアの問題を解決するというプロジェクトを行う場合は、決まってある種のスノードリフトゲームが起こるのです。私が個人的に興味を寄せているものの1つが、 HTML/CSSよりも優れた代替言語 の開発です。この場合、雪の吹きだまりに当たるのは新たなプラットフォーム(少なくとも最初にHTML/CSSへコンパイルできるもの)の研究開発です。HTML/CSSを使用しないためには、他者との連携の問題が大きくのしかかります。TLSライブラリの開発のために何百もの利己的な企業に共同出資させようとするようなものです。しかし運命は変えられないと決めつけて、現実世界のゲームの中で生じるひどい均衡に身を任せる必要など、どこにもありません。ちょっとした メカニズムデザイン に参加することで、ゲームを好転させることができるのです。
Snowdrift.coop の提案する解決策は、 定期出資の誓約に折り合いをつける とてもシンプルなメカニズムです。ここで、スノードリフトゲームの仮説に戻りましょう。あなたは車に乗っていて、外に出て道路の雪かきを手伝うか、車の中で待つかを考えています。ここでもし 均衡の取れた誓約 ができたらどうでしょう? 分担して相手のドライバーもやるなら、自分も雪かきを手伝うという誓約をするのです。相手のドライバーが同様の誓約をすれば、他のドライバーが来た時もこの誓約に倣わせるという道筋を作ることができ、全員がリスクなく協力を約束することができるようになるのです。このようなメカニズムがゲームにより良い均衡をもたらし、ゲームの 利得行列 を意識して手伝わないと決めるのではなく、前向きに協力しようとすることが適切に結果に反映されるようになるのです。
ソフトウェア・コモンズへの出資に際して、 Snowdrift.coop は 出資者 が均衡の取れた定期出資ができるよう、以下のようなフォームを用意しています。 各月毎に、「プロジェクトシェア」1口の定期出資を誓約する人10名につき、1.2円を寄付することに同意する というものです。もし出資者が自分しかいなかった場合は自分の出資負担もなくなり、アカウントからお金が引かれることはありません。またプロジェクト支援のため他の人が定期出資に参加してくると、自分の出資額は Snowdrift.coop のアカウントに入れている額を上限に、二次的に増えていきます。もちろん入れておく額は自分でコントロールできます。1つのプロジェクトに対して2口以上の出資を行うことも可能です。 ここに書いてあることを全部読んで 、より詳しい情報についてはそこに張られているリンク先に飛んでください(すべて調べてあります)。協力する意欲を高める方にゲームを好転させること以外にも、この仕組みには 資金分配の統合 という有益な効果があります。つまり、無作為に複数のプロジェクト間で資金分配がなされ、資金不足でおぼつかないプロジェクトが多数ある状態ではなく、十分に資金がある少数のプロジェクトが生き残るようになるのです。
余談: 私には Snowdrift.coopの メカニズムをさらに改良するアイデアがあります。これはまた別の記事で紹介するつもりです。
もし納得されたら、 彼らの開発に出資すること を検討してみてください。実際皆さんは既に、共同の資金調達用プラットフォームの開発に出資すること自体が、スノードリフトゲームであることに気づいているのではないでしょうか。一度開発ができれば、 Snowdrift.coop はセルフホスティングとなりますので、 Kickstarterなどのサイトのような 全員から取引手数料を取る ようなやり方ではなく、サイト上の通常のプロジェクトと同じようにこのプロジェクト自体への出資を募るようになります。これってすごいことだと思いませんか?
なんと Snowdrift.coop の開発者たちが募っている出資は、謙虚にもいくつかの法的な費用を工面するための約36万円だけです(当初の目標)。でも私は、さらに数千万円かそれ以上の援助を募ればいいのにと思っています。プラットフォームを作り上げている間、近い将来出資がどうなるかなどという心配をしなくて済むようになってほしいのです。何かをやる価値があるということは、それをうまくやってくれる人への資金提供に価値があるということです。私たちみんなに利益をもたらすものを開発してくれる間、その人が快適な生活を送り開発に集中できるようにするのです。
ですから皆さん、心の奥の声に耳を傾け、今度のホリデーシーズンにはぜひ、 Snowdrift.coopの開発に出資してください 。私たちみんなが協力すれば、Googleのフォントの色を最適化したり、まずいローストビーフのファーストフードチェーン店のWebサイトを構築したり、HFTにおける取引の所要時間をあと数ミリ秒短縮しようとしたりといったことへの開発者資源の投入を、違うところに再分配することだってできるかもしれないのです。
@uasiさんより翻訳の修正をいただきました。ありがとうございました!
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 グループマネジャー 株式会社ニジボックス デベロップメント室 室長 Node.js 日本ユーザーグループ代表
- Twitter: @yosuke_furukawa
- Github: yosuke-furukawa