はじめに
何を伝えたいかというと、フィードバックの誤謬を 完全に理解 して、1on1を効果的に実施できたということ。
これはアジャイルコーチから勧められた本であるが、昔読んだ時はあまり刺さらなかった。
最近1on1のために読み返してみると実践に役立つことがあり、今回、実例ベースで話せるので面白いのではないかと思い、記事を書いた。
差し支えない範囲の自己紹介
僕（NibuTake@SMycrow）は何者か。自社商材をスクラムチームで内製化しているエンジニアであり、技術ベースの活動が多くStaff Engineerと名乗っている。（正式な役職は存在しないが、メンバーやマネージャーからは認められているはず）
背景
最初に断っておくと、1on1、僕はやってなかった。なんとなく自発的にやるの気恥ずかしい。エンジニアのためのマネジメントキャリアパス読んだりして、1on1やりたいなぁと思いを馳せたくらい。やるために自身の工数を割いてどれだけ価値があるのだろう、とか、メンバーは管理職と面談もあるのにさらに1on1までやるか、など考えて、結局やめた。でも会社経験を積んで、やらないとダメだなと思うようになった。
なぜかというと、開発者の成長機会の喪失を認識したから。うちでも目標管理はあるけど、結局は現場にいないマネージャーが担当していたり、マネージャー自身に現場レベルのスキルがなかったりして、効果的に活用されていなかった。残念ながら。結果、メンバーの成長について、技術面でのコミットが薄くなっていた。もったいない。
なのできちんと1on1でメンバーのこと理解して、さらに目標管理までやってみようと思った。その時、昔に読んだ本を色々読み返したり、自分の体験を通じたりして、フィードバックの誤謬を 完全に理解 した。そしてそれを広く共有したいと思った。
サマリーで語るフィードバックの誤謬
この本を読んだことのない方にも本記事を理解してもらいたい。簡易的にまとめると以下のようなことになる。まとめには個人差がある
- 長所は伸びやすく、短所は伸ばしにくい
- 指摘よりも、卓越性を褒める方が成長しやすい
- 卓越性を認識・再認識させると、その発生頻度を上げることができる
一つ目はわかるけど実際どうするのという感じ。特殊型ひかえめドサイドンとか作らないよね。 まぁ実際はやってみたら楽しいとか。でも短所はどうするんだろう。
二つ目も理解はできる。指摘はマイナスの矯正程度しか効力がない、複雑化した問題に取り組む業務であれば卓越性を伸ばしましょうと。だけどじゃあ現場ではどうするよ。
三つ目は腑に落ちた。そもそも本人は気づかずチームに良い効果をもたらしていることがある。それを本人が自覚すれば、良いことだと理解して、意識的に実践できるようになる。ディ・モールト良いぞ。
当時読んだ感想としてはこんな感じ。結局、知識としては理解したけど、活かせなかった。けど自分の体験でそれが少し変わった。その具体例を紹介したい。
実例で語るフィードバックの誤謬
前日譚
まず実例からはいる。開発中、夢でなければ こんな感じのコメントをもらった。
NibuTakeさんのPR、良い点が誉められていて、レビュー観点に関して見解が記載してあるので、理想的で良いと思います。
これは素直に嬉しかった。ただ虚をつかれたとも思った。なぜなら僕はこれを意識して行っていたわけではないからだ。これが誉められるなら他の人のコードレビューはどうなっていたんだろうとも思った
1. 卓越性を認識・再認識させると、その発生頻度を上げることができる
今まで僕は意識せず良質なコードレビューをしていたことがあった。それが理解できたので今後も続けようと思った。なぜなら苦ではないし役に立つと分かったから。結果、僕が行う良質なコードレビューの頻度はあがった。はずである
これがつまり、卓越性を認識したことによって、その行動を増やしたということである。
2. 指摘よりも、卓越性を褒める方が成長しやすい
もしも仮に、
NibuTakeさんのPR、良い点を褒めてくれないしレビュー観点に関して見解がないので、もっと質を上げてほしいです。
と言われていたら、、、
修正しようとは思うけど、なかなか主体的にできる気はしない。なにより工夫しようという気はおき辛い。これはそういうこと。
3. 長所は伸びやすく、短所は伸ばしにくい
できていないことをやろうとするより、既に出来ることの頻度を上げるのが簡単ということ。僕はすでにすくなくとも一度、意識せずに卓越性を発揮したのである。これは僕が苦手に挑戦するより、はるかに簡単なことである。拡大解釈ぽいけど、そういうこと。
例えばいきなり、もっとコードの保守性を考えて実装してください、とか指摘されても対応は難しい。できていないこを要求しているからだ。もちろん僕はコードの保守性は考えているが。
実例でみると、フィードバックの誤謬が言っていることが、腑に落ちたのではないかと思う。すくなくとも、僕は腑に落ちた。
行動で語るフィードバックの誤謬
1. 前置き
まずは何番煎じにもなるがまとめ。
卓越性を発揮したタイミングを見つけよう。それを認識・再認識させればその行動は強化されて頻度はあがる。そしてそれはそれほど難しくない
これを実際の行動に落とし込む。そのために、まず卓越性の性質について述べ、行動（1on1）について触れる。
2. 卓越性とは
賛否は置いておいて卓越性とは、
その行動により何らかの有益な結果を生み出すものであり、その有益性を説明して納得させられるもの
とでも定義すればいい。後半の納得性は重要である。よく見るこのタイプの図を見てほしい。
| 本当に卓越 | 本当は平凡 | |
|---|---|---|
| 卓越と認定 | 効果的指摘 | おべっか（偽陽性） |
| 平凡と認定 | 機会損失（偽陰性） | 無意味 |
偽陽性を引いた場合、この人なんか褒めてくれるけど中身がない、となり、信頼性の崩壊を引き起こす可能性がある。信頼されなくなってしまうと、今後正しく卓越性を認めたとしても受け取ってもらえない。だから納得・説明性が重要なのである。
これは観察する側に重要な責務があることを示す。真剣に見ていないと卓越性は見つからないし、適当なことを言うと信頼を失うからだ。
でもこれはきちんとやれば難しくはない。なんなら楽しい。なぜなら良い点を探すから。逆はしんどいけど。一人一人、どんな卓越性を発揮しているのか見て日頃からメモしておく。それだけでおおむねうまくいく。
3. 1on1
1on1ではこうして見つけた卓越性を説明して当人に認識してもらう。他にはコーチングとか色々観点あるけど、本記事では触れない。
これにより、各チームメンバーの卓越性がより頻繁に発揮されるようになり、開発生産性は向上する。すごい。
応用で語るフィードバックの誤謬
1. 問題提起
今までは正直、理論に具象を関連付けただけ。ここからは応用。具象から理論を用いて発展させる。
長所は伸びやすく、短所は伸ばしにくい
僕が気になっていたのはこの点。じゃあ短所はどうするの？
ここが僕なりの結論であり分析であるが、これは表裏一体なのである。つまり双対問題ということ。
2. 双対性
NibuTakeさんのPR、良い点が誉められていて、レビュー観点に関して見解が記載してあるので、理想的で良いと思います。
これを聞いて僕が行ったのは、この行動を増やそうとしたこと。その際に振り返ったのは、
じゃあこれができていない時っていつだろう、という観点。
実際に過去のレビューを見直してみると、指摘箇所が多いPRでは良い点を褒めていることが少なかった。PR出すってレベルじゃねえぞ
指摘が多くなってくると、どうしても他に怪しい点はないかと疑惑の目で見るようになってしまう。そうなると良い点に目がいかない。そういう時は頭を切り替えて、指摘を終えたのち、良い点ないかなと探すようにした。そしたら存外にある、良い点。こうして僕のレビューの質は上がった（すくなくともこのチームにおいては）。
卓越性を発揮した行動の頻度を上げようとすると、それが発揮されていない行動が減るのだ。つまり、長所を伸ばせば、その裏にある短所が改善されるということ。表裏一体なのである。
さらに議論を深める。
逆に、改善したい短所があるとする。例えば、コードレビューが遅いA君が居たとしよう（実際にはいないと良いな）。A君に、コードレビューが遅いから早くして、というのは簡単かもしれない。ただフィードバックの誤謬的に、効果は薄そうである。それに言い辛いかもしれない。それらを解決するのが提案手法である。
3. 悪魔的発想
改善したい短所について、当人比で卓越性を発揮した際に、それを認知させる
実例でいこう。A君だって常に遅いわけではない。思いの外、存外、早いコードレビューをした（少なくとも一度くらいはするのではないか）とする。その時にすかさず、
今回のコードレビュー早くて助かるよ。
とでも言うのだ。これは本心であり事実であるので偽陽性にはならない。これによってA君は強化子を得て、コードレビューが早いことが良い、という認識をすることになる。あとは僕のときとおなじで、卓越した行動が強化され、そうでない行動頻度が減る。悪魔的発想。
いちいち待っていられないし、指摘した方がはやいという意見もある。それも正しいと思う。ただ、いろんな手段を手札として持っておくと、使い分けることでうまく立ち回れるのではないかと思う。
まとめ
卓越性を探しながら仕事するのは楽しい。なにより、各メンバーがより頻繁に卓越性を発揮するようになれば、チームの開発生産性があがる。副次的にモチベーションやエンゲージメントもあがるかもしれない。圧倒的感謝。
この記事が参考になる人が多ければ、1on1掘り下げたり、次も似たテーマで書くかもしれない。