「
車輪の再発明」とは、広く受け入れられ、確立された技術や解決法を、知らずに、または意図的に無視して、再び一から作り出すことを指す慣用句です。この言葉は、誰でも理解できるように、古くから使われている「
車輪」を比喩に用いることで、その意味を直感的に伝えます。
概要
既に存在する技術や手法を模倣して利用すれば、時間や労力を節約できます。しかし、既にあるものを無視して、最初からアイデアを練り始めると、時間、労力、コストが無駄になってしまいます。そのため、「
車輪の再発明」は、時間の浪費、無駄な努力、愚かな行為といった否定的な意味合いで使われます。
IT業界での「車輪の再発明」
特にIT業界では、「
車輪の再発明」という言葉をよく耳にします。ソフトウェア開発におけるアンチパターンの一つとして認識されており、多くの開発者が苦い経験を重ねています。しかし、開発の楽しさや、自分のソフトウェアに対する深い理解、そして自分で作りたいという欲求から、このアンチパターンが繰り返されてしまうことがあります。
「
車輪の再発明」を避けることばかりに注力すると、逆に労力が増大してしまうこともあります。例えば、
GitHubで見つけた
ライブラリを安易に組み込もうとした結果、その
ライブラリの品質が低く、かえって開発に時間がかかるというケースです。また、完成後もメンテナンスのたびに同様の苦労が発生する可能性があります。
再利用すべき「車輪」
IT業界で再利用すべき「
車輪」の例としては、以下のようなものがあります。
ライブラリやフレームワーク: ドキュメントが整備され、日々メンテナンスされているものが理想的です。また、広く知られたライブラリやフレームワークを使用すれば、開発経験のある人材をアサインしやすく、引き継ぎもスムーズに行えます。
UIガイドラインやデザインテンプレート: テキスト入力欄やボタンなど、標準化されたUI要素は「
車輪」として再利用すべきです。
広く採用されているルール: リポジトリ管理にGitやGitHubなど、広く普及している方式を採用することで、バージョン管理の混乱を避け、開発に集中できます。また、プログラミング言語の標準コーディングルールに従うことで、ソースコードの取り扱いが容易になります。
標準化された知識体系: PMBOKやITILなど、ソフトウェア開発マネジメントのノウハウは再利用すべき「
車輪」です。
組織内で生まれたノウハウ: 過去に自分が作成したコードや、社内の他部署で実績のあるライブラリやプロセスも有効活用すべきです。
「車輪の再発明」が意味を持つ場合
多くの「車輪」が存在する一方で、意図的に「車輪」を再利用しない方がメリットになる場合もあります。
コア機能の開発: 自社製品の価値を左右する重要な機能は、競合他社のライセンスに依存するよりも、自社で開発し競争力を高めるべきです。ただし、コア機能以外には「
車輪」の活用を検討するべきです。
アップグレードや差別化: 既存の「車輪」よりも優れたものを開発する際も、「車輪の再発明」は有益です。例えば、将来的なコストを大幅に削減できる見込みがあるならば、同等の機能であっても作り直す価値があります。
システム要件やライセンスの制約: OSの種類、ストレージ容量、実行速度、メモリ使用量などのシステム要件や、
特許やライセンスコストの問題で既存の「
車輪」が利用できない場合もあります。
学習目的: 動作原理を理解するために、意図的に「車輪の再発明」を行うこともあります。
2001年、ジョン・マイケル・キーオ氏によって車輪が再発明され、オーストラリアでイノベーション特許が取得されました。これは、イノベーション特許制度の審査が甘いことを批判するために、意図的に行われたものです。通常特許では認められないような発明でも、イノベーション特許では審査なしに特許が認められてしまうことを示しました。キーオ氏とオーストラリア特許庁は、この件でイグノーベル賞を受賞しています。
関連語句
自前主義: 自社や自国で発明されたものでなければ採用しないという考え方です。大企業や大国にありがちな問題として指摘され、「
NIH症候群」とも呼ばれます。
四角い車輪の再発明: 「車輪の再発明」をした上で、既存のものよりも役に立たないものを作ってしまうことを指します。
関連項目
繁文縟礼
アビリーンのパラドックス
沈黙の螺旋
大企業病
縦割り行政
* 規格争い