t_wの輪郭

　アイデンティティと成果物を紐づけないようにするというのはよく言われるが、なかなか難しい。5年ほどITエンジニアをしているが、それでも成果物に指摘（ダメ出し）を受けるとダメージを受ける。
　とりあえずコードレビューする側が「shit」とか「クソコード」みたいな侮辱する言葉を避けるのは効果があると思う。こうしたダメであることしか示さない言葉を避け、もっと具体に踏み込み、「この個所をこのように変更するとこういった利点がある」といった指摘にできれば良い。簡単な言い換えでWinWinにできるはずだ。

教育者が可能な批判は行動への批判

　行動への批判のみが可能であるという情報をもらった。コードを書く際のやり方に対して指摘ができればいいのだろう。行動への批判は以下の点で利点がある。

• 行動の変容により、成果物の品質が長期にわたって向上する
• 成果物への批判よりも人格攻撃の度合いが低い（教育から見たクソコード批判の問題点を読むにそういうことだと思うが、まだ十分に理解できていない。要調査。）

　具体的にできそうな、コードを書く際の行動への批判については、以下ができそうだ。

• 静的解析ツールを使う
• UMLで設計してからコードを書く

　成果物の問題点から行動の問題点を逆算し、実際に行動を観測し、それを指摘できれば良い。

過去に成された議論

• 『"クソコード"は人格攻撃ではないのか』
• 『クソコード批判とクソコード批判批判はなぜ燃えるのか』
• 『ポール・グレアム「アイデンティティは控え目に」』

https://note.com/qsona/n/nbb36de134346

「コードがクソ」批判、一般化して「成果物がクソ」批判は、教育においては2番目に回避される。
一番忌避されるべきは人格への批判で、これは改善意欲を含めた本人の意欲すべてを削ぐので、無力化か、荒療治で理不尽耐性をつけさせる目的を除いてやってはいけない教育の典型例。
2番目が成果物への批判。成果物は、本人が成果物と考えている以上は、本人の人格への再取り込み（自分はこういう仕事を完成させた人だという自認識）が完成してしまっている。したがって、成果物への批判は、すでにふさがってしまった傷への再手術と同程度に苛つかれる。本人が再手術の必要ありと認識している場合に限り妥当である。
教育者が可能な批判は行動への批判であり、「コードを書くときにお前がすべきであること」を事前、事後の二度に亘り伝えなければならない。事中の指示は、相手からの強い要望がない限り避け、できる限り相手の自発に基づいたサポートに徹する。ただし、本人が誤りを反復したことに気づいていない場合は介入する。事中の深入りはマイクロマネジメントを招き、本人の状況統御能力を毀損するので最低限とする。