「車輪の再発明」大丈夫？

君が考えるようなオレオレライブラリなんて、いまどき絶対どこかで誰かが作ってる。
余計なもん作ってないで、既に用意されたものを使ってくれ。

規模の大きなプロジェクトほどその意見は正しく、その「用意されたもの」を皆が過不足なく使えるよう、上手に誘導することがリードプログラマの腕の見せ所でもあるでしょう。

若手には「車輪の再発明は無駄である」と言っておいた方が余計な事しないですし、コードも統一され生産性もあがると思います。

ただ、それは「プロジェクトをスピーディに遂行する」という面に偏った意見であり、車輪の再発明が役立つことはあります。
どういった場合にそれが役立つのか、考えてみたいと思います。
具体例は unity よりの話です。

車輪があるかどうかわからない

その車輪があるかどうか、知らない場合があります。
作ってもさほど時間かからないし、自作でチャチャっと、という事も多いです。

たしかに用意はされているが、ループの中で何度もコールされるようなものになると、速度負荷がかなり高い、そういうケースもあるでしょう。

その場合、他の車輪を探すだけでなく、自作で代替関数を作ることも考えられます。

LINQ など、よく使うのに思ったより遅かったり、昔の unity だと foreach 使うだけで GC スパイク起こしたり、思いもよらないところにパフォーマンスの罠が潜んでいたりするものです。

便利なものを使っていたのはいいが、そのライブラリは３年前から更新が止まってるんだ……とか、言語やOSのバージョンが上がったらなくなった、動かなくなった……など何かに依存する場合、長年運用するシステムほどリスクが顕在化します。

数年経って、１から作り直すのなんて無理だからセキュリティリスクがあるけどバージョンを上げ（られ）ない。そんな消極的な選択肢は御免ですよね。

他人のライブラリの場合、予想外の挙動を起こすことだってあります。
Python2 から 3 への進化に腹を立てた人は多いでしょう。
Google Ads を使っている人は API Level をあげる度に、なんかしら動かなくなったりしませんか？

こういった時、最初から自前で作ったものであれば……なんてこともあります。
（例は巨大すぎるので、とても自作はオススメできませんが）

公開されたライブラリも自前も、どっちにしろ「属人化」リスクはあります。
ニッチで、長期間運用するアプリケーションほど、どちらがよりリスクが高いか、一考の余地がありそうです。

組み込み系の仕事とか、いくら Web みたって情報ない事が多いですし、今日も車輪が再発明されてたりするんじゃないでしょうか。想像ですが。

Web 系業務は、ありもん使っちゃった方が断然楽！　が、多い

「人が使うライブラリを作る」というのは想像以上に面倒で、大変で、気を配ったものにする必要があります。
人に文句を言われ、再現性の低いバグに悩まされ、それでもライブラリをアップデートする過程で、プログラマーは間違いなく成長します。

なにかを作る時、既にあるクラス、メソッドの入力と出力をお手本にして、自分で構築してみる。
クリエイティビティには欠けるかもしれませんが、とてもいい勉強材料です。

最初から大きなものを作る必要はありません。ソート自作してもいいと思います。
（昨今は ChatGPT に尋ねるだけでメソッド用意してくれそうですが☺）

私は Dictionary もどきを C++ で自作したことがあります。
探せばもっといいものが確実にあったでしょう。でも、ちょっと興味が湧いちゃったもので。

初心者は Color.Lerp (unity) のような「ちょっと面倒だけど、作れそう」なものとか手がけてみるだけでも発見があると思います。コンポーネントを改造してみるとかもいいですね。

ただしこれはあくまで勉強、仕事で作るアプリケーションの場合、あまりオススメできません。
あくまでも自分の実力を磨くため、「どう作ればいいんだろう？」という好奇心や、自分の興味のあるところから作ってみましょう。

おおよそ中級プログラマーを超えてくるとこの車輪を作る作業はとても楽しかったりします。

ゲーム作ってたはずなのに、ひたすらデバッグやテスト工程を自動化するようなもの延々と作っちゃったりしませんか？　なくてもいい所までこだわって。

そういうものの中には Asset Store や GitHubにもっといいものが落ちてたりするわけです。

でも、楽しくプログラムが出来るのであれば、いいじゃないですか。

レゴの基本パーツを組み合わせて自分が作った塔は全然かっこ良くないかもしれません。ありものの完成されたキットを買ってしまえば、自作のものより全然素敵な見た目になるでしょう。
それでも自作のものには、その人にしかわからない達成感、高揚感、次も頑張るぞという気持ち、そういうものが含まれています。

プログラムを長く続ける人ほど、プログラムする楽しさは忘れないようにしたいものですね。

車輪を再発明すると効率悪くなることが多いです。
でも再発明は人（プログラマー）を成長させる、これもまた真理だと思います。

いつまで経っても若手が成長しない、言われた関数しか使えない、応用出来ない。
でも、その理由は若手に「応用が理解できるような、無駄足を踏ませてこなかった」せいかもしれません。
経営者が予算達成ばかり考えるあまり、成長ドリブンに一切お金を出さなくなっちゃう、そういうイメージに近いでしょうか。

もちろん、小さなシステム会社で、現社長（昔プログラマー）が作った使いづらいオレオレシステムを延々と使うのイヤー！　なんて事もあります。

再発明については中級者になったかな……？　くらいで、誰にも迷惑かけない範囲でやってみる限り、いいことだらけで、オススメです。

再発明は、無駄ではないが無駄である。

とても矛盾した結論になりましたが、ケースバイケース、少し先の事も見据え「本当に無駄か」、常々考え続けていきましょう。