車輪を再発明せよ - Reinvent the Wheel
(endler.dev)- 「車輪を再発明するな」 という助言は、創造性と探究心を抑え込む否定的な影響を与える
- 新しい車輪、つまり 既存の道具や技術を再創造 する過程で、深い理解と学びを得られる
- 単純または見慣れているように見える 基礎的な構成要素 も、実際には複雑さと多様なトレードオフを含んでいる
- 自分自身の車輪を発明してみることで、成長、問題解決、実験 に関する能力が強化される
- 既存の成果物を活用することと再創造 することの間で、目的に応じてバランスよく選ぶ必要性が強調される
Reinvent the Wheel
- 「車輪を再発明するな」という言葉は意図自体は良いが、二つのタイプの人々から出てくる助言である
- 実際に車輪を作ってみて、その難しさを体験した人たち
- 試したこともなく、既存の助言を盲目的に従う人たち
- このような助言が繰り返されると、好奇心と探究精神が萎縮する雰囲気が生まれる
- もしこの助言を誰もが守っていたなら、現代の多くの利便性や進歩は実現できなかっただろうと強調している
- 実際、車輪は初期の発明以降も何度も再創造され、発展を重ねてきた
参考: ここでいう「車輪」は、どんな道具、プロトコル、サービス、技術、その他の創作物にも置き換えて考えられる
車輪を自分で発明してみること自体が学びである
「私が作れないものは、理解したとは言えない」
— リチャード・ファインマン
- 何かを 本当に深く理解 するには、小さなバージョンでも自分で実装してみる経験が必要である
- 成果物が完璧でなくても、たとえ活用しなくても、実装してみるその過程自体が重要である
- コンピュータサイエンスの多くの概念—プロトコル、暗号化、Webサーバーなど—は難しく感じられるかもしれないが、実際には誰でも挑戦できる
- より多くの人が自分で作ってみる経験を通じて、既存技術の構造と本質 を理解する機会を得られる
すべては終わりのない探究の過程である（Rabbit Hole）
- 私たちが当然のものとみなしている基本的な構成要素—たとえば文字列やファイルパスなど—も、実際には非常に複雑である
- 自分自身の文字列ライブラリやパスライブラリを実装してみる試みは、多くの学びのきっかけになる
- この過程を通じて、次のような事実に気づく
- 日常的なものの中にも 無限に近い複雑さ が存在する
- 他の人に役立つ何か を作ることは、謙虚さを学ぶ機会でもある
- すべての抽象化は人間が作ったものであり、完璧ではなく、自分なりの別のトレードオフもあり得る
- 実装の途中で、正確性、単純性、性能、拡張性、移植性 など、数多くの選択肢と問題に直面する
- 自分が作った解決策は一部の領域では優れているかもしれないが、あらゆるユーザーや状況に合うわけではない
- 既存のソリューションにも限界があり、自分の問題には適していないかもしれない
- 一つの問題を最後まで掘り下げる経験は、エンジニアとして成長する過程である
- もしプロジェクトを頻繁にあれこれ移るだけなら、意味のある学習は得られない
車輪を再発明すべき理由
- 既存のものより優れた車輪を作ろうとする（「より優れている」の定義はさまざま）
- 車輪がどのように作られるのかを学ぶことが目的である
- 他の人に車輪の原理を教える教育的な目的
- 車輪の発明過程を探究することで、新たな気づきを得る
- 壊れたときに自分で 修理または改善 できる能力を養う
- 車輪を作るのに必要なさまざまな道具や技術を習得できる
- 複合システム（たとえば自動車など）の一部としての車輪の役割を理解する
- 特定のニーズに合った非常に特別な車輪を作るための試み（例: 車いす、スケートボード、陶芸用ろくろ など）
- 自分が作った車輪が、本来の目的とは異なるまったく別の用途で、よりうまく使われることもある
- 世の中では 型にはまらない新しい発想 が重要な役割を果たし得る
Reuse vs Reinvent
- 他人の成果物を軽視してはならず、その仕事を研究し適切に活用する必要がある
- 単なる 不信や無知 によって既存のものを捨てて新しく作らないよう注意すべきである
- しかし、自分で実装したり実験してみたりしなければ、その分野の 中核的な理解と発展 は難しい
- ソフトウェアエンジニアリングでは、小さな実験やプロトタイプの作成が簡単かつ迅速なので、個人的な問題解決に効果的である
- 小さく始めて、シンプルに実装し、反復する過程 が推奨される
- そこで最後に私からの助言は次のとおり
- 洞察(insight) を求めるなら、自分で再発明に挑戦する
- インパクト(impact) を求めるなら、すでに検証されたソリューションを再利用する
"Reinvent for insight. Reuse for impact."
「洞察のために再発明し、インパクトのために再利用せよ」
8件のコメント
四角い車輪を丸くしようとしたら、「車輪を再発明するな」という社長の言葉を思い出しました。車輪再発明亡霊は今でも周りにたくさんいますね。
「牛を失ってから牛小屋を直す」ということわざが、未来への備えをするなという意味ではないのと同じように、
「車輪を再発明するな」も、洞察を得るために時間を投資するなという意味ではないと思います。
こうした言葉がどのような状況で出てきたのか、その前後を切り取ってしまうと本来の意味は歪められます。
つい最近の体験ですが、私は最近、自分だけのとても特別な車輪をひとつ作りました。
Nuxtで1000ページ規模のアプリをビルドするのに7分かかっていたのですが、
いくつかの自動化をあきらめて作り直した結果、20秒ビルドに成功したんです。
どこまで再発明し、どこまで外部依存に頼るのかを判断するのは難しいです。
どんな場合でも、自分でこれを作れるのに時間を節約するためにその依存関係を選ぶことと、その依存関係がなければサービスを作れず依存関係に縛られることは、まったく別の話です。
すべてのコードで可能というわけではありませんが（OSのようなものなど）、できるだけ電子側まで踏み込んで努力することが、システムを理解する助けになるはずです.
ことわざには込められた意味があるのに、言葉どおりにしか解釈しない人が増えている
ああいう主張が流行ると、また平然と会議室がめちゃくちゃになる
ペーパーワーク屋が勢いづいて暴れ回り、同じ失敗を毎年また繰り返す
Hacker Newsのコメント
私はある分野で、自分自身で車輪を再発明した経験がある。最初からそうするつもりだったわけではなく、既存技術が間違っていると思ったからだ。普通は不可能だと言われる問題を、分割統治のやり方でアプローチした。運が良く、そして頑固だったので、結局は成功した。私の車輪はその分野で圧倒的に優れた性能を示した。試してみると、以前は不可能だと思われていたことも、とても簡単にできるようになった。時が経つにつれ、その分野の他の人たちも私の車輪を使い始めた。最初はみんな戸惑うが、一度慣れると二度と前には戻らない。世界中から奇妙なユースケースやワークフローについてのバグ報告や機能要望が届く。直接会うことなどないはずの賢い人たちと、深い技術的な会話を交わす。私が作った車輪で、他の人たちが想像もしなかった成果を成し遂げるのを目にする。夜も眠れなくなるような新しい発見をすることになる。仲間たちが私の車輪の機能説明を受けて、頭がフリーズするのを見るのも面白い。車輪を再発明することを恐れる必要はない。どんな狂った道を転がっていくか、誰にも分からない
既存の車輪をより良くするということ以外に、本当に重要な理由が一つ抜けていると思う。つまり、自分にぴったり合った車輪を作れて、その状態のまま使い続けられるという点だ。人はよく「同じ車輪を再発明するな」と言いながら、自動車の車輪を自転車に無理やりはめ込もうとする。自分のシステムのすべての部分がうまく噛み合うように自作すれば、思った以上に大きな利得を得られることがある
車輪を再発明する重要な理由の一つは、役に立たない依存関係のせいで複雑さが不必要に増えるのを避けるためだ
この意見には完全に同意する。有名なライブラリはさまざまな状況で問題を解決してくれるが、そのせいで不要なコードが大量に含まれていることも多い。大事なのは、短時間で必要な機能を作れるなら、自分で作ったほうが使い勝手もよく、依存関係も最小限にできるということだ。ただし、暗号ライブラリだけは絶対に自作を勧めない
これが私が車輪を再発明する最大の理由だ。依存関係には、望んでいないいろいろな機能が一緒についてくる。私は単に近所のスーパーに行ける程度の機能しか必要ない。そして個人的には、透明でないコードは信用しない。依存関係を使うとしても、自分が一日かければ作れる程度で、レビューもできるものであるべきだ。ソースコードが見られない実行ファイルは、お金を払って買うのでない限り使わない。無料なら必ずソースコードが公開されているべきだ
私はDAG（有向非巡回グラフ）ベースのタスクランナーライブラリを自作した。タスクはキューに属せるようにした。デモをWebブラウザで動かしたかったのでIndexedDBバックエンドを、ElectronアプリではSQLiteを、マルチユーザーのサーバー環境にはPostgresバックエンドをそれぞれ実装した。そしてレート制限用の limiter も追加した。このほかにも、グラフ処理やタスク処理など、いろいろな車輪を自分で作る必要があった。完全に依存関係なしで作ろうとすると、本当にやることが多い。ただ、TypeBoxでタスク入出力スキーマを作って検証するブランチを別に持っている。結局、核心部分にまた別の依存関係が追加されることになるかもしれない
もう一つの理由は、新しいものを発明したり研究したりする能力を、練習によって鍛えられるからだ。すでに解かれた問題でも、十分に練習になる
ときには、不要な抽象化やモジュール化のような複雑さを避けるために車輪を再発明する
一緒に考える価値のある良いエッセイだった。私も似たような経験があり、PythonとNumPyだけを使って、PyTorchスタイルの機械学習ライブラリ（ml-by-hand）をゼロから作った。小さな autograd エンジンから始めて、レイヤー、オプティマイザ、データローダーなどを段階的に自分で実装した。純粋に基本原理を学びたくて始めた。自作ライブラリを使って、古典的な畳み込みニューラルネットワーク（cnn example）から、シンプルなGPT-2（gpt2 example）まで再現してみた。PyTorchやTensorFlowの抽象化なしで、機械学習が内部でどう動いているのかをずっと深く理解できるようになった。再発明した車輪で、さらに自分の手で車まで作ってみたようなものだ
「車輪を再発明するな」と言う人は主に二種類だ、という話に付け加えるなら、実際には三つ目の、しかもずっと一般的なタイプがいると思う。つまり、車輪の再発明の苦労を実際に知っていて、その過程を経験しても、あえて自分でやる価値はまったくないと判断する人だ。教育的であろうとなかろうと、自分でやってみる価値がないと考える
車輪を再発明するのは最高の学習方法だ。ただし、それは学習という文脈に限ると思う。私も何かを深く掘り下げるのは好きだが、会社では締め切りやその他の制約を守らなければならず、思う存分に探究できないことが多い。もし作った車輪を実際にサービスで使うなら、既存のものより本当に優れていなければ使えないと思う
職場で車輪を再発明する人の99%は、既存の車輪がどう作られているのか、なぜそうしたトレードオフの構造になっているのかすら、まともに理解していないことがほとんどだ
自作が必ずしも最高の学習法というわけではない。時間もコストもかかるからだ。よく整理されたドキュメントと実験環境があれば、十分に学べる。知識伝達の明確さそれ自体が別の課題だ。わざわざ全体をゼロから作り直す必要はない
政府システムをグローバルに再実装する実験をしている。実際の政府とは別物だ。たとえば ua.gov-ai.co、ua.ai-gov.co、ng.gov-ai.co、ng.ai-gov.co などがある。今のところCBERとDDPの進捗が最も進んでいる。現在422機関まで進めた。Juneteenth までに終えたい。こういうふうに基礎を作り直すことで、根本原理の理解に役立っている。実際に何か成果物が出るわけではないと分かってはいるが、本質が変わるたびに自分の考えを組み立て直すうえで有益だ。車輪を再発明してみる実験は、いつだって意味があると思う
スタートアップで働くなら、こういう助言はなるべく無視すべきだと思う。（ただし、再発明する車輪が自分のサービスの中核的な性能に関わるなら例外だ。）そうでなければ、限られた資源を浪費するだけで、事業が始まる前に終わってしまう可能性が高い
それでも、スタートアップには車輪を自分で作った経験がある人、つまり本当に車輪を作れる人と一緒にいることが重要だと思う。オープンソースや個人プロジェクトでもいいので、その経験があるべきだ
こうした助言は、職業上の話ではなく、個人的な学習目的での車輪実験に向けたものなのだと思う
友人が言っていた名言を思い出した。「車輪を再発明する理由は、もっと多くの車輪が必要だからではなく、もっと多くの発明家が必要だからだ。」新しい概念を学ぶために自分で作ってみる過程で、頭も心も落ち着きを得られた経験が何度もある。ファインマンの「自分で作れないものは、理解したとは言えない」という名言に触れてから、こうした経験と信念はさらに強くなった。車輪を再発明するたびに、最初の概念に対する直感がより強くなり、まったく知らなかったことも新しく学べる
重複を過度に嫌う風潮こそが、現代の問題だと思う。みんな同じになり、同じものを食べ、似たような仕事をし、似たような必要に従って動く。「車輪を再発明するな」のようなメッセージを極端に押し進めると、結局は一部の裕福な人たちの特殊な要求に応えることしかできない、何も知らない人間になるのが最終到達点かもしれない。もはや料理も、農業も、愛することすら学ばない人生だ
会社は学びに来る場所なのか？ それとも、他人が作った車輪を使って価値を再創造する場所なのか？
作ることは始まりにすぎず、10年ほどサービスを運営していると途中でさまざまなことが起きるはずで、そこで踏ん張るには基礎が必要なのでしょう……学ばなければなりません。