開発者に午前3時に壊れたビルドを修正するように強制すると、モチベーションが損なわれますか？
ビルドを壊すことは悪いことです。さまざまなチームがさまざまな手段を講じて、メンバーがビルドを壊さないように促します。
いくつかの対策は中程度です。たとえば、Joel Spolskyは、Excelチームには、「ビルドを壊した人は、誰かが壊すまでビルドをベビーシッターしなければならない」というルールがあったと語っています。（Joel Spolsky。Joel on Software、20ページ）。
他のものはもっと劇的です。たとえば、Steve McConnellは、「[s]一部のプロジェクトでは、開発者がブザーを着用し、ビルドを壊す責任がある場合は、昼夜を問わずビルドを修正する必要があります。」（Steveマコネル迅速な開発、384ページ）
開発者に夜中に起きて、壊れたビルドを修正するために仕事に来るように強制することは、コミットするコードの信頼性に注意を集中し、2回チェックするように促す絶好の機会のように見えます。
同時に、プログラマーアナリストは通常、個人的な生活を好みます（ラピッドデベロップメントページ252の表11-1によると4番目に優先度の高い動機、マネージャーは15番目、一般の人々）および 午前3時に電話が鳴るのを聞くリスクを理解していない可能性があります 。
個人的には、午前3時に行って間違いを修正するのは面倒ではありませんが、勤務時間が柔軟な会社で働いている場合に限ります。私が知っているほとんどの同僚は、理由が何であれ、会社にとって彼らの存在がどれほど重要であっても、午前3時に仕事に来ることを拒否します。
モチベーションを高く保ちながら、昼夜のブザーなどの厳しい対策を講じる方法は？それとも、そのような抜本的な対策は絶対に避け、他に選択肢がない場合にのみ使用して、チームメンバーのモチベーションを損なう必要がありますか？
壊れたビルドが発生します。それらを完全に回避することは不可能です。開発者は、変更をマージしているときに気が散ったり、完全なテストの実行にかなりの時間がかかる可能性がある非常に大規模なシステムですべてのテストを実行しなかったりする場合があります。理由が何であれ、それらが決して起こらないことを常に保証できるとは限らないことを認識することが重要です。
開発者は、営業時間外にコールバックされることを望んでいません。これはほぼ当たり前のことだと思います。士気への影響は別として、彼らはこれを避けるためにできることは何でもするでしょう。ビルドが中断されないことを100％保証することは実際には不可能であるため、この種のシステムがもたらす影響は、少なくとも一部のシステムが通常の終わりに十分近いところで変更をチェックすることを躊躇することになると思います。彼らがコールバックされるリスクがある時間。完全統合テストスイートの実行に1時間かかる場合、それは人々が午後4時以降にチェックインすることを躊躇することを意味します。つまり、チェックインしていない日の8分の1があります。これにより、早朝に多くの大規模なチェックインが発生し、ビルドが破損するリスクが増加発生します（リスクはチェックインのサイズにほぼ比例するため）。
ですから、いいえ、これは良い戦略ではないと思います。実際には意図したものとは逆の効果があるのではないかと思います。あなたがあなたの質問で引用するジョエルの提案ははるかに良い考えです。
これは主観的な質問かもしれないと思いますが、強制ビルドを深夜/早朝に修正する人々が改善士気やモチベーションに何かをする可能性は低いです。
さらに、プログラマーの奇妙なスケジュールを考慮しても、午前3時に行われる作業は通常の時間に行われる作業と同じ品質にはならない可能性があります。また、コードレビューを行う人、またはバグ修正プロセスの一部である他の人が（もしあれば）少なくなります。
最後に、適切な環境設定を行うことで、実際には発生してはならない問題の解決策のように思われます。ブランチビルドを可能にするCIシステムと一緒にGitを使用しているため、開発者はブランチでコミットするたびにCIエージェントでビルドを実行します（単体テストを含む）。これにより、機能ブランチがトランクにマージされるときに、コードがすでにマージされ（トランク->機能ブランチ）、不可知論的なシステムでビルドおよびテストされていることが保証されます。この場合、トランク上のビルドが失敗する正当な理由はほとんどありません。
したがって、最終的には、難しくはなく、賢く作業します。