工数分析をバージョンアップ。作業コード体系を設計しなおしてみた話。

リモートワークになって、お互いの仕事する姿が見えなくなりちょっとした会話を交わす機会も半減。チームの仕事はちゃんと進んでいるのだろうか、部下は今どの仕事に注力しているのだろうか。毎日の事実情報を集めるのにもやり方を変更せざるを得なくなりました。これまで勤怠管理をシステム化していた企業も、ただ単に一日の勤務時間を把握するだけにとどまらず、勤怠管理の一歩先、「工数管理」によって実態を把握したいというニーズも増えてきています。ダイエットや受験勉強と一緒ですね。可視化することで次の行動を変えること、大事です。

工数管理、当初の目的

工数管理、つまり、だれがどの仕事に何時間費やしているのかを把握することの大きな目的の一つは「より短い時間でできないか？」「より大きな利益をもたらすサービスや顧客はどのあたりなのか？」・・・こういったことを考えて、仕事の軌道修正を図りより大きな成果を生み出すことに注力すること、と考えています。

自社のビジネスは顧客人事の仕事をコンサルティングしたり実務部分を受託したり、という形態のため、原価の大部分を人件費が占めています。人件費はざっくりいうと人件費単価と稼働時間の掛け合わせでできているため、稼働時間の把握というのは大変重要です。稼働時間が想定よりかかりすぎてしまうと利益が圧迫されます。これはわかりやすいかと思いますが、一方で、利益が高ければ高いほどいいのかというと、手放しでよい評価をすることはできず、サービス品質が低下して顧客満足度が下がるリスクをはらんでいないのかチェックをしていく必要があります。

そのため、創業間もないころから工数把握自体はやってきていたようです（少なくとも私が入社した十ウン年前にはすでにしくみがありました）。どの顧客のどのプロジェクトのどの作業に何時間、という粒感で、勤怠システムの出社時刻・退社時刻の登録を行うときに同時に、表示されるプロジェクト＆作業リストに作業時間を分単位で入力しています。

プロジェクトメンバー全員の入力した時間情報が集まってきますので、それを元に毎月プロジェクト別のP/Lを作成して社内に公開するということをやっています。プロジェクトマネージャーは、売上と稼働時間のバランスを見たり、利益額を見たりしながら、プロジェクトの改善を図っていくという使い方です。問題がありそうだと思えば、作業別の稼働時間にドリルダウンして、「思ったよりも運用業務に時間がかかっているから、業務設計を見直したほうがいいな」とか「プロジェクトマネジメントに時間がかかっているが今月は立ち上げ月だから問題ない範囲だな」などと考えます。

従来方法の課題解決：プロジェクト軸だけでなく、サービス軸、人軸での分析をできるようにしよう

ひとつのプロジェクトだけを見るときには上記のような方法で問題ありませんでした。しかし、「プロジェクト」という単位よりさらに下の作業分類レベルになると、プロジェクトマネージャーが作成した作業項目がプロジェクトによってまちまちでした。

例えば、
・ A社のプロジェクトでは、「月次給与計算」「賞与計算」のようなイベント単位での作業項目（粗い）

・B社のプロジェクトでは、「通勤交通費承認作業」「勤怠集計作業」「変動費取り込み作業」「仮計算」・・のような作業単位での作業項目（細かい）

長年続いているプロジェクトの場合は、過去のプロジェクトマネージャーが作成した作業項目を、プロジェクトマネージャーが代替わりしてもなんとな～く使い続けてしまい（勝手に消してしまうと通年の分析できないという悪影響がでるのでは、という配慮も）、かたや新しいサービスを提供するときには作業項目を増築する、ということを繰り返して今は使っていないものも含めて作業項目がやたら多い・・というプロジェクトも多数ありました。それぞれのプロジェクトで提供しているサービスが違うことは珍しくありませんし、分析したい観点が異なるから作業項目が違う、ということも理解できます。

しかしその結果、複数のプロジェクト同士を比較したいと思ったときに、簡単には比較できないという弊害が生じていました。プロジェクトごとに自由な文言を使っていて粒度も違うため、作業項目の粒度を合わせるのに大変な労力がかかっていました。

作業項目は仕事の中身を表すものであり、弊社でいえば「給与計算」「人事評価運用」「採用システム運用」などサービスラインナップと同等のものです。会社の規模が小さかった頃はプロジェクト数も少なく、マネージャーが各メンバーに一人ずつ聞いていけば事足りていましたが、すでにそんなことでやり切れる規模を超えています。事業経営を考えるうえで、プロジェクトという個社事情を取り除いたうえで、事業部横断で「このサービスは適正な利益が出ているのか？」「〇〇さんはどういうサービスの経験が多いのか？」という判断材料を客観的に得ることは重要であり、ここにテコ入れをしたのが今回の一番の目的でした。

刷新のメリットとデメリット

採用のプロジェクトであればどのプロジェクトでも同じ作業項目を割り当てる、同様に人事労務のプロジェクトであればどのプロジェクトでも同じ作業項目を割り当てる、というように工数管理の作業項目を刷新してみて半年ほどが経過しました。やってみてよかったことや、留意点について述べたいと思います。

▼よかったこと
・業務アサインの軌道修正力が増した
プロジェクトマネージャーの役割を期待してアサインしたメンバーが実は期待と異なる運用系の業務に結構時間がとられていて・・・というようなことがチーム全体で一目瞭然になり、人軸で職位に期待することと実態の比較が容易にできるようになりました。本来職務に集中できるようサポートのメンバーをアサインするなどの軌道修正の判断スピードが上がりました。

・同一サービスに対してプロジェクト間で生産性比較ができるように
同じ作業項目に対してプロジェクト別の稼働時間を集計できるようになったため、処理件数やそのサービスでの売上額と割り算することで、1件当たりの処理時間や時間当たりの売上額といった指標でプロジェクト間比較ができるようになりました。どういった指標が適切なのかは、まだ、事業ごとに分析してみて経営メンバーと議論しながら揉んでいるというステータスですがこういった実際の数字をもって議論ができるようになったことは有意義ですし、一歩踏み出したことで次の課題が見えてくるという感じで進んでいます。

▼考慮しておかなければならないこと
・刷新前との比較、累計はできない
当然といえば当然ですが、作業項目が変わったことで工数入力時のルールを変更しているため、プロジェクト単位より細かな粒度のデータに関しては変更前・後のデータを一律には扱えません。そのため、可能であれば会計年度の区切りや四半期の区切りで切り替えるのがよいと思います。

・作業項目の粒度は細かくしすぎない
統一の作業項目を設けたことにより、従前はより細かい粒度で工数管理していたプロジェクトからすると、新しい作業項目はざっくりしたものに感じられ、システム外で独自に管理をしたくなるということがあるかもしれません。それにより、また独自Excelファイルが増えてメンバーの入力工数も倍に・・というのはなんとしても避けたいところです。この問題に対しては、目線を個別作業の時間からプロジェクトやチームの利益に向けさせることが処方箋になるかな、と思っています。細かい作業単位で仕事目標時間をクリアすること以上に大切なことは、その結果空いた時間でもう1社新しいプロジェクトを担当することやより付加価値の高い提案をして全体の数字に貢献することです。プロジェクト独自のたこつぼを増やさないためにも、作業項目をつくるときにはあくまでも全体の目線で分析したい観点を網羅できていれば大丈夫、と割り切ることも必要です。

まだまだ改善は続きます

以上、人事分野のサービスやっているのに紺屋の白袴状態で増改築カオスに陥っていた工数管理をバージョンアップしてみた話でした。切り替え自体は3か月程度の準備期間でしたが、切り替え後も入力内容をチェックしたり各事業に使いづらい点がないかヒアリングしたり、何かと目を配りながら～6か月後程度は細かなマイナーチェンジを加えながらやっています。1回大手術をやったら終わりというわけではなく、会社全体で見たいものが見えるように、工数入力する人が迷わないように、最適化を考えていくのも自分の仕事だなと改めて。