結果として

あくまで個人の見解になりますが
先に結果を言いますと「否」になります。

何回も失敗しているから

実装方法や方針の資料が無い場合で、
他の実装を参考にする…という手順になるのですが、
かなりの確率で間違えてます。

特に変更するソースファイルが増えるほど後の巻き戻しが多いです。

余裕でスケジュール吹っ飛ばします。

問題点

①過去実装からまとめた実装方法を有識者に見てもらう
　→これは繰り返すスパンが短ければ短いほど良いと思います。
　PDCAを高速で回して実装方法を確立するべきです。

②ソースからしか読み取るものが無い
　→レビューの回数を増やすべきだと思います。
　　兎に角自己判断で決めつけないことが大事。
　　fixしてコミットするまでは「実装中」。

③他社との兼ね合いで思想が分からない、または、変更点が被りそう
　→立場によって変わりますが、なるべく影響のない実装方法を模索すること。
　　共通テーブルとか使ってたら、最新版で既存から一部削除されて別途追加されてるなんて事がありかねない。
　　というか実際にあった。

④共通化や使用方法が簡略化されるはず
　→確証の無い思い込みが1番危険
　　実際に、「一部の変更より簡単にする方向性・そういう思想となるんだろう。」と思って進めたところ、ドツボにハマった。
約1ヶ月3、4回目のリファクタリングが発生した
　　他者巻き込む程のリソースとメリットがあれば別ですが、自分の思想と仕事は切り分けることが最短かもしれない

⑤理解度不足
　→検証が大雑把の場合、PDCAのPlanが深く掘り下げられて無いことになる。
　　後々になって判明することでリファクタリングが発生

対策は？

いくつか述べてますが、
　・有識者に見てもらう
　・精度が大雑把なときから何回もレビューしてもらう
　・実装の思い込みがないか立ち止まる(独自理論で都合の良い解釈をしないこと)
　・疑問点はこまめに質問する
　・コードの制御は１行ずつ追ってよく理解すること

以上。
多分基本的な事だと思います。
個人的な見解になりますが、5年目でも未だに出来てなかったポンコツなので記載する。

※再投稿記事（前のは最初の記事に上書きしたため）