kintoneシフト管理の設計方法｜希望収集・調整・勤怠突合まで崩れない構成

kintoneでシフト管理を作るとき、最初に考えやすいのはシフト表です。

日付、スタッフ名、勤務開始、勤務終了、休憩、店舗、メモ。

これらをレコードにして、カレンダー表示や一覧で見れば、シフト表らしい画面は作れます。

しかし、実務で困るのは、シフト表を表示できないことではありません。

本当に崩れやすいのは、次のような状態です。

• シフト希望の提出形式が人によって違う
• 希望は集まるが、必要人数や職種条件と照合できない
• 調整中のシフトと確定シフトが混ざる
• 確定後の変更が口頭やチャットで流れる
• 変更前後、承認者、理由が残らない
• 外部スタッフやアルバイトにkintoneライセンスを持たせるか迷う
• スマホ入力、権限、本人確認の設計が曖昧になる
• シフト予定と勤怠実績が突き合わない
• 給与計算に渡す値が、シフト予定なのか勤怠実績なのか分からない

kintoneでシフト管理を作るなら、最初に設計すべきなのは「カレンダー表示」ではありません。

希望提出、必要人数、調整、確定、変更申請、勤怠突合を、どのアプリとどの状態で分けるかです。

kintoneシフト管理で最初に決めるべきなのは、シフト表の見た目ではなく、「希望・計画・確定・変更・実績をどこで区切るか」です。

この記事では、kintoneでシフト管理を崩れにくい業務システムとして設計する方法を整理します。

kintone勤怠管理の設計方法はこちら
kintoneスケジュール管理の設計方法はこちら

先に結論：シフト管理は「希望」「計画」「確定」「実績」を分ける

kintoneでシフト管理を作るとき、シフトアプリ1つでも始めることはできます。

ただし、現場で使い続けるなら、最初から次の情報を分けて考えます。

分けるもの	1レコードの意味	役割
シフト希望	1人が提出する勤務可否・希望時間	スタッフ側の希望を集める
必要人数・条件	1日、1時間帯、1店舗の必要配置	現場側の必要条件を示す
シフト計画	調整中の仮配置	希望と必要人数を見ながら作る
確定シフト	公開してよい勤務予定	スタッフに通知し、勤怠予定に渡す
変更申請	1回の交代、休み、時間変更	確定後の変更理由と承認を残す
勤怠実績	実際に働いた時間	打刻や勤務実績と突き合わせる
突合結果	予定と実績の差分	遅刻、早退、未打刻、延長を拾う
連携ログ	外部フォーム、勤怠、給与への連携結果	取込・反映漏れを確認する

シフト表は、業務の中心ではあります。

しかし、シフト表だけを作っても、希望収集、調整、変更、勤怠突合は残ります。

シフト管理をkintone化する目的は、きれいな表を作ることだけではありません。

誰がいつ出られるのか。

どの時間帯に何人必要なのか。

誰が最終的に確定したのか。

確定後に何が変わったのか。

実際に働いた時間と合っているのか。

ここまで追えるようにすることです。

kintoneだけでシフト管理をする限界

kintoneは、シフト管理にも使えます。

ただし、シフト管理専用ツールではありません。

標準機能だけで始める場合、次のような限界を先に理解しておく必要があります。

論点	kintone標準だけで起きやすいこと
表形式の入力	Excelのように日付×スタッフの表で一括調整しづらい
カレンダー表示	複数スタッフ、時間帯、店舗を見やすく表示しづらい
外部スタッフ	シフト提出だけの人にもライセンスが必要になる場合がある
スマホ入力	入力項目が多いと、スタッフ側の提出率が落ちる
権限管理	本人に自分の希望だけ見せる設計が必要になる
調整履歴	口頭変更やチャット変更が履歴に残りにくい
勤怠突合	打刻実績や給与計算と分けて設計しないと二重管理になる

テクバンの記事でも、kintoneのみでシフト管理する場合のライセンス費用や標準カレンダー表示の見づらさが課題として整理されています。

テクバン：kintoneでシフト管理をする4つの方法

ここで大事なのは、「標準機能だけでは無理」と短絡しないことです。

小さなチームで、スタッフ全員がkintoneユーザーで、シフトパターンが単純なら、標準機能だけでも十分に始められます。

一方で、スタッフ数が多い、外部スタッフがいる、店舗や職種が多い、シフト表をExcelのように触りたい、確定後の変更が多い場合は、外部フォームやプラグインを前提にした方が現実的です。

条件	推奨方針
社内メンバーだけ、人数が少ない	kintone標準の一覧・カレンダーから始める
希望提出者が多い	外部フォームやスマホ入力を検討する
表形式で調整したい	krewSheetなど表型プラグインを検討する
カレンダー上で直感的に動かしたい	カレンダー系プラグインを検討する
勤怠・給与までつなげたい	勤怠管理・給与ソフトとの境界を先に決める

シフト管理は「標準機能で作るか、プラグインを入れるか」ではなく、「誰が入力し、誰が調整し、どこで確定し、何と突き合わせるか」で設計します。

希望提出・調整・確定を分ける

シフト管理で最初に分けるべきなのは、希望と確定です。

希望は、スタッフが出せる日や時間です。

確定は、責任者が現場条件を見て決めた勤務予定です。

この2つを同じフィールドで上書きすると、後から調整の経緯が分からなくなります。

情報	置き場所	設計意図
希望勤務日	シフト希望アプリ	スタッフが提出した元情報を残す
希望時間帯	シフト希望アプリ	出られる時間、出られない時間を分ける
希望理由・メモ	シフト希望アプリ	学校、家庭、掛け持ちなどの事情を必要な範囲で残す
必要人数	必要人数アプリ、またはシフト計画アプリ	店舗、職種、時間帯ごとの必要配置を持つ
仮配置	シフト計画アプリ	調整中の案として扱う
確定シフト	確定シフトアプリ、または状態で区別	スタッフへ公開してよい勤務予定にする
変更履歴	変更申請アプリ	確定後に何が変わったか残す

シフト希望アプリには、次の項目を持たせます。

フィールド	型	設計意図
提出者	ユーザー選択、またはスタッフID	誰の希望かを明確にする
対象月	日付、文字列	月単位で希望を集める
勤務希望日	日付	出勤可能日を持つ
希望開始・終了	時刻	希望時間帯を扱う
出勤可否	ドロップダウン、チェック	出勤可、不可、要相談を分ける
希望店舗・現場	ドロップダウン、ルックアップ	配置先の候補を持つ
職種・スキル	ドロップダウン、複数選択	レジ、厨房、リーダー、資格などを持つ
メモ	文字列	必要最低限の補足を残す
提出状態	ステータス	未提出、提出済み、差し戻しを扱う

必要人数アプリには、次の項目を持たせます。

フィールド	型	設計意図
店舗・現場	ルックアップ	どこに必要かを示す
日付	日付	必要人数の単位にする
時間帯	ドロップダウン、時刻	朝、昼、夜、または開始・終了で分ける
必要人数	数値	最低限必要な人数を持つ
職種別必要数	数値、テーブル	役割別の不足を見られるようにする
優先条件	テキスト	ベテラン必須、資格者必須など
登録者	ユーザー選択	誰が必要人数を決めたかを残す

シフト計画アプリには、次の項目を持たせます。

フィールド	型	設計意図
対象日	日付	シフトの単位にする
スタッフ	ユーザー選択、スタッフマスタ	誰を配置するか
店舗・現場	ルックアップ	どこに配置するか
開始・終了	時刻、日時	勤務予定時間を持つ
勤務区分	ドロップダウン	通常、応援、研修、休みなど
状態	ステータス	調整中、確定、公開済み、変更中など
参照希望	関連レコード	元の希望とつなぐ
確定者	ユーザー選択	誰が確定したか
確定日時	日時	いつ公開可能になったか

希望、必要人数、計画を分けると、シフト管理は少し複雑になります。

しかし、後から見たときに、なぜその人がその日に入っているのかを説明できます。

シフト管理は、単なる予定表ではありません。

現場の必要条件と、スタッフの希望を調整した結果です。

外部スタッフ入力とライセンス問題

シフト管理では、kintoneの利用者とシフト提出者が一致しないことがあります。

社員はkintoneを使っている。

一方で、アルバイト、パート、外部スタッフ、派遣スタッフはkintoneを普段使わない。

この場合、シフト提出のためだけに全員へkintoneライセンスを持たせるかが問題になります。

入力方法	向いているケース	注意点
kintoneユーザーとして入力	社員、常勤スタッフ、管理者	ライセンス費用と権限設計が必要
外部フォームで入力	アルバイト、外部スタッフ、短期スタッフ	本人確認、重複提出、編集方法を設計する
CSVで一括取込	既存Excel運用から移行する初期段階	最新版管理と取込ミスに注意
管理者が代理入力	少人数、電話・紙提出が多い現場	管理者負荷と入力ミスが残る

トヨクモの記事では、FormBridgeとkViewerを使い、kintoneライセンスを持たない人の登録・閲覧を扱う考え方が紹介されています。

トヨクモ：FormBridge×kViewerで作成したカレンダーから出勤管理

外部フォームを使う場合は、入力できることだけで満足しない方がよいです。

次の設計が必要です。

設計項目	決めること
本人識別	メール、スタッフID、認証、ワンタイムURLなど
提出期限	いつまで提出できるか
再提出	何回まで、どの状態まで編集できるか
入力チェック	日付、時刻、重複、対象月、店舗の制御
確認方法	本人が提出内容を見返せるか
管理者通知	未提出、重複、異常値を誰に知らせるか
権限	他人の希望や確定シフトを見せない

外部スタッフに見せる画面は、社内管理画面とは分けます。

スタッフには、希望提出、自分の確定シフト、変更申請だけ見せる。

管理者には、全体の不足、調整状況、未提出、未承認を見せる。

この分離ができないまま、全員に同じkintone画面を見せると、権限と操作性の問題が出ます。

表形式・カレンダー・プラグインの使い分け

シフト管理では、画面の見え方も重要です。

ただし、1つの表示形式ですべてを解決しようとしない方がよいです。

表示形式	向いている作業	苦手な作業
kintone標準一覧	未提出、未承認、不足などの絞り込み	日付×スタッフの一覧性
kintone標準カレンダー	日付ごとの予定確認	大人数、複数時間帯、複数店舗の表示
表形式プラグイン	Excelライクなシフト調整	権限、外部スタッフ入力、確定後変更の設計
カレンダープラグイン	ドラッグ操作、色分け、時間帯確認	希望収集や承認履歴そのもの
外部フォーム	スマホ提出、外部スタッフ入力	全体調整、責任者確認
勤怠管理システム	打刻、実績、給与連携	希望収集や現場ごとの柔軟な調整

kintone公式ヘルプでは、アプリのレコードをカレンダー形式で表示する使い方が説明されています。

kintoneヘルプ：kintoneでスケジュールを管理するには

ただし、標準カレンダーは、シフト調整専用画面ではありません。

「誰がいつ入るか」をざっくり見るには使えます。

しかし、日付×スタッフ×時間帯×店舗を一度に調整する用途では、表形式やカレンダー系プラグインの方が向くことがあります。

krewのシフト管理シナリオでも、Excelライクな見た目で希望入力や出勤数・休日数の集計を行う考え方が紹介されています。

krew：シフト計画から調整までの業務を効率化

ここで大事なのは、プラグインを入れる前にデータの単位を決めることです。

決めること	理由
1レコードを1人1日シフトにするか	勤怠突合や個人別表示に影響する
1レコードを1店舗1時間帯にするか	必要人数と不足確認に影響する
希望と確定を同じアプリで扱うか	変更履歴と承認の見え方に影響する
休みをレコード化するか	休日数や希望不可日の管理に影響する
変更申請を別アプリにするか	確定後の履歴管理に影響する

画面は後から変えられます。

しかし、1レコードの単位は後から変えづらいです。

シフト管理では、見た目より先にデータモデルを決めます。

変更申請と承認を設計する

シフト管理で一番混乱しやすいのは、確定後の変更です。

「明日出られなくなった」

「AさんとBさんで交代した」

「1時間だけ延長した」

「急に応援勤務が必要になった」

こうした変更が、口頭、LINE、Slack、紙メモで流れると、確定シフトと実際の勤務がずれます。

変更申請アプリには、次の項目を持たせます。

フィールド	型	設計意図
申請者	ユーザー選択、スタッフID	誰が変更を出したか
対象シフト	関連レコード、ルックアップ	どの確定シフトを変えるか
変更種別	ドロップダウン	休み、交代、時間変更、店舗変更、追加勤務
変更前	文字列、参照項目	元の勤務予定を残す
変更後	日時、時刻、スタッフ	変更したい内容を持つ
交代相手	ユーザー選択、スタッフID	交代の場合に使う
理由	テキスト	承認判断と履歴に使う
承認者	ユーザー選択	店長、責任者、人事など
状態	プロセス管理	申請中、承認済み、差し戻し、却下、取消
反映状態	ドロップダウン	確定シフトへ反映済みか

kintoneのプロセス管理を使うと、申請、承認、差し戻しを状態として扱えます。

kintoneヘルプ：プロセス管理と組み合わせると便利な設定

状態は、次のようにシンプルに始めます。

状態	意味	次の行動
下書き	本人が入力途中	本人が申請する
申請中	責任者の確認待ち	責任者が承認または差し戻す
交代相手確認中	交代相手の同意待ち	相手が承諾する
承認済み	確定シフトに反映してよい	管理者または自動処理が反映する
差し戻し	内容に不備がある	本人が修正する
却下	変更を認めない	理由を残して終了する
取消	本人が取り消した	履歴として残す

確定後のシフトを直接編集できる人は、絞ります。

全員が確定シフトを編集できると、シフト表はすぐに壊れます。

本人は変更申請を出す。

責任者は承認する。

承認済みの変更だけが確定シフトへ反映される。

この流れにします。

勤怠実績・給与連携との突合

シフトは予定です。

勤怠実績は、実際に働いた記録です。

この2つを混ぜると、給与連携で間違えます。

データ	役割
シフト希望	スタッフが出られると言った予定
確定シフト	会社が勤務予定として決めたもの
勤怠実績	打刻や承認を経て実際に働いた時間
給与連携値	給与ソフトに渡す確定値

給与に使うのは、原則として勤怠実績です。

シフト予定は、あくまで予定です。

ただし、シフト予定は勤怠実績のチェックに使えます。

突合で見る差分	例
未打刻	シフトはあるが出勤打刻がない
予定外勤務	シフトがないのに勤務実績がある
遅刻	予定開始より実績開始が遅い
早退	予定終了より実績終了が早い
延長	予定終了より実績終了が遅い
店舗違い	予定店舗と実績店舗が違う
休憩不足	予定または実績に対して休憩が足りない

前回の勤怠管理記事でも整理した通り、勤怠は給与・労務に直結します。

kintone勤怠管理の設計方法はこちら

シフト管理側では、予定と実績の差分を拾うところまでに留めるのが現実的です。

給与計算、割増、控除、社会保険、税計算は、給与ソフト側の責任範囲に残します。

突合アプリを作る場合は、次の項目を持たせます。

フィールド	型	設計意図
対象日	日付	日次で照合する
スタッフ	ユーザー選択、スタッフID	誰の差分か
確定シフト	関連レコード	予定を参照する
勤怠実績	関連レコード	実績を参照する
差分種別	ドロップダウン	未打刻、遅刻、早退、延長など
差分時間	数値	何分ずれているか
確認状態	ステータス	未確認、本人確認中、上長確認済み、人事確認済み
対応メモ	テキスト	理由や処理方針を残す

突合結果は、すべて人事が見る必要はありません。

軽微な差分は上長確認で足りるかもしれません。

給与に影響する差分だけ、人事や給与担当に回す設計にします。

権限設計：スタッフには見せる範囲を絞る

シフト管理では、スタッフ本人に見せたい情報と、管理者だけが見る情報が違います。

kintoneでは、アプリ、レコード、フィールドの単位でアクセス権を設定できます。

kintoneヘルプ：アクセス権の設定

シフト管理では、次のように役割を分けます。

役割	見える範囲	操作できること
スタッフ本人	自分の希望、自分の確定シフト、自分の変更申請	希望提出、変更申請、確認
店長・現場責任者	担当店舗の希望、計画、確定、変更	調整、確定、承認、差し戻し
エリア責任者	複数店舗の不足、応援、人員バランス	店舗間調整、応援配置
人事・労務	勤怠突合、例外、締め前確認	確認、差分処理、給与連携前チェック
システム管理者	設定、連携、ログ	アプリ設定、フォーム連携、プラグイン設定

注意すべきなのは、希望メモや変更理由です。

家庭事情、学校、体調、掛け持ちなど、個人情報に近い内容が入ることがあります。

全スタッフに見せる必要はありません。

フィールド単位で隠す、自由記述を減らす、選択肢化するなどの設計が必要です。

情報	権限上の注意
希望メモ	店長・人事以外には見せない
休み理由	最小限にする、または選択肢化する
他スタッフの希望	原則見せない
確定シフト	必要範囲だけ公開する
勤怠差分	本人、上長、人事に限定する
給与連携結果	人事・給与担当に限定する

シフト表は共有したい。

しかし、希望や理由は共有しすぎない。

このバランスを、最初から設計します。

一覧と通知は「未提出・不足・変更」を中心に作る

シフト管理で見るべきなのは、全シフト一覧だけではありません。

管理者が見たいのは、問題があるところです。

一覧	対象
今月の未提出	希望提出期限を過ぎても未提出のスタッフ
必要人数不足	店舗・時間帯ごとに必要人数を下回っている
職種不足	資格者、リーダー、特定職種が足りない
調整中シフト	まだ確定していないシフト
公開待ち	確定済みだがスタッフへ未通知
変更申請中	承認待ちの交代、休み、時間変更
突合差分あり	予定と勤怠実績がずれている
給与連携前確認	差分確認が終わっていない勤務

通知も、例外に絞ります。

通知タイミング	宛先	内容
提出期限前	スタッフ	シフト希望の未提出
提出期限後	店長	未提出者一覧
必要人数不足	店長、エリア責任者	どの店舗・時間帯が不足しているか
シフト確定時	スタッフ	自分の確定シフト
変更申請時	店長	承認待ち
交代相手確認時	交代相手	承諾依頼
勤怠差分発生時	店長、人事	予定と実績の差分

通知文面は、行動に直結させます。

「シフトが更新されました」だけでは弱いです。

「6月後半の希望が未提出です」「6月18日 18:00-22:00のレジ担当が1名不足しています」「変更申請が3件承認待ちです」のように、次の行動が分かる通知にします。

よくある失敗パターン

kintoneシフト管理でよくある失敗は、シフト表を作ることに寄りすぎることです。

失敗	起きること	対策
希望と確定を同じ項目で上書きする	元の希望が分からなくなる	希望、計画、確定を分ける
シフト表だけ作る	未提出、不足、変更、勤怠突合が別運用になる	例外一覧と変更申請を作る
外部スタッフ全員をkintoneユーザーにする	ライセンス費用と管理工数が増える	外部フォームや閲覧画面を検討する
自由記述で希望を集める	集計や調整ができない	日付、時間、可否、店舗を構造化する
確定後も直接編集できる	変更理由と承認者が残らない	変更申請を通す
カレンダー表示だけに頼る	大人数や複数店舗で見づらくなる	表形式、一覧、プラグインを使い分ける
勤怠実績と混ぜる	給与連携で予定と実績が混ざる	シフト予定と勤怠実績を分ける
権限を後回しにする	他人の希望や理由が見えすぎる	本人、店長、人事で見せる範囲を分ける

特に危ないのは、Excelのシフト表をそのままkintoneに移すことです。

Excelの列を再現すれば、見た目は近くなります。

しかし、シフト提出、未提出確認、不足確認、変更申請、勤怠突合は整理されません。

Excelの置き換えではなく、シフト業務の流れを設計します。

1週間で始めるならこの順番

最初から全店舗・全スタッフで始める必要はありません。

小さく始めるなら、1店舗、1か月、1種類の勤務区分で十分です。

日程	やること	成果物
1日目	現在のシフト業務を分解する	希望収集、調整、確定、変更、勤怠突合の流れ
2日目	1レコードの単位を決める	希望、必要人数、計画、確定、変更申請のアプリ案
3日目	希望提出フォームを作る	スタッフ入力項目、提出期限、本人識別
4日目	調整画面を作る	不足一覧、表形式、カレンダー表示
5日目	確定・変更申請を作る	承認フロー、変更履歴、通知
6日目	勤怠実績との突合を試す	未打刻、遅刻、早退、延長の確認
7日目	権限と通知を直す	本人、店長、人事の見える範囲

最初の検証では、実データに近いサンプルを使います。

1か月分のスタッフ希望、必要人数、確定シフト、変更申請、勤怠実績を入れてみます。

そこで、未提出、不足、変更、突合差分が一覧で拾えるか確認します。

シフト管理は、入力画面だけ試しても不十分です。

月末の勤怠確認まで通して試す必要があります。

実装前チェックリスト

kintoneシフト管理を実装する前に、次の項目を確認します。

• 希望、計画、確定、変更、勤怠実績を分ける方針がある
• 1レコードを1人1日、1人1勤務、1店舗1時間帯のどれにするか決まっている
• シフト希望の提出期限、再提出、本人確認のルールがある
• 外部スタッフにkintoneライセンスを持たせるか、外部フォームを使うか決まっている
• 必要人数、職種、スキル、店舗条件を構造化している
• 調整中と確定済みの状態が分かれている
• 確定後の変更申請、承認、差し戻し、取消の流れがある
• 変更前後、理由、承認者、承認日時を残す
• 標準一覧、カレンダー、表形式プラグインの使い分けが決まっている
• 本人、店長、エリア責任者、人事、システム管理者の権限が分かれている
• 希望メモや休み理由を見せすぎない設計になっている
• 未提出、不足、変更申請中、突合差分の一覧がある
• 勤怠実績と突き合わせる項目が決まっている
• 給与連携に使う値は、シフト予定ではなく勤怠実績であると整理されている
• 1か月分のサンプルデータで提出から勤怠突合まで試している

このチェックリストで詰まるところが、実装前に決めるべき論点です。

特に、外部スタッフ入力と確定後の変更は後回しにしない方がよいです。

シフト管理は、運用が始まってから例外が増えます。

例外を吸収できる設計にしておくことが重要です。

まとめ

kintoneでシフト管理を作ること自体は難しくありません。

日付、スタッフ、開始時刻、終了時刻、店舗。

これらを入れれば、シフト表は作れます。

しかし、実務で使えるシフト管理にするには、シフト表だけでは足りません。

必要なのは、希望提出、必要人数、調整、確定、変更申請、勤怠突合を分けることです。

kintoneは、希望収集、状態管理、承認、一覧、通知、他業務との接続に強いです。

一方で、外部スタッフ入力、Excelライクな表操作、カレンダー上の直感的な調整、勤怠・給与連携は、外部フォームやプラグイン、専用勤怠システムと分けた方がよい場合があります。

シフト管理をkintoneで始めるなら、まず次の3つを決めてください。

• 希望、計画、確定、変更、実績をどの単位で分けるか
• 外部スタッフやアルバイトにどう入力・確認してもらうか
• 確定シフトと勤怠実績をどう突き合わせるか

この3つが決まっていれば、kintoneシフト管理は現場で使える業務システムになります。

逆に、ここを曖昧にしたままシフト表だけ作ると、未提出、不足、変更、勤怠差分が別運用になり、結局Excelやチャットに戻ります。

シフト管理は、予定を並べる仕事ではありません。

現場に必要な人員を満たしながら、スタッフの希望と実績をつなぐ業務です。