卓越には天才ではなくシステムが必要だ

優れた製品は、他人より早く違和感に気づき、「まあ十分」を完成と呼ばない一人から始まることがある。しかし品質判断のすべてがその人に戻るなら、卓越は一人の身体に閉じ込められている。

組織は、その人が見ているものを原則、言語、プロセス、意思決定権へ翻訳し、他の人が学べる形にしなければならない。

個人は基準を生み出せる。システムはその基準を個人より長く生かす。

「もっと良く」は基準ではなく願望だ。良い基準は、どこを良くするのか、なぜ重要なのか、どんな証拠で達成を判断するのかを説明できる。

Design principle、definition of done、quality bar、checklist は判断を置き換えない。判断を共有可能にする。

基準は「見ればわかる」より明確に言語化されたときにスケールする。

Design review や code review は品質を高める一方、権力の舞台にもなる。良いレビューは好みではなく、仕事、基準、証拠に焦点を当てる。

成熟したレビューでは、立場の弱い人も理由を求め、「基準未達」と「私の好みではない」を区別できる。

良い critique が守るのは、基準を作った人の自尊心ではなく仕事の品質だ。

品質を最後だけで確認すると、多くの問題はすでに高価になっている。良い組織は requirement、prototype、test、accessibility、security などに品質を前倒しする。

広い意味での QA は一部署の仕事ではない。ミスを起こしにくく、見つけやすく、学びやすくする組織設計そのものだ。

持続する品質は、欠陥を早く見つけるだけでなく、欠陥が普通になることを難しくする。

新しい人は一人ひとり基準線を変える。速さ、肩書き、技術力だけで採用すると、critique や協働、責任、craft が弱いチームになることがある。

卓越した文化には、品質を見抜き、判断を説明し、批評を受け、証拠から学び、他者も引き上げられる人が必要だ。

今日の仕事をする人だけを採用しているのではない。明日の「十分」を決める人を採用している。

基準は、それを持っていた人が去ると消えることがある。次のチームが劣っているからではなく、重要な理由が会話や少数の記憶にしか残っていないからだ。

良い documentation は原則、trade-off、decision log、例、失敗からの学びを残し、同じことを最初から発見し直さなくて済むようにする。

記憶のない組織は、同じ学びに何度も支払う。

基準は余裕がある時には守りやすい。本当の試験は deadline、売上、大口顧客が圧力をかける時だ。誰が release を止められ、誰が risk を受け入れ、誰が結果を負うのか。

権限が曖昧なら品質は階層に負けやすい。成熟した組織は risk に応じて権限を分配し、例外に所有者、理由、再検討日を持たせる。

基準は、守るためにコストがかかる瞬間にも権限を持つとき初めて本物になる。

全員を founder や最高の engineer と同じ思考にすることが目的ではない。原則、技能、feedback によって組織自身が品質を見抜き、その定義を更新できることが目的だ。

review、QA、hiring、documentation、decision rights、feedback loop が一体になると、卓越は一人の才能ではなく集団の能力になる。

基準は、それを作った人が部屋にいなくても生き続けるとき文化になる。