この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。
1on1 でのフィードバック、 360度フィードバックのアンケート、エンゲージメントサーベイ。 人やプロセスの改善につなげるための建設的フィードバックは、仕事をしているとよくある機会です。
これらのフィードバックの質は
- 改善につながりやすい、よりよいフィードバック
- やや情報が不足しているが、行間を推測できそうなフィードバック
- 口が悪いが役に立つフィードバック
- 口調は丁寧だが痛烈な非難になっているフィードバック
- 不満の感情は伝わってくるが具体的に何が問題かわからないフィードバック
- ただただ攻撃的で気が滅入るフィードバック
- 好みの問題に関するフィードバック
- 完全に誤ったフィードバック
などのように様々です。そこで実際に改善につながるフィードバックのノウハウについてまとめます。
障害報告のノウハウを転用する
システム開発に関わる人であれば、障害報告の質によって障害の解決有無や解決スピードが大きく変わるということを実感しているのではないでしょうか。人やプロセスの改善につながるフィードバックのノウハウは障害報告のハウハウと似ています。 あたりまえといえばあたりまえで、障害報告は改善につなげるフィードバックの1例だからです。
- 改善につなげるフィードバック
- 障害報告
- 人やプロセスの改善につながるフィードバック
例えば
- 問題発生時の状況を伝えること
- 事実と解釈を分けること
- 問題箇所がどこかわかりやすく具体的に伝えること
- 5W1Hなど、具体的に伝えること
- 複数の問題を扱う場合は、別々にすること
- 問題と解決策の提案を分けること
などのポイントがあります。
こちらの記事で記載されている内容も参考になります。
上記に列挙した要素を包含するより大きな観点としては、
障害対応する人がこの情報を元に実際に障害対応をする画面を想像すること
です。
提供した情報をもとに問題を理解し、解決策を検討し、実際に解決のアクションまで導くことができるか？ 解決する人の視点でこれらを想像するとよいでしょう。
障害報告のノウハウとは別に必要になるもの
システムの障害報告はあくまで「改善のためのフィードバック」の1例なので、人やプロセス特有で別途気にしておくとよいことがあります。
感情について知らせる
障害報告で感情を扱うことは無いかと思います。しかし、人に関わる改善には感情が関わっていることもあります。 そのため、そのとき自身がどのように感じたのかを自分を主語にして伝えたほうがよいケースもあります。逆に相手を主語にすると相手に対する非難に結びつきます。いわゆるアイメッセージかユーメッセージか、という話です。
感情に関わる改善対象の例としては、上司にとって感情を揺さぶるネガティブな出来事ではないことが、部下にとってはネガティブに解釈されることもあります。ここで、上司の発言で部下が傷ついていた場合、主観での捉え方が異なるため部下自身が感じたことを伝えないと、上司は自分が相手を傷つけていることに気づくことができません。そのため自分が感じたことを知らせることで、はじめて相手に問題が伝わります。 もちろん、率直に伝えること自体がためらわれるくらい関係性が悪いとそうもいかないとは思いますが。
改善可能であるという前提で考える
組織のプロセスや人に関する建設的なフィードバックは、相手は情報を得て改善することができる、という前提に立っているか、改善不可能だとだと考え、相手をただ単に非難するスタンスかでその内容は大きくことなります。 単に不満を伝えるのではなく、相手の改善を助けるための情報提供という視点が好ましいでしょう。
改善者の心を加味する
改善の対象となる相手は人間で、心があります。痛烈な非難があったとして、必要な事実のみを吸い上げ、気にせず改善につなげられる人もいれば、痛烈な非難で改善意欲を失ってしまったり、反発してむしろ意地でもフィードバックを受け入れないという姿勢になる人もいるでしょう。
痛烈な非難に耐えることができる人に対して丁寧なフィードバックをしたら逆にキレる、ということはないでしょうから、丁寧に相手の心を加味したフィードバックをする方向で統一しておくとよいでしょう。過度にオブラートに包んだ回りくどい表現をする必要はありません。相手の改善のために伝えているということが伝わればよいのです。攻撃的な表現でないことはその前提になります。
経緯に敬意を
こちらはプロセスの改善に関するもので、好ましくないプロセスには様々な背景があります。単に担当者の知識、習熟度が原因のこともあれば、予算や時間の不足など苦渋の選択で現状になっている可能性があります。各自がその時点での最善を尽くした、という前提のもと敬意をもったフィードバックをしましょう。
フィードバックをする側の心構え
- 対象となる人やプロセスの改善のためのフィードバックをする
- すべてのフィードバックに対する完璧な対応を求めない
- フィードバックへの対応は時間を必要とする。時間は有限で全ては実施できない
- フィードバックへの対応難度は人によってことなる。あなたにとって簡単なことも相手にとっては難題かもしれない
- フィードバックは正しいとは限らない。誤りや、好みの領域もある
- フィードバックを元にした改善アクションが1発で成功するとは限らない
フィードバックを受けた側の心構え
- フィードバックを元に改善を実施した場合は、その事実を共有する
- フィードバックが活用されていることがわかるのが大切
- 匿名フィードバックの場合はその匿名の範囲にわかるように共有する
- すべてのフィードバックに対する完璧な対応が必要と考えない
- 理由は「フィードバックする側」の内容と同じ
まとめ
不満の感情からくるフィードバックは何かと攻撃的になりがちかもしれません。しかし、不満が解消されたほうが嬉しいはずで、攻撃的なフィードバックや曖昧なフィードバックをするよりもポイントをおさえた丁寧なフィードバックをしたほうが不満の解消確率があがります。フィードバック上手は自分の周囲の質を高めることができる強い武器になるでしょう。
クラスメソッドのカルチャーである CLP にもフィードバックの項目があります。
お客様やチームからのフィードバックを大切にします。相手にフィードバックを求め、内容を前向きに捉えて高速に改善を繰り返します。相手にフィードバックする際には、具体的な行動に繋がるように分かりやすく伝えます。
自戒も込めて、お互い具体的な行動につながるようなフィードバックを心がけましょう。
5
