クエリ文字列を禁止した同僚と、技術的正しさの居心地の悪さ

ある日のコードレビューで起きたこと

先月、社内のコードレビューでちょっとした事件があった。ある同僚が「クエリ文字列によるパラメータ渡し、全面禁止」というルールをプルリクエストのテンプレートに追加したのを見つけたという話。

理由は明快で、キャッシュの管理が煩雑になる、Core Web Vitals のスコアに悪影響が出る、RESTful な設計思想に反する――技術的には筋が通っていた。あ、確かにと思った部分もある。

ただ、チームの反応は微妙だった。既存のエーピーアイは大半がクエリ文字列前提で設計されていたし、ふろんとえんど側の実装もそれに依存していた。「正しいけど、今やる話か？」という空気が漂っていたことを確認した。

技術的に正しいことと、組織として正しいことは別の軸にあるという、わりと古典的な話に着地する。

エンジニアに限らず、人間は暗黙知で回っている部分が大きい。ドキュメントに書いてないルールのほうが強い組織は多い。クエリ文字列がダメだという合理性より、「今までこれで動いてた」という慣性のほうが強いことに気づく。

テクノロジーは人間の怠惰に勝てない、と普段から思っているけれど、今回はまさにそれだった。

結局、そのルールはレビューで却下された。同僚は不満そうだったが、翌週には新規エーピーアイだけパスパラメータに統一する折衷案を出してきた。そっか、この人は「勝つ」ことより「変える」ことを選んだのだという肯定的な結論に至った。

組織の中で技術的正しさを通すには、正論をぶつけるより一歩引いて設計するほうが結果的に速いといった話。うまく説明できないけど、レイテンシーの最適化に似ている。一気に全部変えるより、ボトルネックから順にやるほうが効く。

コード生成や生成AIが当たり前になって、「技術的に正しい選択肢」を出すこと自体のコストは下がった。でも、それを組織に浸透させる部分は相変わらず人間の仕事で、そこにはパフォーマンスチューニングとは違う種類の忍耐がいる。

同僚のあの折衷案を見て、技術力とはコードを書く力だけじゃないことを改めて確認した。地味な話だけど、わりと大事な話だったと思っている。