【事例型】飲食本部がkintoneとfreee人事でシフト承認を集約した型（匿名・概念）

多店舗展開を行う飲食企業にとって、店舗スタッフの「シフト管理」は経営の根幹に関わる重要業務です。しかし、現場では「紙やExcelでの管理」、本部は「freee人事労務での給与計算」と分断され、その間をつなぐ「承認プロセス」がブラックボックス化しているケースが少なくありません。

本記事では、kintoneを承認プラットフォームとして活用し、freee人事労務と連携させることで、煩雑なシフト承認と労務管理を完全に統合する実務的なアーキテクチャを解説します。現場の使い勝手を損なわず、本部のガバナンスを強化する具体的な手法を見ていきましょう。

飲食業のシフト管理が抱える「本部と現場の分断」という課題

店舗ごとにバラバラな管理が生む労務リスク

多くの飲食チェーンでは、店長がシフト表を作成し、それをエリアマネージャーが確認、最終的に本部が給与データとして受け取るという流れを汲んでいます。しかし、この過程がアナログである場合、以下のようなリスクが常態化します。

• 36協定違反の事後発覚： シフト確定時点で長時間労働や連勤をチェックできず、給与計算時に初めて違反が判明する。
• 承認の形骸化： LINEやメールで「今月のシフト送ります」「了解」といったやり取りのみが行われ、変更履歴や承認の証跡が残らない。
• 二重入力のコスト： 店長がExcelで作ったデータを、事務担当者がfreee人事労務に手入力する際、膨大な工数と入力ミスが発生する。

汎用シフトソフトで解決できない「承認フロー」と「原価意識」

市販のシフト管理SaaSも優秀ですが、飲食業特有の「本部による厳密な人件費コントロール」を組み込むには、カスタマイズ性が不足することがあります。例えば、「売上目標に対する人件費率（FL比率）が一定を超えた場合、エリアマネージャーの承認を必須とする」といった動的なワークフローの構築は、汎用ソフトでは困難です。

ここで、業務アプリ構築プラットフォームであるkintone（キントーン）をハブに据える意義が生まれます。

kintone×freee人事労務による「シフト承認集約型」アーキテクチャ

全体設計図：現場申請から給与計算までのデータフロー

目指すべきゴールは、現場で入力された「シフト予定」が、上長承認を経て、そのままfreee人事労務の「勤怠データ（予定）」として同期される状態です。

1. 申請： アルバイトがスマートフォン（外部フォーム）からシフト希望を入力。
2. 集約： kintone上の店舗別アプリにデータが集約され、店長が調整。
3. 承認： 店長が承認申請を出し、エリアマネージャーが人件費予実を確認して決裁。
4. 連携： 承認済みデータのみがAPIまたはCSVでfreee人事労務へ。
5. 実績反映： 当日の打刻実績と、kintoneから送られた予定データをfreee上で照合。

このフローを構築することで、経理・労務側は「正しく承認されたデータ」のみを扱えばよくなります。経理業務全体の自動化については、以下の記事も参考にしてください。

楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャ

なぜ「kintone」をハブにするのか？柔軟なワークフローの優位性

kintoneを採用する最大のメリットは、「プロセス管理」機能による柔軟な承認ルートの設定です。飲食業では店舗の異動や、新店オープンに伴う組織変更が頻繁に起こります。kintoneであれば、プログラミングなしで承認ルートを即座に変更できるため、システムの硬直化を防げます。

【実務】kintoneでのシフト承認アプリ構築ステップ

STEP 1：マスタ情報の整理（店舗・従業員・単価）

まず、すべてのベースとなる「従業員名簿アプリ」をkintoneに作成します。ここで重要なのは、freee人事労務の「従業員番号」とkintoneのレコードを紐付けることです。

• 従業員名、所属店舗、従業員番号（freeeと完全一致）
• 雇用形態（アルバイト、正社員）
• 時給単価（人件費計算用）

STEP 2：シフト申請アプリの設計と入力制限

シフト申請アプリでは、1行（1レコード）を「1人×1日」のシフトとして管理するのがデータ連携の基本です。

フィールド構成例：

STEP 3：プロセス管理を活用した「多段承認」の実装

kintoneの「プロセス管理」を有効にし、以下のステータスを定義します。

• 未申請： 店長がシフトを調整中の状態
• 承認待ち： エリアマネージャーが確認中の状態
• 承認済み： 本部確認完了。このステータスのみfreeeへの連携対象とする
• 差し戻し： 予算オーバー等の理由で再調整が必要な状態

外部連携サービスを用いた「アルバイト用申請UI」の構築

アルバイトスタッフ全員にkintoneライセンスを発行するのは、コスト面で現実的ではありません。そこで、「じぶんシリーズ」や「FormBridge（フォームブリッジ）」などの連携サービスを活用します。これにより、スタッフは自分のスマホからkintoneのアカウントを持たずにシフト希望を提出でき、データは直接kintoneに格納されます。

こうした「現場の入力しやすさ」と「本部の管理」の両立は、AppSheetなど他のツールでも検討の余地があります。詳細は以下のガイドを確認してください。

Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

freee人事労務とのデータ連携と給与計算の自動化

API連携による「勤怠管理」への予定データ流し込み

kintoneで「承認済み」となったシフトデータを、freee人事労務の「勤怠（予定）」として取り込みます。これには、freee公式が提供する「freee for kintone」アプリを活用するか、iPaaS（AnyflowやZapier、make等）を利用して自動連携を構築するのが一般的です。

公式ドキュメント参照：
freee人事労務 APIリファレンス（勤怠の更新）などを通じ、kintone上の日付・時間をfreeeの該当従業員のレコードに書き込みます。

エラーを回避するデータクレンジングのポイント

連携時に最も多いエラーは「従業員情報の不一致」です。kintone側で退職処理がなされていない、あるいはfreee側で新入社員の番号が未発行といったケースです。
これを防ぐため、kintoneのルックアップ機能を用いて、freeeに存在する従業員番号以外は入力できないようバリデーションをかけることが実務上の鉄則です。

また、部門別の原価計算を行う場合は、以下の記事で解説している「配賦」の考え方も重要になります。

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

【徹底比較】kintone連携か、専業シフトツールか

導入を検討する際、シフト管理専用SaaS（Airシフト、ジョブメドレー等）と、kintoneによる独自構築のどちらが良いか、比較表にまとめました。

導入時の注意点と運用でよくあるエラー・対処法

スマートフォンからのアクセス制御とセキュリティ

店長やマネージャーが社外からkintoneで承認作業を行う場合、セキュアアクセスやIPアドレス制限の設定が必須です。特に個人情報を含む従業員名簿アプリへのアクセス権限は、「閲覧のみ」「編集不可」など、役割（ロール）に応じて厳密に制御してください。

承認ルート変更や店舗異動への対応

飲食業では店舗の統廃合が頻繁に起こります。kintone上の「店舗マスタ」を更新した際、自動的に関連するシフト申請アプリのルックアップ先や承認ルート（組織・グループ）が更新されるよう、設計段階で「アプリ間連携」を意識することが重要です。マスタの一貫性が崩れると、freee人事労務への連携時に404エラー（リソース未検出）が多発します。

まとめ：データの集約が経営判断のスピードを変える

kintoneとfreee人事労務を軸にしたシフト承認の集約は、単なる「事務作業の効率化」に留まりません。現場のシフト予定がリアルタイムに本部で可視化されることは、人件費という最大のコストをコントロール下に置くことを意味します。

「紙のシフト表を回収する」「Excelを統合する」といった非生産的な時間から解放され、より本質的な「店舗運営の改善」に注力できる環境を整えましょう。システム構成に不安がある場合は、公式のヘルプセンターやAPIドキュメントを参照しながら、まずは1店舗でのスモールスタートから始めることをお勧めします。