飲食チェーン本部のkintone×freee人事労務連携|店舗申請と本部承認の二段ワークフロー
目次 クリックで開く
多店舗展開を行う飲食企業にとって、従業員の入社手続きや身上変更、退職手続きの管理は、経営のスピードを左右する大きな課題です。店舗数が数十から数百に及ぶと、紙やメール、あるいはチャットツールによる「散発的な申請」が本部労務のキャパシティを圧迫し、給与計算ミスや社会保険手続きの遅延を招く原因となります。
この問題を解決するための現実的な解が、「kintone(キントーン)」を店舗フロント(申請・承認基盤)に置き、「freee人事労務」をバックエンド(マスター・計算基盤)とする二段構成のワークフローです。本稿では、飲食業界の実務担当者が直面する課題を整理し、ツールを最適に組み合わせたアーキテクチャを具体的に提示します。
飲食業界における店舗申請と本部承認の課題
「店舗と本部」の距離が生む労務管理のボトルネック
飲食店では、店長は調理や接客の合間に事務作業を行います。PCを開く時間も限られており、スマートフォンやタブレットから「どれだけ簡単に申請できるか」が重要です。一方で、本部の労務担当者は、不備のないデータを正確な期日までに受け取る必要があります。この「現場の簡便さ」と「管理の厳密さ」のギャップが、多くの企業のDXを阻んでいます。
freee人事労務を全従業員に使わせるのが難しい理由
freee人事労務は非常に優れたプロダクトですが、飲食店の現場運用において以下の2点がハードルとなる場合があります。
- ライセンスコスト:数千人規模のアルバイトを抱える企業では、全従業員にアカウントを付与すると月額コストが膨大になります。
- UIの専門性:多機能ゆえに、初めてシステムに触れるアルバイトスタッフにとっては「どこに何を入力すべきか」が直感的に分かりにくいケースがあります。
そこで、現場での入力インターフェースとしてkintoneを活用し、承認が終わった確定データのみをfreee人事労務に送り込む設計が必要になります。これは、経理業務において「バクラク」と「freee会計」を使い分ける設計思想と共通するものです。
【徹底比較】バクラク vs freee支出管理。中堅企業が「経費精算・稟議」を会計ソフトと分ける本当の理由
kintoneとfreee人事労務を組み合わせる「二段ワークフロー」の概念
二段ワークフローとは、申請のプロセスを「社内の意思決定(kintone)」と「法的なマスター更新(freee)」に分離する考え方です。
フロントエンドとしてのkintone:現場の「使いやすさ」を担保
kintone(サイボウズ株式会社)は、ドラッグ&ドロップで入力フォームを作成できるプラットフォームです。店舗名を選択すると店長名が自動入力されたり、必要な書類(マイナンバーカードや免許証の写真)の添付を必須化したりといったカスタマイズが容易です。また、外部公開フォームツール(トヨクモ株式会社の「じぶんフォーム」等)を併用すれば、kintoneライセンスを持たないアルバイト入社予定者に直接入力させることも可能です。
バックエンドとしてのfreee人事労務:法制度と給与計算の担保
freee人事労務は、蓄積されたデータに基づき給与計算や年末調整、社会保険手続きを自動化します。kintoneから「承認済みデータ」を受け取ることで、本部担当者は手入力から解放され、内容のチェック(監査)に集中できるようになります。
費用対効果:ライセンスコストの最適化
この構成の最大のメリットの一つは、freee人事労務の「給与計算対象外」のスタッフ管理コストを抑えつつ、kintoneで広範囲な情報を収集できる点にあります。kintoneは1ユーザー月額1,500円(スタンダードコース)ですが、店舗ごとに1アカウント共有や、外部フォーム経由での入力を活用することで、数千人のスタッフ情報を管理するコストを大幅に削減できます。詳しい料金体系は、kintone公式の料金ページを確認してください。
【比較】kintone連携ツールによるアーキテクチャの選択肢
kintoneのデータをfreee人事労務へ飛ばすには、いくつかの方法があります。実務で採用される代表的な3つの手法を比較します。
| 連携手法 | メリット | デメリット | 想定される企業規模 |
|---|---|---|---|
| iPaaS(Anyflow, BizteX Connect等) | ノーコードで柔軟なフローを構築可能。他SaaSとも連携しやすい。 | ツール自体の月額費用が発生する。 | 30店舗〜(多店舗展開) |
| freee公式連携プラグイン | 安価で導入が容易。基本的な項目同期に適している。 | 複雑な分岐条件や、特殊な計算ロジックに対応しにくい。 | 10〜30店舗程度 |
| スクリプト開発(API) | 自社業務に100%合わせた完全カスタマイズが可能。 | 開発コストと、仕様変更時のメンテナンスコストが高い。 | 100店舗以上(大規模・独自要件) |
多くの場合、運用変更への柔軟性を考慮し、iPaaS(Anyflowなど)を利用したアーキテクチャが推奨されます。これにより、給与計算に関連する従業員項目の配賦設定なども、プログラムコードを書かずに修正可能となります。
【完全版】給与ソフトからfreee会計への「部門別配賦」と仕訳連携。労務と経理の分断を解決するアーキテクチャ
二段ワークフローの具体的な構築手順
具体的に「入社手続き」を例にとり、フローの構築手順を解説します。
STEP 1:kintoneでの「店舗申請アプリ」の作成
まず、店舗側が入力するkintoneアプリを作成します。必要な項目は、freee人事労務の「従業員追加」に必要な最低限の項目+飲食本部が管理したい独自項目(制服サイズ、過去の飲食経験など)です。
- 氏名・生年月日・住所(基本情報)
- 振込口座情報(画像添付とテキスト入力)
- 雇用契約内容(時給、交通費支給上限、所属店舗)
- 本人確認書類の添付
STEP 2:承認ルートの設定(店舗→エリアマネージャー→本部)
kintoneの「プロセス管理」機能を使用します。
- 未処理:店長が入力中
- エリアマネージャー承認待ち:店舗から提出され、AMが時給設定などを確認
- 本部労務確認中:最終的な書類不備のチェック
- 完了(freee連携待ち):承認がすべて完了し、API連携のフラグが立った状態
STEP 3:freee人事労務へのAPI連携設定
承認が「完了」ステータスになったことをトリガーに、iPaaSやプラグインを通じてfreee人事労務の従業員API(POST /employees)を叩きます。この際、kintoneの「店舗コード」を、freee人事労務の「部門」や「配賦先」に紐づけるマッピング設定を行います。
STEP 4:運用テストとエラーハンドリング
実際の運用では必ずエラーが発生します。代表的なエラーと対処法を事前に設計しておきましょう。
- バリデーションエラー:住所の番地が抜けている、銀行コードが存在しない等。これらはkintone側のフィールド設定で「必須化」や「入力制限」をかけることで未然に防ぎます。
- 重複登録エラー:過去に在籍していたアルバイトが再入社する場合など。freee側のメールアドレス重複チェックに引っかかるため、kintone側で「過去の退職者名簿」と照合するロジックを組むのが理想です。
飲食業 申請種別 × kintoneアプリ設計 × freee人事労務連携ポイント 早見表
前のセクションでkintone×freee二段ワークフローの全体像を説明しましたが、飲食業の申請業務は「店舗スタッフからの申請」と「本部・管理部門での承認処理」の二層構造になっているため、申請種別によってkintoneのアプリ設計とfreee人事労務への連携方式が変わります。以下の表は申請種別ごとの設計指針をまとめたものです。
| 申請種別 | 申請者・申請頻度 | kintoneアプリ設計のポイント | freee人事労務への連携方式 | 飲食業特有の注意点 |
|---|---|---|---|---|
| 有給休暇・特別休暇申請 | 全店舗スタッフ(アルバイト含む)。繁閑差が大きいため月間10〜50件/店舗 | 申請フォームにシフト希望日・理由区分(有給/慶弔/病気)・代替スタッフ手配状況を設ける。モバイルからの申請を前提にフィールド数を10項目以内に絞る。店長承認→本部人事確認の二段階プロセスを標準設定 | freee人事労務のAPI連携またはCSV一括インポートで勤怠データを反映。kintoneの承認完了ステータスをトリガーにMake/Zapierで自動連携する設計が最も運用負荷が低い | アルバイトの有給発生タイミング(半年継続勤務・週所定労働時間)を申請フォームで自動チェックする仕組みがないと、付与前の有給申請を誤承認するリスクがある。入社日と勤務実績から有給残日数を自動計算するフィールドを設けることを推奨 |
| 残業・深夜手当申請 | 主に正社員・時間給スタッフ。閉店後の残業が多い飲食業では日次〜週次で発生 | 残業開始時刻・終了時刻・業務内容・承認者を必須入力に。深夜(22時〜翌5時)の時間帯は自動計算で残業代と深夜割増を分離表示する計算フィールドを設ける | 承認完了後、freee人事労務の勤怠CSVへの追記またはAPI経由での残業時間反映。給与計算締め日(25日等)の3日前までにkintone→freeeへのデータ同期が完了していることを運用チェックリストに含める | 飲食業は法定労働時間の管理が特に重要で、月の時間外労働が45時間・80時間・100時間を超えると36協定の上限規制に抵触する。kintoneのダッシュボードで月累計残業時間を可視化して、本部が各店舗の状況を週次でモニタリングする設計を推奨 |
| 経費精算申請(店舗備品・消耗品) | 店長・副店長。発注・購入の都度発生。月5〜20件/店舗 | 領収書画像アップロード・費目選択(食材費/消耗品費/水道光熱費)・店舗コード・購入日・金額を必須入力に。1万円以上は本部承認を必須とする金額ルールを条件分岐で設定 | freee会計の経費仕訳への連携。kintone承認完了→freee会計のAPI経由で仕訳データを自動作成する。勘定科目マッピングテーブルをkintoneのマスタアプリで管理して、費目選択から勘定科目を自動変換する | 多店舗展開の飲食チェーンでは「店舗コード」が月次の店舗別損益集計のキーになる。freee会計の部門(店舗コード)設定と、kintoneの店舗マスタコードを統一しておかないと、集計時にデータのマッチングエラーが発生する |
| 採用・入退職手続き申請 | 店長・本部人事。採用・退職・雇用条件変更の都度発生 | 氏名・雇用形態・勤務開始日・担当シフト・時給/月給・緊急連絡先・マイナンバー管理番号(マイナンバーは直接保存しない)を登録するアプリ。本部人事の最終承認で雇用確定フラグを立てる | freee人事労務の従業員登録と連携。新規採用承認後にkintoneからfreee人事労務へ基本情報をAPI転送して、社会保険・雇用保険の手続きフローをfreee側で開始する。マイナンバーはfreee人事労務側で管理しkintoneには保存しない | 飲食業のアルバイト離職率は高く、採用・退職が頻繁に発生する。入社から社会保険取得手続きまでの期間を5営業日以内に完了させるSLAを本部人事が管理するKPIとして設定することを推奨。kintoneの申請から手続き完了までのリードタイムを自動計測するフィールドを設ける |
この表で最も設計インパクトが大きいのが「残業・深夜手当申請の自動計算フィールド設計」です。飲食業は深夜営業が多く、残業代と深夜割増の計算を手動で行っている店舗では計算ミスによる未払いリスクが常に存在します。kintoneに残業開始・終了時刻を入力すると深夜時間帯を自動分離して割増率を計算するフィールドを設けるだけで、計算ミスをゼロに近づけられます。このデータをfreee人事労務の給与計算に自動連携することで、給与計算ミスによる労務トラブルを防止する土台が整います。
飲食本部が注意すべきセキュリティと個人情報保護の設計
kintoneとfreeeを連携させる際、最も議論になるのが「個人情報の持ち方」です。
kintone側に個人情報を残さない「クレンジング」の設計
kintoneは非常に便利なツールですが、アクセス権限の設定を誤ると、他店舗のスタッフの個人情報が見えてしまうリスクがあります。これを防ぐために、「freeeへの連携が完了した一定期間後、kintone上の機密情報(マイナンバーや口座番号、住所詳細)を自動で削除またはマスキングする」というクレンジング処理を実装することを強く推奨します。マスターデータはあくまでfreee人事労務に置き、kintoneは「受け皿」に徹する設計です。
権限設定(店舗別アクセス権)の重要性
kintoneの「レコード閲覧権限」を活用し、店長は自分の店舗の申請レコードのみが見えるように設定します。エリアマネージャーは管轄の複数店舗、本部労務は全店舗というように、階層構造に合わせた権限付与が必要です。これは、SaaSアカウント管理における最小権限の原則に基づくものです。
SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ
まとめ:店舗体験と管理精度の両立を目指して
飲食業におけるDXの成功は、本部の効率化だけでなく、「現場の店長がいかに楽になるか」にかかっています。kintoneを申請のフロントに据えることで、店長は直感的な操作で入社手続きを完結でき、本部は正確なデータを自動でfreee人事労務に同期させることができます。
この「二段ワークフロー」の構築は、一見複雑に見えるかもしれませんが、SaaS同士をAPIで適切に繋ぐことで、従来の「紙とExcel」による運用とは比較にならないほどのスピードと正確性をもたらします。まずは特定の店舗からテスト導入し、徐々に拡大していくアプローチをおすすめします。
より高度な自動化を目指す場合は、Google Workspaceなどのグループウェアと連携し、入社時に自動でメールアドレスを発行するなどの拡張も可能です。バックオフィス全体の最適化については、以下のガイドも参考にしてください。
Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド
kintoneとfreee人事労務の二段ワークフローを運用する中で、申請データに含まれる個人情報(口座番号・マイナンバー管理番号)をAPIで連携させる段階では、どのデータを・いつ・どの経路で渡すかの権限設計と操作ログが情シスの確認ポイントになります。自社業務に合わせたAPIアーキテクチャの設計や運用ルールづくりは Claude Code 導入支援 でもご相談いただけます。
kintone業務アプリ・プラグイン活用のご相談
kintoneでの業務アプリ設計や、帳票・連携・自動化を補うプラグインの活用を支援します。現場の運用に合わせたアプリ構成や他システムとの連携まで、具体的な形でご提案します。