新しく買った携帯電話のアプリでおかしな不具合を見つけて開発元に報告したところ、数日後、同じ問題を経験した数百人からの報告がすでに集まっており、修正版も間もなく公開されたという返事を受け取った経験はありますか。一人では原因さえ見当がつかない問題も、多くの人が一緒に調べると、意外に早く解決することがあります。このように、多くの人の目が集まるほどバグが見つかりやすくなるという考えを表した言葉が「リーナスの法則（Linus's Law）」です。
リーナスの法則とは、簡単に言えば「見る目が十分に多ければ、すべてのバグは浅いところに姿を現す」という経験則です。ソースコードを公開し、誰でも調べられるようにするオープンソース（Open Source）の開発方式がなぜ力を発揮するのかを説明する代表的な言葉として、長く引用されてきました。
本資料では、この法則が生まれた背景と正確な意味から、多くの目が効果を発揮する仕組み、そして法則の限界を示した事例や現実での活用方法まで、順に見ていきます。
多くの目が守るソフトウェアの仕組みと限界
リーナスの法則とは何か？
この法則は、アメリカのプログラマー、エリック・レイモンド（Eric S. Raymond）が1997年に初めて発表し、1999年に書籍として刊行したエッセイ『伽藍とバザール（The Cathedral and the Bazaar）』でまとめたものです。名前は、1991年にLinuxカーネルを初めて作ったフィンランド出身の開発者、リーナス・トーバルズ（Linus Torvalds）に由来します。韓国では、英語の発音を反映して「ライナスの法則」と呼ぶことが多くあります。
レイモンドはこの法則を、より正確には「ベータテスターと共同開発者が十分に多ければ、ほぼすべての問題は素早く把握され、その解決策は誰かにとって明白である」と説明しました。
（1）伽藍モデル
少数の専門家が外部と隔てられた環境で綿密に設計し、完成度が高まったときだけ成果物を公開する方式です。バグは深く隠れており、長いテストを経て初めて見つけられると考えます。
（2）バザールモデル
早い段階から頻繁に公開し、誰でも意見や修正案を出せるようにする方式です。Linuxの開発はこのような形で行われており、レイモンドは、多くの参加者のおかげでバグがすぐに見つかると考えました。
多くの目がバグを見つける仕組み
リーナスの法則の核心は、バグを見つける作業と修正する作業を、別々の人が分担できるという点にあります。最初に問題を経験した人が原因を知らなくても、その症状を見た別の誰かは、解決方法をすぐに思いつくかもしれません。
- 多様な利用環境（Diverse Environments）：人によって機器や使い方が異なるため、開発者がテストしきれなかった状況で問題が明らかになります。
- ピアレビュー（Peer Review）：ほかの開発者がコードを読み、書いた本人が気づかなかったミスを指摘します。
- 並列デバッグ（Parallel Debugging）：複数の人が同時に原因を追究することで、一人で作業するときよりも早く手がかりを見つけます。
（1）症状を知らせる人
バグを経験したユーザーが再現方法を具体的に記録すれば、原因を絞り込むための時間が大幅に短くなります。
（2）原因を見抜く人
似た問題を扱った経験のある開発者には、ほかの人には深く見えるバグも、浅い問題に見えます。法則の「浅い」という表現は、まさにこの点を指しています。参加者が増えるほど、こうした人に出会う可能性も高まります。
法則の限界を示した事例
［事例1］2年以上も潜んでいたハートブリード
インターネットの暗号化通信に広く使われるオープンソースソフトウェア、OpenSSLに、2011年末のレビューを経て組み込まれたコードには欠陥がありました。この欠陥は2012年3月のリリース版から広まりましたが、ハートブリード（Heartbleed）という名前で公表されたのは、2014年4月になってからでした。公表当時、信頼されたセキュリティ証明書を使うウェブサーバーの約17％、およそ50万か所に危険があると推定されました。同じ年の9月には、Linuxなどで広く使われるコマンド処理プログラムのBashで、1989年から約25年間潜んでいた欠陥、シェルショック（Shellshock）も発見されました。
［事例2］少数の人に委ねられた基幹ソフトウェア
ハートブリードが明らかになった当時、OpenSSLはごく少数のボランティアによって管理されており、そのうち専業の開発者は一人だけでした。誰でも見られるコードでも、実際に注意深く調べる人がいなければ、バグは長く潜み続けることが明らかになったのです。事件の直後、Linux Foundationは主要企業とともに、重要なオープンソースプロジェクトを支援する基金を設立しました。
リーナスの法則を現実で生かす方法
ソフトウェア工学者のロバート・グラス（Robert Glass）は、レビュアーを増やしても、見つかるバグがそれに比例して増えるわけではなく、有効なレビュアーの人数は二、三人から四人程度だという研究を挙げ、この法則を批判しました。一方で、人気のあるオープンソースプロジェクトほどバグの修正率が高かったという分析もあり、議論は今も続いています。結局、目の数そのものよりも、実際にコードを調べる目がどれほどあるかが重要なのです。
（1）コードレビューを手順に組み込む
すべての変更を一人以上の同僚が読んで承認した後に反映すれば、公開の有無にかかわらず、多くの目による効果を得られます。
（2）重要なコードに人と資源を集める
多くのサービスが依存する重要な部品ほど、専任の管理者を置き、定期的なセキュリティ監査を実施する必要があります。
（3）バグを報告しやすくする
ユーザーが問題を手軽に知らせ、対応の進み具合を確認できるようにすれば、外部の目が自然と集まります。
（4）自動化ツールで隙間を埋める
人が見落としやすい境界値のエラーは、自動化されたテストツールで繰り返し確認することが効果的です。
リーナスの法則は、開かれた協働によってソフトウェアの品質を高められるという信念を、一文で表しています。しかし、ハートブリードが教えたように、コードを公開するだけでは十分ではありません。そのコードを実際に読み、テストする人がいてこそ、この法則は本来の力を発揮します。
公開されているコードを実際に調べる目を集めること。それが、安全なソフトウェアへの第一歩です。
