勤怠管理システム開発の費用と自社開発の判断

01はじめに｜この記事でわかること

要点：この記事では、勤怠管理システムの開発を「作るか買うか」ではなく「どこを作るか」で考えます。3つの作り方、範囲別の費用、3年で見た総額、法令で外せない3点、進め方までを順に見ていきます。Webシステム開発の実案件からまとめました。

「勤怠管理システムを自社用に作りたいのですが、いくらかかりますか」。このご相談は毎月いただきます。ただ、金額をお答えする前に、必ず確認することがあります。「いま困っているのは、打刻ですか。それとも締めの作業ですか」。

ここが分かれ道です。打刻そのもので困っている会社は、じつはほとんどありません。困っているのは、集めたあとの計算と確認です。だとすれば、打刻の仕組みまで作り直す必要はないことになります。

この記事は、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、実際にいただいたご相談と開発案件をもとに書きました。「作らないほうがいい」という結論になる場合も、はっきり書きます。

まずは、勤怠管理システムが何をしてくれるものなのかを動画で押さえておいてください。

02勤怠管理システムとは｜打刻から締めまでの4つの仕事

要点：勤怠管理システムとは、出退勤の記録を集め、就業ルールに沿って計算し、申請と承認を回し、給与計算へ渡すための仕組みです。業務システムのなかでも、法律との結びつきがいちばん強い分野です。

勤怠管理システムの仕事は、大きく4つに分かれます。開発の話に入る前に、この4つのどこが弱いのかを見ておいてください。

• 集める。ICカード、スマートフォン、パソコンのログなどで出退勤を記録します。ここは既製品がとても強い部分です。
• 計算する。所定時間、残業、深夜、休日をルールどおりに集計します。会社ごとの差が出はじめるところです。
• 回す。残業や有給の申請を出し、上長が承認します。承認の経路は組織図によって変わります。
• 渡す。締めた結果を給与計算へ引き渡します。ここが手作業で残っている会社が、いちばん多いです。

ご相談を受けていて感じるのは、1番目で困っている会社はほとんどないということです。詰まるのは2番目と4番目、つまり計算と受け渡しです。それなのに「システムを作り直す」と考えると、1番目まで含めた全体を作る話になってしまいます。

03なぜ勤怠だけ「全部作る」が不利になるのか

要点：勤怠は、労働時間のルールが法律で決まっている分野です。そのルールは数年おきに変わります。全部を自社で作ると、変わるたびの改修費まで自社持ちになります。顧客管理システムのように「会社ごとに正解が違う」領域とは、性格がまったく違います。

あまり語られない違いだと思うので、少していねいに説明します。顧客管理システムは、顧客の捉え方が会社ごとに違うため、既製品が合わないことがよくあります。在庫管理システムも、扱う商品によって数え方が変わります。だから作る価値が出ます。

勤怠は逆です。土台の考え方は法律で決まっています。近年だけでも、これだけ変わってきました。

• 時間外労働の上限規制。厚生労働省の時間外労働の上限規制に関する解説資料のとおり、大企業は2019年4月、中小企業は2020年4月から適用されました。
• 年次有給休暇の取得義務。年5日を確実に取らせる必要があり、取得日数の管理が要ります。
• 記録の保存年限。労働基準法で、賃金台帳などの保存期間が5年（経過措置により当分の間は3年）と定められています。

クラウドサービスを使っていれば、こうした改正への対応はベンダー側が済ませてくれます。自社で全部を作っていると、そのたびに改修の見積りを取り、テストをして、期日までに反映することになります。しかも期日は選べません。

勤怠の開発でいちばん高くつくのは、作る費用ではなく、法改正に追いつき続ける費用です。

04それでもクラウドだけでは回らない会社がある

要点：クラウドサービスが苦手なのは、勤怠そのものではなく前後の工程です。現場の紙をどう取り込むか、締めた結果を独自の給与ルールへどう渡すか。ここが合わないと、Excelでの手作業が残り続けます。

実際にご相談をいただく「合わない」は、だいたい次の4つに収まります。

• 現場が紙や口頭で動いている。建設や運送では、日報や運行記録が先にあり、打刻は後追いです。両者を突き合わせる工程が毎月発生します。
• 案件ごとに時間を分けたい。1日の労働時間を、工事や案件ごとに割り振る必要がある会社です。原価計算とつながるため、勤怠だけでは完結しません。
• 手当のルールが独特。拠点手当、資格手当、夜勤の刻み方など、就業規則に会社独自の条件が並んでいる場合です。
• 拠点で締め日や運用が違う。買収した会社をそのまま運用しているケースでよくあります。1つの設定に寄せられません。

共通しているのは、勤怠の中身ではなく「勤怠の前後」が原因だという点です。だから対処も、勤怠システムそのものを作り直すことではなくなります。

053つの作り方｜クラウド・差分開発・フルスクラッチ

要点：勤怠管理システムの開発には3つの道があります。クラウドをそのまま使う、クラウドを土台に足りない部分だけ作る（差分開発）、すべて作る（フルスクラッチ）です。中小企業でいちばん採用が多いのは、真ん中の差分開発です。

3つの違いを、費用ではなく「誰が何を背負うか」で整理します。外注と内製の判断と同じで、責任の置き場所を先に決めると迷いません。

フルスクラッチが正解になるのは、勤怠が単なる労務管理ではなく、売上や原価と直結している場合です。派遣、警備、設備メンテナンスのように、労働時間そのものが請求の根拠になる業種がこれにあたります。

06例外ルールの数で、選ぶ道はほぼ決まる

要点：判断の目安になるのは、就業規則のなかで「一般的な形から外れているルール」の数です。1個以下ならクラウドで足ります。4個を超えると差分開発、7個を超えるとフルスクラッチが視野に入ります。

ご相談の初回に、必ず就業規則を見ながら例外ルールを数えています。その数と、最終的に選ばれた進め方を並べました。

注目していただきたいのは、フルスクラッチが6%しかないことです。「作りたい」とおっしゃって来られた会社でも、数えてみると2個や3個で収まることがほとんどです。

もうひとつ、数えたあとに検討していただきたい選択肢があります。例外ルールそのものを減らすことです。長年の慣習で残っているだけの手当や締め日の違いなら、就業規則の見直しで整理できる場合があります。開発費をかける前に、社会保険労務士へ一度ご相談ください。

07必ず要る機能と、会社ごとに変わる機能

要点：どの会社でも要る機能は、打刻、集計、申請承認、締め、出力の5つです。会社ごとに変わるのは、割増の計算方法、案件別の集計、他システムへの受け渡し方です。見積りが動くのは、後者だけです。

まず、共通して必要になる機能です。ここはクラウドサービスで十分にそろっています。

• 打刻と修正。記録すること以上に、打刻漏れを本人が直せることが大事です。
• 自動集計。所定内、残業、深夜、休日を分けて積み上げます。
• 申請と承認。残業、有給、振替の申請を、上長がその場で承認できます。
• アラート。上限に近づいた人を、月の途中で知らせます。
• 出力。給与ソフトへ渡す形式で書き出します。

これに対して、会社ごとに変わるのは次のような部分です。販売管理システムとつなぐ場合は、ここに案件番号の受け渡しも入ってきます。

• 案件や工事ごとの時間配分。1日の時間を複数の案件へ割り振り、原価に載せます。
• 拠点別の締めと承認経路。拠点で締め日や承認者が違う場合、経路の設計が必要です。
• 現場データの取り込み。日報や運行記録を読み込み、打刻と突き合わせます。
• 独自の手当計算。就業規則にしか書かれていない条件を、そのまま式にします。

08開発範囲別の費用と期間の目安

要点：目安は、前後工程だけの自動化で60〜150万円、給与や基幹との連携まで含む差分開発で200〜500万円、フルスクラッチで600万円以上です。考え方はシステム開発の費用相場と同じで、画面と連携の数で決まります。

この表で見ていただきたいのは、上2段と下2段の差です。前後工程の自動化までなら、多くの会社にとって現実的な金額に収まります。連携が入った瞬間に、桁がひとつ動きます。

09法改正の追随コストを3年で比べる

要点：初期費用だけで比べると判断を誤ります。3年分の運用費と法改正対応まで足すと、フルスクラッチはクラウドの10倍を超えることがあります。保守・運用費用まで含めて並べてください。

従業員50名の会社を想定した試算です。実際の金額は要件で変わりますので、比率の違いを見てください。

いちばん右の列が、この記事でお伝えしたいことです。金額の差は、そのまま「誰が法改正を追いかけるか」の差になっています。

10法令で必ず押さえる3点

要点：勤怠管理システムを開発するなら、客観的な記録、修正の履歴、保存年限の3点は設計段階で決めてください。あとから足すと、データの作り直しが必要になります。Webシステム開発のなかでも、ここは特に手直しが高くつく部分です。

厚生労働省の労働時間の適正な把握のために使用者が講ずべき措置に関するガイドラインでは、始業・終業時刻の確認と記録、記録書類の保存、責任者による確認が示されています。設計に落とすと、決めることは3つです。

1. 客観的に記録すること。タイムカードやパソコンの使用時間など、本人の申告だけに頼らない記録を残します。自己申告を使う場合は、実態と合っているかを確かめる手順もセットで設計します。
2. 修正の履歴を残すこと。誰がいつ、どの値をどう直したかを残します。監督署の調査でも、労使のやり取りでも、この履歴がすべての根拠になります。
3. 保存年限を決めること。労働基準法では賃金台帳などの保存期間が5年（当分の間は3年）とされています。削除の仕組みまで含めて決めておいてください。

3つのうち、あとから足すのがいちばん大変なのは2番目です。履歴を残していないシステムは、あとから項目を追加しても過去の分は復元できません。

11給与・人事・基幹システムとの連携

要点：連携は多いほど良いものではありません。まず給与への片方向だけを自動化してください。それだけで締めの手作業は大きく減ります。API連携の仕組みを理解しておくと、見積りの読み方も変わります。

よくある連携先を、効果の見えやすい順に並べます。

• 給与計算。締めた結果を給与ソフトへ渡します。片方向で足り、効果がいちばん大きい部分です。
• 人事マスタ。入退社と異動を人事側から受け取ります。二重登録がなくなります。
• 販売・基幹。案件番号を受け取り、時間を原価へ載せます。販売管理システムの導入を同時期に考えているなら、最初から一緒に設計してください。
• グループウェア。予定表と連動させると入力は楽になりますが、優先度は高くありません。

設計で決めるべきことは、じつは1つだけです。「社員情報の正はどのシステムか」。ここが決まっていないと、どちらからでも書き換えられる状態になり、月末に必ず食い違いが出ます。

12開発の進め方｜要件定義から並行稼働まで

要点：進め方は5段階です。勤怠に特有なのは、2段階目のクラウド試用と、最後の並行稼働です。給与に直結するため、1〜2回分の給与サイクルを並べて動かしてから切り替えます。要件定義の進め方とあわせてご覧ください。

勤怠管理システムを導入する5つのステップ

ご相談から本稼働までの流れです。差分開発なら3〜5か月、フルスクラッチなら6か月以上を見ておいてください。

1. 就業ルールの棚卸し。就業規則と実際の運用を突き合わせ、例外を書き出します。ここで「規則には書いていないが現場でやっていること」が必ず出てきます。
2. クラウドの試用。1か月、実際の人数で使ってみます。回るならここで終わりです。回らなかった箇所が、そのまま開発の対象になります。
3. 差分の切り出しと要件定義。回らなかった箇所だけを要件にします。画面が要る部分はワイヤーフレームで先に形を決めます。
4. 開発と連携テスト。先月分の実データを使い、手計算の結果と1円単位で突き合わせます。ここを甘くすると、稼働後に信用を失います。
5. 並行稼働と切り替え。いまのやり方と新しい仕組みを1〜2回の給与サイクル分だけ並べて動かし、差が出なくなったら古いほうを止めます。

2番目を飛ばしたくなる気持ちはよくわかります。ただ、ここを飛ばすと「クラウドでも足りたのに作ってしまった」という結果になりがちです。1か月の遠回りが、数百万円を守ります。

13稼働後12か月で締め作業はどう変わるか

要点：効果は翌月には出ません。むしろ稼働1か月目は作業時間が増えます。運用が慣れる3か月目から下がりはじめ、12か月目には稼働前の3分の1程度に落ち着きます。中小企業のデジタル化で共通して見られる動き方です。

従業員30〜120名の案件について、稼働前から12か月後までの平均を並べました。数字そのものより、形を見てください。

1か月後に作業時間が増えている点を、あらかじめ経営層と共有しておいてください。ここで「失敗だった」と判断されて止まってしまう案件が、実際にあります。

14失敗しやすい3つのパターン

要点：勤怠の開発でつまずく原因は、技術ではなく決めごとです。規則を直さないまま作る、現場を巻き込まない、承認経路を後回しにする。この3つがほとんどを占めます。

• 就業規則を直さないまま作る。実態と規則がずれている状態でシステムに写すと、ずれごと固まります。先に社会保険労務士へ相談し、規則を整えてから設計に入ってください。
• 現場を巻き込まずに決める。管理部門だけで要件を決めると、直行直帰や現場作業の実態が抜けます。稼働後に「押せない」という声が出て、結局紙が復活します。
• 承認経路を後回しにする。誰が誰の申請を承認するかは、組織図そのものです。あとから変えると、権限の作り直しになります。最初に決めてください。

3つに共通しているのは、決めるべき人が決めていないという点です。開発が止まる理由は、技術ではなく合意です。

15相談前に決めておく5項目

要点：相談の前に5項目を紙1枚にまとめておくと、見積りの精度が上がります。人数と雇用形態、例外ルール、締めの手順、連携先、稼働の希望時期です。

1. 人数と雇用形態。正社員、パート、契約社員の内訳を出します。雇用形態の数だけ、計算のパターンが増えます。
2. 例外ルールの一覧。変形労働時間制、独自の手当、拠点差など、標準から外れる項目を書き出します。
3. いまの締めの手順。誰が何日に何をしているかを、時間つきで書きます。ここに自動化できる工程が眠っています。
4. 連携したい相手。給与ソフト、人事システム、基幹システム。どれと、どちら向きにつなぐかを挙げます。
5. 稼働の希望時期。年度替わりや繁忙期を避けると、教育の時間を取れます。

この5項目がそろっていれば、初回の打ち合わせで概算までお伝えできます。特に3番目は、御社にしか書けない情報です。見積りの読み方もあわせて確認しておくと、比較がしやすくなります。

16まとめ｜判断の順番

要点：例外ルールを数える、クラウドを1か月試す、回らなかった部分だけを切り出す、3年分で比べる。この順で考えると、作らない判断も含めて納得のいく結論にたどり着きます。

勤怠管理システムの開発は、機能を並べる作業ではありません。法律で決まっている部分はベンダーに任せ、御社にしかない部分だけを形にする作業です。だから最初の質問が「例外はいくつありますか」になります。

1. 就業規則を開き、標準から外れるルールを数える。
2. クラウドサービスを1か月、実際の人数で試す。
3. 回らなかった部分だけを切り出す。全部を作り直す必要はありません。
4. 初期費用と3年分の運用費を足して比べる。金額の話は、ここで初めてします。

この順番を守ると、「開発しない」という結論になることもあります。それは失敗ではなく、正しい判断です。ZenWeb Japanは2000年創業のPNHグループの一員として、業務システムの開発を日本品質・適正価格でお手伝いしています。作らずに済む方法があるときは、そちらを先にお伝えします。

17よくある質問

1. 勤怠管理システムの開発にはどのくらいの期間がかかりますか？

前後工程の自動化だけなら1〜2か月、給与や基幹との連携を含む差分開発で3〜5か月が目安です。フルスクラッチでは6〜12か月かかります。就業規則の整理に時間がかかる場合は、この前に1〜2か月を足して考えてください。

2. 勤怠管理システムを自社開発するのはやめたほうがいいですか？

全部を作るなら、多くの会社ではおすすめしません。労働時間のルールは数年おきに変わり、その改修費を自社で背負うことになるからです。ただし、クラウドを土台にして足りない部分だけを開発するなら、費用も追随の負担も抑えられます。

3. クラウドではなく開発を選ぶ基準は何ですか？

就業規則のなかで標準から外れるルールが4個を超えるときです。また、労働時間が請求や原価の根拠になる業種では、勤怠と基幹を一体で作る価値があります。まずクラウドを1か月試し、回らなかった箇所を確かめてから判断してください。

4. 開発した後のメンテナンス費用はどのくらいかかりますか？

初期開発費の15〜20%前後が年間の目安です。これとは別にサーバー代とクラウドの月額が発生します。勤怠では法改正への対応が別見積りになることがあるため、メンテナンスの範囲に含まれるかを契約前に確認してください。

5. 就業規則が古いままでも開発を始められますか？

始められますが、おすすめしません。実態と規則がずれたまま作ると、そのずれが固まってしまいます。社会保険労務士に規則を整えてもらってから要件定義に入ると、手直しがほとんどなくなります。