t_wの輪郭

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

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

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

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

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

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

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

過去に成された議論

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

　ダメ出し受けすぎてやる気が出ない。石を積んでは壊される気分だ。学習性無力感というやつだろうか。「何を作ってもどうせダメ出しを受けるんだろう」という気持ちになっている。ダメ出しを受けない時は特に何も言われないので、「仕方ねーな」みたいな雰囲気がある。ダメ出しすることに快感を覚えてないか？人を劣位に置くのは快感がある。私にも覚えがある。

　ダメ出し最小化を目指すと、作業量最小化につながってしまう。作業量を確保するには私自身の捉え方を変える（考え方の転換）しかなさそうだ。
　ダメ出しのダメージを受けないように成果物と精神を分離すると、「自分事で考えろ」なので、なかなか難しい。
　逆に、ダメ出し最大化を目指すのはどうだろうか。と思ったが、低品質な資料を作りまくってしまうだけになりそうだ……

　社長という役職も褒められることがないらしい。大変な役職だ。何をモチベーションにして頑張っているんだろうか。

　ダメ出しを受けた資料を修正するのは難易度が高い。その時のベストを尽くした資料なのだから、それを超える必要があり、成長の痛みを伴う。

なんか疲れてきた。休みたい。毎日ダメ出し受けるのも憂鬱だ。
終わったらぐったりしてしまう。萎縮しすぎるのでしんどい。頑張って開き直ってみようか。考え方の転換をした方が良い。お互いに時間を使っている。

ダメ出しされているのが自分じゃないと思い始める

　アンケートを考えるのが難しすぎるにて仕事がうまくいかなかったと感じているが、発想の転換をしたほうがよさそうだ。確かに手ごわいダメ出しを食らったものの、こちらから提示したアンケート項目の中には二つ三つほどの光るものがあった。そもそもダメでもともとみたいな作業で、いわばゲームでベリーハードをプレイしているようなものだ。失敗することが当たり前なのだと思ったほうがいいのだろう。

　資料作成が捗らない。必ずダメ出しを喰らう。作業依頼者自身も答えがないため、なんとなくダメ出しをしている気がする。
　物申すマンを相手にするだけなら資料を穴あけ問題みたいにしてしまえばいいのだが、答えがない場合にはどうすればいいだろう。

　小さなトップダウンで進めたいのだが、数があると安心するらしく、大きなボトムアップで進めたがる。それならば、中間層を解にするようにして、ボトムアップを演じるようにすればいいだろうか。

　今日も仕事がうまくいかなかった。
　アンケート項目を考えるという厄介な仕事をしているのだが、全体を統括している作業依頼者からのレビューで毎回多くのダメ出しを食ってしまう。アンケートを取る目的をなぜ、なぜ、なぜと考えていっているのだが、推測となるため必ずどこかで外れてしまう。そのたびに少なからぬ方向転換を必要とするのだが、どこまで行ってもゴールにたどり着ける気がしない。賽の河原に石を積んでいるような気分である。

　作業依頼者自身もゴールなど見えていない気がする。レビューの間も「難しい、難しい」とこぼしている。むしろゴールをこちらが圧倒的説得力を伴って設定することが近道なのかもしれない。