労務コラム

業務効率化を図りたい方に知ってもらいたい「工数管理」のポイント

リモートワークになって、お互いの仕事する姿が見えなくなり、ちょっとした会話を交わす機会も以前より随分と減少しました。「チームの仕事はちゃんと進んでいるのだろうか」、「部下は今どの仕事に注力しているのだろうか」と、毎日の事実情報を集めるのにも管理者はやり方を変更せざるを得なくなりました。

これまで勤怠管理をシステム化していた企業も一日の勤務時間を把握するだけにとどまらず、勤怠管理の一歩先、「工数管理」によって実態を把握したいというニーズも増えてきています。このニーズの根幹にある心理はダイエットや受験勉強と一緒で、まずは現状を可視化することで、次の行動を明らかにしたいということにあります。これって大事ですよね。

本日は、「工数管理」の重要性を当社の事例を交えてご紹介します。

工数管理の目的とは

工数管理の目的について、皆さんはどのようにお考えでしょうか。
私は、作業工数を把握することの大きな目的の一つは、「より短い時間でできないか」、「より大きな利益をもたらすサービスや顧客はどのあたりなのか」等々、様々なことを考えて仕事の軌道修正を図り、「より大きな成果を生み出すことに注力することである」と考えています。

当社のビジネスは、顧客の人事業務をコンサルティングしたり、採用活動や給与計算の実務部分を受託するような形態のため、「労働力=商品」となります。この性質上、一般的な企業よりも人件費が占める割合が多いため、工数管理をすることがとても重要です。

人件費は、ざっくりいうと人件費単価と稼働時間の掛け合わせですので、稼働時間の把握というのは大変重要です。稼働時間が想定よりかかりすぎてしまうと収支が圧迫されます。これはわかりやすいかと思いますが、一方で、稼働時間の圧縮を追求し、利益率が高ければ高いほどいいのかというと必ずしもそうでもありません。というのも、時間短縮はサービス品質の低下に繋がる可能性があるからです。いくら稼働時間が短くなって利益率が高くなっても、顧客満足度が下がってしまっては、ビジネスとして成立しません。業務内容を見直すうえでは、そういったリスクをはらんでいないのかチェックをしていく必要もあります。

そのため、どのプロジェクトのどんな作業に何時間という粒感で、勤怠システムの出社時刻・退社時刻の登録を行う際に表示されるプロジェクト&作業リストに作業時間を分単位で入力してもらうことがポイントです。

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

これまでの手法と課題

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

具体的には下記のような粒度の違いです。

  • A社のプロジェクトでは、「月次給与計算」、「住民税」のようなイベント単位での作業項目(粗い)
  • B社のプロジェクトでは、「通勤交通費承認作業」、「勤怠集計作業」のような作業単位での作業項目(細かい)

また、長年続いているプロジェクトの場合、過去のプロジェクトマネージャーが作成した作業項目を、プロジェクトマネージャーが代替わりしてもなんとなく使い続けてしまい、かたや新しいサービスを提供するときには作業項目を増築する、ということを繰り返して今は使っていないものも含めて作業項目がやたら多い…というケースもありました。

それぞれのプロジェクトで提供しているサービスが違うことは珍しくありませんし、分析したい観点が異なるから作業項目が違うということも理解できます。

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

作業項目は仕事の中身を表すものです。当社でいえば、「給与計算」、「人事評価運用」、「採用システム運用」などサービスラインナップと同等のものです。会社の規模が小さければプロジェクト数も少なく、マネージャーが各メンバーに一人ずつ聞いていけば事足ります。ところが、従業員が増えてくると個別ヒアリングは現実的ではありません。

事業経営を考えるうえで、プロジェクトという個社事情を取り除いて、事業部横断で「このサービスは適正な利益が出ているのか?」、「〇〇さんはどういうサービスの経験が多いのか?」という判断材料を客観的に得ることは重要です。
当社では、ここにテコ入れをすることが今回整理した目的でした。

解決方法とその振り返り

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

よかったこと

業務アサインの軌道修正力が増した

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

同一サービスに対してプロジェクト間で生産性比較が実現した

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

考慮しなければならないこと

刷新前との比較、累計はできない

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

コード設計のコツは、分析の観点で整えること

作業項目の粒度は細かくしすぎない

プロジェクト間で統一の作業項目を設けたことにより、従前、今よりも細かい粒度で工数管理していた方からすると、新しい項目はざっくりしたものに感じられしっくりこないということもあるでしょう。中にはシステム外で独自に管理をしたくなるという人が居るかもしれません。それにより、また独自のExcelファイルが増えてメンバーの入力工数も倍になって…というのはなんとしても避けたいところです。この問題に対しては、個別作業の時間把握からプロジェクトやチームの利益にメンバーの目線を向けさせることが処方箋になるでしょう。

細かい作業単位で仕事目標時間をクリアすること以上に大切なことは、効率化により生み出された時間を有効に使えているかどうか、ということです。例えば、もう1社新しいプロジェクトを担当することや、より付加価値の高い提案をして全体の数字に貢献することです。

部分最適のKPIで満足してしまわないよう、作業項目をつくるときにはあくまでも全体の目線で分析したい観点を網羅できていれば大丈夫、と割り切ることも必要です。

また、細かすぎる作業項目は、それぞれの正確な時間を取得することが難しく、「測定しきれない」という壁に当たりやすいということもつけ加えておきます。負担感から適当な稼働時間の申告になってしまっては本末転倒です。

作業の手段ではなく作業の目的から考える

時々見かける例として、「電話」、「メール」、「会議」など、仕事の手段で時間を把握しようとしてしまうケースがありますが、当社では、手段で取得するのではなく業務の目的によって整理することにしています。電話の時間が少なすぎる、メールの時間が長すぎる、という分析やマネジメントではなく、提案のための時間が適切に確保されているか、というような観点で見ていきたいためです。
これは実績時間と計画時間を比較する際のメリットにもなります。
計画の単位としては、「メール」、「会議」などの手段ベースの時間ではなく、「プロジェクトマネジメント」、「追加提案」等の目的ベースで稼働計画を立てているからです。

終わりに

DXという言葉が流行ったこともあり、業務効率化を図りたいと考える方が増加しました。しかし、効果の薄い部分にシステムやRPAを導入しても意味がありません。工数管理をするということは、どこから手を付けるべきなのかを明らかにすることになります。

当社の場合は、既に自社システム導入して長い年月が経過していたこともあり、工数の作業コード変更の準備に3ヶ月もかかりました。変更後も入力内容をチェックしたり各事業に使いづらい点がないかヒアリングしたり、何かと目を配りながら、半年程度は細かなマイナーチェンジを加えながらやっています。

社内で使い続けてもらうためには、1回大手術をやったら終わりというわけではなく、会社全体で見たいものが見えるように、工数入力する人が迷わないように、最適化を考えていくのも大切なことです。事例としてご参考になれば幸いです。

当社では、EHRという勤怠管理システムの中で工数管理を実現するとともに、給与計算をはじめとした様々な人事労務の業務をご支援しています。

今回のコラムのように工数を管理していくには、まずは勤怠管理をシステム化しデータが必要なタイミングですぐに抽出できるようにすることから始まります。その抽出したデータを分析するためには、導入をする際にやりたい分析を明らかにし、それを踏まえたシステム設計をすることが重要です。

当社では企業様のご要望に合わせてオーダーメイドでご支援プランをご提案しておりますので、まずはお気軽にご相談ください。

この記事を書いた人

経営企画室 リーダー
SIer、クラウドERP開発企業を経てレジェンダ入社。前職でのシステム導入対応やレジェンダでの人事領域のアウトソーシングなど、これまでのキャリアではもっぱらプロジェクト型の業務を経験してきた。2020年より経営企画に従事し、ルールに則り工数をつける側からルール設計しデータ分析する立場へ。

お問い合わせフォーム(お客様用)

※営業ご担当者様のお問い合わせはこちら

お問い合わせフォームの推奨ブラウザ以下の通りです。
Edge (最新ver)/Chrome (最新ver)/Firefox (最新ver)/Safari (最新ver)/Internet Explorer 11

お問合せフォームで送信できない場合は「こちら」よりメールにてご連絡ください。
担当より折り返しご連絡させていただきます。