自分のプログラムコードが最良だと思い込んで、レビューを受けないプログラマがいて、プロジェクトの進捗に支障を来してます。どうすればいいでしょうか。

納期先に納期の延長が可能であれば，
「ルールに従った製造過程に基づくモジュールを遅れて出荷する」

不可能であれば，
「コードレビューが出来なかったモジュールを納期通りに出荷する」。
問題があれば，そのレビューを受けない者に何かしらの処分や賠償請求が妥当と考えます。

　プロジェクトとしての文書体系と役割分担が確立していない様に思えます。

　質問の内容からはプログラムのレビューだと思っていました。
　レビューの目的が時系的に矛盾します。詳細設計の意図を伝えるのはプログラミングの前に行うものです。
　単体テストの成績が悪いから詳細設計を変更するということは、本末転倒であり、堂々巡りをしてしまう様に思えます。

　考えられる対策は、問題のプログラマに設計スキルの高いメンバーを組み合わせることです。

　とは言え、プロジェクト推進は、文書体系図でシステム構築の情報がキチンと成果に繋がり、役割分担表で負荷分散とチェック機能が働くことが前提です。大丈夫ですか？
　

詳細設計の変更を単体テストレビューで報告すること自体が間違っていますね。詳細設計の再レビューは当然であり、それが受け入れられないというのは、メンバーとして不適切です。
断固、メンバーから外しましょう。

老婆心：その人は根っからのプログラマで設計書を書くことが出来ないのではないでしょうか。純粋にプログラマとして活かすことができるのであれば、除外も再考の余地があるのかと思います。

　話をちょっと戻しますが、詳細設計書にロジックが書かれているのであれば、プログラムソースと冗長になります。
　プロジェクトの生産性を高めるには、無駄のない文書体系が必要です。
　”詳細設計を変えた”のがロジックだとしたら、詳細設計書のフオームからロジックの記述を省くことが再優先です。
　因みに、ソースコードにはコメントとして詳細設計書の章番号を記載し、対応付けをルール化しておくことが保守を容易にします。

解任した場合は作り直す前提で考えられているようですが、レビュー報告書がないと納品できないってことでしょうか？
解任してコードだけ使うのは無理な感じですか？
もうひとつ
「修正」ではなく「変更」と書かれていますが、だったらレビューをした版のコードを使う選択肢はないのですか？
変更ということは性能的な目標未達とかですよね？
だったらとりあえず動くものはあるわけですから、後日差し替えという選択肢もあると思います。
いずれにしろ、さっさと解任しないとどんどん取り返しがつかなくなりそうな…

詳細設計書は 提出してもらえないのでしょうか?


また、応じない理由 何でしょう?

その理由によって 対処する内容は 変わってくるはずです。

あと 詳細設計のレビューをしておきながら、単体テストが悪かったから修正というのは ちょっとおかしいと思います。

それだと詳細設計のレビューがちゃんとなされていなかったということにならないでしょうか？

この場合、レビューをした人にも責任があるでしょう。

レビューは 当事者がいなくてもできるものです。

詳細設計書を提出してくれないのでしょうか？

作成物を納品してくれないんなら はずすしかないんじゃないでしょうか？

＞修正したとしてもドキュメントとして残っていないと思われます。

それは修正したと言えないのではないでしょうか？

詳細設計書を修正していないからレビューできない ということなんですね。

詳細設計書の修正には どれぐらい時間が かかるのでしょう？
そして それを修正してもらう時間はあるのでしょうか？

変えたならなおのこと必要。

拒む理由が他にあるのではないですか？

＞基準成績をクリアした

不具合はない ということなんですね。

でも 作成物は 提出しないとダメですよね。

だわかきさんの仰ることが全てであるならば、
「レビューの目的をはき違えている、問題がないことを証明して、記録に残しておく必要がある」
「レビューも仕事（成果物）に含まれる」
というのが回答になります。

いくら基準を満たしていても、それを証明できなければ意味がない。
切符は買っていても、検札で見せられないなら降ろされます。

でも、たぶんですけど、そんなことは承知しているのではないかとも思うんですよね。
もちょっと込み入った事情とかあったりしませんかね？
なんでそんなにこだわるの？と聞いてみてはいかがでしょうか。

khurataさんの意見が正しいと思います。
さらにいえば、その人が居ることによるロスは単に時間や作業量だけではありません。むしろ、レビューなど無視しても良いと社員一同に公式に広報することによる後からのダメージが大きいと思われます。
その人を説き伏せるか、辞めさせるか、もっと優れたモジュールを作り直すか、あなた自身が心を決めるべきで、経営者としての判断を必要とする場面です。

　「コードレビューが出来なかったモジュールを納期通りに出荷する」のと、「ルールに従った製造過程に基づくモジュールを遅れて出荷する」のと、どちらが「良い」のかは、その時その時の判断が有るだろうと思います。
　「現場の判断」は、往々にして理想論や「べき論」だけでは決められないものです。
　しかし、だからといってルールを軽視してよいという前例を作ってしまうと、いずれそれは定着してしまうでしょう。人は楽な方に流れやすいからです。
　仮に今は前者を採るのだとしても、それはあくまで特例であることを、内部に周知徹底しなければなりません。可能であるならば、何らかの実質を伴うペナルティをチームに課しても良いでしょう。

詳細設計レビューはメンテナンスが用意に引き継ぎが必要になるためのものだろうし、客先の要望ならなおさらですね。
主張することも理にかなっているような気がしますが、メンテナンス面で仕様変更の調査等で
他人が分かるようにしないといけないことを論じてみては如何でしょう。
その方もおそらく他人の製造したプログラムをメンテするときに詳細設書があれば、他人に説明しやすいはずです。

コーディング規約に準拠してるかどうか詳細設計レビューで検証するためって言えばどうでしょう。
それでも持論を展開するようであれば、外された方がいいと思います。

ソースだけ取得してこちらで勝手に開発者不在でレビューを行い、その結果を持って対応するというのはどうでしょうか？
個人所有のPCでもない限り会社の開発したデータは会社のものであり所有権は会社にあると思いますのでソースの提出を求められれば拒否は出来ないと思います。
開発者不在というのがひっかかるかもしれませんが、レビューを通すだけの状態で開発者がインフルエンザにかかってしまい期限に間に合わない場合は不在でレビューもあり得ます。
（ちょっと面倒ではありますけど）

担当プログラマの中では一連の流れに整合性が取れているのでしょうが、外野から見れば
「法律に書いてなければやっていいわけではない」
という状態ですので権限なり強制力を発揮していくほかないと思います。

＞設計担当SEの責任になってしまうのです。だからSEは再レビューを要請しているのですが、

その担当プログラマが詳細設計書を書き換えたならば、その担当プログラマの責任になるのではないでしょうか？

おぉ。こちらこそ他のやり取りを確認しておりませんでした。

私の例示した原因は今回の件には影響しないようですね。

設計段階ですと雰囲気的には個人的な感情（この程度でいちいち再レビューをする意味がわからない、影響はないはずだ等）の可能性が高いようにも思われます。

工期そのものに無理が無い（つまり、レビューに関わる肯定を再度入れることによりその負担を担当者が負うような状況）ということであれば、進捗に影響を及ぼしている以上は外すしかないと思われます。

※その他、レビュー時の雰囲気や進め方等わからない部分が多いので、何がベストかという点は判断しかねますが、現状の情報からですと上記の選択がベターかなと思います。