工数データと人事評価を、同じ言葉でつなぐ

別々に運用されている2つ

多くの会社で、この2つは別々に動いています。

工数の記録。誰が何にどれだけ時間を使ったか。勤怠や工数管理のシステムに入っています。 人事評価。半期ごとの評価表。

どちらも人に関するデータですが、接続されていません。評価のときに工数は見ないし、工数を見るときに評価は関係ない。

これをつなぐと、何が変わるか。

つなぐと、分母が出せる

評価で難しいのは、個人ごとに条件が違うことです。

同じ成果でも、扱っている業務の性質が違えば意味が変わります。定型業務ばかりの人と、非定型の業務が多い人を、同じ基準で比べるのは無理があります。

工数のデータがあると、「その人が担当している業務のうち、どれくらいが定型か」が分かります。これが分母になる。

分母が分かると、その人にとって何が改善なのかが個別に定義できます。定型業務が9割の人には自動化が課題で、1割の人には別の課題がある。

前提として、分類の整備が要る

ただし、そのままではつながりません。工数データ側の整備が要ります。

実際に見てみると、入力の粒度が部署によってまったく違うことが多いです。

ある部署は15分単位で、1日5〜10行入れている。分析に使える粒度です。別の部署は「制作業務」のような大きな括り1本で、1日数時間をまとめて入れている。これでは何も分かりません。

後者を「バケツ」と呼んでいますが、この分解が最初の仕事になります。

バケツを分けるところから

分解の基準として使っているのは、月の工数です。

ひとつのタスク名に月8時間を超える工数が集まっているなら、それは分解する。逆に、細かすぎて入力が続かないものは、まとめる。

現場の入力負荷を上げすぎると、入力自体が止まります。精度と継続性のバランスを取る必要があります。

属性は、列を足して持つ

分類を整理したあと、各タスクに属性を持たせます。

• 定型か非定型か
• 自動化の余地があるか
• 今どこまで自動化されているか

ここで大事なのが、タスク名を変えるのではなく、列を足すことです。名前を変えると、現場の入力方法が変わり、過去データとつながらなくなります。

属性はマスタ側に持たせて、現場の入力は変えない。この形なら、現場の負担ゼロで分析ができます。

定型＝自動化できる、ではない

やってみて重要だと分かったのが、この区別です。

定型の業務がすべて自動化できるわけではありません。物理的な作業、外部システムに手で入力するしかないもの、対面が必要なもの。定型でも機械には置き換えられない。

だから、「定型か」と「自動化の余地があるか」を別の列で持ちます。ここを混ぜると、「定型なのだから自動化できるはず」という誤った期待が生まれます。

同じ語彙でつなぐ

最終的に目指しているのは、工数と評価で同じ言葉を使うことです。

工数側で「この業務は自動化の余地が大きい」と定義されている。評価側でも同じ定義を使って「その人がどこまで進めたか」を見る。

言葉が揃っていると、工数の記録がそのまま評価の材料になります。別々に集める必要がなくなる。

一言でいうと、評価は人を測り、工数は業務を測る。同じ語彙でつなぐという設計です。