リーナス・トーバルズと「未完成で出す」という技術

はじめに

この記事は、Linux の生みの親であるリーナス・トーバルズ（Linus Torvalds）の生い立ちと開発思想を追いながら、未完成でもリリースしたLinuxと
日本人的の品質管理の「中途半端なものを出せない」という感覚を整理したメモである。

結論を先に書くと日本の品質管理は正しい。
ただし適用範囲を間違えると、それは検品ではなく先送りになる。

本記事における「リリース」とは、ソフトウェアや創作物を他人の目に触れる場所に置く行為全般を指す。完成品の出荷という意味ではない。

1. Linux は5ヶ月で書かれた

1-1. 開発期間

リーナスがひとりで Linux を書いていた期間は、およそ5ヶ月である。当時彼はヘルシンキ大学の学生であり、本業は学業だった。

1991年04月  ヘルシンキ大の自室で開発着手（Minix環境上）
1991年08月25日  comp.os.minix に「趣味で作ってる」と投稿 ← 初めて外部の目に触れる
1991年09月17日  バージョン 0.01 公開
1991年10月05日  バージョン 0.02 公開 ← 外部からパッチが届き始める

完全なソロ作業は4月から9月まで。第三者の介入を「他人のコードが入った時点」とするなら、境目は1991年10月である。

1-2. 0.01 の中身は大したものではなかった

バージョン 0.01 は「OS っぽい何か」に過ぎない。

実装されていたもの	実装されていなかったもの
ブート処理	独自ファイルシステム（Minix のものを借用）
タスク切り替え	ネットワーク機能
キーボードドライバ	移植性（AT互換機専用）
シリアルドライバ	単体での起動（Minix上でのビルドが前提）

つまり世界を変えたソフトウェアの初版は、単体では動かないシロモノだった。

2. 第一声が「言い訳と予防線」だった件

2-1. 有名な投稿

1991年8月25日、Usenet の comp.os.minix に投稿された内容を要約するとこうなる。

・趣味でOSを作っている
・GNU のような大きくて本格的なものにはならない
・ただの趣味の産物である
・AT互換機用で、移植性もない
・どんな機能が欲しいか教えてほしい

謙遜、予防線、そして質問。これが Linux の第一声である。

多くの人間が「見せられたものじゃない」と言って公開を止める段階よりも、おそらく下の完成度で彼は世に出した。

Usenet とは
インターネット黎明期に存在した世界規模の分散型掲示板システム。comp.os.minix のような分野別グループが存在し、投稿すると世界中の購読者に配信された。現在の SNS におけるタイムラインに近い。

2-2. リーナスの開発思想

彼の発言や振る舞いから抽出できる原則は以下の通り。

原則	内容
Talk is cheap. Show me the code.	議論するな、動くコードを出せ
Release early, release often	早く出して何度も出す。完成させてから出すのではない
壮大な計画を立てない	「俺はビジョナリーじゃない。目の前の問題を潰してきただけだ」
Just for Fun	面白いからやる。義務では続かない

自伝のタイトルがそのまま『Just for Fun』である。そもそも仕事と趣味の境界が存在しない人間だった。

3. なぜ5ヶ月の産物が世界標準になったのか

3-1. 出来が良かったからではない

理由はタイミングと権利である。

3-2. 4つの要因

要因	内容
代替品がなかった	PC上で動く自由な UNIX が実質存在しなかった
GNU が待っていた	コンパイラもシェルも完成済み。足りないのはカーネルだけだった
GPL へ変更	当初は商用利用禁止の独自ライセンス。1992年に GPL 化したことで安心して投資できる対象になった
抱え込まなかった	パッチを送れば本当にマージされ、名前も残った。参加に手応えがある場所に人は集まる

5ヶ月の産物が優れていたのではない。みんなが持っている部品と噛み合う形をしていて、しかも誰でも改造してよかったから、集合体として育った。

4. ネットもGitもない時代の開発

4-1. 当時の通信環境

一般家庭にインターネットは無い。しかし大学と研究機関にはあった。参加者の実態は「世界中の大学のCS系にいた人間」であり、母数は小さいが全員が UNIX を知り、C が書け、ハードウェアも触れる。純度が異常に高い集団だった。

4-2. バージョン管理は人力だった

Git は存在しない。当時の運用フローは以下の通り。

1. 開発者が diff コマンドでパッチファイルを作成
2. メールでリーナスに送付
3. リーナスが目視で読み、手作業で patch コマンドを適用
4. 全部入れたら tar.gz に固めて ftp サーバーに配置

マージも競合解決も全て彼の頭の中にあった。つまり初期の Linux は「リーナスの処理能力」が開発速度の上限だった。

そしてこの方式は1991年から2002年まで、およそ11年間続いた。

Git 誕生の経緯
2002年に BitKeeper という商用バージョン管理システムを導入して手作業から解放されたが、2005年にライセンス問題でそれが使えなくなる。激怒したリーナスが約2週間で自作したのが Git である。今日世界中の開発者が使っているツールは、11年間手でパッチを当て続けた男の産物と言ってよい。

5. リーナスの人物像

5-1. 出自と現住所

項目	内容
出生	ヘルシンキ（フィンランド）
民族的背景	Finland-Swedes（スウェーデン語系少数派）。母語はスウェーデン語
1997年	Transmeta 社に就職しシリコンバレーへ移住
2004年頃	オレゴン州ポートランド近郊へ。理由は「シリコンバレーの喧騒が嫌」
2010年	アメリカ国籍取得
現在	オレゴン州在住。カーネル開発は完全リモート

余談：妻
妻のトーベはフィンランド人で、元・空手のフィンランド代表。国内チャンピオン6回。出会いは彼が大学で開いた授業で、彼女が受講生だった。家庭内で最強なのは本人ではない。

5-2. 趣味

趣味	補足
スキューバダイビング	既存のログ管理ソフトが気に入らず、自作の「Subsurface」を開発した
水泳	日課
ビール醸造	自宅でクラフトビールを仕込む。IPA 好き
ピアノ	本人いわく下手

気に入らないと自分で作る。これはもはや病気の域である。

5-3. 金銭面

ビル・ゲイツと比較されることがあるが、桁が3つほど違う。

人物	推定資産
リーナス・トーバルズ	数千万ドル規模
ビル・ゲイツ	1000億ドル超

理由は単純で、GPL にした時点で「独占して売る」道を自分で閉じたからである。

収入源は Linux Foundation からの給与、1999年に Red Hat と VA Linux から感謝の意味で贈られた株、そして著書の印税。本人は「金持ちになりたければ最初から違うことをやっていた」と繰り返し述べている。

代わりに手に入れたものは業界全体に対する事実上の拒否権である。ゲイツになりそこねたのではなく、ならない道を選んだ。

6. 上流と下流の構造

6-1. 全部がリーナスに来るわけではない

よくある誤解として「世界中のカーネル更新は最終的にリーナスにプルリクされるのか」というものがあるが、答えは半分正解、半分違うである。

対象	リーナスの承認
公式カーネルへの新機能・修正	必要（ただしメンテナ経由）
ディストリビューションの独自パッチ	不要
Android 等の独自カーネル	不要

彼が握っているのは「公式カーネルに何を入れるか」だけである。命令権はないが、源流を押さえている。

現在の体制
安定版（stable）の管理は右腕のグレッグ・クロー＝ハートマンが担当し、リーナスは新バージョンの統合に専念している。また彼は現在も GitHub の Pull Request を基本的に使わず、メールベースで運用している。

6-2. 作品数が異常に少ない

リーナスの代表作は Linux と Git のみ。しかも Git は Linux を管理するために仕方なく作った副産物であり、純粋な発明は実質1個である。

これは能力の問題ではない。彼の本業はコードを書くことではなく、他人が書いたコードを読んで入れるか蹴るかを判断することだからだ。年間数万件のパッチが流れ込むプロジェクトの最終審査官を30年やっていれば、他を作る暇はない。

7. 同じ道を歩んだ人々

「握れば巨富を得られたものを、普及のために手放した」枠には他にも人物がいる。

人物	作ったもの	手放し方
ティム・バーナーズ＝リー	WWW（HTML/HTTP/URL）	1993年、CERN が特許なしで全世界に無償開放。放棄額は兆単位とも言われる
リチャード・ストールマン	GNU、GPL	思想として自由を規定。トーバルズが使ったライセンスの生みの親
ブレンダン・アイク	JavaScript	10日間で作った言語が地球上の全ブラウザで動いている
ギド・ヴァンロッサム	Python	クリスマス休暇の暇つぶしから世界標準へ
まつもとゆきひろ	Ruby	個人開発から Rails で世界的に普及
磯崎元洋（やねうらお）	BM98 / やねうら王	後述

ストールマンとトーバルズの違い
ストールマンは原理主義者、トーバルズは実用主義者である。トーバルズは「俺は思想でやっていない、技術が面白いだけだ」と繰り返し距離を置いており、二人の関係は良好とは言い難い。

7-1. 磯崎元洋（やねうらお）という例

日本における同型の人物として挙げておく価値がある。

項目	内容
生年	1971年
プログラミング歴	5歳から
代表作1	BM98 BMS（音楽ゲーム、1998年6月公開）
代表作2	やねうら王（コンピュータ将棋、オープンソース）

BM98 の異常さは公開速度にある。

1997年12月  beatmania アーケード稼働開始
1998年06月  BM98 BMSフォーマット 公開       ← 半年
1998年08月  本人が開発・配布を中止し、きくちゃんが引き継ぐ ← 関与は実質2ヶ月

決定的だったのは本体と譜面データ（BMS）を完全分離したことである。BM98 単体では何も再生できず、プレイヤーは制作者のサイトを巡って譜面を集める必要があった。結果として「曲を作る側」に世界が開放され、20年以上続く BMS 文化が生まれた。

やねうら王も同型である。オープンソース化した結果、2019年の世界コンピュータ将棋選手権では決勝に残ったソフトが全てやねうら王のライブラリを使用していた。

余談：本人の棋力
磯崎氏の将棋倶楽部24 でのレーティングは1800程度（二段）。Ponanza 開発者の山本一成氏（R2400）と比べ、将棋への愛着は薄いと本人が語っている。将棋が好きで作ったのではなく、問題として面白いから解いたタイプであり、この思考回路はトーバルズと共通する。

8. 本題：日本的品質管理と「先送り」は違う

8-1. まず前提を確認する

「中途半端なものを出すな」という感覚は正しい。検品して、合格したものだけを出荷し、不良があれば謝罪して直す。この姿勢そのものは否定されるべきものではない。

問題は適用範囲である。

8-2. 領域を分ける

領域	方針	理由
物理製品・人命・金銭	完璧に検品する	出荷後の回収が不可能または高コスト。失敗すると人が死ぬか会社が潰れる
ソフトウェア・創作・アイデア	出して直す	回収コストがほぼゼロ。かつ、出す前には不良を検出できない

後者について、決定的な違いが2点ある。

違い	観点	物理製品	ソフトウェア・創作
違い1	回収コスト	市場に散らばると回収不能	修正版を上書きすれば全ユーザーが直る
違い2	不良の検出可否	ブレーキの不良などは測定できる	「使いにくい」「刺さらない」は他人に触らせるまで絶対に判明しない

8-2-1. ただしバグは別枠である

ここを混同してはならない。ソフトウェアの不良は2種類に分かれる。

種類	例	出す前に検出できるか	対応
技術的欠陥	落ちる、データが壊れる、脆弱性、計算が誤っている	できる	出す前に潰す。日本的な検品が正しく機能する領域
価値の欠陥	使いにくい、要らない機能、そもそも刺さらない	できない	出さなければ判明しない。出して聞くしかない

「未完成で出せ」とは機能の欠落を許すという意味であり、壊れていることを許すという意味ではない。

実際トーバルズのカーネル運用は極めて厳格である。

・rc版を数週間回してから正式リリース
・回帰（regression）は無条件で拒否。動いていたものを壊すパッチは通さない
・"Don't break userspace"（ユーザー空間を壊すな）を最優先ポリシーとする

0.01 は機能がスカスカだったが、その狭い範囲では動いた。Release early とは「小さく完成させて出す」ことであり、「大きく未完成のまま出す」ことではない。

判断基準は以下の一問で足りる。

足りないのは「機能」か？        → 出せ。それは次の課題である
足りないのは「動作の確実さ」か？ → 直せ。それは検品が未了である

つまり一人で行う検品は、検出不能な不良を、検出不能な方法で無限に探している状態である。だから終わらない。

8-3. 検品には期限が要る

ここが核心である。

「合格するまで出さない」は検品ではない。判断の先送りである。

本物の品質管理には必ず基準と締切が存在する。基準を満たしたら出荷する。それが検品だ。無期限に見直し続けるのは工程ではなく停滞である。日本の職人は完璧主義に見えて、実際には納期を守る。

8-4. 「まだ足りない」の正体

厳しい指摘になるが、書いておく。

「まだ足りない」「見せられたものじゃない」という感覚は、多くの場合自己防衛である。

出さない  → 批判されない → 可能性のまま保存できる
出す      → 批判されうる → しかしフィードバックで伸びる

さらに現実的な話として、自己評価はあまり当てにならない。自分で「中途半端」と思っているものが他人からはそこまで酷くなく、逆に「完璧だ」と思って出したものが酷評されることもある。だから出して聞くしかない。

なお「返品されたらすぐ直す」という姿勢があるなら、それは出せる側の人間である。出してはいけないのは、批判されたら折れる、逃げる、直さない人間だ。直せるのであれば怖がる理由はない。

8-5. 最後に

「趣味で作った。大したものではない。
 どんな機能が欲しいか教えてほしい。」

世界を変えたソフトの第一声がこれである。同じ文言を添えて出せばよい。

まとめ

論点	結論
Linux の単独開発期間	約5ヶ月（1991年4月〜9月）。第三者のコードが入るのは同年10月
初版の完成度	単体で起動もできない、Minix依存の断片的なもの
第一声	「趣味の産物で大したものではない」という予防線つきの投稿
普及した理由	出来の良さではなく、タイミング・GNUとの補完関係・GPL・開放姿勢
転換点	1999年（IBM参入と Red Hat 上場）。2008年の Android で全人類の手に
開発思想	Talk is cheap／Release early, release often／壮大な計画を立てない／Just for Fun
当時の開発環境	Git なし。diff をメール送付し、リーナスが手作業で patch を適用。これが11年続いた
Git 誕生	その11年間の反動として2週間で自作された
代表作	実質 Linux ただ1つ。Git はその副産物。一箇所に全賭けした結果
現在の役割	約100名のサブシステムメンテナからのプルリクを審査する最終審査官
ディストリとの関係	Ubuntu も Android も彼の承認は不要。命令権はないが源流を押さえている
金銭	ゲイツになりそこねたのではなく、GPL を選んだ時点で自分でその道を閉じた
日本的品質管理	正しい。ただし物理製品・人命・金銭の領域において
ソフト・創作の領域	回収コストがゼロで、不良は出さないと検出できない。ゆえに出して直すのが正解
検品と先送りの違い	検品には基準と期限がある。「合格するまで出さない」は判断の先送り
「まだ足りない」の正体	多くの場合は自己防衛。批判を避け、可能性のまま保存しようとしている
出してよい人間の条件	返品されたら直せること。直せるなら怖がる理由はない