第100条
ブレイントラスト (権限を持たない助言)
オーナーを覆せる人からの意見は、活かされるより先に防御の対象になる。修正を強制できない仲間なら率直に言えるし、オーナーも落ち着いて聞ける。
心得
率直に指摘し、直し方は持ち主に任せる
どうするか
設計レビューや RFC のレビューでは、レビュアーは問題とその原因と思われるものを指摘するが、直し方は指図しない。判断は作者に任せ、作者は指摘の一つひとつに書面で答える。部屋には、作者を評価する上司ではなく、似たものを作った経験のある仲間を集める。誤りのツケが他人に回るもの (セキュリティ、データ消失、取り消せない移行) では、止める権限のある承認を残す。ただし助言のためのレビューとは別の手順にする。
なぜ起きるか
仕事に深く入り込んだ人は全体が見えなくなり、外の目を必要とする。ところがその目が修正を押しつけられるなら、オーナーは話を聞くためではなく作品を守るために部屋に入り、レビュアーは問題を指摘するところから自分の解決策を指図するところへずれていく。拒否権を外すと両側が変わる。言ったことに拘束力がないからレビュアーは遠慮なく言え、聞いたことが命令ではないからオーナーは耳を傾けられる。そのうえで、結果に責任を持ち、その場の誰も知らない制約を知っているオーナーが直し方を選ぶ。
当てはまらなくなるとき
関門としてのレビュー：死角のツケがオーナー以外の誰か (セキュリティの穴、失われたデータ、別チームのオンコール) に回るなら、無視できる助言では足りず、レビュアーが止められなければならない。
出典
Ed Catmull の発言。「Spark Creativity with These Tips from Pixar's President」(『First Round Review』, 2015) による。"the Braintrust should have no authority" と、責任者が "would never have to come into the room in a defensive posture" で済むようにするという点の出典。仕組みの全体は Ed Catmull with Amy Wallace『Creativity, Inc.』(Random House, 2014) に詳しい。対抗原理は、"the reviewer can certainly deny approval" とするコードレビューの承認者モデル (Google『The Standard of Code Review』) から。
原典を読む引用するとき
Hammurabi『第100条 ブレイントラスト (権限を持たない助言)』 https://kanywst.github.io/hammurabi/ja/laws/braintrust/
BibTeX
@misc{hammurabi-braintrust,
title = {ブレイントラスト (権限を持たない助言)},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 100},
url = {https://kanywst.github.io/hammurabi/ja/laws/braintrust/}
}