評価手法概要
チームに A, B, C の３名がいます
A は B, C を評価
B は A, C を評価
C は A, B を評価
評価は、最低３つ良い所を列挙、各々点数（１～５）を付ける、良い所の数は無制限
任意でコメントを付ける
自己評価は不要
評価閲覧権限について
- コメントと点数を閲覧可能（給与に関する人間、部長以上等）
- 点数を閲覧可能（リーダー以下、係長以下等）
- 閲覧不可能（下請け、一般社員等）
スコアの考え方
- 回答毎に偏差値化
- 偏差値の平均値を取る
- 後述の信頼度スコアと併せて見る（又は信頼度をそのまま掛け算する）
例: 点数 2, 3, 5 と付けた場合
| 列挙した良い点 | 点数 | 偏差値 |
|---|---|---|
| 良い所１ | 2 | 39.3 |
| 良い所２ | 3 | 47.3 |
| 良い所３ | 5 | 63.4 |
例: 点数 1, 2, 3, 4, 5 と付けた場合
| 列挙した良い点 | 点数 | 偏差値 |
|---|---|---|
| 良い所１ | 1 | 35.9 |
| 良い所２ | 2 | 42.9 |
| 良い所３ | 3 | 50.0 |
| 良い所４ | 4 | 57.1 |
| 良い所５ | 5 | 64.1 |
偏差値化する理由
Aは １～５を満遍なく使用する
Bは 低評価気味で １～２、稀に３を使用する
Cは 高評価気味で ４~５ ばかりを使用す
等、絶対値という個人の感覚を信用せず、「高い低い」という感覚を信用するようにします。
スコアの補足を作成する
同値対応
偏差値の都合上 全て５ の場合等、全て同じ点数の場合、標準偏差が0になり計算できません
そのため初期値 ２，３，４ を与える等します
点数が３点あたりに集中しそうであれば ２，３，４ で良いでしょう、とりあえず計算できれば良いのなら 0, 5 等でも良いと思います。
疑似データを加えることで、標準偏差0による計算不能を回避します。ただし、この場合は信頼度を下げ、補正値であることを明示します。
信頼度ラベルの作成
例
次のような表を作成し
信頼度ラベルを作成します
| 条件 | 評価者信頼度 |
|---|---|
| 評価件数 1〜2件 | 0.2 |
| 評価件数 3〜5件 | 0.7 |
| 評価件数 6件以上 | 1.0 |
| 一定以上の分散がある場合 | いくつか倍率を加算する |
ツールやExcel等で表示する時にこの信頼度を一緒に表示してデータの信頼度指標にします
ソートして信頼度の高い物だけ見るとか低い物だけ見るとか、閲覧時に利用します。
性善説評価
チーム全員が善人であった場合には、各評価を偏差値変換することで、チーム内で相対的にどう評価されているかを確認できる。
当然ですが、絶対値、偏差値スコア、コメントを考慮しなんらかのアクションを決定するには人の手を使う事が前提です。
スコアそのままにシステム化できる物ではありません。
性悪説評価（異常検知利用）
本手法を実施した場合に次の傾向になると仮定します
- 基本的には偏差値＋－０くらい
- 無難なポジティブコメント
- 若干のネガティブコメント
この前提から見て外れ値になった時点で「パワハラ等の問題がある」「突出して優秀な人材」「突出してダメな人材」があるかもという示唆になります。
次の評価を考えます
- A, B は無難な評価を記載
- C は A, B を低評価、コメントに不満が現れている
この評価は次のように推定できます
- A, B は結託したパワハラにより C に全ての仕事を投げ成果を搾取している
- C が突出して優秀な人間である
- C は仕事のできない人間である
良いか悪いかは分からないが異常かもしれない を検知できます。
評価閲覧権限について
基本的には人事評価担当かつそれなりに信用のおける人材であれば全て閲覧可能、それ以外は閲覧不可能で良いと思います
派遣・SESによる下請けチームの場合には、チーム内部に閲覧できる必要は無いでしょう、回収した結果を元にチーム再編成や単価資料に利用すれば良いと思います
一般社員同士である場合も閲覧権限は不要と考えます。
社歴が長く上役とのやり取りが多いとか、給与評価に関わるような人材であればスコアとコメントの両方を閲覧できて良いと思います
「場合により点数だけ閲覧可能」この微妙な権限についてなんですが、下請けを雇ったりチーム編成を変える権限はあり、チームにあまり顔を出さないみたいな人用という感じです、かなり面倒なポジションですがあり得る話ではあるのでそういう権限も考慮します。
スコアデータのサンプル
従業員Ａが記入した評価シート、Ｂ，Ｃについて評価している
| 評価対象 | 良い点 | 点数 | コメント |
|---|---|---|---|
| B | サーバ構築のスピードが早く正確 | 5 | いつも助かっています。 |
| B | 不明な点をすぐに質問して解消する姿勢 | 4 | |
| B | チーム内での進捗共有を欠かさない点 | 3 | |
| B | ドキュメントの整理が丁寧であること | 2 | |
| B | 毎朝遅刻せずに出社し規律を守っている | 1 | |
| C | 複雑なバックエンド処理の設計能力が高い | 5 | 技術力は非常に高いと思います。 |
| C | 開発環境の自動化を推進してくれた点 | 4 | |
| C | 単体テストの網羅性が高くバグが少ない | 3 |
従業員Ｂが記入した評価シート、Ａ，Ｃについて評価している
| 評価対象 | 良い点 | 点数 | コメント |
|---|---|---|---|
| A | 指示が明確で分かりやすい | 2 | |
| A | 定期的なミーティングを主催してくれる | 2 | |
| A | トラブル発生時の相談に乗ってくれる | 2 | |
| C | 職人のような高い開発スキルを持っている | 3 | |
| C | ソースコードのレビューが的確である | 2 | |
| C | リリース作業の手順書を作成してくれた | 2 |
従業員Ｃが記入した評価シート、Ａ，Ｂについて評価している
| 評価対象 | 良い点 | 点数 | コメント |
|---|---|---|---|
| A | 最低限の進捗管理は行っている点 | 2 | |
| A | 外部とのミーティングを調整してくれる | 1 | もう少し現場の負荷を考慮してほしい。 |
| A | 必要な機材の手配を迅速に行ってくれた | 1 | |
| B | 言われたタスクは指示通りに消化する点 | 2 | |
| B | ドキュメントのフォーマットに従って記入できる | 1 | |
| B | 依頼したデータの出力を時間通りにやった | 1 | 負荷の偏りを改善してほしいです。 |
結局人力は必要
当たり前ですが、この手法により出した点数やコメントを元にシステム的に人事異動や解雇を実施する事は想定していません。
点数の分散やコメント、他の経緯を考慮して評価指標にしましょうという話です。
本記事で重要な点は
評価は、最低３つ良い所を列挙、各々点数（１～５）を付ける、良い所の数は無制限
この加点一方向の評価制度だと思います。
予め項目を用意するとありもしない役割の性能評価を強いる、評価点のある人材の評価ができないというような事になりがちなので良い所を積極的に探すよう促します。
予めの項目ではなく判例を５～６個上げておくくらいは良いかもしれません。
スコアや異常検知云々の面倒な話を無視したとしても、「加点一方」「良いところを探す」の２点評価のほうが自分は好みです。
以上です。