Pull Requestと「謙虚、尊敬、信頼」

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

• 出版社/メーカー: オライリージャパン
• 発売日: 2021/11/29
• メディア: 単行本（ソフトカバー）

一年半前に読んだ本ですが、あらために2章「チームでうまく仕事をするには」を読み返してみると最初に、次のように述べられています。

本章において決定的に重要な考え方は、ソフトウェア開発とはチームによる取り組みであるということだ。そして、エンジニアリングのチームで（あるいは他のどんな創造的共同作業でも）成功するためには、「謙虚、尊敬、信頼」という中心的原則をめぐる自身の行動を改革する必要がある。

また、9章「コードレビュー」（p.197）からの抜粋ですが、コードの変更については次のように述べられています。

変更にLGTMの印が付いた後で、作者はその変更をコードベースへコミットすることを許されるが、それは作者が全コメントを解決し、その変更が承認されることを条件としている.

GoogleでのコードレビューのプロセスはGitHubを使ったPull Requestとは異なりますが、基本的には承認されることが条件となります。

私自身がGitHubを仕事で使うようになったのは、2017年9月からソラミツで働き始めてからでした。それから、メルペイ、カウシェと働いてきましたが、PRをdevelopブランチやstagingブランチへマージするには承認（approve）が必須でした。

チームの他のメンバーにレビューを依頼し、コメントを通した指摘の内容を理解して、適切な対処（コードの修正やコメントを通した説明、etc）をして、承認されてから、そのPRをマージするということです。そして、重要なのは、個々のソフトウェアエンジニアの役割（アーキテクト、テックリード、チームリーダー、etc）に関係なく、同等に承認を必要とする運用です。

もちろん、レビューしてもらって承認してもらったからと言って、完璧なコードであることが保証されたわけではありません。そうではなく、「チームによる取り組み」として、このようなプロセスを行い、集団的英知を増やし「バス係数」（プロジェクトを完全に破綻させるために必要な、バスに轢かれる人の数）を高めることになります。

しかし、このような運用ではなく、ソフトウェアエンジニアの役割によっては、レビューしてもらう必要も承認も必要とせずにPRをマージできるが、他のソフトウェアエンジニアはレビューと承認を必要とする運用ではどうでしょうか。PRの承認を要求される役割のソフトウェアエンジニアにとって、承認なしでマージされるPRすべてがベストプラクティスのようなお手本であれば、おそらく何も問題はないかもしれません。しかし、何を行っているのか分かりにくコードだったり、十分なテストコードが書かれていなかったり、必要な説明が書かれていなかったりするかもしれません。

あるいは、きちんとレビューして、コメントをしたにもかかわらず、コメントに対する修正内容を再度確認することを依頼されることなく、PRの作成者の判断でマージされたらどうでしょうか。そうなると、次からはきちんとレビューする気が失せるかもしれません。このようなことが起きないように、レビューと承認を必要とするプロセスをチーム全体で運用するわけです。

一部のソフトウェアエンジニアだけが、Pull Requestを承認なしでマージできる運用は、長期的な視点では「謙虚、尊敬、信頼」を破壊するベストプラクティスかもしれません。