前職でフロントエンドチームのスペシャリストとして開発プロセスを考えるポジションにいた。そのときに試してみて良かったなと思えたのはAutoApproveという仕組みで、これは任意のPRにAutoApproveというラベルが付くとGithub Actions経由でPRがGithub BotにApproveされコードレビューなしでマージできるというもの。
コードレビューでは、プロダクトの規模が大きくなっていくにつれ認知的・時間的なコストが嵩む。レビュワーも広汎なドメインや設計レベルの知識が求められたり、人が増えると「これレビューする意味ある?」みたいなPRもレビュワーにバンバン飛んでくる。そうなると、全体的にさらっと見てApproveしたりする。これはもちろんレビューをされる側もそうで、コードレビューという仕組みがあるとなんとなくレビューをゲートキーピング的に捉えてしまいがちなところがある。
なんのためにコードレビューをするか、という意思統一が抜本的に図れていればいいが、それであっても「レビューが通ってるからOKでしょ」みたいな、ある意味自分のコードのオーナーシップを軽く見がちな傾向がコードレビューに対する向き合い方次第では醸成されやすい。これは 「その変更で何かが起きたらひとりで責任を取れ」という話ではなく、ひとりのソフトウェア・エンジニアとしてある程度のレベルがあるなら自律して品質に責任を持てる状態になっていることを期待できるでしょ、という話。
実際、主観的ではあるがAutoApproveの仕組みがあったことで、ある程度本質的にレビューが必要なものだけが厳選されて飛んでくるようになった感覚があった。たとえばtypo修正だったり、内部的になツールだったり、ビューや設計のちょっとした変更であればみんなさっさと入れてしまうし、あとから共有とともにその良し悪しを議論するほうが圧倒的にスピード感があった。
特に前職のフロントエンドはElmで実装されていたこともあり、言語的な特徴*1から仮に大きな変更と言ってもそのバリエーションには限界があることがかなり予測できていた。このあたりは、言語やフレームワークの自由度に大きく依存する。
若干エクストリームな思想ではあるが、そもそもエンジニア採用の時点でレビューが頻繁に必要になるエンジニアを入れないほうがいいというか、前提としてコードレビューがなくても信頼できてガンガンコミットするのを許せるような人材を集めたほうが、プロダクト開発の生産性は高いんじゃないかという気持ちもある。とくにベンチャーやスタートアップならなおさらそうで、組織の最高速度を上げられるなら無限に上げたほうが良いはずだと思っている。
とはいえ、やっぱり人間はある程度の責任を背負わないと成長できない。
余談
とはいえ、冷静に考えるとフロントエンドという領域だからできたみたいな話もある気がする。
言い方には気を付けたいが、バックエンドに比べてフロントエンドのほうが(セキュリティは別として)インシデントのインパクトが小さい傾向はある。たとえばバックエンドで不整合なデータを生み出すようなコードが混入すると、そこそこ重めの復旧作業が発生することが考えられるが、フロントエンドでそういった尾を引くインシデントを起こすリスクは少ないのではないか。
壊れたら気軽にロールバックできるようなリリースプロセスを作り、E2Eほどではないにしてもスモークレベルの自動化テストを用意して、コアの機能以外は壊れても後から余裕をもって修正をリリースできるようにすればいい。もちろんプロダクトやビジネスの性質にもよるが、それでもフロントエンドのほうがやっぱりアグレッシブになれるような気がしている。