標準的な手法は、単に「多くの人が使っているから」標準なのではありません。

経験豊富なエンジニアを採用しても、独自ルールばかりのプロジェクトでは...

せっかく優秀な人が入ってきても、独自ルールの学習に時間を取られるのはもったいないことです。
その人が持っている知識や経験を、すぐにプロジェクトに活かせる環境を作る方が、チーム全体の生産性は上がります。

ただ、一つだけお願いがあります。

「標準でできないか」を一度は検討してほしいのです。

「うちは特殊だから」と思っていたことが、実は標準の範囲内で対応できることも多い。
だって標準は、世界中のありとあらゆるケースを経験してきた人たちが作ってきたものだから。
「こういう例外ケースがあるんだけど」→「それ、こうすれば対応できるよ」というのが大体用意されています。

それでも本当にダメなら、仕方ない。でも「なぜ標準から外れるのか」は明文化しておいてください。
そうしないと、数年後に「なんでこうなってるんだっけ？」になります。必ず。

初めてこのリポジトリを見た人でも、Git FlowやSemVerを知っていれば「あ、これね」で終わり。
説明する側も楽だし、覚える側も楽。みんな楽。

「ブランチ名どうしよう」「コミットメッセージの書き方どうしよう」みたいな、どうでもいいけど決めないといけないことって山ほどあります。

これを毎回議論してたら、いつまでたってもコード書けない。
「Git Flowでいこう」「SemVerでいこう」で終わりにすれば、その分の時間と頭のリソースを、本当に考えるべきことに使えます。

標準に乗るっていうのは、「決めなくていいことを決めなくて済む」ようにすること。
それって、自由になることなんですよね。

独自ルールがはびこる組織には、ある傾向があります。

「社内ルールに詳しい人」が、技術的な意思決定権を持っているケースです。

口が達者で、自分を実際より優秀に見せるのがうまい。社内政治にも長けている。
でもその「詳しさ」は、社内のローカルルールに対するもので、世界標準の知識じゃない。
Git FlowもSemVerも知らないけど、「うちの会社のやり方」は完璧に把握している。

こういう人が意思決定すると、どうなるか。
「自分が詳しいやり方」を採用するんです。当然ですよね。
結果、独自ルールがさらに増え、標準を知っている人が力を発揮できなくなり、システムは遅くなり、コストは上がる。

若手の皆さんへ。
上司が本当に技術を理解しているのか、それとも社内ルールに詳しいだけなのか。
その見極めは、自分のキャリアを守るためにも大事です。

上司・マネージャーの皆さんへ。
部下の中に「標準を知っている人」がいたら、その人の意見をちゃんと聞いてください。
「うちのやり方と違う」で片付けず、なぜその標準が存在するのかを一緒に考えてほしい。

長々と書きましたが、言いたいことはシンプルです。

迷ったら、世界標準に乗っておけ。

世界中の人たちが何年もかけて「これがいい」と辿り着いた答えを、わざわざ独自に作り直す必要はありません。
その労力は、もっと価値のあることに使った方がいい。

そして何より、次に入ってくる人のことを考えてほしい。
その人が「これ常識？独自ルール？聞いていいの？」で悩まなくて済む環境を作ること。
それが、チームとして健全な状態だと思います。