--- title: "予約システムのスタッフ管理｜指名・シフト・勤怠の3層を分けて設計する" url: "https://www.issoh.co.jp/column/details/16983/" published: 2026-08-26 updated: 2026-08-26 categories: ["Webシステム"] publisher: "株式会社一創" --- # 予約システムのスタッフ管理｜指名・シフト・勤怠の3層を分けて設計する 予約システムの機能一覧には、どの製品にも「スタッフ管理」という項目が並びます。ところが導入後に詰まる場所は現場ごとにばらばらでした。指名予約が1人に偏る、シフトを変えたのに予約枠が閉じない、月末に給与計算へ渡すデータが足りない。原因は、スタッフという言葉が3つの違う対象を同時に指したまま要件を書いていることです。予約システムそのものの機能と種類は[予約システムの機能・種類と開発判断を整理した記事](https://www.issoh.co.jp/column/details/12829/)で扱っています。 ## まとめ｜スタッフ管理を3層に分けて設計を決める 結論から書きます。予約システムのスタッフ管理は、予約枠に割り当てる資源としてのスタッフ、顧客から指名される対象としてのスタッフ、労務管理の対象としてのスタッフという3層に分けると、要件の抜けが見えるようになります。機能一覧を眺めても差が分からないのは、3層がひとつの項目名にまとめられているからでした。 既製サービスで吸収しやすいのが第1層と第2層、越えやすいのが可否が組み合わせで変わる部分と第3層とのデータ受け渡しです。指名予約はスタッフと時間を同時に押さえる二重在庫であり、指名なしの予約を同じ枠で受けると、割り当てを後から決める処理が必要になりました。労務管理は守備範囲の外です。予約が持つのは未来の予定であり、労働時間の記録として求められる客観的な記録には当たりません。 判断の順番はひとつです。押さえる資源を確定し、顧客が誰を選べるかを決め、その情報をどこまで労務側へ渡すかを決める。この順で要件表を書けば、開発会社へ渡す仕様の範囲まで迷わず絞れます。 ## 「スタッフ管理」が指す3つの層と、混ざったまま要件を書くと壊れる場所 ### 割り当てる資源としてのスタッフ、指名される商品としてのスタッフの違い 第1層は、予約が成立するために押さえる資源としてのスタッフです。1件の予約で人が1人ふさがる、という在庫の話に還元されます。誰であるかは問われず、空いている人が1人いれば予約は成立しました。 第2層は、顧客が選ぶ対象としてのスタッフです。指名料の有無にかかわらず、顧客が特定の担当者を選べる時点で、スタッフは資源ではなく選択肢になります。必要な情報も変わり、プロフィール、担当できるメニュー、顧客側に表示する名前が加わりました。Squareのヘルプセンターでも、スタッフごとに顧客向け情報、行うサービス、表示名、予約可能時間を設定すると記載されています。 この2層を分けないと典型的な破綻が起きます。指名なしで受ける導線を残したいのに製品がスタッフ選択を必須にしている、あるいは全員が同じ仕事をする前提の製品を選び担当者ごとの表示を後から足せない。どちらも契約後に判明する失敗でした。 ### 労務管理の対象としてのスタッフを予約側へ持ち込んだときに起きる齟齬 第3層は、労務管理の対象としてのスタッフです。雇用形態、労働時間、休憩、残業、給与。予約は未来の予定を扱い、労務は過去の事実を扱うため、予約システムがこの層へ手を伸ばすと必ずどこかで整合しなくなりました。 10時から11時の予約が入っていたスタッフが、実際には9時50分に出勤して11時20分まで対応した。予約システムの記録は10時から11時のままです。差分を埋める仕組みを予約側へ足すと、実質的に勤怠システムをもう1つ作ることになります。予約システムが持つのは受付可能かどうかという状態だけで、それが有給なのか休憩なのかは持たせない。この線引きが後の設計を軽くしました。 ### 3層を分けて書いた要件表が、製品選定にかかる時間をそのまま短くする 3層に分けた要件表は、そのまま製品への質問リストになります。第1層は予約1件で押さえる資源の数、第2層は顧客が選べる単位と選べない場合の割り当て方、第3層は勤怠システムへ渡す項目です。 | 層 | 管理する対象 | 正となる仕組み | 先に決める項目 | | ------- | -------- | --------- | ----------- | | 第1層 資源 | 予約でふさがる枠 | 予約システム | 同時に押さえる資源の数 | | 第2層 選択肢 | 顧客が選ぶ担当者 | 予約システム | 指名の有無と可否の範囲 | | 第3層 労務 | 労働時間と給与 | 勤怠・給与システム | 予約側から渡す項目 | なお、誰がどの画面を触れるかという権限の設計はスタッフ管理とは別の軸です。役割ごとの閲覧範囲や操作ログの持たせ方は[予約システムの管理者機能を5領域に分けて整理した記事](https://www.issoh.co.jp/column/details/16977/)で扱っているため、そちらと合わせて組み立ててください。 ## 指名予約が生む二重在庫｜スタッフと時間を同時に押さえる枠の設計 ### 指名ありと指名なしを同じ枠で受けると起きる、割り当ての後決め問題 指名しない予約は店舗という単位に対して1件の在庫を消費し、指名する予約は特定のスタッフに対して1件を消費します。この2つを同じカレンダーで受けると在庫の粒度が2階層になりました。割り当て先を決めていない予約が3件あり、その後で指名予約が入ると、3件をどう配分するかによって指名を受けられたり受けられなかったりします。 設計の選び方は3つです。受け付けた時点でスタッフを自動的に確定する方式、確定せずプール枠として持ち当日朝に割り振る方式、指名なしの受付枠数を店舗全体の在庫から切り出す方式。3つ目は在庫を機械的に分けるため実装が軽く、繁忙期に指名枠が食い潰されるのも防げます。指名の比率が読めない立ち上げ期は、この方式から始めると安全でした。 ### Microsoft Bookings の3設定が示す、1対1・N対1・1対Nの分岐 Microsoft Learn の共有予約のサービス定義（ms.date 2024-08-08時点）では、スタッフの割り当てページに3つのコントロールが並びました。「選択したスタッフを予約に割り当てる」では予約が1人のスタッフメンバーでスケジュールされます。「複数のスタッフ」は割り当てられた全員とともにスケジュールされる形をN対1の予約サービスと呼び、全員が出席できる場合にのみ予約を作成できると明記されていました。「顧客が予約のために特定のスタッフを選択できるようにする」が指名の可否そのものです。 さらに、イベントあたりの最大出席者数を設定すると同じ予定時間と同じスタッフを複数の顧客が予約でき、これを1対N予約サービスと呼んでいます。汎用ツールの側でも3つの型を設定で切り替える構造が採られていました。迷う場合は、1件の予約が成立するために同時に必要な人数を数えてください。2人以上ならN対1で、対応できる製品はかなり絞られます。 ### 所要時間がスタッフごとに違うときの枠の刻み方と、バッファ時間の扱い 同じメニューでも経験の浅いスタッフは時間がかかります。長いほうへ揃えれば設定は単純ですが、速いスタッフの稼働に空白が生まれました。目安は差が枠の刻み幅を越えるかどうかで、刻みが30分で差が10分なら揃えて構いません。20分を越えるなら、組み合わせごとに所要時間を持つ設計を検討してください。 片付けや準備の時間は、所要時間とは別に扱うほうが管理しやすくなります。Microsoft Bookings のバッファー時間は、予定が予約されるたびにスタッフの予定表へ余分な時間を追加し、空き時間情報にも反映される仕様です。公式の説明では、予定が午後3時に終了し10分のバッファーが追加された場合、予定表は午後3時10分まで予約不可として表示されます。所要時間を水増しして吸収すると顧客に見える時間が実態と食い違うため、分けて持てる製品を選んでください。 ## 誰でも対応できるわけではない場面｜メニューとスタッフの可否表の作り方 ### メニューとスタッフの可否をマトリクスで持つ場合の行と列の決め方 可否は、メニューを行、スタッフを列に置いた表で持つのが基本形です。Microsoft Bookings ではサービス単位で担当できるスタッフを割り当て、Square 予約ではスタッフ単位で行うサービスを設定すると、製品によって入口が逆になりますが、持っている情報は同じマトリクスでした。 迷うのは行の粒度です。メニュー名をそのまま行にすると改定のたびに表を作り直すことになります。担当できる技能を束ねて行にし、メニューから技能を参照する二段構えにすれば、メニューが増えても可否表は変わりません。ただし二段構えを標準機能で持てる既製サービスは限られるため、メニュー数が20を越えて改定が多いなら追加開発の検討対象になります。 列の粒度も確認してください。個人ごとに持つと入退社のたびにメンテナンスが発生し、ランクで持つと同じランクの中の例外を表現できません。ランクで既定値を決めて個人ごとの例外を上書きする形が扱いやすく、これを製品側で表現できるかを確かめてください。 ### 資格の期限で可否が変わる場合の持たせ方と、製品の設定を越える兆候 医療、介護、整備、教育。資格や講習の有効期限で担当可否が変わる業種では、可否表に時間軸が加わります。持たせ方は、可否表の各セルに有効期間を持たせるか、スタッフ側に有効期限を持たせて可否を計算するかの2つです。前者は直感的な代わりに、資格が複数のメニューに関わると更新漏れが起きます。後者を既製の予約システムで表現できることはまずありません。期限管理は外に置き、期限が近づいた時点で可否表を書き換える形へ落としてください。 可否の要件が製品の枠を越えるときには、はっきりした兆候が出ます。ひとつ、組み合わせごとに所要時間や価格が変わる。ふたつ、可否が期間や時間帯で変動する。みっつ、複数のスタッフを組み合わせないと成立しないメニューがある。1つだけなら回避策が取れます。所要時間の差はメニューを分割して登録し、期間変動は運用で書き換え、複数スタッフはN対1に対応した製品を選ぶ。ただし2つ以上が重なると回避策が互いを打ち消し合い、メニュー数が実運用に耐えない規模まで膨らみました。Microsoft Bookings ではサービスの数を50に制限する必要があると公式に記載されており、分割による回避には上限がある点も見ておいてください。 ## シフト表と予約枠のどちらを正とするか｜同期の方向で決まる運用負荷 ### 確定シフトを取り込む方式と、予約を先に受けて人を配置する方式の差 シフト表を正とする方式では、確定したシフトを取り込み、出勤しているスタッフの時間だけを予約可能枠として開きます。人員計画が先にあり、そこから売上機会を作る業態に向いた形です。決めるのは取り込みの経路と頻度で、経路はCSVの手動取り込み、API連携、予約システム側での直接入力という三択になりました。手動取り込みは初期費用がかからない代わりに、急な変更が反映されるまでの空白が生まれます。当日の欠勤で予約を止めたいなら、当日分だけは予約システム側から直接止める経路を残してください。 逆に、予約が先に入り、その予約に合わせて人を配置する業態もあります。訪問サービス、士業の相談、法人向けの打ち合わせなど、需要が読みにくく単価が高い領域です。必要人数が決まらないためシフトの確定が直前になり、労務側の計画が立てにくくなりました。この形を選ぶのは、1日あたりの件数が読める場合に限ってください。 実務では両方向の組み合わせが最も多く見られます。基本のシフトは月次で流し込み、当日の受付停止だけは予約システム側で操作する。この折衷が動くかどうかは、取り込み済みの枠を手で上書きできるかにかかっていました。デモの段階で、取り込んだ枠を1件だけ閉じてみてください。 ### 4カ月先まで枠を自動生成する製品実装から読み取れる、先行期間の設計 どこまで先の枠を開けるかは、実装の負荷と運用の安心感が釣り合う地点で決めます。サロン向けのリザービアでは、その月を含む4カ月分の店舗の受付時間が毎月1日に自動更新される仕組みが採られています。同時に受付を開始する人数を制限できることも公式に記載されていました。 この4カ月という数字自体が正解というわけではありません。読み取るべきは、枠の生成を毎月の定時処理として持ち、そこから先は開けないという割り切りです。受付期間を無制限にすると、遠い将来の予約が入ってからシフトが変わり、調整の連絡が発生しました。自社の受付期間は、シフト確定のサイクルから逆算してください。外部カレンダーとの同期方式は[カレンダー連携の同期方式を3つに分けて比較した記事](https://www.issoh.co.jp/column/details/16973/)で扱っています。 ## 予約システムのシフト機能が勤怠管理にならない理由と、分担の線引き ### 始業終業の記録として求められる方法と、予約実績が満たさない部分 厚生労働省が平成29年1月20日に策定した労働時間の適正な把握のためのガイドラインでは、使用者は労働者の労働日ごとの始業・終業時刻を確認し記録することが求められています。方法として原則に挙げられているのは、使用者が自ら現認して確認し適正に記録するか、タイムカード・ICカード・パソコンの使用時間の記録等の客観的な記録を基礎として確認し適正に記録するかのいずれかです。 予約システムが持っているのは、予定された対応の開始時刻と終了時刻でした。予約が1件も入らなかった時間帯も労働時間ですし、予約が延びた分も労働時間になります。同ガイドラインは自己申告制による場合についても、労働者への説明、必要に応じた実態調査と所要の労働時間の補正を求めています。シフト情報を自己申告の代わりに使う運用は、この補正の仕組みを持たない限り成立しません。 ### 予約システムと勤怠システムを結ぶときに渡す項目と、渡さない項目 分けたうえで、両者をどうつなぐかを決めます。渡す方向は、シフト情報が勤怠側から予約側へ、実績の一部が予約側から勤怠側へ、という二方向になりました。 | 方向 | 渡す項目 | 渡さない項目 | | -------- | --------- | -------- | | 勤怠から予約へ | 出勤予定の時間帯 | 雇用形態・時給 | | 予約から勤怠へ | 対応件数・指名件数 | 顧客の個人情報 | | 予約側で持たない | 実打刻の時刻 | 休憩・有給の理由 | 渡さない項目を先に決めるのが要点です。予約システムに時給が入ると給与計算の一部が予約側へ流れ込み、権限の設計まで巻き込みます。顧客の個人情報を勤怠側へ渡すと、勤怠システムが個人情報を扱う仕組みになりました。集計値だけを渡す形に留めれば、双方の責任範囲は明確なままです。 ### 指名料や歩合の計算を予約システム側で持つべきかどうかの判断材料 指名の事実は予約システムにしかなく、給与計算は勤怠・給与システムにあるため、どちらで計算するかの正解が定まりません。計算式が変わる頻度が高いなら変更しやすい側に、売上額や商品販売が絡むなら販売データを持つ側に置くのが整合します。実務としては、予約システムは指名の有無と件数までを確定させ、金額の計算は外へ出す形が扱いやすいと考えています。ただしサロンのように歩合が給与構造の中心にある業態では、予約・カルテ・販売が1つの製品に統合されている前提で設計が組まれました。業態特有の要件は[サロン管理システムの機能範囲と選び方をまとめた記事](https://www.issoh.co.jp/column/details/16076/)で扱っています。 ## 既製サービスのスタッフ管理が止まる条件と、越えたときに取る選択肢 ### スタッフ数がプラン階層に乗る構造と、店舗をまたぐ応援勤務の扱い 多くの予約サービスでは、登録できるスタッフ数がプランの階層に組み込まれています。増員そのものは数分で終わりますが、階層をまたぐ人数に達した瞬間、月額が一段上がる構造でした。見落とされるのは繁忙期だけの増員で、年に2カ月のために上位プランを年間契約することになりかねません。プラン階層と機能の対応は[予約管理システムを3タイプに分けて比較した記事](https://www.issoh.co.jp/column/details/16964/)で扱っています。 もうひとつが応援勤務です。既製サービスの多くは店舗を単位としてスタッフを紐づけるため、1人が複数店舗に所属する形は、店舗ごとに別アカウントを作る形で回避されがちです。この回避策には、同じ人が2店舗で同時刻に予約を受けられてしまう、指名の履歴が分断される、プラン上のスタッフ数が実人数の倍で数えられるという副作用が同時に効きました。エリアマネージャーのように店舗を横断する役割があるなら、閲覧範囲も先に決めておいてください。 ### 予約と同時に設備や部屋も押さえる要件が、標準の枠設計を越える理由 スタッフに加えて機器や部屋も同時に押さえないと成立しない予約があります。歯科のチェア、整備工場のリフト、スタジオの機材。予約1件が消費する在庫が2つ以上になりました。標準の枠設計はスタッフ1人に1つのカレンダーを持つ形が前提であり、2つ目の資源が加わると、両方が空いている時間だけを計算する処理が要ります。 しかも資源ごとに所要時間が違う場合、たとえば施術は60分でも機器の占有は40分といった要件になると、標準機能ではまず表現できません。同時に押さえる資源が2つ以上あり、かつ占有時間が違う。この2条件が重なった時点で、既製サービスの設定だけでは着地しないと判断して構いません。 ## 既製品のままで運用できる4条件と、開発へ切り替える3つの境界線 ### 既製サービスのスタッフ管理のままで運用して差し支えのない4条件 次の4つがすべて当てはまるなら、既製サービスの標準機能で運用して差し支えありません。第一に、予約1件で押さえる資源がスタッフ1人だけであること。第二に、担当できるメニューの可否が個人ごとに固定で、期限で変動しないこと。第三に、スタッフが1つの店舗にのみ所属し、応援勤務が例外的であること。第四に、シフトの確定が月次または週次で、当日の変更が電話対応で吸収できる件数に収まること。 この4条件に収まる事業では、追加開発の費用対効果がまず出ません。製品を選ぶ基準は予約導線や決済のほうへ寄せて構いません。 ### 追加開発へ切り替える3つの境界線と、要件表を渡すときの粒度の決め方 逆に、次の3つのいずれかが中核にあるなら、パッケージへの追加開発か独自開発を検討してください。ひとつめは、予約1件が2つ以上の資源を同時に押さえ、資源ごとに占有時間が異なること。ふたつめは、メニューとスタッフの可否が期限や時間帯で変動し、人手で追いきれない規模であること。みっつめは、1人のスタッフが複数店舗をまたいで稼働し、指名の履歴を横断で持つ必要があること。 たしかめ方は簡単です。3つの条件それぞれについて、いま何件の例外を人手で処理しているかを1週間数えてください。週に10件を越えるなら、その処理は運用の工夫ではなく仕組みの問題です。総額を比べる段階に入ったら、[予約管理システム開発](https://www.issoh.co.jp/service/system/reservation/)のように既製品の限界を前提に要件から設計できる開発会社へ、要件表を持って相談するのが早道になります。 渡す要件表は、層ごとに3列で書きます。第1層は資源と数と占有時間、第2層は顧客が選べる単位と可否の決まり方と例外、第3層は渡す項目と方向と頻度。粒度で迷ったら画面ではなく状態を書いてください。「資格欄を作る」ではなく「資格の有効期限が切れた翌日以降、そのメニューの予約を受け付けない」と書けば、既存機能で済むかどうかを開発会社の側で判断できます。指名の履歴を顧客側と予約側のどちらに持つかは、[予約と顧客を同じIDで持つかどうかを整理した記事](https://www.issoh.co.jp/column/details/16975/)と合わせて決めてください。 ## よくある質問 ### 指名予約に対応していない予約システムでも運用でカバーできますか？ 指名の比率が低く、件数が1日数件までなら運用で回せます。予約時の備考欄に希望する担当者を書いてもらい、管理画面で割り当てる形です。ただし、希望した担当者が埋まっていた場合の確認連絡と、顧客側で空きが見えないための取りこぼしが弱点でした。指名が売上の3割を越えるなら、対応した製品へ切り替えるほうが安く付きます。 ### スタッフのシフトは予約システムと勤怠システムのどちらで管理しますか？ 確定したシフトは勤怠側で管理し、そこから予約システムへ受付可能な時間帯として流し込む形をおすすめします。厚生労働省のガイドラインが原則とするのは、現認による確認か、タイムカードなど客観的な記録に基づく確認です。予約の予定時刻はどちらにも当たらず、勤怠の確定には使えません。 ### スタッフごとに所要時間が違う場合、予約枠はどう設定すればよいですか？ 差が予約枠の刻み幅に収まるなら、長いほうへ揃えてください。刻みが30分で差が10分程度なら、揃えても空きの損失は限られます。差が刻み幅を越える場合は、組み合わせごとに所要時間を持てる製品を選んでください。メニュー自体を分けて登録する回避策もありますが、登録できるサービス数の上限に当たる場合があるため事前の確認が要ります。 ### スタッフが増えると予約システムの費用はどのくらい上がりますか？ 製品によって差が大きく、一律には言えません。共通しているのは、スタッフ数がプランの階層に組み込まれていて、一定人数を越えた時点で月額が段階的に上がる構造です。増員の見込みがあるなら、現在ではなく2年後の人数で月額を比べてください。繁忙期だけ増える事業では、期間限定で増減できるかどうかも差になります。 ### スタッフ管理の要件だけで受託開発を選ぶ判断は妥当ですか？ 妥当になる場合があります。予約1件が複数の資源を占有時間の異なる形で押さえる、可否が期限で変動する、店舗をまたぐ指名履歴を横断で持つ。このいずれかが中核なら、予約画面が単純でもスタッフ管理の要件だけで既製サービスの枠を越えます。逆に、画面の使い勝手だけが不満なら、製品の乗り換えで解決することがほとんどでした。 ## 関連記事 - [予約システムとは？主な機能・種類と、既製サービスで足りない場合の開発判断を解説](https://www.issoh.co.jp/column/details/12829/)：予約システムの全体像から入る場合 - [予約システムの管理者機能｜管理画面の要件を5領域に分けて要件書に落とす](https://www.issoh.co.jp/column/details/16977/)：管理画面の権限や例外処理を決める場合 - [予約管理システムの比較｜3タイプ別の選び方と既製品で足りなくなる境界線](https://www.issoh.co.jp/column/details/16964/)：製品タイプとプラン階層を見る場合 - [予約管理システムのカレンダー連携｜Googleカレンダー運用の限界と同期方式3つの選び分け](https://www.issoh.co.jp/column/details/16973/)：同期方式を決める場合 - [サロン管理システムとは？予約・カルテ・POSを統合する機能と選び方・開発判断](https://www.issoh.co.jp/column/details/16076/)：サロン業態で歩合まで含める場合 --- 出典: [予約システムのスタッフ管理｜指名・シフト・勤怠の3層を分けて設計する]()（株式会社一創）