「車輪の再発明」とは？ITエンジニアに便利な「車輪」と「再発明」すべきシーン

「車輪の再発明」は、英語の「reinventing the wheel」に対応する言葉です。直訳すると「車輪を作り直す」という意味になり、再利用できる既製品があるにも関わらず、わざわざ自前のものを作ろうとする行動を戒めるときに使われます。とはいえ、すべての「再発明」が必ずしも悪いこととは限りません。

そこで今回は、ITエンジニアにとっての「車輪の再発明」の意味について詳しく説明していきます。エンジニアリングでは既存の「車輪」を積極的に利用すべきときと、意図的に「再発明」を選択すべきときがあることがわかるでしょう。

「車輪の再発明」とは

まずは、「車輪の再発明」という言葉の基本的な意味と、「再発明」を避けるべき理由について説明します。

「車輪の再発明」の意味と使われ方

「車輪の再発明」はIT業界で耳にする機会の多いフレーズですが、実は海外でも広く通じる「ことわざ」のようなものです。誰もが知っていて単純明快な機能をもつ「車輪」を引き合いに出すことで、「わざわざ自分で作る必要のないもの」を比喩的に表現しています。無駄な作業に時間や労力を費やしている様子を、皮肉を込めて表現したいときに使われる言葉です。

類義語としては、「自前主義」や「NIH症候群」が挙げられるでしょう。「NIH」は「Not Invented Here」の略で、「ここで発明されたのではない」という意味です。自前で作ったものでなければ認めないという、「車輪の再発明」と同じような姿勢を表しています。

「車輪の再発明」には魅力がある

ITエンジニアのなかには、「デザインパターン」や「アンチパターン」という用語を聞いたことがある人も多いのではないでしょうか。デザインパターンとは、ソフトウェア開発における優れた設計手法を整理したものです。これに対して、誰もが陥りやすく、失敗につながりやすい手法はアンチパターンと呼ばれるようになりました。

業界内で広く知られる「スパゲティコード」や「デスマーチ」は、アンチパターンの代表格でしょう。そして、「車輪の再発明」もアンチパターンの一つに数えられています。これまで多くの人が、同様に苦い体験を繰り返してきたということです。

では、なぜ「車輪の再発明」は繰り返されてしまうのでしょうか。ITエンジニアにとっては、「開発は楽しいものだから」というのが大きな理由かもしれません。また、「自分のソフトウェアのことは自分が一番に理解している」という想いも自然と強くなるものです。自分で作りたいという欲求は、意識しなければ避けがたいものだといえるでしょう。

「車輪の再発明」を避けているつもりでも

「車輪の再発明」を避けようと意識するあまり、かえって苦労する結果になることもあります。

例えば、GitHubで見つけたライブラリを自分のソフトウェアに組み込むケースについて考えてみましょう。もし、ライブラリがテストもされていない粗悪品だったとしたら、何が起こるでしょうか。ソフトウェアの完成までに、想定した以上の時間がかかるかもしれません。なんとか完成までこぎつけたあとも、メンテナンスのたびに同じような苦労があると考えられます。

このように、いくら「再発明」を避けて既製品を利用したとしても、うまくいかない場合はあるのです。では、「車輪の再発明」の本質はどこにあるでしょうか。ITエンジニアにとっては、「開発に割ける限られた時間を、より生産的なものにしよう」と考えられるかどうかが一つのポイントになるでしょう。生産的な時間が今よりも増えるかどうかを基準とすれば、既存の「車輪」を利用するか、それとも「再発明」するかを選べるようになります。

ITエンジニアが活用したい「車輪」の例

ソフトウェア開発に再利用できる「車輪」の数は、とても数えきれません。ここでは、積極的に活用することで生産性を高めやすい「車輪」の例を、種類別に紹介していきます。

ライブラリやフレームワーク

ソフトウェア開発で必要とされる機能の多くは、すでに利用できる状態になっています。例えば、Web開発者向けのフレームワークだけでも、以下のような候補が挙げられるでしょう。

・CakePHP

・Django

・Laravel

・Ruby on Rails

これらのライブラリやフレームワークは、使用することで車輪の再発明を回避するだけでなく、ドキュメントが整備されている、日々メンテナンスされバグが出にくい、引継ぎの際に経験をもった人をアサインしやすいなどのメリットもあります。

もちろん、これらの使い方を習得するのにも、ある程度の時間は必要です。しかし、同じものを自前で作るよりも、はるかに少ない労力で済む場合が多いでしょう。そのようなライブラリやフレームワークを積極的に活用すれば、より力を注ぐべき開発に集中できるようになります。

そのためにも、GitHubや公式サイトで公開されている情報をチェックして、できる限り信頼できるものを選ぶようにしましょう。

UIのガイドラインやデザインテンプレート

ソフトウェアのUIを高品質なものにするには、動作環境ごとの基準にしたがうのが堅実でしょう。UIは通常、テキスト入力欄や各種ボタンなどの「車輪」から構成されるためです。

例えばiOSやAndroidには、レイアウトや動作に関するガイドラインが定められています。ガイドラインにしたがって開発を進めれば、違和感のないUIを実現しやすくなるでしょう。

また、ユーザーが理解しやすく使いやすいUIにするには、画面構成や画面遷移の仕様をあらかじめ考えておくことも大切です。そのための「車輪」として、さまざまなデザインテンプレートやワイヤーフレームが使えます。UIについてゼロベースで検討する必要がなくなるため、モバイルアプリのほか、Webサイトやパソコン用アプリの開発にも便利です。

広く採用されているルール

ソフトウェア開発の現場には、広く採用されているルールがあります。わずらわしく感じることもあるかもしれませんが、これらは価値があるからこそ取り入れられている「車輪」です。

例えば、git-flowやGitHub Flowに則ってリポジトリを運用している開発チームは多いでしょう。これにはバージョン管理に関する不要な混乱を避け、開発作業に注力しやすくなるなどの効果があります。

使用するプログラミング言語に標準のコーディングルールがあれば、そのまま開発チームのルールとして取り入れるのもおすすめです。例えばC#には、Microsoftが定めたコーディングルールがあります。各種ライブラリやフレームワークの開発者も同じルールにしたがっている可能性が高いことなどから、ソースコードを扱いやすくなるでしょう。

標準化された知識体系

ソフトウェア開発のマネジメントについても、再利用可能なノウハウが多数あります。以下は、その一例です。

・PMBOK：プロジェクトマネジメントのノウハウを体系化したもの

・ITIL：ITサービスのマネジメントにおけるベストプラクティスを体系化したもの

いずれも、チームとして目標を達成するためのプロセスなどが体系的に整理されています。必要な部分だけを抜き出して用いることもできるので、チェックリストのような使い方をしてもよいでしょう。

PMBOKとITILについては、関連するページもあるので参考にしてください。

・PMBOKとは？プロジェクト管理における基礎や活用方法！

・変更管理とは？ITILの標準プロセスを参考に目的やフローを解説

組織内で生まれたノウハウ

利用可能な「車輪」は、意外に身近なところで生まれることもあります。例えば、過去に自分で作ったソースコードのなかには、別の開発に応用できるものもあるでしょう。また、社内のほかの部署で実績のあるライブラリやプロセスなども、再利用しやすい「車輪」の一つです。

しかし現実には、組織内にあることが知られないまま埋没していくものも少なくありません。開発者が異動するたびに忘れ去られ、知らぬ間に「車輪の再発明」に陥っているかもしれないのです。こうした身近な「車輪」の存在に気付くためには、日頃からノウハウを共有し、属人的な知識をなくしていこうとする組織的な努力が求められるでしょう。

意図的な「車輪の再発明」にメリットがあるシーン

ソフトウェア開発にはライブラリやフレームワークだけでなく、ルールやノウハウも含めてさまざまな「車輪」が存在することを説明してきました。一方、これらを再利用しないほうがメリットを得られる場面もあります。ここからは、意図的に「車輪の再発明」を選択すべきシーンについてみていきましょう。

コア機能を開発するとき

ソフトウェア製品には、その価値を決める「コア」があります。コアにあたる機能は、通常は「車輪」を再利用しないほうがメリットが大きい部分です。

極端な例ですが、自社製品の価値を左右するようなメインの機能を競合他社から買ってきたライセンスで実現できるとしたら、そうするでしょうか。この戦略にどれほどの意味があるかは、慎重に検討しなければならないでしょう。開発チームの多くは、競合と同等以上の機能を自力で開発する道を選ぶと考えられます。

このとき重要となるのは、いかにしてコア機能の開発に注力するかです。そのためには、コア以外の部分で積極的に「車輪」を活用し、生産性を高めるのが効果的だといえます。

アップグレードや差別化に狙いがあるとき

既存の「車輪」が、欲しいものと少しだけ違うということもあるでしょう。この場合は、似たようなものでも作り直す必要があるかもしれません。

ここで少し、本物の車輪の歴史を振り返ってみましょう。最初に発明された車輪は、木製の円盤でした。もし「再発明」を完全に否定していたら、より頑丈で軽量な金属製の車輪や、空気タイヤなどは誕生しなかったかもしれないのです。

ソフトウェアもこれと同様で、より優れたものにするためにアップグレードすべきときがあります。また、既存のものより優れたソフトウェアかどうかは、必ずしも機能性だけでは決まりません。例えば、今後のコストを大幅に削減できる見込みがあるのなら、機能が同等でも作り直す価値はあるといえるでしょう。

システム要件やライセンスなどの制約が厳しいとき

まさに利用したい「車輪」があるにもかかわらず、何らかの理由で採用できないこともあります。例えば、以下のような場合です。

・OSの種類やストレージ容量などの要件をクリアできない

・実行速度やメモリ使用量などのパフォーマンスが期待どおりではない

・特許やライセンスのコストが許容できない

・間接的に必要となるライブラリが多く管理しきれない

これらは、時間と労力をかけてでも「再発明」せざるを得ないケースです。同様のニーズが多くありそうなら、自作の「車輪」をオープンソースとして公開することを目指してみるのもよいでしょう。

発明の苦労を体験したいとき

既存の「車輪」の真似をしてみるのは、プログラミングや設計の勉強として実践的な方法の一つです。同じ機能を自分でも作ってみることで、1つの「車輪」が完成するまでのプロセスと苦労を体験できます。

動作原理を学ぶために、既存のライブラリやフレームワークを観察してみるのもよいでしょう。ものによっては随所で「デザインパターン」が使われていたり、ほかの「車輪」を再利用したりしている様子もわかります。

「車輪の再発明」を意識して生産的な時間を増やそう

ITエンジニアにとって「車輪の再発明」という言葉は、さまざまなものがソフトウェア開発に再利用できることを示しています。ライブラリやフレームワークはもちろん、開発にまつわるルールやノウハウも、無駄な作業に時間と労力を費やすことを避けるのに役立つものです。

一方、すでにあるものを作り直すことが、必ずしも悪い行動というわけではありません。大切なのは、既存の「車輪」を活用すべきか、あえて「再発明」すべきかを状況に応じて見極めることです。先人の成果を上手に活用して、生産的な時間を増やしていきましょう。