飲食本部と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など）を利用したアーキテクチャが推奨されます。これにより、給与計算に関連する従業員項目の配賦設定なども、プログラムコードを書かずに修正可能となります。

【完全版】給与ソフトからfreee会計への「部門別配賦」と仕訳連携。労務と経理の分断を解決するアーキテクチャ

二段ワークフローの具体的な構築手順

具体的に「入社手続き」を例にとり、フローの構築手順を解説します。

STEP 1：kintoneでの「店舗申請アプリ」の作成

まず、店舗側が入力するkintoneアプリを作成します。必要な項目は、freee人事労務の「従業員追加」に必要な最低限の項目＋飲食本部が管理したい独自項目（制服サイズ、過去の飲食経験など）です。

• 氏名・生年月日・住所（基本情報）
• 振込口座情報（画像添付とテキスト入力）
• 雇用契約内容（時給、交通費支給上限、所属店舗）
• 本人確認書類の添付

STEP 2：承認ルートの設定（店舗→エリアマネージャー→本部）

kintoneの「プロセス管理」機能を使用します。

1. 未処理：店長が入力中
2. エリアマネージャー承認待ち：店舗から提出され、AMが時給設定などを確認
3. 本部労務確認中：最終的な書類不備のチェック
4. 完了（freee連携待ち）：承認がすべて完了し、API連携のフラグが立った状態

STEP 3：freee人事労務へのAPI連携設定

承認が「完了」ステータスになったことをトリガーに、iPaaSやプラグインを通じてfreee人事労務の従業員API（POST /employees）を叩きます。この際、kintoneの「店舗コード」を、freee人事労務の「部門」や「配賦先」に紐づけるマッピング設定を行います。

STEP 4：運用テストとエラーハンドリング

実際の運用では必ずエラーが発生します。代表的なエラーと対処法を事前に設計しておきましょう。

• バリデーションエラー：住所の番地が抜けている、銀行コードが存在しない等。これらはkintone側のフィールド設定で「必須化」や「入力制限」をかけることで未然に防ぎます。
• 重複登録エラー：過去に在籍していたアルバイトが再入社する場合など。freee側のメールアドレス重複チェックに引っかかるため、kintone側で「過去の退職者名簿」と照合するロジックを組むのが理想です。

飲食本部が注意すべきセキュリティと個人情報保護の設計

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完全ガイド