ソフトウェアエンジニアの福井(@eyasy1217)です。
人は何か新しいものを作るとき、すでにあるものを調べて、それに乗るより、土台ごと新しいものを作る傾向にあると思います。
例えば、
- 既存のawsリソースに乗らずに、新しくawsリソースを作る
- 社内で使われている既存の運用CLIを機能拡張せずに、新しくCLIを作る
- ツールのソースコードを、既存の乗れそうなGitリポジトリではなく、新しく作ったGitリポジトリで管理する
などです。
似たような概念で、Platform EngineeringのGolden Path*1があります。
ですがこれは車輪の再発明を避けるために標準を提供する話で、この記事は車輪の再発明の話はないので、少しコンテキストは違います。
で、この既存に乗らないことの何が問題か
結果的にコストが増えるケースが多いでしょう。
例えば、
- awsリソースの場合は、管理コストや、金銭コスト増
- CLIの場合は、AI PlatformのAPI呼び出しコードが重複するなどの管理コスト増
- Gitリポジトリの場合は、パッケージ管理が散らばることなどによる管理コスト増
です。
もちろん既存のものに乗らずに、新しく作った方が良いケースもあります。
既存CLIに関連性の薄い機能を乗せても、密結合になるだけです。
ですが自分の経験上、乗った方が良かったケースが多いように感じます。
では、なぜ既存に乗らない傾向にあるのか
いくつか理由はありそうです。
- 既存のものに乗るのはリネームなどの作業が必要で、面倒臭く、リスクがある
Gitリポジトリの場合は、新しいコードを乗せるため、既存のディレクトリ整理が必要かもしれません。 - 既存のものを発見し、どう乗せるかを考える負担がある
- 既存のものを信用していない
Not Invented Here Syndrome*2という、組織が自ら生み出したもの以外のものを避ける傾向を意味する言葉があり、これと関連性はありそうです。
ただ、やはりこれらを乗り越えて、既存のものに乗った方が良いケースが多いように感じます。
まとめ
コードを書くときも既存の乗れるクラスを探したりすると思いますが、それと同じ話かと思います。
自分がこれから作るものだけにフォーカスせずに、作るもの周辺を俯瞰して作り始められると良いでしょう。
