JP2022184655A - シフトマッチングシステム - Google Patents

Abstract

【課題】店舗側の都合とアルバイトの希望とをすり合わせ、アルバイトの納得感を充足する、シフトマッチングシステムを提供する。【解決手段】シフトマッチングシステム１は、店長が操作する店長端末3と、複数のアルバイトがそれぞれ所持するアルバイト端末４と、サーバー２とを有し、店長端末３から必要なアルバイトシフト枠の条件としての日時及びポジションについての決定信号が入力されると、サーバー２に保存されたアルバイトデータベースから、これらの条件を満たすアルバイトが抽出されるとともに、サーバー２に保存された時給算出基準に基づき当該アルバイトシフト枠に対応する時給が算出され、当該日時、ポジション、算出された時給が、抽出されたアルバイト端末４に表示され、この表示に対しアルバイト端末４から承認信号が入力されると、当該アルバイトシフト枠に対するそのアルバイトの出勤予定及び時給が確定される。【選択図】図１

Description

本発明は、アルバイトの勤務シフトを生成しマッチングするシステムに関する。

従来、飲食店などにおけるアルバイトの求人については求人サイトなどを利用して行われているが、必要とする人材がなかなか確保できないという実情があり、求人広告への出費も少なくない。

アルバイトの雇用に際しては、求人広告に対して応募してきた人材に面接を行い、雇用契約を行った後に実際のシフトを組んでいくという手順が踏まれている。この雇用契約の際には、店とアルバイトの間で、見込み勤務期間、基本時給、勤務時間、勤務日数、見込み月給についての合意がなされる。この合意は健康保険、社会保険とも関連し、適宜調整される。通常、雇用契約の期間は半年などと定められ、特に問題がなければ自動更新される。

アルバイトの勤務予定は、アルバイトからの勤務希望に基づき、その店の店長がシフト表と呼ばれるタイムテーブルを作成することで調整され、このシフト表によりアルバイトの勤務時間が決定される。すなわち、雇用契約を結ぶタイミングが勤務契約についての仮決定、シフト表が決定となる通常２週間に一度のタイミングが本決定となっている。

しかしながら、必ずしもアルバイトからの勤務希望が採用されるとは限らず、さらに、契約時に合意された勤務時間、勤務日数、見込み月給も実現しない場合が多い。また、シフト表を決定するのは店長なので、店長と仲の良いアルバイトほどシフト希望が通りやすいなど、店長次第で理不尽なシフトとなる場合もあり、アルバイトのみならず経営者にとっても不利益となる場合がある。

また、アルバイトの時給は一般的に能力や勤務年数により決定され、夜勤手当などを除き、契約期間を通して一定である。そのため、忙しい時間帯や人手不足になりやすい週末などの勤務については、店長がアルバイトにお願いするといった個人間の力関係によりシフト構成が成り立っていた。さらに、シフト表の決定後に社会事情の変化や大口予約のキャンセルなどによるアルバイトの勤務予定が店側からキャンセルされることがあり、この場合には店長からアルバイトにお願いし、アルバイトに対するキャンセル料が支払われることもなく、個人間の力関係のみで取り消されるという、アルバイトに対しては不利な状況が通常であった。

一方で、店長はシフトの調整に時間を取られているという実情がある。このため、シフトの調整を支援するツールも開発されている。例えば、特許文献１には、パートタイマーやアルバイトなどの従業員の能力を反映した勤務シフト表を作成することのできる勤務シフトマッチングシステム及び勤務シフト管理装置が開示されている。

特開2005-258563号公報

しかしながら、特許文献１のシフトマッチングシステムでは、店長の行う作業の一部をシステムが肩代わりすることができたとしても、アルバイトの希望と店側の都合が合致しないという問題は残る。また、人手不足になりやすい時間帯におけるシフトについては依然として店長とアルバイトの関係に依り、店長の手腕次第である。

本発明は、上記課題を解決するものであり、店側の都合とアルバイトの希望とをすり合わせ、アルバイトの納得感を充足する、シフトマッチングシステムを実現することを目的とする。

上記課題を解決するため、本発明のシフトマッチングシステムは、店長が操作する店長端末と、複数のアルバイトがそれぞれ所持するアルバイト端末と、サーバーとを有し、前記店長端末から必要なアルバイトシフト枠の条件としての日時及びポジションについての決定信号が入力されると、前記サーバーに保存されたアルバイトデータベースから、これらの条件を満たすアルバイトが抽出されるとともに、前記サーバーに保存された時給算出基準に基づき当該アルバイトシフト枠に対応する時給が算出され、当該日時、ポジション、算出された時給が、抽出されたアルバイト端末に表示され、この表示に対しアルバイト端末から承認信号が入力されると、当該アルバイトシフト枠に対するそのアルバイトの出勤予定及び時給が確定される。

実施形態の顧客管理システムの機能構成を示すブロック図である。 実施形態のシフトマッチングシステムにおけるある店のシフト表を示す図である。 実施形態のシフトマッチングシステムにおける各装置間でのデータのやり取りの流れを示すフローチャートである。

本発明のシフトマッチングシステムの実施形態について説明する。図１は、実施形態のシフトマッチングシステムを示すブロック図である。

図1に示すように、実施形態のシフトマッチングシステム１は、互いにインターネット経由で接続されたサーバー２と、店長端末３と、アルバイト端末４とを有する。店長端末３には店長アプリケーション３１がインストールされ、アルバイト端末4にはアルバイトアプリケーション４１がインストールされている。なお、店長端末３がサーバー２を兼ねるという態様も可能である。また、アルバイトアプリケーションと店長アプリケーションとは同一のアプリケーションであってログインIDにより異なるロールが設定されて異なる挙動をするものであってもよい。

典型的にはアルバイト端末4はアルバイトが個人で所有する携帯電話であり、アルバイトの数だけ存在する。店長端末３は店長に支給されるパソコン、タブレット端末、携帯電話等であり、通常は店に１つ存在する。サーバー2は本部または他の場所に存在する。

サーバー2内には、アルバイトデータベース、店舗データベース、店長データベースが格納されている。

アルバイトデータベースには、アルバイトの氏名や住所といった一般的な履歴書に記載される内容のほか、特に本実施形態のシフトマッチングシステムで使用される、勤務経験のある店名、勤務可能なポジション及びそのポジションに対するスキルレベル、基本時給、評価ポイント、勤務可能な曜日及び時間帯、見込み勤務期間、基本時給、勤務時間、勤務日数、見込み月給、健康保険及び社会保険の有無、雇用契約の期間等のデータが含まれている。

店舗データベースには、店名や住所、席数といった一般的な基本情報のほか、特に本実施形態のシフトマッチングシステムで使用される、過去の客数、売上、シフト表、予算、等が含まれている。

店長データベースには、店長の氏名や住所等といった一般的な履歴書に記載される内容のほか、特に本実施形態のシフトマッチングシステムで使用される、過去に在籍した店名や経験したポジション、給与、評価ポイント等が含まれる。

図２は、例として２０２０年３月３０日における、ある店のシフト表を示している。図2においてシフト表32は店長端末３に表示され、店長アプリケーション３１内で開かれている。

シフト表32には、左端にキッチン・フロアといった大項目である所属、その右に焼き場・刺し場・揚げ場・洗い場といった小項目であるポジション、さらに鈴木・田中といった名前が表示され、続いて各人の勤務開始・終了時間、また休憩の開始・終了時間が表示される。

画面右側には、上端に時刻がタイムライン状に記載され、その下に設けられたタイムテーブルには各人の勤務シフトがガントチャート状に、すなわち時間ごとの枠を塗りつぶす形で表現されている。

その下に記載されているのは時間ごとの小計人数で、すなわち当該所属における当該時間枠に属するアルバイトの勤務人数である。例えば一人が３０分間勤務する場合は0.5人とカウントされる。

小計人数の下の合計人数は小計人数の合計であり、すなわち当該店舗における当該時間枠に属する勤務人数である。

さらに下には客数予算が記載されている。これは当該時間枠における予想来客数を示し、単位は人である。

その下の売上予算は、当該時間枠における予想売上を示し、単位は千円である。

さらに下の人時接客指数は、当該時間枠におけるアルバイト一人あたりの予想接客人数であり、客数予算を合計人数で割ったものである。この数字が大きいほどアルバイト一人あたりの負担が大きくなる。

その下の人時売上は、当該時間枠におけるアルバイト一人あたりの予想売上であり、売上予算を合計人数で割ったものである。この数字が大きいほど、支出すなわちアルバイトの給料に対する収入すなわち売上が大きいということになり、効率の良い経営ということになる。

＜アルバイトシフト枠の作成＞ 実施形態のシフトマッチングシステム１において、このようなシフト表はサーバー２により自動的に生成される。このシフト表の生成方法について説明する。

図２に示すようなシフト表でまず設定されるのは、客数予算と売上予算である。サーバー２には過去の客数と売上の実績のデータベースが格納されている。サーバー２は、ある日のシフト表を生成するにあたり、条件が近い過去の日の客数と売上の実績を参照し、予測をする。具体的には、一週間前の同じ曜日や一年前の同じ曜日、またはそれらの平均、もしくは祝日であれば一年前の同じ祝日における、客数と売上の実績を、予測値として、客数予算と売上予算に入れる。なお、一週間前のデータを使うのか、一年前のデータを使うのか、これらを割合で採用するのかといった選択は、後述する店長アプリケーション３１における設定画面で設定可能である。また、予測値としてサーバー２が客数予算と売上予算に入れた数値は、後から店長が修正可能である。

続いて、客数予算と売上予算とから、それぞれのポジションにおける必要人数が導き出される。具体的には、店長アプリケーション３１における設定画面で一定範囲の人時接客指数に対応するそれぞれのポジションの必要人数をテンプレートとして設定し、店舗データベースの一部として保存し、サーバー２は、これを参照することで、当該時刻における人時接客指数に対応するそれぞれのポジションの必要人数を引き当てる。なお、一定範囲の人時接客指数と一定範囲の人時売上でアンド条件とすることもできる。このようにして、シフト表に、それぞれの時間帯に必要な人員の枠が設定され、人時生産性が適宜に調整される。

このように、アルバイトシフト枠は、サーバー２に保存された実績データベースにおける過去の類似する日程を参照して導き出されると共に店長端末３に表示され、必要に応じて店長が修正した後、店長端末３から店長が決定ボタンを押すことで必要なアルバイトシフト枠の条件としての日時及びポジション並びにスキルレベルについての決定信号がサーバー２に通知され、シフト枠が確定される。なお、店長が決定ボタンを押さない場合には店長端末３に対しアラートが表示されたり、店長の決定の有無によらず時限的に、例えば２週間に一度のシフトの希望提出期限に確定されるようにしてもよい。

＜勤務希望の提出＞ アルバイトデータベースには、アルバイトの契約時のデータである仮契約データが含まれ、店長アプリケーション３１及びアルバイトアプリケーション41から参照可能である。仮契約データを参照した場合、図4に示すように、勤務条件、例えば休日のみ勤務可能であるとか、週3日の勤務であるといった情報が、視覚的に確認可能に表示される。具体的には、一週間を表すタイムテーブルのうち勤務不可な時間帯は黒く塗りつぶされ、土日どちらか勤務というように複数日から１日選択の場合には当該複数日、ここでは土日が赤で塗りつぶされる。月水金のうち２日というように複数日から２日選択の場合には当該複数日、ここでは月水金が紫で塗りつぶされ、複数日、例えば平日のうち３日勤務可能というように３日選択の場合には当該複数日、ここでは平日が青で塗りつぶされる。いつでも勤務可能という曜日及び時間帯に関しては塗りつぶされない。一日における最大勤務時間は各曜日の下に表示される。

そして、アルバイト端末4におけるアルバイトアプリケーション41には、図3に示すように一週間のカレンダーが表示され、アルバイトは、自分の希望シフトを提示することができる。具体的には、勤務不可な時間帯は黒く塗りつぶされて、ここでは９時以前及び２１時以降、また木曜週日がデフォルトでの勤務不可となっている。

ここで、アルバイトは、勤務不可な時間帯を追加で申請することができる。具体的には、勤務不可な時間帯を黒枠で塗りつぶすことにより、その時間帯が勤務不可であることを表示できる。図３においては３０日の月曜日の１１時から１６時、４日の土曜日の１１時から１７時が勤務不可として指定されている。この勤務不可時間の指定は、タッチ端末で行われるため、勤務不可時間を指でなぞって指定するのみで、容易である。

この際、仮契約データに示された仮契約時の条件を満たさないような指定を行った場合、例えば土日のどちらかに出勤するという仮契約になっていたところ土日の両日を黒枠で塗りつぶすような場合には、アラートが表示され、仮契約時の条件を満たさない旨のメッセージが表示される。仮契約時の条件を満たさないままシフト申請を行った場合には、評価ポイントの下落や基本時給ダウンなどの、事前に合意された罰則措置が行われる。また、仮契約の範囲内で、どの程度の勤務量で勤務したいかを、画面右上のボリューム調整で指示することができる。

なお、勤務不可な時間帯の入力がなされると、シフト自由度が算出される。シフト自由度とはシフトを組む際の選択可能性を示す数字であり、例えば、平日のうち２日×８時間勤務するという仮契約であった場合、平日毎日８時間の枠があるうち月曜日を勤務不可として黒枠で塗りつぶした場合には50%、月曜と火曜を黒枠で塗りつぶした場合には３３%、月曜と火曜と水曜を黒枠で塗りつぶした場合には０％となる。時間の要素も同様に算入される。シフト自由度が低い状態が続くとアルバイトの評価ポイントが下がることになる。また、同様に、アルバイトのシフト協力度も算出される。シフト協力度とは、需給比率の低い、人気のないシフト枠に対してどれだけ勤務可能とするかを数値化したものである。後述するが、当該曜日及び時間のアルバイト枠に対するマッチング可能なアルバイトの数の平均を算出することで、需給バランスを数値化することができる。需給比率の低いシフト枠に対し勤務可能としている割合を算出することで、当該アルバイトのシフト協力率を算出することができる。シフト協力率は評価ポイントに反映される。

このようにしてアルバイトにより決定され、提出された勤務希望は、アルバイトデータベースに保存される。勤務希望の提出期限について、勤務不可な時間帯の入力が可能な期間についてのタイムリミット、すなわち希望提出期限が設けられる。希望提出期限は当日の１週間前、当週の２週間前といった設定が可能であり、慣習的には２週間に一度設けられる。

＜アルバイトシフト枠のマッチング＞ 上述のように、希望提出期限までに、サーバー２において、シフト表に、それぞれの時間帯に必要な人員の枠、すなわちアルバイトシフト枠が設定されている。それぞれのアルバイトシフト枠には開始及び終了の日時及びポジション、場合によってはこのポジションにおけるスキルレベルが紐づいている。これに対し、サーバー２に保存されたアルバイトデータベースから、これらの条件を満たすアルバイトが抽出される。より具体的には、サーバー２は、アルバイトシフト枠に紐づく日時及びポジションを満たすアルバイトを、アルバイトデータベース内に格納された各アルバイトの勤務希望を参照することによりマッチングし、抽出する。このマッチングが行われるタイミングは、希望提出期限の後となる。

この際、一つのアルバイトシフト枠にマッチするアルバイトが一人であった場合、このマッチングは確定する。一つのアルバイトシフト枠にマッチするアルバイトが複数いた場合、アルバイトデータベースに格納されている仮契約時のデータにおける各アルバイトの見込み勤務時間を参照し、各アルバイトの見込み勤務時間と実際の勤務時間との乖離が最も小さくなるように、また上述のボリューム調整も勘案されてアルバイトが割り振られる。また、選択が可能な場合にはアルバイトの評価ポイントの高いアルバイトを優先的に割り振るよう設計されている。基本時給が高いアルバイトより基本時給が低いアルバイトが優先的に割り振られても良い。このようにして、マッチングが確定する。見込み勤務時間と大幅に相違す
る時間数のアルバイトシフト枠をマッチングする場合には店長端末にアラートが表示されるように設定することもできる。このようなことは保険などの福利厚生上も重要となる。なお、一つのアルバイトシフト枠にマッチするアルバイトが一人もいない場合、後述する方法で再募集することになる。

＜アルバイトの時給算出＞ 続いて、アルバイトごとの基本時給とサーバーに保存された時給算出基準に基づき、アルバイトシフト枠にマッチングされたアルバイトの各時間ごとの時給が算出される。具体的には、各アルバイトには基本時給が設定され、アルバイトデータベースに格納されているが、アルバイトシフト枠ごと、または時間ごとに、時給算出基準としての係数が定められ、基本時給にこの係数が掛け合わされることで、当該時間の時給が算出される。

時給算出基準としての係数は、ポジション、人時接客指数、人時売上、FL比率、アルバイトシフト枠の長さ、時間帯、が考えられる。

ポジションについて、代わりの少ない、すなわち難易度の高いポジションほど、係数は高くなる。アルバイトデータベースにおいて当該ポジションの勤務が可能なアルバイトの見込み勤務時間の和を実際の当該ポジションの枠時間数で割ることで、代わりが多いか少ないかを数値化することができる。

人時接客指数については、上述の通り、想定される客数から割り出されている。人時接客指数の多い時間帯ほど忙しいと考えられるから、乗算する係数の数値を大きくすることが合理的である。人時売上についても同様に考えることができる。

FL比率については、経営上の問題となるが、一定以上のFL比率が予想される場合に時給を下げるという対応が考えられる。例えば、店長がFL比率の上限を６０％と設定した場合、売上から原材料費を算出できるから、（原材料費＋人件費）÷売上によりFL比率を算出し、これが60%を超えた場合に、各アルバイトシフト枠についての時給を下げるか、アルバイトシフト枠を減らすことでFL比率が60%を超えないようにプログラムすることができる。なお、このFL比率は、時間帯ごとで算出しても、一日単位で算出しても良い。

アルバイトシフト枠の長さについても、時給算出基準となり得る。一般的に、アルバイトシフト枠の長さがある程度長い方が好まれ、例えば２時間といった短いアルバイトシフト枠は好まれない。しかしながら、店舗としてはピークタイムが２時間程度であったりして、短い枠でのアルバイトの需要は高い。このように、需要に対する供給が低い長さの枠については、高い係数を乗算することで、時給を高くすることができる。アルバイトシフト枠の長さに対する係数を設定するためには、人が設定してもよいが、後述のように希望提出期限後に発生した２時間枠のアルバイトシフト枠を時給が変動する状態でアルバイトに対して募集し、これに対しアルバイトがいくらでこの枠に応募するかという分析を行えば、基本時給に対しどれほどの係数を掛ければこの２時間枠のアルバイトシフト枠に対する時給として妥当かを数値化できる。

時間帯についても同様に、需要と供給で考えることができる。深夜や早朝、週末は一般的にアルバイトの供給は少ないので、高い係数を乗算することで、時給を高くすることができる。当該曜日及び時間のアルバイト枠に対するマッチング可能なアルバイトの数の平均を算出することで、需給バランスを数値化することができる。もちろん、法定の夜間手当なども係数となる。

以上のように、店舗側によるアルバイトの需要と、アルバイト側の供給に影響を与える様々な要素を係数とし、当該アルバイトの基本時給に乗算または加算して時給を確定できる。時給は一つのアルバイトシフト枠の中で固定であっても良いし、一つのアルバイトシフト枠の中でも時間によって変動しても良い。このように、希望提出期限におけるアルバイトシフト枠と希望日時とのマッチングによって確定されたシフトに、アルバイトごと、時間ごとに異なる時給が定まる。これにより、忙しい、または供給の少ないアルバイトシフト枠に入ったアルバイトにはボーナスが出ることになるから、アルバイトの納得感を醸成できる。また、基本時給に対しどのような係数が適用されているかをアルバイト端末に表示することにより、いっそう納得感を醸成でき、後の希望の提出にも影響するから、アルバイトと店側との間で良い循環が生まれる。

＜例外的アルバイトシフト枠に対するアルバイトの募集＞ 上述のように、希望提出期限の後速やかに、サーバーがアルバイトシフト枠に対するアルバイトのマッチングを行い、その時給が算出され、原則的なシフトが確定するが、希望提出期限においてアルバイトシフト枠にマッチするアルバイトがいなかった場合や、アルバイトのキャンセルにより枠に空きが生じた場合、大口の予約が入るなどして希望提出期限の後にアルバイトシフト枠が増加した場合など、例外的なアルバイトシフト枠が存在する場合、アルバイトデータベースに登録されているアルバイトに対し募集を行うことになる。その手順について説明する。

＜アルバイトシフト枠の時給算出＞ まず、サーバーに保存された時給算出基準に基づき、当該アルバイトシフト枠に対応する時給が算出される。すなわち、例外的なアルバイトシフト枠に対応する時給は時給算出基準に定義された様々なパラメーターにより変動するダイナミックプライシングとなる。時給算出基準とは上述の通り、当該アルバイトシフト枠の時給を決定するための要素であり、係数である。この係数はアルバイトシフト枠のポジションに対応する基本の時給に対して乗算または加算される。言い換えれば、原則的なシフトは基本時給を基礎としてアルバイトシフト枠に係数が存在して時給が決定されるのに対し、例外的なシフトについては、アルバイトシフト枠について時給が存在する。この場合、原則的には誰が入ったとしても当該アルバイトシフト枠に対する時給は同じになる。

ダイナミックプライシングについて、具体的には、ポジション、スキルレベル、人時接客指数、人時売上、FL比率、アルバイトシフト枠の長さ、時間帯、当該日時までの残り時間、最低賃金などが時給算出基準になり得る。

詳細に説明すると、サーバーにおいて、当該アルバイトシフト枠のポジションに対応する基本の時給がデータベースから参照され、これに対し時給算出基準に定義された係数が乗算される。当該アルバイトシフト枠のポジションに対応する基本の時給またはポジションに対する係数は、店舗データベースに含まれている。当然、難易度の高いポジション、需要に対する供給の少ないポジションほど時給は高くなる。ポジションに対する需給比率の算出方法は上述のとおりである。これに、スキルレベルのポイントが加算または乗算される。人時接客指数、人時売上、FL比率、アルバイトシフト枠の長さ、時間帯についての需給比率は上述の通り数値化することが可能であり、これらによって定められた係数が、基本の時給に乗算される。

当該日時までの残り時間については、当該日時まで近づくほど一般的にアルバイトの供給が困難となるので、高い係数を乗算することで、時給を高くし、マッチングされたアルバイトからの応募を促すことができる。当該日時までの残り時間は次第に短くなるので、この係数は、残り時間が短くなるほど高くなる変数とすることができる。

＜アルバイトシフト枠に対するアルバイトのマッチング＞ 次に、当該アルバイトシフト枠に対するアルバイトのマッチングが行われる。この場合のマッチングは時間的な要素ではなく、当該アルバイトシフト枠の属性であるポジション、スキルレベルを満たすアルバイトが抽出される。ここで、アルバイト端末及び店長端末から、アルバイトごとに時給の上限、下限を設けることができ、これに当てはまらない場合には当該アルバイトはマッチングから外れるという設定を行うことにより、当該アルバイトの基本時給より低い時給の募集がなされないようにするといったことができる。

＜アルバイトシフト枠に対するアルバイトの決定＞ アルバイトが抽出されると、当該日時、ポジション、算出された時給が、抽出されたアルバイト端末4に表示され、募集が行われる。具体的には、通知音を伴ったプッシュ通知としてアルバイト端末4に当該日時、ポジション、算出された時給の情報が表示されたり、アルバイトアプリケーション41を開いた場合にカレンダー上に表示されるなどの態様が考えられる。この際、カレンダー上に時給を数字で表すほか、色の表示で表すことにより視覚的に時給が判別しやすいように構成しても良い。原則的なシフトは確定しているのに対し例外的なシフトは未確定な募集状態であるから、カレンダー上に表示される場合も原則的なシフトとは異なる色で表示され、また点滅するなど目立つ処理が行われても良い。

この募集に対し、アルバイトが応募し、すなわちアルバイト端末４から承認信号が入力されると、当該アルバイトシフト枠に対するそのアルバイトの出勤予定及び時給が確定される。これにより、他のアルバイトは当該アルバイトシフト枠に入ることはできなくなり、他のアルバイトのアルバイト端末４のアルバイトアプリケーション４１にはこのアルバイトシフト枠が表示されなくなる。なお、当該アルバイトシフト枠に入るアルバイトを店長端末から指定することもできる。その場合には、店長端末３から承認信号が入力され、当該アルバイトシフト枠に対するそのアルバイトの出勤予定及び時給が確定される。

ここで、アルバイトシフト枠の日時までの残時間により変化する変数については、残時間に応じて算出される時給が変化するから、この時給が抽出されたアルバイト端末にリアルタイムに反映されて表示される。つまり、いずれかのアルバイト端末から承認信号が入力されるまで、カレンダー上の時給の表示が動的に変化することになる。また、残時間が減って時給が上がり、下限時給金額を超えることで、今まで表示されていなかったアルバイトのアルバイト端末にも表示される場合もある。

以上のようにして、アルバイトシフト枠が埋まる。これをもって、店舗とアルバイトの本契約が結ばれると考えることができる。この過程において、時給が需要と供給に従って決定されていくため、アルバイト及び店側の納得感が醸成される。また、仮契約時の見込み勤務期間、基本時給、勤務時間、勤務日数、見込み月給との乖離が生じないように警告を発したり、乖離が生じるような勤務体系でのアルバイトシフト枠については表示を非表示にして予約確定できないようにすることで、仮契約と本契約とを同一に近づけていくことができる。

上述の例では、希望提出期限の時点で決定可能な原則的シフトについては、各アルバイトの基本時給を基準に、時給算出基準により導かれた係数が乗算または加算され、最終的な当該時間についての時給が決定される一方、希望提出期限以降の例外的なシフトについてはアルバイトシフト枠に対して時給算出基準により時給が定められて募集が行われ、アルバイトがこれに対して応募することで当該アルバイトシフト枠に対するそのアルバイトの出勤予定及び時給が確定されるが、希望提出期限を設けない運用も可能である。この場合、アルバイトシフト枠が発生した時点でアルバイトの抽出及び抽出されたアルバイトに対する募集が行われることになる。

＜不規則的なアルバイト枠＞ また、別の実施形態として、突然アルバイトが休むなど、不規則的に生じたアルバイトシフト枠に対し、かつてその店でアルバイトしていたOB/OGを含む待機アルバイトに対し募集を行う例について説明する。

店長は、店長端末３から、サーバー２に対し、生じたアルバイトシフト枠の条件を入力する。この内容は、日時、枠の長さ、ポジション、スキルレベル、時給である。この場合の時給は、支払い可能な時給の上限を店長が決定し、入力する。

一方、アルバイト側は、希望する時給や日時をアルバイト端末４からサーバー２に対し入力して待機する。希望する日時とは勤務可能な時間であり、図３に示
すようなインターフェイスで入力することができる。この入力データは勤務可能なポジションやスキルレベルとともにアルバイトデータベースに登録される。なお、特に時間希望を入れずに待機することもできる。希望する時給は、アルバイトがこの金額であれば勤務できると考える時給を指定する。時間に関わらず一律にすることもできるし、曜日や時間帯、枠の長さ、特定の時間についてそれぞれに指定する変動制にすることも可能である。

サーバー２は、店長端末３からのアルバイトシフト枠の条件入力が行われた場合、マッチングを行う。すなわち、アルバイトデータベースを参照し、当該条件に合致するアルバイトを抽出する。時給については、店長が入力した時給より安い希望時給を提示しているアルバイトが抽出される。

その後、抽出されたアルバイトのアルバイト端末４にプッシュ通知をし、勤務の打診をする。この際、複数のアルバイトに対し打診を行い、これを最初に承認したアルバイトの勤務が確定し、この時点で他のアルバイトに対する打診が取り消される。この際の複数のアルバイトは、希望する時給の低い順に数人をピックアップしても良いし、抽出された中から店長が選択しても良い。また、一人のアルバイトに時限付きで打診を行い、承認されなかった場合に次のアルバイトに打診を行うという形式も可能である。

上述のマッチング方法は組み合わせて使用することができる。複数の店に対して行うこともできる。サーバーは第三者が運営する。

＜アルバイトシフト枠のキャンセル＞ アルバイトは、アルバイトシフト枠に対するそのアルバイトの出勤予定が確定された後、当該出勤予定について都合が悪くなったような場合に、当該アルバイトのアルバイト端末から、当該出勤予定に対するキャンセル希望信号をサーバー２に対し発することができる。このような場合、サーバー２により、アルバイトシフト枠の日時までの残時間が算出され、この残時間に応じて算出される変数を算入することによりキャンセル料が算出され、このアルバイトシフト枠及びキャンセル料が当該アルバイトのアルバイト端末に表示される。このキャンセル料は違約金の意味合いがある。すなわち、残時間が短いほど、キャンセル料は高くなる。この表示に対し、当該アルバイト端末から確認信号が入力されると、店長端末にこのアルバイトシフト枠及びキャンセル料が表示される。これに対し店長端末から承認信号が入力されると、当該アルバイトシフト枠に対するそのアルバイトの出勤予定がキャンセルされると共にキャンセル料が決定される。実際には、キャンセル料は、当月のアルバイトの給料から引かれることになる。一方で、このアルバイトシフト枠に空きが出ることになるから、条件を満たす他のアルバイトのアルバイト端末に対し、このアルバイトシフト枠についての通知が表示される。この際の時給は残時間が短いほど高くなるから、前述のキャンセル料とほぼ相殺され、アルバイト側及び店側の納得感を醸成できる。なお、キャンセル料やアルバイトシフト枠についての時給は、アルバイトシフト枠の日時までの残時間により直線的に比例するのみならず、あるタイミングの前か後かで大きく変わるように設定することができる。

逆に、アルバイトシフト枠に対するそのアルバイトの出勤予定が確定された後、店長が当該時間帯のアルバイトを減らしたいと考えた場合に、店長端末から、当該時間帯の一つまたは複数の出勤予定に対する取り消し要請信号を発することができる。この取り消し要請信号が発せられた場合、サーバーにおいて当該アルバイトシフト枠の日時までの残時間が算出され、この残時間に応じて算出される変数を算入することにより取消料が算出され、このアルバイトシフト枠及び取消料が当該アルバイトのアルバイト端末に表示され、この表示に対し当該アルバイト端末から承認信号が入力されると、当該アルバイトシフト枠に対するそのアルバイトの出勤予定が取り消されると共に取消料が決定される。これは、例えば数日前になって大口の予約がキャンセルになったり、当日の天候が悪く当初の予測よりも客数が少ないと見込まれる場合などに、店長がアルバイトを減らして人件費を抑えるために行われる。当然ながら取消料は当初の時給より低い。そして、当該日時が近いほど、また取り消したい枠が多いほど、高くなる。なお、例えば人員を５人から３人に減らしたいような場合に、店長は、５人に対し出勤予定に対する取り消し要請信号を発し、このうち２人が承認信号が入力した時点で他の３人に対する取り消し要請信号はキャンセルされるように設定できる。

このようにして、アルバイトシフト枠が確定した後でも、店長とアルバイトの双方に納得感のある金額を提示して、合理的にキャンセルをすることができる。なお、キャンセル料や取消料に代えて、またはこれと共に、キャンセルをした者に対する評価が下がるようなペナルティを与えても良い。店長側からの取り消し要請については、店長が入力するほか、予約のキャンセルや天候変化などに伴う予想客数の変化に応じて、サーバー２が自動的に行うこともできる。

＜他店舗との融通＞ さらに、実施形態のシフトマッチングシステム１において、他店との間でシフト表の空き状況を互いに公開し、空きが生じている場合に当該他店からのヘルプを受け入れることができる。具体的には、アルバイトは、複数の店舗に対しエントリーすることができ、アルバイトの勤務希望がこれらの店舗に対して公開される。これに対し、これらの店舗のシフト表に照らしてマッチングされたアルバイトシフト枠が当該アルバイトのアルバイト端末に表示され、アルバイトはこれを承認することができる。なお、メインの店舗を決めて、重複した場合にはメインの店舗のアルバイトシフト枠のみが表示されるような運用も可能である。

＜他のシステムとの連携＞ さらに、実施形態のシフトマッチングシステム１において、サーバー２がタイムカードと接続され、アルバイトの出勤や退勤の実績をシフト表と照らし合わせることができる。アルバイトが遅刻または欠勤した場合には時給を減給または取り消したり、評価が下がるようなペナルティを与えることもできる。 さらに、実施形態のシフトマッチングシステム１において、サーバー２がレジスターシステムと接続され、アルバイトシフト枠における来客数が多い場合にはボーナス時給を加算したり、当該アルバイトの出勤時間における来客数が相対的に多い場合には特定のパラメーターによりアルバイトの評価数値を上げたり、当該アルバイトによるオーダー担当時の客単価が相対的に多い場合には特定のパラメーターによりアルバイトの評価数値を上げるという運用ができる。このように客観的な情報による評価を行うことで、従来のような主観に基づく評価による理不尽な扱いを避けることができる。

サーバーは、評価ポイントの数値に基づき、基本時給の昇給や減給を行う。この評価は、他店へ当該アルバイトがヘルプで勤務する場合や移籍する場合、別の業種に転職する場合にも利用することができる。評価を一定の範囲で公開することによりスカウトを行うこともできる。例えば、特定のスタッフの評価ポイントを他店に対して公開することで、当該スタッフに対するスカウトを募集することができる。他店はその評価ポイントを閲覧することで当該スタッフをスカウト費用を支払ってスカウトできる。

このようにして、本発明のシフトマッチングシステムによれば、サーバー２が人時生産性を最適化しつつ、アルバイト及び店長、経営者の納得感を充足し、仮契約と本契約を近づけることができる。

次に、以上のようなシフトマッチングシステムと連動して用いられる顧客管理システムについて説明する。

サーバー2内には、顧客データベースが格納されている。

顧客データベースには、顧客の氏名または通称や居住地等の属性データのほか、来店履歴や注文履歴のデータが含まれている。属性データは主に顧客が自身で入力するが、アルバイトがアルバイト端末から入力する場合もある。例えば、顧客との会話からの情報やサービスにミスがあった履歴などを入力することで、他の店員に申し送りすることができる。

顧客端末５は位置情報検出手段を有し、位置情報検出手段により顧客端末５が当該飲食店に入ったことが検出されると、サーバー２において当該顧客端末５に紐付けられた顧客情報が引き当てられ、この顧客情報が各アルバイト端末４に通知される。

ここで、位置情報検出手段とは、例えば顧客端末５に内蔵されたGPS受信機であり、これにより、顧客端末５を所持した顧客が当該飲食店に入店すると、顧客端末５はGPS受信機により入店を検知してチェックイン信号をサーバー２に送信し、チェックイン状態となる。

すると、サーバー２から各アルバイト端末４に、この顧客が来店したことを知らせる信号とこの顧客の顧客情報の一部が送信され、各アルバイト端末４には、「〇〇様が来店しました」というようなアラートが表示される。これにより、顧客を出迎えたサービススタッフは「〇〇様いらっしゃいませ」と、顧客に応じた挨拶をすることができる。来店履歴や前回対応したサービススタッフ名がサーバー２に保存されていることで、当該サービススタッフが「〇〇様、お久しぶりです、お変わりないですか」と気の利いた会話をすることもできる。

また、顧客の注文データから嗜好情報をデータベースに記録し、アルバイト端末４に通知を行うことで、サービスに活かすことができる。嗜好情報とは例えば、麺硬め、サビ抜き、大盛り、といった情報である。これらを保存するデータベースはカルテと呼ばれる。カルテには、オーダーした内容など自動的に保存される情報と、スタッフの書き込みにより保存される情報がある。
自動的に保存される情報について、具体的には、顧客の注文情報をデータベースに記録しておき、麺硬めを指定した割合が一定以上であったとすると、顧客が今回ラーメンを注文した際に、オーダーを受けたサービススタッフがアルバイト端末４からラーメンのオーダーを入力すると、サーバー２からアルバイト端末４へ「麺は前回同様固めにしますか？」とアラートが送信され、表示され、これを受けてアルバイトは顧客に「麺は前回同様固めにしますか？」と聞くことができるから、顧客は特別なサービスを受けているという印象を持つ。また、ケースごとのバリエーションでアラートを発生させることもできる。例えば、当該顧客が４名で来店した場合には「サビ抜き」を指定するという履歴が残っていれば、当該顧客が４名で来店し、かつ寿司を注文した際にサーバー２からアルバイト端末４へアラートを送信することで、当該アルバイトは「サビ抜きにしますか？」と確認することができる。さらに、店員がアルバイト端末を左フリックや右フリックといったジェスチャーをすることによりカルテや過去の伝票を直接参照できるようになっていてもよい。コーヒーをブラックにするか、お酒を熱燗にするか、なども過去のデータを参照することでアラートとすることができる。さらに、いつも頼んでいるものを今回は頼んでいないといった場合には、オーダーの最後にアルバイト端末４に「今日は頼まなくて良いんですか」とアラートが出て、これに従ってアルバイトが尋ねることで顧客の注文抜けを防ぐと共に、もてなしの印象を与えることができる。

サーバー２のカルテには、スタッフの書き込みにより保存される情報として、会話を補助するためのデータも保存することができる。例えば、出身地や趣味、特別な申し送りなどがこれに当たり、顧客が顧客端末５から自分の情報を入力することもできるし、アルバイトがアルバイト端末４から入力することもできる。特にこのような顧客の情報は、電子的な伝票に記載可能であることが望ましい。このデータがアルバイト端末４にアラートとして表示されたり、またアルバイト端末４からデータベースを参照することで、アルバイトはこのような顧客情報に応じて顧客と会話することができる。また、カウンターで隣同士になった顧客に共通点があった場合にサーバー２がアルバイト端末４にアラートを発し、「今日はお客さん二人とも〇〇県出身ですね」というように会話を促すこともできる。なお、顧客が隣同士になっていることは、顧客端末のGPSのほか、顧客端末のブルートゥース（登録商標）、顧客端末による席のQRコード（登録商標）の読み込み、アルバイト端末４からの入力などにより判別できる。さらに、顧客が入力しておらず、かつ当該アルバイトとの以前の会話の中で出てきていない情報、すなわち他のアルバイトが入力した情報を当該アルバイトが知っていることは不自然なので、当該アルバイトが知り得た情報に限定し、当該アルバイト端末４に通知を行うことができる。具体的には、カウンターで隣同士になった顧客に共通点があった場合であって、かつその情報を入力した者が当該顧客または当該アルバイトであった場合にのみ、サーバー２がアルバイト端末４にアラートを発するよう設計することにより、このような機能を実現できる。

さらに、顧客の注文データから導かれる平均単価や来店回数データから、顧客をランク付けすることができる。ランクの高い顧客には一品サービスを行ったりVIP席に案内する、料理長が挨拶に来るなどのサービスを行うことができる。サーバー２はそれらのサービスを行うことを促すアラートを各アルバイト端末４に送る。

顧客データにボトルキープデータが記録されている場合には、サーバー２はアルバイト端末４にボトルキープアラートを送信する。これを受けてアルバイトはボトルラックへ行き、アルバイト端末４に表示されたボトルを探すボタンを押す。それぞれのボトルにタグが掛けられており、サーバー２から当該顧客に紐付いたタグに信号が送られ、当該タグに内蔵されたLEDが光ることで、当該顧客のボトルを簡単に発見することができる。また、店長端末やアルバイト端末を操作して、一定期間来店のない顧客のボトルを抽出することができる。そして、サーバー２から信号を発し、これらの顧客のボトルについたタグを光らせることにより、一定期間来店のない顧客のボトルを廃棄することが簡単にできる。

アルバイト端末４とサーバー２との間で行われる処理として、タイムカード処理がある。アルバイトが店に出勤すると、アルバイト端末に内蔵されたGPS受信機などの位置情報検出手段により出勤処理が行われ、同様に退勤時も退勤処理が行われる。なお、GPSのほか、従業員通用口に設けられたQRコードをアルバイト端末４で読み取ることによりこれらの処理が行われてもよい。アルバイトが勤務中に使うアルバイト端末４はアルバイトの私物のアルバイト端末４と別であることが望ましい。

このようにすることで、スタッフは別の店に移籍した場合にも顧客を別の店に誘導することは難しくなる。また、特に女性のスタッフは顧客に個人情報を教えたくないために直接連絡することは困難だったが、アルバイト端末４の連絡先を教えることで顧客と直接連絡が可能になる。直接連絡が可能になると、直接スタッフに予約が入り、それに合わせてシフトを組むことも可能となる。

このような顧客管理システムと上述のシフトマッチングシステムによれば、顧客の予約に合わせてシフトを組むといった新しいシフトの組み方が可能となる。特に、担当のスタッフが予約当日は休みであるにも関わらず1時間だけ顔を出してくれるといったサービスは顧客にとってはとても嬉しいことであり、顧客が予約を入れた際にはサーバー２からアルバイト端末４へ通知がなされ、当該予約時間に短時間出勤することを促す表示がなされる。これに対してアルバイト端末４から出勤を希望する申請を行った場合には、店長端末３に対してその旨の通知がなされ、店長の承認を経て当該スタッフのシフトが確定する。この際の時給に対する係数は通常より高めに設定される。

これと関連し、顧客端末４からは、現在どのアルバイトが出勤しているかわかるように設計することができる。具体的には、顧客が顧客端末４からサーバー２に問い合わせ情報を送ると、サーバー２は、チェックイン、チェックアウト情報に基づき、現在出勤しているアルバイトを顧客端末４に通知する。もちろん、シフト表に基づいて通知することもできる。

さらに、顧客端末４から店の予約を入れることができる。これは、店の予約台帳に直接ではなく、担当するスタッフへの個人的な連絡の形を取ることができる。そして、予約が確定した場合、サーバーは、当該スタッフが優先的にシフトに入るように、当該アルバイトスタッフの当該シフト枠に対する時給の係数を高く設定する。ここで、顧客端末から予約が入ったタイミングが当該予約時間に近ければ近いほど、当該予約客を担当するアルバイトの当該予約時間への時給が高くなるように係数が設定され、当該アルバイトの当該時間帯への出勤希望がさらに促されるようにしてもよい。これを一歩進めて、顧客が顧客端末４からアルバイトのシフトをリクエストできるように設計することもできる。さらに、顧客に対する担当スタッフが決まっている場合に、これを利用してアルバイトのシフトを調整することができる。例えば、ある顧客のカルテに対し担当のスタッフが２名いた場合、この２名がなるべく重複しないようにシフト管理することで、当該顧客が不意に来店した際に担当が不在という事態を回避できる。さらに、アルバイトシフト枠に対するあるアルバイトの出勤予定が確定された後、当該アルバイトの担当する顧客が複数来店した場合、この担当顧客数に応じて高くなる変数を算入することにより、当該アルバイトシフト枠に対するそのアルバイトの時給が高くなるようにして、事後的にボーナスを与える仕組みを構築しても良い。

顧客端末４には自動決済機能を付加することができる。すなわち、顧客がクレジットカード情報などの決済情報をサーバー２に登録した場合には、顧客が顧客端末４に表示された「精算」ボタンを押すことで精算できるほか、顧客が顧客端末４を持って店を出た時に、GPSなどの位置情報検出手段によりこれを検出し、自動的に精算することができる。これにより、顧客は会計せずに店を出ることができるから、レジに並ぶ必要もなく、特別感を味わうことができる。さり気なく奢ることもでき、接待などで使いやすい。顧客端末４には月額決済機能を付加することもできる。顧客はクレジットカードにより月額を支払うことができる。顧客データベースには顧客のランクが記録されるが、このランクに応じ、ツケで支払うことができるように設計することもできる。

顧客端末４には、店外であっても、当該飲食店の顧客同士が接近した際にこれを互いの顧客端末４に知らせるアラート機能を設けることができる。GPS等の位置情報検出手段によりこれを実現し、これにより、顧客同士が知り合うきっかけになり、ひいては当該飲食店への来店を促すことにつながる。

店長端末２から操作可能な機能としては、分析機能がある。例えば、あるアルバイトが出勤している時間内の客単価が他のアルバイトと比べて高いといったことを客観的なデータから割り出すことができる。

また、店長端末２からは、顧客に求人を出すことができる。この際、顧客のデータベースから顧客をセグメント化し、特定のセグメントの顧客端末４にのみ求人の表示を出すことができる。

以上のように、本発明のシフトマッチングシステム及び顧客管理システムを利用すれば、アルバイトのシフトと時給をより実態に即した形で流動的に運用できる。また、スタッフに対する顧客の支持率や、当該日程にそのスタッフの担当する顧客が何人いるか、誰が接客すると客単価が高いかといった要素でシフトを決めることもできるから、スタッフのモチベーションがあがり、スタッフが顧客を引っ張ってくることも増える。このようなアルバイトのデータベースにはOB、OGも入ることができ、能力の高いスタッフがより大きな報酬を得て自由に働くことが可能となる。

１ シフトマッチングシステム
２ サーバー
３ 店長端末
４ アルバイト端末
５ 顧客端末
３１ 店長アプリケーション
４１ アルバイトアプリケーション

Claims (11)

1. 店長が操作する店長端末と、複数のアルバイトがそれぞれ所持するアルバイト端末と、サーバーとを有し、
   前記店長端末から必要なアルバイトシフト枠の条件としての日時及びポジションについての決定信号が入力されると、
   前記サーバーに保存されたアルバイトデータベースから、これらの条件を満たすアルバイトが抽出されるとともに、前記サーバーに保存された時給算出基準に基づき当該アルバイトシフト枠に対応する時給が算出され、
   当該日時、ポジション、算出された時給が、抽出されたアルバイト端末に表示され、
   この表示に対しアルバイト端末から承認信号が入力されると、当該アルバイトシフト枠に対するそのアルバイトの出勤予定及び時給が確定される、
   シフトマッチングシステム。
2. 前記時給算出基準は、当該アルバイトシフト枠の時間の長さにより変化する変数を含み、当該アルバイトシフト枠の時間の長さにより算出される時給が変化する、請求項１に記載のシフトマッチングシステム。
3. 前記時給算出基準は、アルバイトシフト枠の日時までの残時間により変化する変数を含み、この残時間に応じて算出される時給が変化し、さらに残時間が減っていくにつれてこの時給が変化し、この時給が抽出されたアルバイト端末に反映されて表示される、請求項１に記載のシフトマッチングシステム。
4. 前記アルバイトシフト枠は、前記サーバーに保存された実績データベースにおける過去の類似する日程を参照して導き出されると共に前記店長端末に表示され、前記店長端末からの決定信号により確定される、請求項１に記載のシフトマッチングシステム。
5. アルバイトシフト枠に対するそのアルバイトの出勤予定が確定された後、当該アルバイトのアルバイト端末から、当該出勤予定に対するキャンセル希望信号が発せられた場合、アルバイトシフト枠の日時までの残時間が算出され、この残時間に応じて算出される変数を算入することによりキャンセル料が算出され、このアルバイトシフト枠及びキャンセル料が当該アルバイトのアルバイト端末に表示され、
   この表示に対し当該アルバイト端末から確認信号が入力されると、店長端末にこのアルバイトシフト枠及びキャンセル料が表示され、これに対し店長端末から承認信号が入力されると、
   当該アルバイトシフト枠に対するそのアルバイトの出勤予定がキャンセルされると共にキャンセル料が決定される、請求項１に記載のシフトマッチングシステム。
6. アルバイトシフト枠に対するそのアルバイトの出勤予定が確定された後、前記店長端末からの当該出勤予定に対する取り消し要請信号が発せられた場合、アルバイトシフト枠の日時までの残時間が算出され、この残時間に応じて算出される変数を算入することにより取消料が算出され、このアルバイトシフト枠及び取消料が当該アルバイトのアルバイト端末に表示され、
   この表示に対し当該アルバイト端末から承認信号が入力されると、当該アルバイトシフト枠に対するそのアルバイトの出勤予定が取り消されると共に取消料が決定される、請求項１に記載のシフトマッチングシステム。
7. 顧客端末から予約が入った場合に、当該予約客を担当するアルバイトが当該予約時間への時給が高くなるように係数が設定され、当該アルバイトの当該時間帯への出勤希望が促される、請求項１に記載のシフトマッチングシステム。
8. 前記顧客端末から予約が入ったタイミングが当該予約時間に近ければ近いほど、当該予約客を担当するアルバイトの当該予約時間への時給が高くなるように係数が設定され、当該アルバイトの当該時間帯への出勤希望がさらに促される、請求項７に記載のシフトマッチングシステム。
9. 顧客端末から、当該顧客を担当するアルバイトの出勤についての希望を受け付け、希望のあった当該時間への当該アルバイトの時給が高くなるように係数が設定され、当該アルバイトの当該時間帯への出勤希望が促される、請求項１に記載のシフトマッチングシステム。
10. ある顧客カルテに対し担当のスタッフが複数いた場合、当該複数スタッフがなるべく重複しないようにシフト管理することで、当該顧客が不意に来店した際に担当が不在という事態を回避する、請求項１に記載のシフトマッチングシステム。
11. アルバイトシフト枠に対するあるアルバイトの出勤予定が確定された後、当該アルバイトの担当する顧客が複数来店した場合、この担当顧客数に応じて高くなる変数を算入することにより、当該アルバイトシフト枠に対するそのアルバイトの時給が高くなる、請求項１に記載のシフトマッチングシステム。

Images