・【バックオフィス内製化に伴うID管理と二度手間の多大さ】
グループ会社からの独立に伴うバックオフィス業務の内製化により、少ないリソースで体制構築が急務に。旧システムではアカウント発行やCSVを用いた差分管理（手動比較）に1件あたり30〜40分かかり、従業員にとっても複数システムへのログイン・ID管理が手間となっていた。
・【月末に集中するリマインドと、給与計算の期日を圧迫する勤怠締めの遅延】
打刻修正が後回しにされ月末まで溜まる構造になっており、以前は半数程度の社員へ個別にリマインド連絡を実施。手動でExcel/CSVに書き出した目視チェックなど手動作業に半日以上を費やし、勤怠締めが「2営業日目の午後」までかかり給与計算のスケジュールを圧迫していた。
・【自社独自の休暇管理（年30日付与）のアナログ運用と問い合わせ負荷】
同社は、有給休暇と独自の特別休暇を合わせて入社日に「年間30日」付与する柔軟な制度を持つ一方、旧システムでは休暇残日数が分かりづらく従業員からの問い合わせが頻発。付与作業も目視で1人ずつ手作業で行う必要があり、30分〜1時間かけて対応していた。
・【Slack完結による圧倒的な従業員体験と「日々自動で締まる」運用設計】
日々のコミュニケーションの基盤であるSlack上で出退勤・休憩の打刻や修正、通知の確認までが完結し、別途ログインするストレスや修正の手間を完全に解消できる点。
・【バクラクシリーズ共通IDによる一元管理と圧倒的な開発スピード】
すでに導入していたバクラク申請・経費精算とID管理が一元化され、アカウント発行がわずか5分で完結する点。さらにトライアル中に提出した6件の改善要望が約1ヶ月ですべて機能反映されるなど、開発・サポート体制への圧倒的な信頼感。
・【並行稼働不要・およそ1ヶ月で移行できる設定の簡便さ】
直感的で迷わないUI/UXにより、管理側の初期設定が非常にシンプルで、一般的に発生し得る旧システムとの並行運用期間を設けることなく、およそ1ヶ月でスムーズに本番稼働へ切り替えられる点。
・【Slack自動通知で「日々勝手に締まる」運用が定着。勤怠締めは1営業日午前中に完了】
自動で届くSlack通知からの直接修正機能と日次リマインドにより「毎日勤怠が締まる」運用が定着。従業員数が70名規模へ増加したにもかかわらず、月末の個別リマインドの対象は2〜3名へと激減。給与締めの過密スケジュールにも余裕を持って対応可能に。
・【自社独自の休暇管理が「わずか2分」に短縮。問い合わせもゼロへ】
勤務表画面上で有給休暇・特別休暇の残日数が一目で確認できるようになり、従業員からの問い合わせがゼロに。AIを活用したCSV読み込みにより、複数名の特別休暇付与作業が30分以上から「2〜3分」へ短縮された。
・【自動休憩付与で修正・差し戻しゼロ。管理部門・従業員双方のストレスを解消】
システムの自動休憩設定の活用により、毎月発生していた手動チェックや修正差し戻しが全期間を通じてたった1回に減少。全社統一のバクラク体験により、管理部門・従業員双方の業務負担が劇的に軽減された。
グループ会社からの独立に伴い、経理1名・労務1名という最小限のリソースでバックオフィス業務の内製化に挑んだNstock株式会社。同社では、フルフレックスや年間30日の休暇付与をはじめとする柔軟な働き方を尊重する一方、複数システムにまたがるID管理や、打刻修正が月末に偏ることによる「手動リマインド＆集計作業」が業務を圧迫していました。
特に、打刻漏れの個別追跡や手作業の目視チェックにより勤怠締めが「2営業日目の午後」までずれ込み、タイトな給与計算スケジュールを圧迫していた点や、手作業に頼っていた独自休暇の管理は、バックオフィスの質を落とさずに体制を構築する上での最優先課題となっていました。
こうした「労働基準法を踏まえた確実な勤怠管理」と「Slack完結による圧倒的な従業員体験」を両立し、課題を解決したのが「バクラク勤怠」の導入でした。
旧システムとの並行稼働期間を設けず、わずか1ヶ月ほどでスムーズな本番稼働を実現。日次の自動通知により「日々勝手に締まる」運用を定着させたことで、月末の個別リマインド件数を約20名からわずか2〜3名へと激減させ、勤怠締めを「1営業日の午前中」へと大幅短縮した同社の挑戦。その舞台裏について、経理担当の鈴木様と労務担当の松島様にお話を伺いました。
——バクラク勤怠を導入される前の背景や、当時のバックオフィス体制について教えてください。
鈴木さん： 当社は元々グループ組織の子会社（連結子会社）で、バックオフィス業務（経理・労務）は親会社の組織にお任せしている状態でした。そこから独立するタイミングで内製化を進めることになり、経理担当として私が、労務担当として松島が入社しました。
最初は経理1名・労務1名というミニマムなリソースで業務を回す必要があったため、いかに業務を効率化・自動化できるかが大きな課題でした。また、これまで親会社のサポートを受けていたため、従業員に対して「独立したことでバックオフィスの質が落ちた」と感じさせたくないという強い思いもありました。
松島さん： 以前利用していた勤怠管理システムは、コスト面ではクリアしていたものの、運用面や機能面でいくつかの壁にぶつかっていました。
一つ目は「ID発行とアカウント管理の手間」です。入社者が発生するたびに個別にIDを発行・付与する必要があり、マスターデータとして保持しているCSVとシステムの形式を比較・調整する作業が発生していました。1人分のアカウントを発行・設定するだけで30〜40分ほどかかっていた上、従業員にとっても経理システムと勤怠システムでログインが分かれており、二度手間のストレスを与えていました。
——日々の勤怠打刻や、月末の「勤怠締め作業」ではどのような課題がありましたか？
松島さん： 以前のシステムでは、リアルタイムなエラー検知や日次催促の仕組みがなかったため、打刻漏れや修正が「月末まで後回しになる」ことが常態化していました。
月末になると、対象者をピックアップして個別に連絡を回すのですが、当時は50名ほどの組織規模に対して20名近くに個別リマインドを行っていました。さらに、システムから書き出したCSVをExcelに取り込み、関数で組んだデータを目視でチェックするという極めてアナログな確認作業を行っていたため、リマインドや修正対応だけで半日以上の工数を奪われていました。
鈴木さん： 当社は給与の支払いが「月末締め・翌月15日払い」と非常に短いスケジュールになっています。祝日やゴールデンウィークなどが重なると給与計算に使える日数が極端に少なくなるため、いかに早く勤怠を締められるかが重要な課題であり、負荷でもありました。しかし当時は締め作業が「2営業日目の午後」までかかっており、後ろの給与計算や経理処理を圧迫する大きな原因になっていました。
——Nstock様では「フルフレックス」かつ「年間30日の休暇付与（有休＋自社独自の特別休暇）」という柔軟な働き方を導入されていますが、休暇管理における課題はいかがでしたか？
松島さん： 前システムでは休暇管理画面が別ページに独立していたため、従業員から「自分の有休があと何日残っているか分からない」という問い合わせが頻繁に届いていました。
また、入社日にNstock独自の特別休暇を一括付与する運用の際、前システムでは自動計算や柔軟な一括設定ができなかったため、1人ひとりの有休残日数を目視で確認し、手動で計算して個別に付与登録を行っていました。ミスが許されない作業なので、月初に新しい仲間が入社する日は「必ず出勤する必要があり、集中して30分から1時間作業する必要」がありました。
——リプレイスの検討にあたり、バクラク勤怠を選ばれた決め手を教えてください。
鈴木さん： 私は以前から経理側で「バクラク申請・経費精算」などを利用しており、バクラクのプロダクトに対する圧倒的な信頼感がありました。「実務を深く理解している人が作っている」という納得感があり、勤怠管理機能がリリースされたと聞いた時も「バクラクなら間違いないはずだ」と感じていました。
実際にトライアルを進める中で決定打となったのは、カスタマーサクセス（CS）やサポートチームの対応の速さと的確さ、そして「開発スピードの速さ」です。
松島さん： 他社システムもいくつか比較検討しましたが、管理部門・従業員双方の使いやすさに加え、機能改善のスピードが異次元でした。トライアル期間中の約1ヶ月半の間に、当社から実務上の改善要望を6件お伝えしたのですが、なんとその6件すべてが1ヶ月以内でプロダクトに機能反映されたんです。
特に、勤務パターンに応じた交通費計算の設定や、有休残数の半休同士の組み合わせなど、当社で給与計算ミスを防ぐために不可欠だった要件を伝えたところ、わずか1〜2週間ほどで機能改善が行われました。一般的なSaaS製品では「要望を出しても変わらない」ことが多い中、ユーザーの声に即座に応えてくれる開発姿勢を見て、「このサービスなら安心して運用できる」と確信しました。
——バクラク勤怠の導入によって、日々の勤怠管理や集計作業はどのように変化しましたか？
松島さん： 劇的な変化がありました。まず、勤怠締めにかかるリードタイムが「2営業日目の午後」から「1営業日の午前中」へと大幅に短縮されました。
一番の要因は、日々Slackへ自動で届くリマインド機能と、通知画面から直接修正を行える仕組みです。仮に打刻が漏れていた場合、朝や夕方の指定した時間に「打刻を忘れていませんか？」とSlackに通知が届き、従業員はログインし直すことなくSlack上でそのまま修正を完結できます。労務が手動で追跡しなくても「その日その日で勤怠が締まる」という理想的なサイクルが全社に定着しました。
結果として、従業員数が50名から70名規模へと拡大したにもかかわらず、月末に手動で個別に催促メッセージを送る対象は以前の約20名から「わずか2〜3名」へと激減しました。
鈴木さん： 月末の締め作業が1営業日の午前中で終わるようになったことで、その後の給与計算やチェック工程に十分な時間を割けるようになり、精神的な焦りやリスクが解消されました。
また、「自動休憩付与機能」の導入効果も絶大です。以前は毎月5〜6件発生していた休憩時間の入力漏れやチェック・修正依頼の差し戻しが、システムの自動補正により完全にゼロになりました。現在はフレックスの不足時間が発生していないか確認する程度で、締め完了後のエラーチェック作業はわずか30分程度で完了しています。導入してからこれまで、差し戻しが発生したのは全期間を通じてたった1回だけです。
——休暇管理やID管理の工数はいかがでしょうか？
松島さん： 有給休暇や特別休暇の残日数が勤務表の画面上に分かりやすく常時表示されるようになったため、頻繁にあった従業員からの問い合わせは完全にゼロになりました。
また、特別休暇の付与作業についても外部AIツールと連携したCSV一括登録を活用することで、以前は1人ひとり目視で計算・登録していた作業が、5〜6名の入社者がいる月でも「わずか2〜3分」で完了するようになりました。もう出社して半日から丸1日かかる手作業に追われる必要はありません。
アカウント管理に関しても、バクラクシリーズに統合されたことでID付与にかかる時間が1件あたり30〜40分から「5分未満」へと短縮され、バックオフィス全体の工数が大幅に削減されています。
——新システムへの移行や、社内への定着化で工夫された点はありますか？
松島さん： 実は、導入決定（2月中旬）から本番運用開始（4月1日）まで「わずか1ヶ月ほど」で移行を完了させました。
一般的に、勤怠システムを切り替える際は2〜3ヶ月ほどの準備期間を設け、旧システムとの「並行稼働期間」を挟むことが多いと思います。しかし、バクラク勤怠は初期設定が直感的で分かりやすく、サポートに頼らずとも労務側でスムーズに設定を完了できたため、並行稼働なしで4月1日に一斉切り替えを行いました。
鈴木さん： 従業員への周知も、全社MTGでの簡単な説明と、簡易マニュアル（Slack連携の手順などを記載したもの）を共有しただけです。
導入前は「勤怠システムを入れ替えるのは管理者側の都合であって、従業員にとっては使い勝手が変わって負担になるのではないか？」という懸念が正直少しありました。しかし実際に導入してみると、従業員から「Slackで完結してすごく楽になった」「ログインの手間がなくて助かる」「過去一番忘れずに打刻できている」といったポジティブな声が続々と上がってきました。現場のストレスを減らせたことが何より嬉しかったですね。
——最後に、これからバックオフィス体制の内製化やバクラク勤怠の導入を検討している企業へメッセージをお願いします。
鈴木さん： 勤怠管理システムのリプレイスは「管理者が楽になるだけ」と思われがちですが、バクラク勤怠は現場の従業員体験を劇的に向上させてくれます。特に日常的にSlackを利用している企業や、フルフレックスなどの自由な働き方を取り入れている企業にとっては、圧倒的におすすめできます。
また、すでに経理側などでバクラクを利用しているなら、勤怠もバクラクシリーズで統一することを推奨します。ID管理の一元化やUIの統一感による使いやすさはもちろんのこと、契約手続きや請求受取、問い合わせ窓口が一つにまとまるという、地味ながら強力なメリットを実感できます。そして何より、カスタマーサポートのレスポンスの早さと親身な対応は、システムを運用する上で最大の安心材料になります。
松島さん： 組織が小さいうちは手動運用で乗り切れても、従業員数が増えてくると管理工数は爆発的に増加します。バクラク勤怠を使っていれば、労働基準法をはじめとする法律上遵守すべき勤怠管理の基準をクリアしながら、「自動化の仕組み」を作ることができます。
労務・経理側の設定も、現場の操作も迷わずに運用できる「圧倒的な扱いやすさ」があるからこそ、バックオフィスの貴重なリソースをより本質的な組織づくりや業務改善に投入できるようになると実感しています。
圧倒的な使いやすさで、打刻‧勤怠管理の負担を削減する「バクラク勤怠」を詳しくご説明した資料です。バクラク勤怠が解決できることをご案内しております。
企業の勤怠管理の現状を把握するため、タイムカード以外の方法で自身の勤怠打刻を行う従業員541名を対象に、「勤怠管理に関する実態調査」を実施しました。
今後の企業様の勤怠管理を効率化・生産性向上に活かせるヒントが得られる調査概要になっております。
