勤怠管理システム刷新事例｜Excelデータ移行を止めずに進めた手順

「また集計が合わない」——月末になるたび、勤怠Excelの数字と打刻の記録を突き合わせ、深夜まで電卓を叩く。給与計算の締め切り直前に計算ミスが見つかり、差し戻しが発生する。従業員が50人を超えたあたりから、こうした光景が毎月の恒例になってしまった中小企業は少なくありません。

「そろそろ勤怠管理システムを入れよう」と決断するのは簡単です。けれど、いざ動き出そうとすると、別の不安が押し寄せてきます。創業以来ためてきた過去数年分のExcelデータは、新しいシステムにちゃんと移せるのか。移行作業の最中に勤怠の集計が止まって、給与計算に穴があいたりしないか。自社だけの複雑な就業ルール（変形労働時間やみなし残業、拠点ごとに違う締め日）に、システムが対応できるのか。

勤怠管理は給与に直結する基幹業務です。だからこそ「失敗が許されない」というプレッシャーがあり、最初の一歩を踏み出せないまま、限界を超えたExcelをだましだまし使い続けてしまう。これは、システム刷新を任された管理部門の方が共通して抱える悩みです。

そこで本記事では、従業員50〜150名規模の中小企業が、Excel勤怠管理から専用システムへ刷新したプロジェクトを、要件定義から既存データの移行、並行運用、本稼働までの流れに沿って解説します。とくに、競合記事ではあまり踏み込まれない「既存ExcelデータのData migration（データ移行）」の実務を中心に据えました。

なお、本記事は特定の1社を指すものではなく、私たちが開発会社として中小企業の刷新プロジェクトに関わるなかで見えてきた、典型的な進め方を匿名の代表事例として再構成したものです。具体的な数値は、自社の状況に当てはめて読めるよう、範囲や定性表現で記載しています。「うちでも同じことができるのか」を判断する材料として読み進めてください。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

Excel勤怠管理が限界を迎えた中小企業の実態

刷新の話に入る前に、まずは「どんな会社が、どんな状況で刷新を決めたのか」を整理します。自社の状況と照らし合わせながら読んでみてください。

事例企業のプロフィールとExcel勤怠管理の実態

今回の代表事例は、従業員50〜150名規模、複数拠点を持つサービス業の中小企業です。創業以来、勤怠管理はExcelで運用してきました。よくあるパターンとして、最初は数人分の出退勤を1枚のシートで管理していたものが、人数の増加とともに「従業員ごとのシート」「月ごとのファイル」へと膨らみ、いつの間にか管理ファイルが何十枚にもなっていました。

Excelそのものは優秀なツールです。問題は、長年の運用のなかで誰かが工夫を重ね、複雑な関数やマクロが積み上がっていったことにあります。深夜残業や休日出勤の判定、有給の残日数計算、変形労働時間の集計などを、入れ子になったIF関数やVLOOKUPで処理しているケースは珍しくありません。

そして決定的な問題が、属人化です。これらの関数を組んだ担当者はすでに退職していたり、本人すら「なぜこの式でうまくいくのか」を説明できなくなっていたりします。一箇所セルを直すと別の集計が狂う——そんな状態では、誰も怖くて触れません。

刷新の引き金になった3つの課題

この事例で刷新の決断を後押ししたのは、次の3つの課題でした。

第一に、集計ミスの常態化です。手入力や複雑な関数に頼る以上、人的ミスをゼロにはできません。月末の集計でミスが見つかり、給与計算がやり直しになる。再発防止のためにチェック工数が増え、管理部門の残業がかさむという悪循環に陥っていました。

第二に、属人化と担当者退職のリスクです。前述のとおり、複雑なExcelを誰も触れない状態は、担当者が辞めた瞬間に勤怠管理が止まりかねない時限爆弾です。「あの人しか分からない」業務は、会社の事業継続そのものを脅かします。

第三に、働き方改革への対応です。長時間労働の是正や有給取得の管理が強く求められるなか、労働時間の客観的な把握は企業の責務になっています。厚生労働省の「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」では、使用者は労働者の始業・終業時刻を確認・記録する必要があるとされ、自己申告のみによる把握は原則として認められていません（厚生労働省ガイドライン）。テレワークの併用も広がるなか、Excelの手集計でこの要求に応え続けるのは限界がありました。

これら3つが重なり、「もうExcelでは無理だ」という共通認識が経営層と現場の双方で固まったことが、刷新プロジェクトの出発点になりました。

勤怠管理システム刷新の要件定義で押さえたこと

「システムを入れる」と決めても、いきなり製品を選ぶのは危険です。自社が本当に必要とする条件を整理しないまま導入すると、「結局Excelの方が柔軟だった」という後悔につながりかねません。そこで最初に取り組んだのが要件定義です。

要件定義とは、システムに「何をさせたいか」「何ができている必要があるか」を、漏れなく言葉にして整理する作業です。建物でいえば設計図にあたり、ここが曖昧だと後工程すべてが揺らぎます。

現場ヒアリングで「隠れたExcelルール」を洗い出す

この事例で最も重視したのが、現場ヒアリングによる「隠れたルール」の発掘です。長年Excelで運用してきた会社には、ドキュメント化されていない独自の運用ルールが必ず存在します。

たとえば「特定の部署だけ締め日が違う」「直行直帰の日は手書きメモで補正している」「繁忙期だけ別の集計シートを使う」といった、その場しのぎで生まれた例外処理です。これらは関数の中や担当者の頭の中にしか存在せず、表面的なヒアリングでは出てきません。

そこで、各拠点・各部署の実務担当者に「実際にどう入力し、どう例外を処理しているか」を一つずつ確認しました。現行のExcelファイルを画面に出してもらい、「このセルの数式は何を計算しているのか」を一緒に解きほぐしていく作業です。地味ですが、ここを丁寧にやるほど、後のデータ移行と本稼働でのトラブルが減ります。

パッケージか開発か——要件から導いた選定の判断軸

要件が見えてくると、「市販のパッケージ製品（SaaS）で足りるのか、それともカスタマイズや開発が必要なのか」という分かれ道に立ちます。

中小企業の勤怠管理システムには、すぐ使えるクラウド型のサービスが数多くあります。標準的な就業ルールであれば、こうしたサービスで十分に効率化できます。一方で、システム形式は自社開発・パッケージ・クラウドサービスに分かれており、企業ごとに選択が割れているのが実態です（ITmedia）。

この事例では、複数拠点で締め日が異なり、変形労働時間制とみなし残業が混在するという固有の就業ルールがありました。これらを既製のサービスにすべて吸収させようとすると、設定の限界にぶつかるか、運用側が無理に業務をシステムに合わせる必要が生じます。基幹業務でそれをやると、現場が混乱します。

判断軸は「自社の就業ルールのうち、変えられないもの・変えるべきでないものは何か」でした。法令で守るべき部分や、現場の働き方として合理性のある部分は、システム側で吸収すべき要件です。逆に、過去の惰性で残っているだけの例外は、この機会に整理する対象になります。この切り分けを行ったうえで、固有要件をカスタマイズで対応する方針を選びました。

既存ExcelデータのData migrationをどう設計したか

ここからが、多くの方が最も不安に思う部分です。「過去のデータは失われないか」「移行で集計が狂わないか」——この問いに正面から答えるのが、データ移行（Data migration）の設計です。

データ移行とは、古いシステム（ここではExcel）にためられたデータを、新しいシステムに正しく移し替える作業を指します。単純なコピー＆ペーストではありません。データの形式も構造も違うため、丁寧な設計と検証が欠かせません。

移行対象を決める——「全部」ではなく「何年分・どの項目」を見極める

最初に決めるのは、移行する範囲です。「過去のデータは全部移したい」と考えがちですが、これは多くの場合、得策ではありません。

古いデータほど、当時の運用ルールが今と違っていたり、表記がバラバラだったりして、移行コストが跳ね上がります。一方で、実務で参照されるのは直近のデータがほとんどです。そこでこの事例では、「労働関連の法定保存期間や給与・社会保険の実務上必要となる年数」を基準に、移行する年数を絞り込みました。

項目についても同様です。日々の打刻記録すべてを移すのか、月次の集計結果だけでよいのか。新システムで実際に使う項目を起点に、「移すべきデータ」と「アーカイブとして元のExcelを保管しておけば足りるデータ」を切り分けました。すべてを移そうとせず、目的から逆算して対象を決めることが、移行を現実的な規模に収めるコツです。

Excelデータのクレンジングと項目マッピング

移行対象が決まったら、次はデータクレンジングと項目マッピングです。

データクレンジングとは、データの「汚れ」を落とす作業です。長年運用したExcelには、Excel特有の落とし穴が数多く潜んでいます。代表的なものを挙げます。

• 表記揺れ: 同じ部署名が「営業部」「営業課」「営業」と混在している、氏名の姓名間スペースが全角・半角でバラバラ
• 関数依存セル: 表示されている数字が手入力ではなく数式の計算結果で、そのままでは値として取り出せない
• 欠損値・空白: 入力漏れや「-」「未定」などの非数値が混ざり、システムが読み込めない
• 書式の罠: 日付が文字列として保存されていたり、「8:00」が時刻ではなく文字列扱いになっている

これらを放置したまま移行すると、新システムでエラーが出たり、別人のデータとして登録されたりします。そこで、表記を統一し、数式は値に変換し、欠損は補完または除外のルールを決めて、一件ずつ整えていきます。

クレンジングと並行して行うのが項目マッピングです。これは「Excelのこの列は、新システムのこの項目に対応する」という対応表を作る作業です。たとえばExcelの「出社時刻」列を新システムの「始業打刻」に、「区分」列を「勤務区分マスタ」に紐づける、といった具合です。前段の現場ヒアリングで洗い出した「隠れたルール」が、ここで効いてきます。隠れた例外処理を見落とすと、マッピングに穴があき、移行後のデータがずれるからです。

移行リハーサルとバリデーション

設計とクレンジングが終わっても、いきなり本番移行はしません。必ず移行リハーサル（本番と同じ手順を、テスト環境で予行演習すること）を行います。

リハーサルの目的は、「実際にデータを流し込んだときに何が起きるか」を本番前に把握することです。この段階で初めて気づく問題は多く、たとえば想定外の文字コードでデータが化けたり、特定の従業員だけマッピングが合わなかったりします。本番でこれが起きたら大事故ですが、リハーサルなら何度でもやり直せます。

リハーサルとセットで行うのがバリデーション（検証）です。ここでの合言葉は「移行前後で数字が一致するか」です。具体的には、次のような突き合わせを行います。

• 移行した従業員の件数が、元のExcelの人数と一致するか
• ある月の総労働時間や残業時間の合計が、旧Excelの集計値と新システムの集計値で一致するか
• 有給残日数など、繰り越しのある項目が正しく引き継がれているか

この「合計値の一致確認」こそが、「過去データを失っていない」ことの何よりの証拠になります。検証はサンプル数件で済ませず、全体の合計と、特殊なケース（変形労働の対象者、月をまたぐ深夜勤務など）を狙い撃ちで確認するのがポイントです。数字が合わなければ、原因を特定してクレンジング・マッピングに立ち返り、合うまでリハーサルを繰り返します。

旧Excelと新システムの並行運用から本稼働へ

データ移行の目処が立っても、まだ安心はできません。「移行中に勤怠集計が止まらないか」「現場が混乱しないか」という不安に応えるのが、並行運用から本稼働への切り替え設計です。

なぜ並行運用期間を設けたのか

この事例では、いきなり新システム一本に切り替えるのではなく、旧Excelと新システムを一定期間あわせて動かす並行運用を選びました。並行運用とは、新旧両方の仕組みで同じ業務を走らせ、結果を突き合わせながら新システムの信頼性を確かめる期間のことです。

確かに、一時的に二重入力の手間が発生し、現場の負荷は増えます。新旧両方を動かすぶんコストもかかります。それでも並行運用を選んだ理由は、勤怠が給与に直結する基幹業務だからです。もし新システムだけに切り替えた直後に計算が合わなかったら、給与の支払いに影響します。これは絶対に避けねばなりません。

並行運用期間中は、毎月の締めのたびに旧Excelと新システムの集計結果を突き合わせ、ズレがあれば原因を追います。設定の不備か、運用の慣れの問題かを切り分け、潰していきます。「新システムの数字を信用してよい」という確信が、データで裏づけられた時点で、本稼働への切り替え（カットオーバー、新システムへ完全に移行すること）に進みます。期間をあらかじめ固定するより、「何回連続で数字が一致したら本稼働とする」という合格基準で判断する方が、安全かつ納得感がありました。

現場が止まらない切り替えの段取り

システムがどれだけ正しくても、現場の人が使えなければ意味がありません。むしろ刷新の成否は、現場の受け入れにかかっていると言ってもよいほどです。

導入直後は、操作に不慣れな従業員による入力ミスや問い合わせが増えるのが一般的です。これを見越して、この事例では次のような段取りを組みました。

• 説明会の実施: 全従業員向けに、打刻の方法と「なぜ変えるのか」を伝える場を設けました。「楽になる」という当事者メリットを示すと、協力が得やすくなります
• 拠点ごとのキーパーソン配置: 各拠点に操作に詳しい担当者を置き、現場の小さな疑問をその場で解決できる体制を作りました。すべての問い合わせを管理部門に集中させない工夫です
• ロールバック方針の事前合意: 万一、本稼働後に重大な不具合が出た場合に、旧Excel運用へ一時的に戻す手順をあらかじめ決めておきました。「いざとなれば戻せる」という安心感が、現場が新システムを試す心理的なハードルを下げます

特に最後のロールバック方針は、失敗が許されない基幹業務だからこそ重要です。後戻りできる準備があることが、結果的に前向きな切り替えを支えます。

刷新で変わったこととこれから刷新する企業への学び

ここまで、要件定義からデータ移行、並行運用、本稼働までの流れを見てきました。最後に、刷新によって何が変わったのか、そしてこれから刷新を考える企業が押さえるべきポイントを整理します。

刷新後に変わったこと

この事例で得られた変化を、定性的に整理します（具体的な削減率などの数値は企業ごとに異なるため、傾向として記載します）。

まず、集計工数が大きく減りました。これまで月末に管理部門が手作業で行っていた集計・チェックの多くが自動化され、締め作業にかかる時間と残業が縮小しました。担当者は、数字を作る作業から、数字を見て判断する仕事へと役割を移せるようになりました。

次に、集計ミスが解消に向かいました。手入力と複雑な関数に依存していた部分がシステム化されたことで、人的ミスの入り込む余地が減り、給与計算の差し戻しが起きにくくなりました。

そして、法対応が自動化されました。労働時間の客観的な記録が仕組みとして残るようになり、残業時間の上限管理や有給取得状況の把握が、特別な作業をしなくても日々のデータから把握できるようになりました。働き方改革で求められる客観的な労働時間把握（厚生労働省ガイドライン）に、無理なく応えられる体制が整ったといえます。

加えて、見えにくい効果として属人化の解消があります。複雑なExcelを誰も触れないという時限爆弾が取り除かれ、担当者が代わっても勤怠管理が止まらない状態になりました。

これから刷新する企業が押さえるべきチェックポイント

最後に、この事例から導かれる、再現のためのチェックポイントをまとめます。自社で刷新を検討する際の確認リストとして活用してください。

• 製品選びより先に要件を固める: 自社の就業ルールのうち「変えられないもの」を言語化してから製品やカスタマイズを検討する
• 現場の「隠れたルール」を必ず洗い出す: ドキュメント化されていない例外処理が、後のデータ移行で必ず効いてくる
• 移行対象は目的から逆算して絞る: 「全部移す」ではなく「何年分・どの項目が必要か」を先に決める
• 移行は必ずリハーサルとバリデーションをセットで行う: 「移行前後で合計値が一致するか」が、データを失っていないことの証拠になる
• 基幹業務は並行運用で安全に切り替える: 合格基準を決めて、数字の一致を確認してから本稼働へ進む
• 現場の受け入れ体制を準備する: 説明会・キーパーソン配置・ロールバック方針が、現場が止まらない切り替えを支える

Excelからの刷新は、「過去のデータを失わないか」「集計が止まらないか」という不安が先に立ち、踏み出しにくいプロジェクトです。けれど、要件定義からデータ移行、並行運用、本稼働までを一つずつ段取りすれば、失敗が許されない基幹業務であっても、安全に進めることができます。

自社の就業ルールが複雑で、既製のサービスでは吸収しきれないと感じる場合は、要件の整理段階から開発の知見を持つパートナーに相談すると、移行設計や並行運用の合格基準づくりがぐっと現実的になります。本記事の進め方が、自社の刷新を構想する際の地図として役立てば幸いです。