車輪の再発明か、車輪を使った教育か。

はじめに

「車輪の再発明」という単語を知らないプログラマはモグリです。

車輪の再発明（しゃりんのさいはつめい、英: reinventing the wheel）とは、「広く受け入れられ確立されている技術や解決法を（知らずに、または意図的に無視して）再び一から作ること」を指すための慣用句。誰でも直観的にその意味が分かるように、車輪という誰でも知っていて古くから広く使われている既存の技術を比喩の題材として使った慣用表現で、世界中で使われている。
（中略）
特にIT業界、なかでもSEやプログラマの間で好んで用いられている表現、概念である。

https://ja.wikipedia.org/wiki/車輪の再発明

同時に、それなりに経験値を持っているプログラマは

車輪の再発明が無駄な行為かどうか？（無駄である/いや、無駄ではない）

という議論も山ほど聞いてきています（※）。やれ、組み込み系の実行速度だの、これまでの社内パッケージの状況からだの、昔のモジュールはしょぼかったのがあって信用できないだの、GPL系だからソースコード公開できないだの…。これに関しては、どちらの結論も、つまり「車輪の再発明はすべきでない」も「車輪の再発明をしても良い」も「むしろ、車輪の再発明をすべき」も

議論する人たちの前提知識・理解が間違っていることも含め

世の中には山ほど記事が存在します。

そんな中で、どうしてこの記事を書いたか？　それは

未だにこの言葉を知らない「プログラマ」が日々生まれている

からに他なりません。

（※）なお、プログラマの間では、この類の「当人によって強く信じられている結論」が複数確認されているような題材を議論することを「宗教論争」と呼んだりします。

仕事で使うプログラムなら「レビュー」されないといけない

私は、どんな種類のプログラムを書く人であれ、一度くらいは既存のライブラリ、モジュール、パッケージ、…などに頼らず、一からコードを書いてみるということはやったことがあると思っています。

ライブラリーに頼らずAIを自作、手を動かすことで理解が進む

ここでは、最小二乗法を使った単回帰分析のためのスクリプトを紹介しています。本文中でも紹介されているように、本来はnumpyを使えば簡単に実行できるので、たとえばシステム本番環境で利用する時にはわざわざこういう実装はしません。してはいけないと思います。

しかし、自学自習で原理原則を学びたい時などには、このように「すでにモジュール化されているコードを自力で改めて一から実装する」ことで、基本的なアルゴリズムが理解でき、かえって理解が進むということも多いのは事実だと思います。車輪の再発明は、原理の理解に加えて、モジュールを使えば「正解」を出すことができるので、実装間違いを見つける＝「コードのデバッグスキル」を高めるのにも役立ちます。そのため、新人向けOJTなどでもよく行われています。

原理原則を学ぶのだとしても、仕事でシステムに組み込むのだとしても、肝心なのはコードレビューです。有識者がコードレビューを行えば、そこで車輪の再発明は気付けるのであり、逆に言えば

車輪の再発明に気づけないレビュアはレビュア足りえません。

レビューとは品質を確保するための行為であり、コードレビューで品質が低いものを見過ごせば、単体テスト/システムテストでの手戻りリスクが上がるだけです。

つまり、車輪の再発明が悪いとかそういうことではなく、コードの品質を取るために何を選択すべきかという話なのです。もちろん、

ここでいう品質には「実行速度」なども当然含まれる

ので、あえてモジュールにあるコードの一部を再実装するという可能性は否定していません。

「遊び」で書くコードなら、何でもいいじゃない

そして、肝心なのは、「コードを書くのが楽しい」、特に

「設計図もない状態でアルゴリズムを即興で書くのが楽しい」という層

は一定数存在するのです。こちらは完全に遊びです。即興、アドリブ、フリースタイル。「バグなくコードが動いた」という瞬間が最高に楽しい、という人たちがいう車輪の再発明は全く意味が異なります。

こういうコードはレビューの対象にはなりません。文字通りスクラッチ（書き殴った）コードだからです。なので、別に、車輪の再発明であっても何にも問題はないのです。

終わりに ~ この論争にケリをつけよう

最後に、この論争にケリをつける一言を書いて終わりにしたいと思います。