今回は、ある企業や組織などのチームにおいて、何らかのアウトプットを出し、フィードバックを受ける側に着目し、三つの方法を紹介する。
チームの育て方(2)：アウトプットの育て方（レビューやコメントなどフィードバックの方法） - ari's worldに続くフィードバック編の第2回である。
今回の記事において、読みやすさの観点から、フィードバックを受ける人を行為者と、フィードバックする人を支援者あと表現する。
- 活動を行いアウトプットを作り、フィードバックを受ける人を行為者と呼ぶ。
- なんらかのアウトプットや活動に対して、フィードバックを与える人を支援者と呼ぶ。
ゲート設定
プロジェクトやコミュニティなどで、行為者は、なんらかの作業やアウトプットをしている。
品質や内容に不備があると、そのアウトプットの効果や価値が落ちてしまう。
- 品質や効果などの価値を上げるために、ピア・レビューなどのフィードバックを活用できる。
- 品質や価値を上げるためのトレードオフとして、納期やコストが増え、スピードなどが遅くなる場合がある。
- 支援者が、フィードバックのタイミングを作ると、行為者が主体的に関わるチャンスを減らしてしまう。行為者がフィードバックを望まないのに、フィードバックされると迷惑に感じることさえある。
- 支援者が、強制的にフィードバックをし続けると、行為者は支援者に依存しがちだ。
それゆえ、行為者および支援者は、アウトプットに向かうプロセスにおいてゲートを設定し、そこでゲートを通過するために適切なフィードバックを行う。
たとえば、ある企業でソフトウェアの開発・保守などを行う場合、ビジネス企画チームとソフトウェア開発チームの二つのチームに着目した例を示す（監査や承認のためのゲートは省いた）：
- ビジネス企画を始めた段階と、チケットに登録するときの開発チーム向けゲート（オプション）
- ソフトウェア開発者が、チケットがアサインされたとき、その解釈や対応策についての開発チームおよびビジネス企画者向けゲート。どのようなシステムテストを想定しているか、見積などの内容を含む。
- ソフトウェア開発担当者によるソースコードと動作についての開発チーム内部でのゲート
- ソフトウェア開発担当者と運用者によるリリースについてのビジネス企画者に向けてのゲート
この場合、行為者がゲートを通過させる責務を負った。
営業活動のための発表資料でも、構想段階と発表資料、発表内容など、状況に応じて相談もしくはフィードバックなどのゲートを設定する。ゲートは、通過、条件付き通過、不通などを決める。
このように適切なフィードバックを得られるように状況に応じた調整する。
組織やコミュニティ、そのアウトプットの内容に応じた、ふさわしい
ゲートの強度を設定する。
重要度や複雑度など様々な状況に応じて、ゲートの増減や、フィードバック強度の加減などのチューニングが行われる。
ゲートを増やし強度を上げると、スピードが落ちるので、必要にして十分な強度を維持することがチームを健全に継続するために必要である。
フィードバックを受ける行為者自らが、主体的にプロセスを進めるように設定することが望ましい。
行為者の主体性を維持するために、いくつかのファシリテートを行うことが多い。
たとえば、支援者も、一緒にゲートを通過させるよう協力的に振る舞うことだ。
その結果、必要に応じた負荷を伴った品質や効果を高めることができる。
ゲートを通過した成果物は、その組織やコミュニティにおける代表する意見として採用することができる。
叩かれるより、種探し
チームで作業について、コメントやレビュー等のフードバックを受ける機会がある。
支援者が攻撃的な意図はないとしても、行為者はコメントやレビューなどのフィードバックをされると攻撃だと受け取られがちだ。
その結果、行為者はおびえ、無視し、怒るなど、非効果的な感情になることがある。
行為者は、建設的な批判と攻撃を区別することは、論理的にも感情的にも困難なことが多い。
なぜならば、支援者は権力や立場がひとつ上がり、行為者は、相対的に支配され、強制されることになるからだ。
たとえば、親が子どもに注意する際、あきらかに親が権力や立場が高くなる傾向にあるからだ^1。
支援者が「それは攻撃ではない」と主張したとしても、それの真偽や妥当性はわからない。
行為者は、いったん冷静になり攻撃と受け取りやすい傾向を理解した上で、フィードバックされた意見が、攻撃かどうかを判断する。
特に「事実かどうか」であるとか「指摘事項がどのような改善をもたらすのか」などのような判断基準を通す。
もし攻撃に感じたとしても、もし許容範囲であれば、その攻撃性を受け入れればよい。
ただし、攻撃性が許容範囲を超えるような場合は感情的になってしまう。
その攻撃を受けたと感じたときに、怒ったり無視したりすると、効果的なコミュニケーションになりにくく、アウトプットの価値があがりにくくなる。
そのようなときは、支援者に、意図を質問することや、攻撃的と感じたことをフィードバックすることが望ましい。
その際、支援者のプライドが刺激しにくくし、健康的なコミュニケーションを実現するため、行為者は元気な子どものように振る舞い、攻撃に感じたことをやんわり伝える。
たとえば「そんなに激しく言われると、おろおろしちゃう。」とか「おおっ、なんか来ましたね」とか、自分の言葉で表現できるとそれが突破口になりやすい。
もしかすると支援者は「攻撃と批判を分けるべき」とか「攻撃しているつもりはいない」のような指導をされるかもしれない。
具体例な事実を示しながら、意図を確認したり「この部分が攻撃されるように感じたので、このように改善してほしい」と伝えよう。
それゆえ、行為者は攻撃かどうかを冷静に判断し、もし受け入れられない攻撃に感じた場合は、1. 明るい元気な子どものように振る舞いながら、2. 攻撃に感じたことを伝える。
ただし、本来の目的は、アウトプットなり価値や品質を向上させることであるため、このような議論はコンパクトにし、タイミングを図ることを忘れてはならない。
その結果、攻撃的な状態というフィルターを通じてではなく、アウトプットの価値をあげやすくなる。
なお、あまりに叩き切るような攻撃的な支援者については、いったん距離を置くようにするのも一つの手だ。
牛のように歩く（選択と昇華の戦略）
フィードバックをするためには、時間を割いて、それなりに時間が必要になる。
第三者からチェックすることは、視点が増え、改善することが多くある。
しかしながら、受けたフィードバックに対応することによって、品質や価値が高まるとは限らず、逆に低下することさえある。
場合によっては、論理的な一貫性がなくなるなど全体のストーリが壊れるなどの問題が発生することさえあるのだ。
たとえば、支援者のAさんからのフィードバックを反映した後で、別の支援者である上司の方針が全く異なり、すべてを作り直すなどはよくある。
そのように行為者がフィードバックに対応することは、リスクやコストをはらんでいる。
それゆえ、フィードバックについての文脈の理解と戦略に基づいて対応する。
どのようなフィードバックでも適切かどうかは不明だ。
- 支援者についてなどの前提条件や文脈の確認
- その人の経験や背景を知る。
- 知識やスキルや、モチベーションを推定する。状況を利用して、何らかのことをしようとしているか。
- 師弟関係など無視することが困難な場合から、何らかの売り込みが予想し対応しない可能性などのもっともらしさ判断の前提になる。
- フィードバック内容の把握と理解
- 行為者がフィードバックを受け取るとき、支援者に感謝の意を伝える。
- 大量のフィードバックがあるときは、指摘事項をまとめる。
- 小さめのタイポなどや一見して妥当な内容は、その場で修正してしまうのも手だ（２分以内かどうかを判断基準としている）。
- 指摘事項が不明瞭、もしくは、意図や理由が不明なときは確認する。
- 戦略と仕様解の検討
- 本来の意図や目的を改めて確認する。よいフィードバックであれば、その意図や目的を修正することも視野に入れる。
- 指摘事項が有効か、重要かどうか、対応可能な内容かを判断する。
- 行為者の意図と、支援者の指摘事項が一致しない場合、確認や未対応などの判断をする。双方の意図を取り入れるような修正も検討する。
- 限られた時間の中で有効に変更するため、対応にどの程度の時間が必要とされるか。
- 全体のストーリとの関係性を確かめ、妥当ではない場合は、確認するか、対応しない等の判断をする。
- 戦略に基づいて対応し、再びアウトプットする。
- 改善されているか、もう一度確認してからアウトプットする。
- フィードバックしてくれた支援者に感謝の意を述べることをお忘れなく。
- 必要に応じて、再びフィードバックを得る。
その結果、フィードバックを活かし、アウトプットの質や価値が向上させる。
謝辞
フィードバックの受け方があることをフィードバックしてくださったT氏に感謝します。
Image : http://commons.wikimedia.org/wiki/File:Field_in_Kärkölä.jpg
には、このように紹介されていた。
