総合点と ABCD の格付けを、毎月 Excel で手作業で作っている
3 つの加重評点が総合点になり、総合点が順位付けされ、その期間の業務達成率から等級の割当が決まり、順位に沿って等級が強制され、部門が割当の範囲で調整する。手作業の 3 段階を毎月やり直し、しかも担当者が変われば結果が変わります。
月次の人事評価：採点、順位付け、ABCD の格付け、そしてその後に出る質問までを、検証できる 1 本のラインに
評価のラインを壊すものは 2 つあります。不透明な計算式と、安定しない答えです。同じ質問を 4 回して 4 通りの数字が返れば、誰もそれを評価面談に持ち込みません。引き渡したあとの回り方はこうです。モデルは質問を理解して答えを整え、計算はエンジンが行います。
01
引き受ける前、どこで詰まっていたか
過去の月は等級 1 文字しか残らず、推移を見るにはシートを手で読む
シートは 1 人 1 行で、当月には 3 つの評点と合計があり、過去の月は等級の列が 1 本だけです。「この人は 1 月から 5 月でどう動いたか」「誰が D を 2 回連続で取ったか」に答えるには行を拾うしかなく、人数が増えれば必ず漏れます。
汎用のチャットツールは、正しそうで検証できない数字を出す
モデルに文章の中で計算させると、同じ質問でも回によって違う数字が返ります。入社日を表計算のシリアル値のまま読んで繰り返したり、「D は何人か」と聞けば氏名ではなく割合を返したりします。どれも評価には使えません。
02
引き受けたあと、どう回るか
まず定義を発行し、計算はそのあと
評点項目、重み、3 段階の分布ルール、組織階層、Excel の列対応を、会社の設定としてデスクトップ版に発行します。重みが確認されるまでは、総合点を再加重せず、シートの合計列から取ります。
データソースは、アップロードされた評価シートだけ
評価シートに API はほとんどないので、ソースは会話でアップロードされた Excel です。列の定義とともにスナップショットとして取り込みます。新しくアップロードしていない後の質問では、直近の一致するスナップショットを使います。なければ、代わりのものを探しに行くのではなく、アップロードを求めます。
計算は決定的なエンジンで。モデルは会話だけを担う
個人の複数月の明細、グループや部門の全員、D が 2 回以上といったしきい値での絞り込み、ある推移に当てはまる人の一覧。この 4 種類の問いを、エンジンが 1 つの定義のもとで計算します。何度聞いても答えは同じです。
「連続して」と「上向き」は別々に計算する
右肩上がりは、毎月がその前の月より厳密に良いことを指します。上向きは、途中の振れを許したうえで期末が期首より良いことを指します。現場ではこの 2 つを別の質問として扱うので、エンジンも別々のリストを返します。
氏名の一覧は、質問者の役割に従う
部門責任者は部門、チームリードはチーム、グループリードはグループ。退職者や評価対象外の人は自動で除外され、分布にも一覧にも現れません。
03
どこで必ず人を待つか
- 最初の計算の前に、発行された定義（項目、重み、分布ルール）を書き出して人事の確認を受けます
- 氏名を含む分布と警告一覧は、質問者の可視範囲に留まります。範囲外の氏名は答えに現れません
- 結果を誰かに送るのは人の承認を待ちます。変更した定義は次の実行から効きます
どう受け入れるか
- すでに手作業で格付けした月を再実行する。ABCD の分布と一覧が一致するはずです
- 同じ質問を 4 回する。4 つの答えは 1 字も違わないはずです
- 数人をサンプルにして、入社日と各月の等級を元のシートと照合する
04
定義はどこから来るか
06
よくある質問
評点項目と重みはほかと違います。動きますか？
項目、重み、等級ルールは、会社ごとに発行する設定でありコードではありません。導入時に一度すり合わせ、その後の重みの変更は設定変更で、アプリの更新は不要です。
なぜ決定的なエンジンにこだわるのですか？
これらの数字は評価面談に持ち込まれるからです。モデルの文章の中で計算すると、同じ質問に違う答えが返り、検証もできません。エンジンが固定された定義のもとで計算し、モデルは結果を整えるだけ。どの数字も、元のシートまでたどれます。
評価システムに直接つなげますか？
多くの企業は月次の評価を Excel で回していて API がありません。そのためこのラインは、アップロードされたシートから動きます。Lark Base や Lark ドキュメントの表も読めます。
グループリードが他グループの一覧を見られますか？
見られません。可視範囲はプロンプトではなく固い制約として、役割で絞ります。全社の視点は人事と権限を持つ管理職だけです。