- 組織内の承認・レビュー段階が増えるほど、業務処理速度が指数関数的に遅くなる構造を説明し、実際に各承認段階が約10倍ずつの遅延を引き起こす事例を示す
- AIコーディングツールがコード作成速度を劇的に高めても、その後のレビュー・パイプラインの 待ち時間(latency) は減らないため、全体の速度改善効果は限定的
- W. E. Demingの製造業の品質哲学をソフトウェアに適用し、QA段階を追加する方式が、むしろ 品質と速度の両方を悪化させると指摘
- レビューを減らしつつ、同時に モジュール化と信頼に基づく品質文化で置き換えるべきであり、レビュー自体を不要にする構造的改善が核心
- 小規模チームがAI時代に有利であり、小さく美しいコンポーネントを組み合わせる方式で組織とシステムを再設計する必要がある
レビュー段階が10倍の遅延を生む法則
- ネットワーク効果の法則のように、チーム規模が大きくなると 調整オーバーヘッド が発生し、チームを2倍にしても速度は2倍にならない
- 数十年前に知った経験則: レビュー段階が1つ追加されるたびに、プロセスは10倍遅くなる
- 理論的根拠はないが、現実で繰り返し観察される現象
- ここで測定する時間は労力(effort)ではなく 壁時計時間(wall clock time) であり、追加時間の大半は待ち時間
- 具体例:
- 簡単なバグ修正のコーディング: 30分
- 隣の同僚によるコードレビュー: 300分(約5時間、半日)
- アーキテクトチームの設計文書承認: 50時間(約1週間)
- 他チームの予定に載せること(例: 顧客の機能要望): 500時間(12週間、1会計四半期)
- その次の段階である 10四半期(約2.5年) も非現実的ではなく、Tailscaleのような比較的小さな会社でも、製品方針の転換時にはこの水準の遅延が発生する
AIではこの問題を解決できない
- Claudeが30分かかるコーディングを3分で済ませても、節約した27分を使って 自分でAIと反復レビュー するか、検証されていないコードをレビュー担当者に渡すかのどちらか
- レビュー担当者には依然として5時間かかり、自分でも読んでいないコードを渡せば レビュー担当者は不快に感じる
- エージェント型コーディングの真の価値は、1週間規模の大きなプロジェクトを数時間で完成させることだと言われるが、成果物が大きすぎてレビュー担当者が一度に確認できない
- 小さな単位に分割する必要があり、それぞれに5時間のレビューサイクルが発生
- 設計文書がなければ意図的なアーキテクチャも存在せず、結局は設計レビュー会議に行き着く
- 結果として 2時間で終えたプロジェクトが再び1週間に戻る
唯一の方法はレビューを減らすこと
- 特異点(Singularity)理論の前提: システムがますます賢いシステムを作り、改善単位あたりの所要時間が0に収束すれば爆発的成長が起こる
- この理論を信じない理由: 何かを完了するのにかかる時間の大半が、実作業時間ではなく 壁時計時間、つまり待ちと遅延 だから
- 遅延時間は総当たり(brute force)では克服できない
レビューなしにはできないのではないか
- パイプラインの最初の段階(AI生成コード)は速くなったが、その後のレビュー段階がボトルネックだという症状を多くの人が認識している
- 直感的な解決策: レビューをやめよう → 成果物が粗くても 100倍安ければ、1%の価値しか出なくても損益分岐する という論理
- この論理の土台にはかなり愚かな前提がある
- AI開発者の狂気への下降曲線(AI Developer's Descent Into Madness):
- プロトタイプを驚くほど速く作る → 超能力のように感じる
- プロトタイプにバグが出る → AIに修正を指示する
- 変更するたびに、直した分だけ 新しいバグが発生 する
- AIエージェントが自分でコードレビューすれば、自分のバグを見つけられると錯覚する
- エージェント間でデータを直接受け渡しする自分に気づく
- エージェントフレームワークの必要性を認識する
- エージェントでエージェントフレームワークを書く
- 1段階目に戻る
- Claude Codeが実用的になったのは数か月前になってからであり、この循環はごく最近始まったばかりだが、多くの同僚や尊敬される人々がこの サイクルにはまり込んでいる
なぜレビューをするのか
- 会社が成長すると、協業・レビュー・管理の段階が増える → ミス防止が目的であり、規模が大きくなるほど ミスのコストが増える ため
- 新機能の平均付加価値が、それによって生じる新たなバグの平均損失より低くなる時点が来る
- 機能の価値を高める方法がないため、 損失を減らす方向 に進む
- 点検と統制を増やせば速度は遅くなるが、品質は 単調増加(monotonically increasing) するため、継続的改善の基盤のように見える
- しかし「より多くの点検と統制」は品質向上の 唯一の方法ではなく、危険な方法 でもある
「品質保証(QA)」はむしろ品質を下げる
- W. E. Demingが日本の自動車製造業で広めた品質哲学を参照
- 工場におけるQA段階の問題: 部品製作 → 検査/QA → 不合格品の除去 → 見落とし防止のため 第2のQAを追加
- 単純な数学モデルでは合理的(QA段階ごとに欠陥の90%を捕捉できるなら、2段階で 100分の1に減少)
- しかし 自律的な人間エージェント(agentic humans) の環境では、インセンティブが歪む:
- 第2QAチームは第1QAチームを評価する役割でもあり、同僚の解雇につながる結果を熱心に探すインセンティブがない
- 第1QAチームは第2チームが見つけてくれると期待して 努力を減らす
- 部品製作チームもQAチームがいるので自己点検をおろそかにする → 20%遅くなるより10%の廃棄率の方がましに見える
- 品質向上のための全面的なエンジニアリング再設計は コストが高すぎて敬遠される
- Toyota Production SystemはQA段階を完全に取り除き、全員に 「ライン停止」ボタン を与えた
- 米国の自動車メーカーも同じボタンを設置したが、 誰も押さなかった → 解雇への恐れ
信頼(Trust)
- 日本のシステムが成功し、米国のシステムが失敗した違いは 信頼
- 個人間の信頼: 上司が本当にすべての欠陥を知りたがっており、発見したらラインを止めるべきだと確信できること
- 管理者間の信頼: 経営陣が品質に本気で取り組んでいると確信できること
- 経営陣間の信頼: 正しいシステムとインセンティブが与えられれば、個人が 高品質な仕事をし、自ら欠陥を見つける と確信できること
- 追加条件: システムが 実際に機能するという信頼 → まず機能するシステムが必要
可謬性(Fallibility)
- AIコーダーはしばしば質の悪いコードを書くが、この点では 人間のプログラマーと同じ
- Demingのアプローチに魔法の解決策はない → エンジニアがシステム全体に ボトムアップで品質を設計 しなければならない
- 問題が起きるたびに「どうしてこんなことが起きたのか?」と問い、 ポストモーテムとFive Whys で根本原因を見つけて修正する
- 「コーダーが悪かった」は根本原因ではなく 症状 → コーダーがミスできてしまった構造的原因を探さなければならない
- コードレビュー担当者の本当の役割はコードレビューではなく、 自分のレビューコメントそのものを不要にすること
- その種のコメントが将来発生しないようシステムを改善する
- レビューなしでも済む状態を目標にすべき
- 例:
go fmt を作った人々 → 空白に関するコードレビューコメントを永久に除去 → これこそ本当のエンジニアリング
- レビューがミスを発見する時点では、すでにミスは発生した後 → 根本原因はもう過ぎ去っている
モジュール性(Modularity)
- レビュー・パイプライン(QA段階)は機能せず、速度を落としながら 根本原因を隠す → 原因解決がさらに難しくなる
- AIコーディングの魅力: パイプラインの最初の段階が 圧倒的に速い → 超能力のように感じる
- 20年間のコードレビュー文化の陰に隠れていた問題を解決し、 真の品質文化に置き換える ための十分な動機が生まれた可能性
- 楽観論者は半分正しい: レビュー段階の縮小は必要だが、 置き換えなしに縮小すればFord Pintoや最近のBoeing機 のような事態に行き着く
- Demingが製造業にもたらしたような 完全なパッケージとしての転換(table flip) が必要 → 「全社的品質」システムは半分だけ採用することはできない
- レビューを取り除きながら、 同時にそれを不要にしなければならない
- 小さな単位で新しいシステムを完全採用する方法は可能:
- 旧来型の米国自動車メーカーが 日本のサプライヤーの高品質部品 を購入することにたとえられる
- 部品がうまく作られていれば、他の場所のQA段階を取り除ける → 「部品組み立て」作業の複雑さが大きく減る
- 小さく美しいものを組み合わせて、大きく美しいものを作れる
- 互いに信頼する少人数チームが、 自分たちにとって品質とは何か を理解したうえで個別コンポーネントを作る
- 顧客側チームが 自分たちにとって品質とは何か を明確に説明する → 品質が ボトムアップで広がる
小規模チームとAI時代の組織設計
- 小規模スタートアップ は新しい世界でより有利である可能性が高い → 人が少ないため、レビュー段階ももともと少ない
- 一部のスタートアップは高品質コンポーネントを高速に生産する方法を見つけ、残りは失敗する → 自然選択による品質
- 大企業は遅いレビューシステムが固定化しているため、取り除くと 完全な混乱が起こる 可能性がある
- 会社規模に関係なく、エンジニアリングチームはより小さくでき、チーム間の インターフェースをより明確に定義 できる
- 1社の中で 複数チームが同一コンポーネントを競争的に開発 するモデルも可能
- 各チームは少人数とコーディングボットで構成される
- 100通りの方法を試し、最善を選ぶ → 進化による品質
- コードは安いが 良いアイデアは依然として高価 → 新しいアイデアを以前より速く試せる
- モノリス-マイクロサービス連続体 に新たな最適点が現れる可能性
- マイクロサービスは小さすぎるとして悪評を得たが、もともとの用語での「マイクロ」サービスは 「2枚のピザチーム」 が構築・運用するのに適した大きさ
- AI時代では 「1枚のピザと少しのトークン」 程度
- 新しい高速コーディングによって、 モジュール境界そのものをより速く実験 できる
- 機能(feature)は依然として難しいが、 リファクタリングと自動化された統合テスト はAIが得意な領域
- 以前は分離するのが怖かったモジュールを切り出してみることができる → コード行数は増えても、大規模チームが両側を保守する 調整オーバーヘッドに比べれば安い
- どのチームにも大きすぎるモノリスと多すぎるレビュー段階が存在する
- 特異点までは行かなくても、 はるかに良い世界をエンジニアリングできる → 問題は解決可能
- 核心は 信頼
2件のコメント
go fmtを初めて見たときの自分: いや、なんでフォーマットを自分の好みにできないんだよ…！今: フォーマットに好みなんて必要？
Hacker Newsのコメント
レビューをまったくしないという選択肢もある
レビューを前倒ししてコード設計セッションに変え、デイリーで問題を提起し、難しい部分はペアプログラミングで解決すれば、レビューの目的の大半は消える
残りの10%である変数名、空白、パターンのようなものは linter で自動化できる
結局重要なのは、チームが合意したコードを信頼して書ける信頼ベースのチーム文化を作ることだ
実際の実装中になって初めて問題に気づく
完璧に計画通りになることはほとんどなかった。結局反復的なアーキテクチャ会議が必要になるが、それはまた週次会議の沼にはまる
自分で書いたコードすらレビューしなくなると、積み上げてきた信頼が一瞬で崩れる
Toyota Production System のようにQA段階をなくすには、全員が欠陥を見つけたとき即座に止められる信頼が必要だ
レビューパイプラインは問題を隠し、速度を落とすだけだ
この一文自体が地獄の定義のようだ
これがかなりうまく機能する。人は自分でテストを書き、手動検証も並行して行う
誤ったデプロイを10分でロールバックできる安全網も構築している
コードレビューはボランティアのジレンマだ
「PRをたくさんレビューした」より「機能をたくさんリリースした」方が評価に反映されるからだ
結局レビューは、自分の仕事に直接影響があるときにだけ積極的に行うようになる
だがコードは柔軟なので、素早くマージして後から修正する方が、かえってより速い収束をもたらすことがある
特にバグを事前に見つけてオンコールのストレスを減らしたいという動機は大きい
理解できなくても質問を残すことが学習に大いに役立つ
リーダーになりたいなら、コードと設計ドキュメントのレビューを数多くこなすべきだ
この記事は自分の直感と経験を明確に整理してくれた文章だった
Tailscale の製品も好きだったが、今ではCEOのファンにもなりそうだ
書き手の Avery に感謝し、この文章を広く共有するつもりだ
Valve はコミュニケーション帯域の限界を理解している数少ない会社だ
組織が大きくなるほどコミュニケーション負荷は指数関数的に増加する
他の会社ももう気づいていてよさそうだが、いまだにそうではない
レビューが5時間以内に処理されるというのが驚きだ
ほとんどは数日単位で進む
だが、すべての開発者がバグを見つけたとき即座に止められる文化があるなら、レビューは不要かもしれない
現実には、リリース目標を達成できないと個人が不利益を受ける構造になっている
今の会社ではレビューは数分で終わるが、技術的負債が急増している
一定時間が過ぎると自動で「レビュー待ち」のメッセージが来た
すべてが測定され、成果への圧力が強かった
チーム規模さえ適切なら、この習慣は学習可能で広められる
ビジネス側も開発者もあまり気にしていない
レビューの価値対努力の比率はしばしば無視される
レビューが実際に品質を高めないなら、その時間は無駄だ
細かな議論より「動くか」だけ確認して素早くマージする方が効率的だ
あとは後続のコミットで改善すればいい
レビューは短く、方向性だけを確認するチェックポイントであるべきだ
「レビュアーの仕事はレビューをなくすこと」という言葉に全面的に同意する
この記事は直列化されたプロセスを前提にしているが、実際には並列で進む
複数のバグを同時に処理すれば、レビュー遅延は大きな問題ではない
核心は同時作業数(N) を調整することだ
リンク
PRレビュー速度が遅いほどコンテキストスイッチのコストが大きくなる
計算結果では、レビュー速度を上げると生産性が大きく向上する
「レビュアーの目標はレビューを不要にすること」という言葉には共感するが、
信頼の範囲が会社の外にまで広がると話は変わってくる
たとえば
npm updateで悪意あるコードが配布された場合、事後対応では遅すぎる信頼ベースであっても、時には人による検証が必要な地点が存在する
マネージャーは生産性を強調しながら、同時に速度を落とすプロセスも維持している
複雑な問題なので、単純に良い悪いとは言いにくい
オペレーターは生産性と安全の両方に責任を負わなければならない
事故の前は生産性が、事故の後は安全が強調される
外部の人間はこの二重の役割のバランスをうまく理解していない
関連リンク