2016/12/28
批評の受け止め方
ネットに初心者が公開したプログラム等の成果物にあんまりツッコミが入ると萎縮しちゃうんじゃないか、という話が上がってた。
何かを表現することの初期段階に、 安全な環境で批評を受けるのは重要だ。たとえ Don't take it personallyと言われても、 意識的に自分と自分の作ったものを分けて考えるのは(最初のうちは)難しい。
ただ、ツッコミにもいくつか種類があって、 それを全部「不寛容社会」のせいにするのも乱暴すぎる。
成果物(ここではプログラム等)に対するツッコミの目的は、いくつかに分類できる。 複数の目的が混じっている場合もあるが、ツッコミを読み解くことで、そこに込められた 情報を目的別に分離できる場合が多い。
- 成果物自体の改善を目的とするもの: 最終的に、指摘が成果物に反映されることを期待するツッコミ。 バグの指摘、アルゴリズム上の問題、運用上の落とし穴の解消、等。 具体的な修正案やパッチの形を取ることが多い。
- 読者への情報提供を目的とするもの: 検索して訪れた読者が情報をそのまま流用するとまずいことが起きる可能性があるため、 そういう読者への付加的な情報を提供しようとするもの。 作者が本文を変更して注意書きを足してくれるに越したことはないが、 コメント等で読者の目に触れるようになっていればいい。
- 作者の行動を変えることを目的とするもの: 作者に一歩進んでほしいという建設的なものも、 その程度の意識で出てくるなといった非建設的なものもある。
- 突っ込む側の自己満足: 自分の優位性を誇示するマウンティング目的とか、 自分が押すフレームワークやら言語やらの布教目的とか。
個人的な印象では、エンジニア界の手斧の投げ合いの結構な割合は1や2だと思う。 コードが良くなることや、誤った情報が広まらないことが重要であって、 誰が書いたかとか誰が指摘したかはどうでもいい。 とはいえ、3や4も混ざってなくはない。
一方、作者の方の目的も色々だ。 成果物を晒してブラッシュアップする、というのが目的とは限らない。 初めて書いてみてうまく動いたからやったー！っていう気持ちをシェアしたいだけかもしれないし、 勉強を続けるモチベーション維持のために経過報告をしているだけかもしれない。
作者の目的と指摘者の目的が食い違っている時に、摩擦が生じる。
公開する以上、不特定多数からのフィードバックが集まるのは仕方ない。 作者の側として、次のことをまず前提にするといい。
ツッコミを受けとるか流すかは、作者の一存で決めることである
こう書くと当たり前のようだけど、何か言われたら影響されちゃうのも人間の性である。 けれど、「影響されるかどうかを決めるのも、自分の一存」なのだ。 明後日の方向に突っ込んでる無価値な批評はいくらでもあり、 そんなのをいちいち相手にする必要はない。 自分の目的にとって役に立つ批評だけより分けて使い、後は捨てればいい。
その前提を置いた上で、寄せられたツッコミのカテゴリにより対応を変える。 (混ざっている場合は要素ごとに分離して考えれば良い)
- 突っ込む側の自己満足 - 無視する。
- 作者の行動を変えようとするもの - 「この人の言うことなら聞いていいかも」と思える場合は取り入れる。それ以外は無視。
- 成果物の改善 - 成果物を今後も使うつもりでメンテしていきたいなら取り入れよう。 でも、自分ではサンプルや練習のつもりで、それ以上改善する意図が無い時にこれが来たら、 その旨説明してお引き取り願うのが良かろう。 最初からそう説明してたのに指摘してくるのは無視でいい。
- 読者への情報 - これは自分の問題ではなく、自分が書いたものを読む不特定多数の利益に関することである。 間違ったり誤解されやすい情報を広めることが本意でなければ、 その事実が読者の目に触れるようにしておくのが良いだろう。
だいたいにおいて、突っ込む側には「何かを変えたい」というモチベーションがある。 その変えたいものが、自分が変えたいものと一致するなら、指摘を利用すればいいし、 そうでないなら受け流せばいい。 相手のゲームに乗る必要はない。 自分のサイトで発表したなら、ゲームのルールを決めるのは自分だ。
Tags: Programming, 表現
Post a comment