勤怠管理システム外注の進め方｜要件定義とベンダー選定の判断軸

勤怠管理システムを外部ベンダーに開発委託する意思決定は、業務システムの外注のなかでも難易度が高い部類に入ります。就業規則の運用ルール、複数拠点の締め日、変形労働時間制、法改正への継続対応、給与計算や人事評価との連携——どれか一つでも要件から漏れると、開発中盤で大きな手戻りが発生し、費用も期間も想定の 1.5 倍以上に膨らむことは珍しくありません。

一方で「失敗できない領域だから」と社内で抱え込もうとしても、HR システム開発の経験者が社内にいなければ、要件の網羅性を担保する術がありません。ベンダーに任せきりにすれば、後から「そこは初めから言ってもらわないと」というやり取りが発生し、追加見積が積み上がっていきます。多くの発注者が最初に直面するのは、「何を自分で決めて、何をベンダーに委ねるか」の線引きの難しさです。

この難しさを乗り越える鍵は、外注のプロセスを「要件定義から定着まで」を一枚の設計図として捉え、発注者が押さえるべきポイントを事前にチェックリスト化しておくことにあります。ベンダー選定の巧拙は、選定後のマネジメントで挽回できますが、要件定義の抜け漏れは後から取り返せません。だからこそ、社内整理・RFP・ベンダー選定・契約形態・費用管理の各段階で、発注者側が主導権を握る仕組みが必要です。

本記事では、HR・勤怠管理システムを外注する際の実務プロセスを、発注者視点で解説します。全体像の把握から、HR 固有の要件チェックリスト、RFP の書き方、ベンダー評価の判断軸、契約形態の選択、費用相場と失敗予防策までを一気通貫でまとめました。読み終える頃には、社内キックオフミーティングの議題リストと、来月のマイルストーンが手元に整っている状態を目指します。

HR・勤怠管理システムを外注するとは（外注設計の全体像）

「勤怠管理システムの外注」と一言で表現しても、実際にはパッケージ SaaS の設定代行から、フルスクラッチのカスタム開発まで、複数の選択肢があります。ここで言う「外注設計」とは、要件定義・ベンダー選定・契約・開発・定着までを一貫した設計対象として捉え、発注者側の意思決定と役割分担を事前に組み立てておくことを指します。単に「開発会社にお願いする」ではなく、「どのフェーズで、誰が、何を決めるか」を発注者主導で設計しておくことが、HR・勤怠領域では特に重要になります。

なぜ HR・勤怠領域は他の業務システム外注と比べて難易度が高いのでしょうか。理由は 3 つあります。第一に、就業規則が企業ごとに異なり、システム化された共通仕様が存在しないこと。第二に、労働基準法改正・36 協定・フリーランス新法など、法改正に継続対応する保守設計が必要なこと。第三に、給与計算・人事評価・タレントマネジメントなど連携先が多く、周辺システムとの整合性を保つ設計が求められることです。

外注設計の全体プロセス

HR・勤怠管理システムの外注は、大きく 6 つのフェーズに分けて設計します。

1. 社内整理: 現状の業務フロー、就業規則、既存システムとの連携、課題を棚卸しする
2. RFP 作成: 提案依頼書として要件をまとめ、複数ベンダーに配布する
3. ベンダー選定: RFP 回答を比較し、質問・面談を経て 1 社に絞り込む
4. 要件定義: 選定ベンダーと詳細要件を確定し、仕様書に落とし込む
5. 開発・テスト: 設計・実装・受入テストを進める
6. 定着: 現場への展開、運用フローの浸透、保守フェーズへの移行

このうち発注者側が主導すべきなのは 1、2、3、6 のフェーズです。4 と 5 はベンダー主導で進みますが、発注者側にも意思決定と受入判断が求められる場面が多くあります。

SaaS 導入で足りるケースとカスタム開発が必要になるケース

外注設計を始める前に、そもそも自社の要件がカスタム開発を必要とするレベルなのかを見極める必要があります。以下のいずれかに当てはまる場合はカスタム開発（一部を含む）を検討する余地があります。

• 就業ルールに変形労働時間・裁量労働・フレックスが複雑に混在し、既存 SaaS の設定範囲を超える
• 複数拠点で締め日・集計単位・承認フローが異なり、SaaS の標準機能では表現できない
• 給与計算・人事評価・独自の労務手続きシステムとの連携要件が SaaS の API 制約を超える
• 業界特有の労務要件（医療の当直・製造の三交代・小売のシフト連動）を SaaS が標準サポートしていない

逆に、就業ルールが比較的シンプルで、標準的な打刻・集計・給与連携で足りる場合は、SaaS 導入で十分なケースがほとんどです。まずは現行 SaaS の限界がどこにあるのかを言語化し、その部分だけをカスタム開発で補完する選択肢（後述のハイブリッド構成）も検討してください。

全外注・部分内製・ハイブリッドの発注形態

発注形態には大きく 3 つの選択肢があります。

システム内製化は失敗事例も多く、経済産業省の DX レポートでも、内製化を掲げた企業の多くが「体制構築の失敗」「業務との両立困難」で頓挫していることが指摘されています（経済産業省 DX レポート）。内製の判断は「自社にエンジニアがいるか」ではなく、「継続的な保守・改修を回せる体制と時間を確保できるか」で行うことをおすすめします。

発注前に社内で整理すべき HR 固有の 5 要件

外注設計の成否を決めるのは、RFP を書き始める前の社内整理フェーズです。ここで「何が要件から漏れると危険か」を洗い出しておかないと、ベンダー選定後の要件定義でスコープが膨らみ、費用と期間が想定を超えます。以下では、HR・勤怠システムで特に漏れやすい 5 領域を、"漏れると開発中盤で手戻りが発生する順" に整理します。

就業規則を「システムに落とせる粒度」で棚卸しする

就業規則は文章で書かれているため、そのままではシステム化できません。「所定労働時間は 1 日 8 時間、休憩 1 時間」という記述を、「打刻から休憩差引・残業判定・深夜勤務加算までの計算ロジック」に変換する作業が必要です。この変換作業をベンダー任せにすると、就業規則の解釈が現場運用と食い違い、リリース後に「実際にはこう運用していた」という指摘が現場から上がります。

社内整理の段階で、以下の粒度まで言語化してください。

• 所定労働時間・休憩時間・遅刻早退の扱い
• 残業・休日出勤・深夜勤務の判定条件と手当計算式
• 有給休暇・特別休暇・振替休日の付与ルールと消化順序
• みなし労働時間・持ち帰り残業・在宅勤務の取り扱い

書き出してみると、就業規則には記載されていない「暗黙の運用ルール」が現場に相当数存在することに気づくはずです。この暗黙ルールを可視化することが、要件漏れ防止の第一歩です。

変形労働時間・裁量労働・フレックスの併用パターンを図示化する

多くの企業では、部署や職種によって労働時間制度が異なります。営業部はフレックスタイム制、開発部は裁量労働制、製造部は 1 ヶ月単位の変形労働時間制、という具合です。この併用パターンをテキストで記述するだけでは、ベンダーが要件を誤解する可能性が高くなります。

以下のように、部署 × 労働時間制度のマトリクスを作成し、それぞれの集計単位・清算期間・特別ルールを一覧化してください。

このマトリクスは RFP に添付できる形で整備しておくと、ベンダー選定時の見積精度が上がります。

複数拠点・複数雇用形態の締め日と集計単位

拠点や雇用形態ごとに締め日が異なるケースは、HR・勤怠システムで頻出する落とし穴です。本社は 15 日締め、地方拠点は 20 日締め、パート・アルバイトは月末締めといった運用が並行している場合、給与計算との連携タイミングが複雑化します。

さらに、業務委託契約のフリーランスへの支払管理も勤怠システムに含めるかどうかで、必要機能が大きく変わります。フリーランス新法（正式名称: 特定受託事業者に係る取引の適正化等に関する法律）が 2024 年 11 月に施行され、業務委託先への発注書面の交付や支払期日の遵守が義務化されました（公正取引委員会 フリーランスの取引適正化に向けた取組）。勤怠と業務委託を同一システムで扱う場合、この要件も設計対象に含める必要があります。

給与計算・会計・タレントマネジメント等の連携先システム一覧化

勤怠システムは単独で完結せず、必ず周辺システムと連携します。連携先の棚卸しを怠ると、要件定義の後半で「そのシステムと連携する API がない」「CSV フォーマットが合わない」という問題が発覚します。

以下の観点で連携先を洗い出してください。

• 給与計算: どの給与計算ソフトを使っているか、連携方式（API / CSV / 手入力）、連携頻度
• 会計: 労務費の仕訳連携が必要か、部門別集計のルール
• 人事評価・タレントマネジメント: 従業員マスタの一元管理をどうするか
• 勤怠打刻機器: IC カード、生体認証、モバイル打刻、位置情報打刻の要否
• シングルサインオン: SAML / OpenID Connect などの ID 基盤連携

各連携先について「必須連携」「あれば嬉しい」「将来検討」の 3 段階で優先度を設定しておくと、RFP でオプション要件として提示しやすくなります。

法対応（労働基準法改正・36 協定・フリーランス新法・マイナンバー）の責任範囲

法改正への対応をどこまでベンダーの保守契約に含めるかは、契約時に必ず合意しておくべき論点です。含まれていないと、法改正のたびに追加見積が発生し、想定外の保守コストが積み上がります。

社内整理の段階では、以下を確認してください。

• 労働基準法改正（時間外労働の上限規制など）の対応履歴と、次回改正への備え
• 36 協定の届出管理をシステム内で完結させるか、外部ツール（電子申請）に任せるか
• マイナンバー管理を勤怠システムに含めるか、別システムで分離するか
• フリーランス新法対応（発注書面・支払期日）を勤怠システムのスコープに含めるか

これらの責任範囲を発注前に整理しておくと、RFP の「保守要件」欄が具体化し、ベンダー間の見積比較がしやすくなります。

RFP（提案依頼書）で発注者が伝えるべきこと

社内整理が終わったら、次は RFP の作成です。RFP は単なる要件リストではなく、「複数ベンダーから比較可能な提案・見積を引き出すための設計書」として位置づけてください。書き方が甘い RFP に対しては、ベンダー各社が独自解釈で提案してくるため、後から比較できません。

RFP に必ず含める 10 項目

以下は、勤怠管理システム開発の RFP に含めるべき最低限の 10 項目です。各項目に「なぜ必要か」「書き方が甘いとどう困るか」を添えて解説します。

1. プロジェクトの背景と目的: 現状の課題と、システム刷新で解決したいこと。書き方が甘いと、ベンダーが「機能を作ること」を目的化して提案してしまう
2. 従業員規模と拠点構成: 従業員数・雇用形態別内訳・拠点数と所在地。書き方が甘いと、ライセンス費・拠点別カスタマイズ費の見積がぶれる
3. 勤務形態の一覧: 部署別の労働時間制度マトリクス（前章参照）。書き方が甘いと、想定外の変形労働対応で開発中盤に追加費用が発生する
4. 打刻方式の要件: IC カード・モバイル打刻・生体認証・位置情報打刻の必要性。書き方が甘いと、ハードウェア調達費が見積から漏れる
5. 承認ワークフロー: 申請・承認の階層と、代理承認・エスカレーションのルール。書き方が甘いと、ワークフローエンジンの再設計で工数超過する
6. 36 協定管理・法対応: 対応範囲と、法改正時の保守契約への含有可否。書き方が甘いと、法改正のたびに追加見積が発生する
7. 連携先システム: 給与計算・会計・タレントマネジメント・SSO などの連携方式。書き方が甘いと、要件定義でスコープ拡大する
8. クラウド・オンプレの方針: SaaS・IaaS・自社オンプレのどれで運用するか、セキュリティ要件との整合性
9. スケジュールと予算: 希望リリース時期、初期費用の上限、月額保守費の想定レンジ
10. 選定基準: 提案評価の観点と配点（機能適合度・実績・価格・保守体制など）

機能要件と非機能要件の書き分け

RFP では機能要件（何ができるか）だけでなく、非機能要件（どのように動くか）も明示する必要があります。非機能要件の抜けは、リリース後の運用障害として顕在化することが多いため、要件定義の段階で必ず盛り込んでください。

代表的な非機能要件は以下の通りです。

• 可用性: 月次の稼働率目標（99.5% など）、計画停止の頻度と時間帯
• セキュリティ: 通信・保存データの暗号化、アクセスログの保管期間、脆弱性診断の頻度
• パフォーマンス: 月末締め処理時のレスポンスタイム、同時アクセス数の想定
• バックアップ: バックアップの頻度・保管期間・リストア手順
• 監査対応: 監査ログの取得範囲、外部監査への対応可否

見積を比較可能にするための工夫

複数ベンダーから見積を取っても、内訳の粒度がバラバラだと比較できません。以下の 3 つの工夫で、見積を強制的に比較可能な形に揃えてください。

• 必須機能とオプション機能の分離: RFP で「必須」と「オプション」を明示し、ベンダー側にも同じ区分で見積を要求する
• 段階見積の要求: フェーズ 1（コア機能）・フェーズ 2（拡張機能）・フェーズ 3（将来機能）の 3 段階で見積を要求する
• 保守費用の書式統一: 月額保守費・法改正対応費・障害対応費を項目別に分けて記載してもらう

ベンダー選定の判断軸——発注者チェックリスト

RFP 回答が出揃った後、複数ベンダーから 1 社を絞り込むフェーズに入ります。ここで多くの発注者が陥る失敗は、「実績が多いから」「担当者の印象が良いから」といった定性的な判断で選定してしまうことです。定性的な判断を避けるためには、発注者側が事前に用意した質問リストとチェック項目に基づいて評価する必要があります。

HR 実務理解度を測る 5 つの質問

ベンダーの「HR 実務理解度」を測るには、抽象的な「実績を教えてください」ではなく、具体的なシナリオベースの質問を投げるのが有効です。以下の 5 つの質問を、面談時に必ず投げてください。

1. 変形労働時間制の混在対応: 「営業部にフレックス、製造部に 1 ヶ月単位変形労働時間制が混在するとき、月末締めで残業判定をどう設計しますか？」
2. 複数拠点の締め日対応: 「本社 15 日締め、地方拠点 20 日締めのケースで、給与計算連携をどう分割しますか？」
3. 法改正対応の姿勢: 「直近 3 年間の労働基準法改正で、どの改正にどう対応しましたか？保守契約の範囲でしたか？」
4. API 連携の経験: 「弊社で利用中の給与計算ソフトとの連携経験はありますか？連携方式は API か CSV か、どちらを推奨しますか？」
5. 保守継続実績: 「5 年以上保守を継続しているクライアントは何社ありますか？その中で追加開発を伴ったのは何社ですか？」

これらの質問への回答の具体性で、ベンダーの HR 領域における実装経験の深さが見えてきます。

提案書の品質を見抜くポイント

RFP に対する提案書からは、ベンダーの姿勢と実力を読み取ることができます。以下の 3 点に注目してください。

• 要件への逆質問の質: 良い提案書には「この要件について、以下の解釈で合っていますか？」という逆質問が含まれます。逆質問がゼロの提案書は、要件を深く読み込んでいない可能性があります
• リスク開示の姿勢: 「この要件はスコープ拡大のリスクがある」「この機能はフェーズ分割を推奨」といった正直なリスク開示があるかどうか
• 見積内訳の粒度: 「開発一式 500 万円」ではなく、機能単位・工程単位で内訳が示されているか

過去実績のヒアリング方法

過去実績を確認する際、「導入企業数」だけを聞いても意味がありません。以下の粒度で確認してください。

• 実装領域の粒度: 勤怠のみか、勤怠 + 給与計算連携か、HR 統合か
• プロジェクト規模: 従業員数・拠点数・開発期間・体制人数
• 保守年数: 導入後の保守継続年数と、その間の追加開発の内容

可能であれば、類似規模・類似業種の導入事例を 2〜3 件、担当 PM と面談する機会を要求してください。

コミュニケーション・体制面の確認項目

技術力だけでなく、プロジェクト進行時のコミュニケーション体制も確認しておく必要があります。

• PM の常駐可否: プロジェクト期間中、PM が常駐するかリモートか
• 現場ヒアリング回数: 要件定義時に何回の現場ヒアリングを想定しているか
• 成果物レビュープロセス: 設計書・仕様書のレビュー頻度と承認フロー
• 障害対応窓口: リリース後の障害対応時間帯・エスカレーションルート

契約形態と発注体制の設計

ベンダー選定と並行して検討すべきなのが、契約形態と発注体制の設計です。契約形態の選択は、後工程の柔軟性と発注者の負担に大きく影響します。

準委任 vs 請負——HR・勤怠システム開発ではどちらを選ぶか

外注時の契約形態には、大きく分けて「請負契約」と「準委任契約」があります。両者の違いを整理すると以下の通りです（厚生労働省 労働者派遣事業に係る法令・指針・疑義応答集・関連情報等）。

HR・勤怠システム開発の場合、要件定義フェーズは準委任、開発フェーズは請負というハイブリッド運用が現実的です。要件定義段階では、発注者側も要件が確定しきっていないため、成果物の完成義務を課すのは無理があります。一方、開発フェーズでは要件が固まっているため、請負契約で完成責任を明確化できます。

指揮命令関係と偽装請負を避けるための運用ポイント

外注時に発注者が陥りやすいのが、偽装請負のリスクです。偽装請負とは、契約上は請負・準委任でありながら、実態としてベンダーの技術者に対して発注者が直接指揮命令している状態を指します。

以下の運用ポイントを守ることで、偽装請負のリスクを避けられます。

• ベンダー技術者への指示は、必ずベンダー PM 経由で行う
• 作業場所を発注者オフィスにする場合も、ベンダー技術者の勤怠管理はベンダー側で行う
• 業務内容の追加・変更は、契約書・注文書の修正で対応し、口頭指示で済ませない
• ベンダー技術者の評価・処遇に発注者が関与しない

三者定例で進行を管理する

外注プロジェクトの進行管理は、発注者 PM・ベンダー PM・現場キーマンの三者定例が最も機能します。以下の運用を推奨します。

• 頻度: 週次 1 時間、フェーズ移行時は隔週で 2 時間
• 参加者: 発注者 PM（意思決定権あり）、ベンダー PM、現場キーマン 1〜2 名
• 議題: 進捗確認、決定事項の合意、リスク・課題の共有、次週のマイルストーン
• 議事録: 決定事項と宿題を明確化し、参加者全員で合意する

現場キーマンを定例に巻き込むことで、要件解釈のズレを早期発見でき、リリース後の「聞いていない」を防げます。

費用相場と発注後の失敗を防ぐポイント

費用相場は多くのメディアで解説されているため、本章では相場情報を短く整理した上で、「費用が膨らむ典型パターン」と「発注者としての予防策」に紙面を割きます。

HR・勤怠システム開発の費用構造

勤怠管理システムのカスタム開発費用は、規模・機能により大きく変動します。市場公開情報のなかでは、機能規模別に以下のレンジが示されています（LASSIC「勤怠管理システム開発を外注する費用相場と委託先の選び方」）。

• 最小限（基本打刻・集計のみ）: 200〜400 万円程度
• 標準（申請・承認・有給管理を含む）: 400〜900 万円程度
• 大規模（多打刻方式・複数シフト・API 連携を含む）: 900〜1,800 万円以上
• 年間保守費: 開発費の 15〜20% が市場参考値

これらはあくまで参考レンジです。就業ルールの複雑さ、連携先の数、非機能要件（可用性・セキュリティ）で大きく上下します。HR 統合まで含めた大規模カスタムでは、上記レンジを超えるケースも珍しくないため、必ず複数社から見積を取得して比較してください（費用感の別視点として、開発の発注/外注/依頼/委託の進め方は Ripla「勤怠管理システム開発の発注/外注/依頼/委託方法について」 も参考になります）。

費用が膨らむ 3 つの典型パターン

発注後に費用が想定を超えるケースは、以下の 3 パターンに集約されます。

• 要件追加: 要件定義後に「あの機能も」「この画面も」と追加要望が発生し、追加見積が積み上がる。対策は、初期 RFP でオプション要件まで洗い出し、フェーズ分割で予算を確保しておくこと
• 法改正対応: 保守契約の範囲外で法改正対応が発生し、都度追加費用が発生する。対策は、契約時に「軽微な法改正対応は保守契約に含む」という条項を明記すること
• データ移行: 既存システムからのデータ移行費用が想定以上に膨らむ。旧システムのデータ品質が悪く、クレンジング工数が発生することが多い。対策は、RFP 段階でデータ移行スコープを明確化し、旧データのサンプルをベンダーに提示すること

保守フェーズの契約設計

開発フェーズが終わっても、システムは動き続けます。保守フェーズの契約設計を怠ると、リリース後 1 年目からトラブル対応で発注者が疲弊するケースがあります。以下の 3 点は必ず契約に盛り込んでください。

• 法改正対応の含有範囲: 労働基準法・36 協定・関連法令の改正時の対応工数が保守費に含まれるか
• SLA（サービスレベル合意）: 障害対応の目標時間、システム稼働率の目標値
• 障害対応窓口: 平日日中のみか、24 時間対応か、緊急連絡先の明示

まとめ——外注設計を成功させるための発注者の役割

ここまで、HR・勤怠管理システムを外注する際の実務プロセスを、要件整理から契約・費用管理まで解説してきました。最後に、発注者が実行すべきアクションを時間軸で整理します。明日からの動き方の指針として活用してください。

発注者が最初の 2 週間でやるべきこと

• 現状の業務フローと就業規則の棚卸し（部署別・雇用形態別）
• 現行 SaaS の限界事例と、カスタム開発が必要な機能の明確化
• 部署 × 労働時間制度マトリクスの作成
• 連携先システム一覧の作成と優先度設定
• 社内キックオフミーティングの実施（情シス・人事・現場代表の三者で合意形成）

RFP 送付から契約までのマイルストーン

• 第 1 週: RFP ドラフト作成、社内レビュー
• 第 2 週: RFP を 3〜5 社に配布、質問受付期間を設定
• 第 3〜4 週: ベンダー質問対応、提案書受領
• 第 5〜6 週: 提案書レビュー、上位 2〜3 社との面談
• 第 7〜8 週: 最終選定、契約条件交渉
• 第 9〜10 週: 契約締結、キックオフ

開発フェーズで発注者が主導すべきレビューポイント

• 要件定義書のレビュー（就業規則との整合性を現場キーマンと確認）
• 画面設計・帳票設計のレビュー（実運用のイメージで確認）
• テスト計画・受入テストシナリオの合意（発注者側で受入基準を策定）
• リリース判定会議（機能要件・非機能要件・運用体制の 3 軸でチェック）
• 定着支援計画の合意（マニュアル・研修・問い合わせ窓口の設計）

HR・勤怠管理システムの外注は、要件の複雑さと法対応の継続性という 2 つの難所を抱えています。しかし、社内整理・RFP・ベンダー選定・契約設計の 4 つのフェーズで発注者が主導権を握れば、失敗リスクは大きく下げられます。本記事のチェックリストを手元に置きながら、まずは社内キックオフの議題整理から着手してみてください。