ハクソク

世界を動かす技術を、日本語で。

レビューの各層があなたを10倍遅くする

45日前原文(apenwarr.ca)

概要

  • レビューの層が増えるごとにプロセスが10倍遅くなる現象
  • AI導入でもレビュー遅延は解消しない現実
  • 品質保証（QA）を増やすほど逆に品質が下がるパターン
  • 真の品質向上には信頼とシステム全体の改善が不可欠
  • 根本原因の特定と継続的なシステム設計改善の重要性

レビューの層が増えるごとに10倍遅くなる現象

  • ネットワーク効果の法則では、メンバー数が増えると価値やコストが急増

  • チーム規模を倍にしても速度は倍にならない、調整コスト増大

  • ある経験則：「承認の層が増えるごとにプロセスは10倍遅くなる」

  • 理論的根拠は不明だが、現場では驚くほど当てはまる現象

  • 「ウォールクロックタイム」＝実働時間ではなく待ち時間が大半

    • 例：バグ修正→30分、隣の同僚レビュー→5時間、設計ドック承認→1週間、他チーム調整→12週間

AI導入でもレビュー遅延は解消しない現実

  • AI（例：Claude）でコーディングが速くなっても、レビュー工程がボトルネック
  • 小さな修正でもレビュー待ち時間は変わらず、AI導入の恩恵が薄い
  • 大規模な改修でも、レビュー分割・設計レビューが必要になり結局遅延
  • 結論：AIによる自動化だけでは全体のスピードは上がらない

唯一の持続的な高速化手段：レビュー層の削減

  • シンギュラリティ理論（自己改良の加速）は現実的でない
  • 実際のボトルネックは待機・調整によるレイテンシ
  • 強引にレビューを省略しても、品質低下やバグの増加で本末転倒
  • 安易な「レビュー省略→AI任せ」は、品質管理の崩壊リスク

品質保証（QA）を増やすほど品質が下がる理由

  • W. E. Demingの品質管理哲学によると、QA工程の追加は逆効果
  • QAチームが複数になると、責任のなすりつけ合い・モチベーション低下
  • 現場・設計段階で品質を作り込むことが本質的な改善
  • 例：Toyota Production Systemの「誰でもライン停止できる権限」

信頼とシステム全体の改善が不可欠

  • 信頼がなければ現場は「指摘を恐れて」本当の問題を報告しない
  • 管理職・経営層も現場を信頼し、現場もシステムを信頼する必要
  • システムそのものが根本的にうまく機能する設計であることが前提

継続的なシステム設計改善の重要性

  • AIコーダーも人間もミスをする、ミスの根本原因を潰す仕組みが必要
  • レビューの役割は「同じ指摘が二度と必要ない仕組み」作り
    • 例：「go fmt」で不要になった空白チェック
  • 発生したミスはすでに遅い、根本原因分析・再発防止が重要
  • レビューやQA層を増やすだけでは根本解決にならない
  • 本質は「システム全体の連続的な改善」

まとめ

  • レビューやQA層の追加は根本的なスピード・品質向上にならない
  • 信頼と現場主導の品質作り込み、システム全体の設計改善が鍵
  • AI導入もボトルネックは変わらず、根本原因の特定と改善が不可欠
  • 現場の知恵と継続的な改善こそが、真の生産性向上の道

Hackerたちの意見

コーディングエージェントの前でも後でも、PRのレビューに5時間かかったことはないな。ここでの遅れは調整やコミュニケーションの問題、いわゆる「神話のマンモス」みたいなやつ？それなら納得できるけど。
└
PR自体は5時間もかからないけど、他のエンジニアが自分の作業から切り替えるのを待ってると、簡単にそのくらい時間が経っちゃうね。
└
記事では壁時計の時間を指定してたよ。一日での返答は、急を要しない限りは結構普通だね。多くの人が朝の活動として新しいPRをレビューしてるし。
└
開発者の中には、Slackの通知でPRを見たら作業を中断する人もいるけど、ほとんどはそうじゃない。大体の開発者は、PRのために一日2回くらい時間を確保してる。それでも最低5時間はかかるよ。PRが一日の終わりに来ることもあって、次の日まで見られないこともある。それだと5時間以上かかるね。私の経験では、PRが5時間以内にレビューされることは稀だよ。
└
記事は遅延を含む総時間について言ってるんだ。PRレビューが実際に5時間の作業を要するって言ってるわけじゃないよ。誰かがレビューするのを待つのに大体半日かかるってことだね。
└
> 「神話のマンモス」最高だね。
└
僕が見たパターンの一つは、そこそこ複雑なコードベースを持つチームには、PRをレビューするための必要なコンテキストと専門知識を持った2〜3人のシニアがいるってこと。彼らは他のチームメンバーにプロジェクトを割り当てるし、他のメンバーは彼らにPRを提出する。そうすると、レビューキューがすぐに溜まって、平均レビュー時間が落ち込む。これが良い状況とは言えないけど、こういう状況には簡単に陥るんだよね。
└
PRのレビューに5時間かかることもあるよ。もしそのPRがデータベース、UI、APIに関わる機能全体だったら、全部の部分でQAしなきゃいけないし、サムズアップしたらすぐにクライアントに出ちゃうからね。そしたら時間がかかるし、いくつかの重大な問題を見つけることになるだろうし、またそのループが始まるんだよね。
PRが5時間で処理される職場ってどこなんだろう。私の経験では、時間じゃなくて日数で測られることが多いよ。彼に同意するけど、もし全ての開発者がバグを修正するためにストップボタンを押すことに抵抗がなければ、レビューは必要ないかもしれないね。現実は、どの開発者もリリース目標を達成できなかったら評価が下がるからね。
└
ページの下の方に、彼がTailscaleのCEOだって書いてあるよ。
└
君が説明したようなチームで働いたことがあるけど、最悪だった。今のチームのソフトウェア開発ライフサイクルは、5時間くらいのラインに近い。今日中に誰かが君のコードをレビューしていなければ、スタンドアップでそれを持ち出して、誰かにやるって約束させる。
└
レビューに数日かかる会社で働いていたことがある。CTOはスピードについてよく文句を言ってたけど、コードの質は悪くなかった。今はレビューに数分かかる会社で働いてる。書いたコード3行に対して技術的負債が5行ある。生産環境に出てしまった複雑なバグに数ヶ月かかって取り組んでる。
└
まだ真剣にレビューを扱ってるプロジェクトを見たことがないな。ビジネスも開発者も全然気にしてないし。
Valveはこのことを理解している数少ない会社の一つだと思う。個々の生産性はコミュニケーションの帯域幅にほぼ常に制限されるし、コミュニケーションの負担は、ツリーやメッシュのノードが線形に増えるにつれて指数関数的に増えるからね。[完全に接続される必要はないから、少し減衰した指数でもいいけど]
└
これに気づいたのはジェフ・ベゾスが最初だったと思う。みんながその後賢くなったと思うかもしれないけど、そうでもないんだよね。
でも、レビューをしないってわけにはいかないよね！実際にはできるけど。レビューを左にずらして、代わりに「コードデザインセッション」って呼んで、デイリーミーティングで問題を挙げて、難しい部分はペアプログラミングで乗り越えれば、みんながレビューで見つけるべきだと思ってることの90%は消えちゃう。チームで何を作るか合意してれば、バグやアーキテクチャ、デザインの問題を見つける期待はなくなるよ。残りの10%の変数名やホワイトスペース、パターンみたいなことは、人じゃなくてリンターでチェックできる。チームがそのレベルに達すれば、コードレビューをやめても大丈夫。あとは、合意したコードを書けると信頼できるチームを作る必要があるけど、もしレビューが誰かが仕事をちゃんとやったか確認するためのものであれば、もっと大きな問題があるってことだね。
└
尊敬するエンジニアたちが、PRを作る生産性の約束のためにチームとしての働き方を放棄しているのを見たことがある。それは、自分たちの成果物をレビューしなくなったことに気づいた瞬間、何年もの信頼が一瞬で吹き飛んでしまう。
└
> 「合意したコードを書けると信頼できるチームを作る必要がある」 新しく入った人にも古い人にも「自分のやりたいことをやって、私たちは君を信頼してるよ。ちなみに、君の電話番号は持ってるからね。ありがとう」って言ってる。これがめちゃくちゃうまくいく。人々は手動で確認するのが難しいことに対して、テストを書くためにわざわざ頑張るし、テストを書くのが難しいことを手動で確認する。これとは別に、安全ネットを作ることも大事。悪いデプロイを戻すのに約10分かかる。
└
自律エージェントに任せようとすることの問題の核心のようだね。アマゾンのエージェントが本番環境を削除したことへの反応として、レビュー段階を実装したんだ。 https://blog.barrack.ai/amazon-ai-agents-deleting-production...
└
これもペアプログラミングやエクストリームプログラミングの前提だよね。もしコードレビューが有用なら、常にやるべきだ。
└
僕はレビューが全くない会社にいて、中堅のポジションなんだ。作ってるツールは全然面白くないから、これが一番いいポジションかもしれない。たまに改善点やツール、サイドプロジェクトを探る時間があるんだけど（最後のやつは上司には内緒ね）。
└
そうそう！AIを使う時もそれがうまくいくんだ。最初にデザインセッションをして、何を作るかをしっかり話し合うと、結果がかなり良くなる。次に、どうやって作るかの計画セッションをして（「レビュー可能性」の世界の驚きだね）。それから、物事が複雑になったら止めて、人間と一緒に作業する指示を出す。ここにいる誰か、そういう自己観察のための良いシステムプロンプト持ってる？「詰まってるかも、ちょっとループしてるかも。人間と話そう！」って感じのやつ。
└
そしたら、コードデザインセッションに予算を全部使っちゃって、顧客に見せるものが何もなくなるんだよね。
└
でも、クロードはマジでバカだよね。
└
問題は、レビューがすごく時間がかかるってこと。たくさんの調整やペアプログラミングって、そんなに時間がかかるわけ？
└
これは有名な「計画に何時間もかければ、コーディングに数分の節約になる」というやつだね。アーキテクチャはホワイトボードで計画できるものじゃなくて、実装してみて初めて気づく難しさへの対応なんだ。何を作るか、どう作るかに合意できて、それが実際に機能する計画になったら、君は俺よりすごいよ。20年間のソフトウェア開発でそんなことは一度もなかった。計画したことのほとんどは、実装の最初の数時間で崩れちゃうんだ。反復的なアーキテクチャ会議は必要だけど、週次会議の罠にハマることになるんだよね。
小さいものなら、レビューは早くてスムーズだよね。関係者全員が情報を共有していれば、リアルタイムでレビューが進む。レビューが問題になるのは、作業とレビューのステップを分けちゃう時。AIコーディングにも同じことが言える。ペアプログラミングを選べば実際に役立つし、10,000行のコードを生成させてレビューできない状態になることもある。コンテキストを切り替えるのが生産性を殺すってことをみんなに理解してもらう必要があるよね。同時にいろんなことが起きて、記憶が限られていると、ロード/セーブにかかる時間が、1つのことをやっている時よりも遅くなるんだ。
└
正直、単一のLLMがやってることをそのまま追ってるだけだと、自分でやるより遅くなるから、そのアプローチはあんまり役に立たないかな。計画をレビューするのが好きなんだ（これは、何かがコードベースにどこにフィットするかの仮定を明らかにして、意図を正しく伝えたか確認するため）。長いプロセスの場合は、ざっくり監視して、アーティファクトをレビューする。このやり方だと、他のエージェントを使ったり、会議やプロダクト調査、コーヒーを作ったりしながら、2〜3のことを並行して進められる。
僕の経験では、チームメンバーがレビューの時間を優先する文化（GHの更新を1日に数回チェックしたり、変更を小さなパッチに分けたりすること）が、全体的な進捗をかなり早くすることに繋がる。これは明らかに文化の問題で、技術的にも組織的にも実装が難しいわけじゃない。ただ、チームの速度を個人の速度より重要視して、みんなが協力することが必要なんだ。
└
例えば、あるチームメンバーが街や道路の幾何学的投影をライブビデオにするコードを書いてるとする。別のチームメンバーは、車を自動で追尾するドローンのコードを書いてる。僕はここで認証コードを書いていて、起こりうるすべての分岐をモデル化してる。PRを見ただけの人からどの程度の知的なピアを期待するべきなんだろう？問題を研究している人の知的なピアであるべきだと思うし、努力を基本的に倍にするのはかなり合理的だよね。
いい記事だし、真実だと思う。スタートアップや小さい組織は、承認のレイヤーが少ないから、AIからより良い価値を引き出せると思う。
デザインレビューを数日待つのは、簡単に避けられる痛みだよね。無駄なシステムを作るために数ヶ月かける準備ができてればいいんだけど。
これって最初に「物事が直列化されている」って前提を置いてるけど、実際はそうじゃないことが多いよね。もし30分ごとにバグ修正をして、それを全部レビューに出したら、レビューが5時間後に終わっても全然気にしないよ。その間に10個のバグを修正してるからね！確かに、5時間後にレビューのフィードバックをもらうと、10個前のバグに戻って何だったか思い出さなきゃいけなくて、余計に時間がかかるかもしれないけど、そのバグにはどうせその時間がかかるんだから。遅い非同期コミュニケーションでスピードを保つ鍵は、同時にN個のことに取り組むことだよ。
いい記事だね。個人的な経験から言うと、最先端のものを作るなら、優秀なエンジニアやレビュー担当が必要だけど、それ以外のことなら、いろんなことがそこそこできる個人（チームじゃなくて）で十分だよ。設計からコーディング、コミュニケーション、コスト管理、テストまで、全部自分でやらせて、レビューなしで進めさせるのがいい。成果物がどれだけうまく機能するかで評価すればいいんだ。