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

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

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

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

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

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

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

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. 就業規則が古いままでも開発を始められますか？

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