フィードバックをする際に何を考えているか

フィードバックは相手の成長のために大切な機会にも関わらず、きちんと自分の意図を伝えるのが難しいです。そしてフィードバックを伝える本人以外にも、 肯定的な内容・否定的な内容に関わらず少なからず影響を与える場合があるように感じています。

そこで、自分が他者にフィードバックするときのポリシーや背後にある意図をメンバーに共有することで認識の齟齬を事前に防ぐという目的で、合わせて自分がフィードバックする時の基準のブレを減らすために、この記事を書こうと思いました。

まず本記事内でのフィードバックの定義、フィードバックする対象の定義を行った後それらに対しどのような基準でフィードバックするのか書きます。

本記事内でのフィードバックの意味

「褒める」「叱責する」というリアクション や「〜という行動が良かった」「〜の点が悪かった」という内容を伝えることを意味しています。詳細は後述しますが、前者2つは結果に対するフィードバック、後者2つは振る舞いに対してのフィードバックです。

フィードバックする対象 = 「結果」と「振る舞い」

「結果」の意味はそのままの意味です。良い結果としては、例えば「ライブラリを最新にアップグレードした」 「売り上げを向上させる機能追加を完遂した」「登壇し影響を広げた」「ルーティンを自動化する機能を作った」があります。逆にマイナスのものでは「障害を起こした」が当てはまるでしょう。

振る舞いは、結果と比較するとそのプロセス、すなわち全体にしろ一部にしろそれが結果に何らかの影響を与えるものだと考えています。具体的には「業務以外の技術分野に対しても感度が高く研鑽にも余念が無い（から新プロジェクトで新たな技術を導入するときに主導的な役割を果たせた）」は振る舞いと言えます。他にも「後輩の支援をしっかりする」や「一度失敗したことは繰り返さないような努力をする」「前向きに困難に取り組む姿勢」なども振る舞いと言えます。

結果に対してのフィードバック

良い結果に対してはきちんと称賛します。

一方で悪い結果に対して叱責はしません。もしフィードバックしたとしても「次から気をつけよう」という類のフィードバックに留めます。なぜなら振る舞いもしくはプロセスを見直すことが大事だと考えるからです。

振る舞いに対して

良い振る舞い

称賛します。この際、「等級・経験と照らし合わせて」称賛すべき振る舞いなのか、「一般的に等級関係なしに」素晴らしい振る舞いなのかを区別し後者の場合は明示的にその旨を伝えます。理由として、組織に入ったばかりもしくは年齢が若いメンバーに対して称賛しても、「入ったばかりだから褒めてくれている」と誤解されるのを避けるためです。

この理由で同じことをしても人によって褒められる回数が異なる場合があります。これは贔屓ではありません。シニアレベルのエンジニアがジュニアレベルのエンジニアと同じことをしても褒められないですが、逆は賞賛に値するのは当然のことです。そのため、褒められないイコール評価されてない、もしくはその人が出来ないと評価されていることにはなりません。

賞賛するケースでは、等級や経験以外にも考慮している点があります。他のメンバーに見習って欲しい良い振る舞いをしている場合は、等級や経験の前提を無視し称賛することがあります。チームにその振る舞いが良い振る舞いだと認識してもらうためです。

良くない振る舞い

正確にフィードバックすることを心掛けます。

例えば障害調査でクエリをミスして誤った結論を出すという失敗をした場合を考えます。また、その人は普段からSQLを書くことに苦手意識を感じているにも関わらず、普段の業務で理解することなくコピペでSQLを書いていたとします。

この場合、失敗して結果に対し責めることはありませんが「普段のオペレーションや問い合わせ調査でコピペせずきちんと欲しい結果を導き出すクエリを書く練習をすべきだった」というフィードバックをします。結果を責めても何にも生みませんが、振る舞いを直すことは今後の失敗を防ぎ成長する契機となるからです。現状認識やフィードバックが的外れでないことに注意を払います。

悪い結果を責める意図なく「何でできなかったのか」聞くことがあります。責めてるのではなく振る舞いについて考えてみて欲しい、もしくは普段の振る舞いについてどう考えてるのか共有して欲しいという気持ちの発露です。

余談

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングによると、マイクロマネジメント組織は具体的で細かい指示をする組織、自己組織化された組織は抽象的で自由度のある指示をする組織と述べていますが、似たようなことがフィードバックにも言えます。すなわち、振る舞いのフィードバックが少なくてもメンバーが成長していける状態は自律している状態であり、逆に、振る舞いに対するフィードバックが多くしなければいけない状態をマイクロマネジメントが必要な状態と言えます。

例えば、結果に対する内省をすることできちんとそのプロセスまで振り返ることができる人と「何かができなかった、それは〇〇ができないからだ」というトートロジーのような分析や「自分は技術力がないから」という分析しかできない人がいる場合、それぞれ自律した人とマイクロマネジメントが必要な人となります。

メンバーが自律している状態に近づくことで、メンバーに対しビジョンを共有するコミュニケーションコストが減少し、共に先を見据えることが可能になると考えているため、自分の所属する組織がこの状態になれるよう目指します。

参考文献

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 広木 大地 (著) 技術評論社  2018