コラム: 車輪の再発明は本当に悪いのか
「車輪の再発明（Reinventing the Wheel）」は、既存のものを一から作り直す無駄な行為として批判されることが多いです。しかし、本当にいつも悪いのでしょうか？
「車輪の再発明」とは
┌─────────────────────────────────────────────┐
│ 典型的な批判 │
├─────────────────────────────────────────────┤
│ │
│ 「そんなの既存のライブラリ使えばいいのに」 │
│ 「フレームワークがやってくれるよ」 │
│ 「時間の無駄だ」 │
│ │
└─────────────────────────────────────────────┘
確かに、ビジネスの現場で締め切りに追われながら既存のものを再実装するのは非効率です。
しかし、すべての「再発明」が悪いわけではありません。
1. 成功した「再発明」の歴史
世界を変えたソフトウェアの多くは「再発明」から生まれています。
Linux
┌─────────────────────────────────────────────┐
│ Linuxの誕生 │
├─────────────────────────────────────────────┤
│ │
│ 1991年、Linus Torvaldsが開発 │
│ │
│ 当時の状況: │
│ ├── UNIXは既に存在していた │
│ ├── 商用UNIXは高価だった │
│ └── MINIXは教育用で制限があった │
│ │
│ 「再発明」の結果: │
│ └── 世界中のサーバーで動くOSに │
│ │
└─────────────────────────────────────────────┘
Git
┌─────── ──────────────────────────────────────┐
│ Gitの誕生 │
├─────────────────────────────────────────────┤
│ │
│ 2005年、Linus Torvaldsが開発 │
│ │
│ 当時の状況: │
│ ├── CVS、Subversionが既に存在 │
│ ├── BitKeeperを使っていたがライセンス問題 │
│ └── 既存ツールは分散開発に向いていなかった │
│ │
│ 「再発明」の結果: │
│ └── ソフトウェア開発のスタンダードに │
│ │
└─────────────────────────────────────────────┘
共通点
成功した再発明の特徴:
├── 既存のものに明確な不満があった
├── 新しい要件や状況があった
├── 作り手に深い理解と技 術力があった
└── 結果的に既存のものを超えた
2. 依存の怖さ
既存のライブラリやフレームワークに依存することには、見えにくいリスクがあります。
left-pad事件
┌─────────────────────────────────────────────┐
│ 2016年に起きた事件 │
├─────────────────────────────────────────────┤
│ │
│ left-pad: 文字列を左から埋めるだけの │
│ たった11行のライブラリ │
│ │
│ 何が起きたか: │
│ ├── 作者がnpmから削除 │
│ ├── これに依存していたライブラリが壊れる │
│ ├── そのライブラリに依存していた... │
│ └── 世界中のプロジェクトがビルド不能に │
│ │
│ 教訓: │
│ └── 小さな依存でも大きなリスクになりうる │
│ │
└─────────────────────────────────────────────┘
依存のリスク
┌─────────────────────────────────────────────┐
│ 外部依存が抱えるリスク │
├─────────────────────────────────────────────┤
│ │
│ メンテナンス停止 │
│ └── 作者が興味を失う、時間がなくなる │
│ │
│ セキュリティ脆弱性 │
│ └── 依存先で発見されると自分も影響を受ける │
│ │
│ ライセンス変更 │
│ └── 突然、商用利用が制限されることも │
│ │
│ 破壊的変更 │
│ └── バージョンアップで動かなくなる │
│ │
└─────────────────────────────────────────────┘
シンプルなものは自作する選択肢
検討すべきケース:
├── 数十行で書ける機能
├── コア機能で長期的に使う部分
├── 依存を増やしたくないプロジェクト
└── セキュリティが重要な箇所
3. 「自前主義」の罠
一方で、なんでも自作すればいいわけではありません。
NIH症候群（Not Invented Here）
┌─────────────────────────────────────────────┐
│ NIH症候群とは │
├─────────────────────────────────────────────┤
│ │
│ 「自分たちが作ったものでないと信用できない」│
│ 「外部のものは品質が低いはずだ」 │
│ 「うちには独自の要件がある（本当に？）」 │
│ │
│ 結果: │
│ ├── 車輪の再発明を繰り返す │
│ ├── 本来の開発に時間が使えない │
│ ├── バグだらけの劣化コピーができる │
│ └── 保守コストが膨れ上がる │
│ │
└─────────────────────────────────────────────┘
エゴと要件の見分け方
┌─────────────────────────────────────────────┐
│ 正当な理由か、エゴか │
├─────────────────────────────────────────────┤
│ │
│ エゴの兆候: │
│ ├── 「なんとなく気に入らない」 │
│ ├── 「自分ならもっとうまく作れる」 │
│ ├── 「外部のコードは信用できない」 │
│ └── 具体的な問題を説明できない │
│ │
│ 正当な理由: │
│ ├── 具体的な要件の不一致がある │
│ ├── パフォーマンス要件を満たせない │
│ ├── ライセンスが合わない │
│ └── 長期サポートが必要だが見込めない │
│ │
└─────────────────────────────────────────────┘
4. 学習としての再発明
学習目的の再発明は、最も価値のある再発明かもしれません。
「使う」と「作る」の理解の差
┌─────────────────────────────────────────────┐
│ 理解の深さの違い │
├─────────────────────────────────────────────┤
│ │
│ フレームワークを「使う」人: │
│ ├── APIの使い方を知っている │
│ ├── ドキュメント通りに動かせる │
│ └── 問題が起きると手が止まる │
│ │
│ 仕組みを「作った」ことがある人: │
│ ├── なぜそう設計されているか理解している │
│ ├── 制約やトレードオフを知っている │
│ └── 問題の原因を推測できる │
│ │
└─────────────────────────────────────────────┘
写経の価値
作ってみると分かること:
├── DIコンテナを自作 → 依存解決の仕組みが分かる
├── HTTPサーバーを自作 → プロトコルの理解が深まる
├── ORMを自作 → SQLとオブジェクトの変換を理解
├── テンプレートエンジンを自作 → パース処理を理解
└── 簡易フレームワークを自作 → 設計判断の理由が分かる
動くものを作って初めて分かる
┌─────────────────────────────────────────────┐
│ 本を読むだけでは得られないもの │
├─────────────────────────────────────────────┤
│ │
│ ・エッジケースの存在 │
│ ・設計判断の難しさ │
│ ・「簡単そう」が実は複雑だったこと │
│ ・既存実装への敬意 │
│ │
│ 作ってみて初めて │
│ 「なるほど、だからこう設計したのか」 │
│ と 腑に落ちる │
│ │
└─────────────────────────────────────────────┘
判断の基準
再発明すべきとき
✓ 学習が目的のとき
✓ 既存のものが要件に合わないとき
✓ 長期的に保守する必要があるとき
✓ パフォーマンスが重要なとき
✓ 依存を最小限にしたいとき
既存のものを使うべきとき
✓ 締め切りが厳しいとき
✓ 標準的な要件のとき
✓ チームの学習コストを下げたいとき
✓ コミュニティのサポートが必要なとき
✓ 自分で保守し続ける余裕がないとき
まとめ
┌─────────────────────────────────────────────┐
│ 車輪の再発明の評価 │
├─────────────────────────────────────────────┤
│ │
│ 悪い再発明: │
│ └── 理由なく、既存のものを作り直す │
│ （NIH症候群） │
│ │
│ 良い再発明: │
│ └── 明確な目的を持って、意図的に作る │
│ （学習、要件、依存削減） │
│ │
│ 世界を変えた再発明: │
│ └── 既存の限界を超える新しい価値を生む │
│ （Linux、Git） │
│ │
└─────────────────────────────────────────────┘
「車輪の再発明」という言葉で思考停止せず、なぜ作るのか、なぜ作らないのかを問う姿勢が大切です。