パウ・パトロール型チームの人事評価を考える

評価のたたき台にする四つの観点

まずは、次のような配分を考えてみました。効果が検証された評価制度や数値ではなく、話し合いを始めるための案です。メンバーは担当領域、リーダーは連携やチームの成果を重めにするなど、役割に合わせて調整します。何を期待するかは、評価期間が始まる前に本人と確認しておきます。

チームの成果に本人がどう関わったかを確認する

チームが目標を達成したかだけでは、一人ひとりが何をしたのかは分かりません。重大なリスクを早く見つけた、曖昧だった仕様を整理した、他職種との認識を合わせた、といった具体的な仕事を確認します。

たとえば、リリース前の確認が進んだ背景に、前提条件を整理した人や環境を準備した人がいるかもしれません。結果を説明するときに、その過程も含めて記録します。問題が起きなかったことだけから、予防の効果を断定しないようにします。

役割ごとに期待する成果を決める

役割が違えば、確認したい成果も違います。すべてを同じ件数で比べるために換算するより、その役割で何を期待していたかを具体的にします。件数を参考にする場合も、仕事の難易度や担当範囲を一緒に確認します。

• テスト設計：リスクに対する観点の妥当性と、レビューで確認できる根拠
• 探索的テスト：仮説の立て方、発見した問題、調査結果の共有
• 自動化：検知したい範囲、保守性、実行時間、日々の運用への定着
• 業務改善：作業負荷の変化、標準化、引き継ぎやすさ
• リーダー：優先順位、役割分担、意思決定の支援

相談対応や知識共有も評価に含める

相談対応、レビュー、必要な人への橋渡し、情報整理は、ほかの人の成果を支えます。こうした時間を使った人が、担当件数だけでは不利にならないようにしたいです。

手順や判断基準を文書にした、サブ担当を育てた、振り返りをもとにチェックリストを直した、といった仕事も記録します。本人が詳しくなったことに加え、ほかの人もその知識を使えるようにしたことを評価します。

件数を増やすことが目的になっていないか

件数の順位や目立つ障害対応ばかりを評価すると、相談対応や予防の仕事を引き受けにくくなるかもしれません。ただ、支援した回数を競うようにしても、それが何に役立ったのかは分かりません。

何をしたか、その根拠と仕事への影響を短く残しておき、評価の面談などで確認します。うまくいかなかった試みも、試した内容、分かったこと、次に変えることまで見ます。評価を通じて、チームで協力できた場面と、うまくいかなかった場面を振り返れるとよいと思います。