プログラミングの自転車：定義、原因、回避法

プログラミングの自転車とは

自転車 とは、ディベロッパーコミュニティの用語で、すでにライブラリ、フレームワーク、またはサービスとして利用可能な機能の独自実装を作り出すことを指します。英語圏では、reinventing the wheel（車輪の再発明）という表現が使われます。

この比喩の由来は、車輪 が人間最古の発明の一つであることに関係しています。21世紀になってこれを再び作り出すことは意味がありません。プログラミングでは、この類比はさらに正確です：既存のライブラリは、数千人のエンジニアが長年にわたって最適化してきた“車輪”です。これより低質な独自の車輪を作ることは、リソースの無駄づかいです。

RedMonk の分析レポート（2023）によると、平均的なコマーシャルアプリケーションは約500の外部依存を使用しています。これらをすべて独自に書き直すとすれば、プロジェクトコストは十倍になり、市場へのタイムラインは数年延長するでしょう。パッケージマネージャーのエコシステム（npm、Maven、PyPI、NuGet）は、車輪の再発明を防ぐために存在しています。

自転車のサイン

コード が自転車であるかは、いくつかのサインで識別できます：標準的な問題を非標準な方法で解き、テストやドキュメントがなく、既存ライブラリで長年対応されているエッジケースを処理していません。こうしたコードは、よく「独自の要件」を覚えて書かれますが、実際には標準的なものと何ら変わりありません。

自転車とカスタムソリューションの違い

カスタム ソリューションは、既存ライブラリがアーキテクチャやライセンスの制約で適合しない場合に正当化されます。自転車は、客観的な理由なしに作られます—「試しに作ってみたい」という欲望、他者のコードへの不信、または既存ツールについての無知からです。その違いは根本的です：カスタムは意識的な選択ですが、自転車は間違いです。

ディベロッパーが自転車を発明する理由

ひとつ目 の最も一般的な理由は、既存ソリューションについての無知です。ジュニアディベロッパーは、標準ライブラリにJSON解析用の組込み関数があることを知らないかもしれません。その代わりに、手動でパーサーを書いてしまいます。この問題は、言語エコシステムに参ったばかりの初心者に特に起こりやすいです。

ふたつ目 の理由は、制御の幻想です。経験を積んだディベロッパーは、人気ライブラリの著者より「じぶんかく書ける」と信じていることがあります。しかし統計は逆を示しています。数百万のプロジェクトで使用されているライブラリでのエラーの確率は、新しく書かれたコードよりも大幅に低いです。Synopsys（2024）によると、オープンソースコードには1,000行あたり平均0.1のエラーしかありませんが、企業コードには1–2のエラーがあります。

みつつめ の理由は、再利用の文化の不足です。仕事を始める前に既存のソリューションを調査する習慣がない会社では、各ディベロッパーが「自分の自転車」を作ります。これにより、同じプロジェクト内に、異なるディベロッパーが書いた3つの異なるHTTPクライアント実装が存在することがあります。

心理的な要因

IKEA効果 とは、自分で作ったものを客観的に優れた既製品よりも高く評価する心理現象です。プログラミングでは、「自分の自転車」への驕りと、明らかな利点があるにもかかわらず既存ライブラリに置き換えたがらない意欲として現れます。

プロジェクトで自転車を作る影響

経済的 な影響が最も明確です。Stripe（2022）の推計によると、ディベロッパーは労働時間の35%を、既に存在するソリューションのコードを作ることに費やしています。10人のチームでは、毎年約20万ドルが車輪の再発明に費やされていることになります。

技術的 な影響には、コードベースの拡大、テストカバレッジの低下、バグと脆弱性の増加が含まれます。さらに、独自コンポーネントはすべて、監視と保守が必要な障害ポイントとなります。

Google の研究「Why Google Stores Billions of Lines of Code」（2023）では、最大級のテック企業でさえ、新たな依存関係を追加したり独自実装を書いたりするには、厳密な決定プロセスが存在することが指摘されています。多くの内部チームは、まず単一コードリポジトリで既存ソリューションを探します。

チームへの影響

自転車 は情報の非同期性を生みます：ディベロッパーが離れると、独自コンポーネントにはドキュメントもサポートもありません。新しいチームメンバーは非標準なコードを理解する必要があり、生産性のある仕事に使えた時間を無駄にします。

よくある自転車の例

最も よくある例は、手動でのJSONやXMLの解析です。言語を問わず、ほとんどの現代言語にはこれらのための組込みツールがあります。ディベロッパーは、JSON.parse()が一行で問題を解決するにもかかわらず、オブジェクトツリーをトラバースする再帰関数を書いてしまいます。

ふたつ目 の例は、独自のHTTPクライアント実装です。標準ライブラリ（fetch、axios、OkHttp、URLSession）は、キャッシュ、再接続、タイムアウト、セキュリティをサポートしています。独自クライアントは、これらの要件のうち少なくとも一つを満たさないことが多く、本番環境でバグの原因となります。

みつつめ の例は、SLF4J、Winston、Log4jの代わりに独自のロギングシステムを作ることです。ディベロッパーは、既存ライブラリがローテーション、ログレベル、非同期書き込み、監視システム連携をサポートしているにもかかわらず、その実装に数週間を費やします。

# 自転車 — 手動CSV解析
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# 代わりに標準ライブラリを使用
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

アンチパターン：独自ORM

独自 ORM（Object-Relational Mapping）の構築は、抑えて最も高価な自転車でしょう。Hibernate、Entity Framework、SQLAlchemyなどの既存ORMは多年にわたって開発され、キャッシュ、レイジーロード、マイグレーション、多数のDBMSをサポートしています。独自ORMは通常、ひとつのデータベースに制限され、コネクション管理に重大なエラーを含みます。

自転車が正当化される場合

学習 は、自転車が正当化されるだけでなく有用でさえある情報です。教育目的で独自のパーサー、HTTPサーバ、ORMを書くことで、これらのツールが内部でどのように動作するか理解できます。ただし、学習プロジェクトと本番環境のコードを混同しないことが重要です。

独自 の要件が独自実装を必要とすることもあります。特定のプロトコル、データフォーマット、ハードウェアプラットフォームをサポートするライブラリがない場合は、カスタムソリューションが正当化されます。但し、その前に、タスクが真に独自のものか、単に調査不足でないか確認すべきです。

ライセンス の制約も另の正当な理由です。GPLやAGPLなどのオープンソースライセンスは、企業のビジネスモデルと互換性がない可能性があります。こうした場合、より許可的なライセンスのもとで独自実装を開発することが正当化されます。

3回の試行の法則

実践的 なルールとして、独自実装を書く前に、3つの異なる既存ソリューションを見つけてテストすることをおすすめします。どれも適合しない場合のみ、独自に作り、既存のオプションが拒否された理由をドキュメントに残します。これにより、無意識の自転車作りを防げます。

自転車を避ける方法

ひとつ目 のステップは、標準的なタスクを始める前に、既存ソリューションを探す習慣を身につけることです。パッケージマネージャ、GitHub、Stack Overflowで検索を使います。調査に費やした時間は、独自コードを書かないですみることで数倍になって返ってきます。

ふたつ目 のステップは、自転車を見つけることに焦点を当てたコードレビューの導入です。レビューでは、「なぜこのタスクに既存ライブラリを使わないのか」と質問します。客観的な理由がなければ、それは自転車です。GoogleやMetaでは、コードレビューで車輪の再発明をチェックすることが必須です。

みつつめ のステップは、内部ナレッジ登録を作ることです。プロジェクトで使用されているライブラリやツール、それらが解決するタスクをドキュメントに残します。新しいディベロッパーが無知から自転車を作らないよう、この情報にアクセスできるようにします。

• 調査 する パッケージマネージャを新しいタスクの前に
• 確認 する 言語の標準ライブラリ—標準的なタスクの80%をカバー
• 使う コードレビューで自転車を見つける
• ドキュメント する ライブラリ選択の決定理由
• 更新 する エコシステムの知識をカンファレンスやブログで

Not Invented Here シンドローム

NIHシンドローム は、外部ソリューションを使用することに対する組織的な偏見です。NIHシンドロームの企業は、オープンソースライブラリを自社の開発よりも優れていても拒否し、すべてを内部で開発しようとします。このシンドロームは、自転車の企業版です。

古典的な例は、1990年代末のNetscapeです。同社は、既存のコードベースを進化させる代わりに、ブラウザを一から書き直すことに数年を費やしました。結果は、市場シェアの失っておよびAOLによる売却でした。対照的に、Android はLinuxカーネルの上に構築され、数千のオープンソースコンポーネントを使用しており、製品を記録的な短時間で市場に抜ぐことができました。

Harvard Business Review（2023）の研究によると、NIHシンドロームの低い企業は、製品を市場に629０％速く抜き、開発コストを30%節約しています。コードの再利用文化は、現代のソフトウェア開発における競争上の利点です。

// 自転車 — カスタムソート実装
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// 組込みソート — 標準ソリューション
arr.sort((a, b) => a - b);