エンジニアリング統括責任者の手引き ―組織を成功に導く技術リーダーシップ

19章エンジニアリングプロセスの進め方

Uberは、DUCKレビューと呼ばれる技術仕様レビュープロセス†1を実施していた。「DUCK」は何の略でもなかったが（意図的に頭字語ではないものとして作られた）、それ以外は極めて典型的なレビュープロセスだった。私が参加した当初は、週に1、2件の技術仕様レビューをしていた。依頼されるレビューの量は増え続け、半年後にはレビューを依頼してからフィードバックを受け取るまでに1～2週間の遅れが生じるようになった。それから1年後、レビューを何も行えない状況となり、このプロセスは崩壊した。これは私にとって教訓となる経験だった。なぜなら、DUCKレビューは非常に価値あるフィードバックを生み出していたにもかかわらず、そのフィードバックに対して私たちが支払う対価よりも運用コストの方が高かったため、最終的には失敗に終わったからだ。

[†1] 著者による記事「Tech Spec Review（技術仕様レビュー）」（https://infraeng.dev/tech-spec-review/）参照。

マネジメントのキャリアを歩み始めたばかりの頃は、ほとんどのプロセスが失敗するのは、目の前の問題への対処が不十分だからだと考えていた。プロセスの結果が芳しくないのは、プロセスの細かさや厳密さが足りていないからだと考えていた。その後、よく考えられたプロセスがそれでも失敗する中で学んだのは、良いプロセスは品質とオーバーヘッドの間の慎重なトレードオフの上に成り立っているということだった。素早く実行されるが低品質のフィードバックを提供するコードレビュープロセス（たとえば、プルリクエストが行われてから2営業時間以内にコードレビューを完了することを要求する）をよく見かける。また、（DUCKレビューの場合のように）非常に複雑で質の高いプロセスでありながら、遅すぎるために最終的に無視されてしまうこともよくあることだ。 ...