課題と効果
課題
- 約3,200名を対象に、入社区分・勤続年数で異なる3〜4パターンの適用ルールを、人事担当者がその都度手作業で判定・通知
- パターンの取り違えによる通知漏れと、負荷の高さによる対応頻度の低さ（月1〜2回）が常態化
効果
- Automation Anywhereによる全自動化で、対象者本人・上長・人事部への通知を条件分岐からメール送付まで一気通貫で実行
- 通知漏れの問い合わせはゼロに。実行頻度を月1〜2回から月10〜15営業日へ引き上げ、削減効果は当初想定の77時間／年から200〜300時間／年規模へ拡大
導入前
3,200名分の複雑な判定を、すべて手作業で
対象となる社員は約3,200名。人事担当者は勤怠システムからデータを取得し、4月入社か中途入社か、勤続1年目か2年目以降かによって異なる年休のカウント基準に照らして未取得者を判定し、本人とその上長へ個別に通知するという作業を、すべて手作業で行っていた。判定パターンは3〜4通りにのぼり、都度人の目で判断する必要があった。
この手作業への依存が、2つの問題を生んでいた。1つは、パターンを取り違えて通知対象から漏れてしまう人的ミス。部署によって通知先が上長Aだったり別の担当者Bだったりする例外ルールも数多く存在したが、これはシステムで一元管理されているわけではなく、部内のローカル資料に書き留められているだけだった。もう1つは、負荷の大きさから手作業での通知が月1〜2回が精一杯という、対応頻度の低さだった。
図：3200名を篩にかける手作業の実態
再設計
「実は違うルールだった」――要件定義で5〜6回覆った仕様
自動化にあたり最も苦労したのは、要件定義そのものだった。年休の付与・カウント基準は、新卒か中途か、勤続1年目か2年目以降かによって異なる。2年目以降は一律で4月1日を起点にカウントする一方、1年目の中途採用者は入社日を起点に1年間をカウントする必要があるなど、細部のルールは現場の人事担当者自身も「自分たちが実際どう運用しているか」を正確に言語化できていない状態だった。
そのため、開発着手から稼働までの間に「実はこうだったんですよ」という仕様変更が5〜6回発生した。言葉だけでのすり合わせでは行き違いが起きるため、時間軸を帯状の図にして「ここからここまでをカウントする、で合っていますか」と一つずつ確認しながら、現場も混乱していたルールを整理し、本当の仕様へとたどり着かせていった。
図：年休カウント起点の違い（要件定義で使った帯状図）
Automation Anywhereで、判定からメール送り分けまでを自動化
構築したRPAは、Azure上の仮想環境で稼働するAutomation Anywhereを中心とした仕組み。勤怠システムから取得したデータを1レコードずつ条件分岐にかけ、対象者ごとに上長を判定したうえで、本人向け・上長向け・人事部向けにそれぞれ異なる文面のメールを自動生成して送付する。
部署ごとに異なる通知先の例外ルールは、Excelの「マスタファイル」に整理し、RPAがそこを参照して自動判断できる形に落とし込んだ。要件定義フェーズでは条件分岐を明確化・簡素化したうえで、テストパターンを網羅的に洗い出し、机上でユーザーと一つひとつすり合わせている。体制としては、PMとして全体管理を担当しつつ、顧客企業側のプロパー社員がPLとして参画、開発を専任1名が担当するという座組みで、2025年8月から9月というタイトな期間の中で要件定義から稼働まで駆け抜けた。
導入後
削減効果は当初想定の77時間から、200〜300時間規模へ
全自動化後、通知漏れに関する問い合わせは、メールサーバーに障害が発生した際を除いて一切来ていない。当初の試算では、月1〜2回の手作業運用を前提に「年間77時間の削減」という数字が見込まれていた。しかし自動化によって処理の負荷そのものがなくなったことで、現在は月の半分以上にあたる月10〜15営業日のペースでチェック・通知を実行できるようになっている。
図：自動化による効果の変化
手作業であればこの頻度を実現すること自体が不可能だったため、実際の削減インパクトは当初の想定を大きく上回り、年間で200〜300時間規模に達している。人事部からは、年休未取得者への対応スピードが上がったことに加え、判定・通知にかかっていた人的な負担がほぼなくなったことへの感謝の声が数多く寄せられている。
次の一手――ツール統合とAIエージェント化への挑戦
同社では、Automation Anywhereに加えてBizRobo、Power Automateも並行して稼働しており、ツールの一本化についても社内で継続的に議論されてきた。ただし、BizRoboで稼働しているのは失敗が許されない基幹レベルの処理が中心であり、オンプレミス型ゆえの安定性を優先し、移行は慎重に見送られている状態だ。
一方で、生成AIをRPAに組み込む検証も始まっている。画面レイアウトの変更に弱い従来型のRPAに代わり、生成AIへのプロンプト指示で柔軟に画面操作を行わせる仕組みの実証が、このチームを実験の場として動き出している。長年にわたり積み重ねてきたグループ全体のRPA支援は、こうした新しい技術検証の受け皿としても広がりを見せている。
