(57)【特許請求の範囲】
【請求項１】
資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する要求取得処理と、
少なくとも前記融通先の需要予測に関する需要予測情報と既存の前記資源との対比結果から前記融通先で不足する前記資源を判断する判断処理と、
前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する融通処理と、
前記要求情報への応答として、融通可能な前記資源の状況を表す返答情報を前記融通元から受け付ける受付処理と、
前記融通元に対して、少なくとも前記融通先への前記資源の融通に係る融通手当を含む報酬を与える精算処理と、を有し、
前記融通処理では、前記需要予測情報を用いた前記判断処理の結果に基づく前記要求情報への応答としての前記返答情報を用いて前記融通情報を生成し、
１以上のプロセッサにより実行される、
店舗支援方法。
【請求項２】
資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する要求取得処理と、
前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する融通処理と、を有し、
前記融通情報は、少なくとも前記融通先の需要予測に関する需要予測情報に基づく情報であって、
前記需要予測情報を、前記要求情報と対比可能な態様で出力する対比処理と、
前記需要予測情報と前記要求情報との対比結果から前記資源を融通することの妥当性を検証する検証処理と、を更に有し、
前記融通処理では、前記需要予測情報を用いた前記妥当性の検証結果に基づいて前記融通情報を生成することで、前記需要予測情報に基づく前記融通情報を生成し、
１以上のプロセッサにより実行される、
店舗支援方法。
【請求項３】
資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する要求取得処理と、
少なくとも前記融通先の需要予測に関する需要予測情報と既存の前記資源との対比結果から前記融通先で不足する前記資源を判断する判断処理と、
前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する融通処理と、
前記要求情報への応答として、融通可能な前記資源の状況を表す返答情報を前記融通元から受け付ける受付処理と、
前記融通先への前記資源の融通を行った場合に、前記融通先と前記融通元との少なくとも一方に及ぼし得る効果を推定する効果推定処理と、を有し、
前記融通処理では、前記需要予測情報を用いた前記判断処理の結果に基づく前記要求情報への応答としての前記返答情報を用いて前記融通情報を生成し、
１以上のプロセッサにより実行される、
店舗支援方法。
【請求項４】
前記融通情報を前記融通先に通知する通知処理を更に有する、
請求項１〜３のいずれか１項に記載の店舗支援方法。
【請求項５】
前記融通先と、前記融通元と、前記資源として前記融通先に融通される人員との少なくともいずれかから、前記資源の融通の評価に関する評価情報を受け付ける評価処理を更に有する、
請求項１〜４のいずれか１項に記載の店舗支援方法。
【請求項６】
前記融通先に融通する前記資源の所在に関する所在情報に基づいて前記融通元を探索する探索処理を更に有する、
請求項１〜５のいずれか１項に記載の店舗支援方法。
【請求項７】
前記資源として前記融通先に融通される人員に求める作業内容と作業スキルとの少なくとも一方を指定する作業指定情報を受け付ける作業指定処理を更に有する、
請求項１〜６のいずれか１項に記載の店舗支援方法。
【請求項８】
前記融通先において前記資源が不足するに至った原因を推定する原因推定処理を更に有する、
請求項１〜７のいずれか１項に記載の店舗支援方法。
【請求項９】
前記資源は、前記融通先の営業に用いられる設備を含む、
請求項１〜８のいずれか１項に記載の店舗支援方法。
【請求項１０】
前記融通元は、前記融通先とは別の店舗を含む、
請求項１〜９のいずれか１項に記載の店舗支援方法。
【請求項１１】
請求項１〜１０のいずれか１項に記載の店舗支援方法を、１以上のプロセッサに実行させるためのプログラム。
【請求項１２】
資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する要求取得部と、
少なくとも前記融通先の需要予測に関する需要予測情報と既存の前記資源との対比結果から前記融通先で不足する前記資源を判断する判断部と、
前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する融通部と、
前記要求情報への応答として、融通可能な前記資源の状況を表す返答情報を前記融通元から受け付ける受付部と、
前記融通元に対して、少なくとも前記融通先への前記資源の融通に係る融通手当を含む報酬を与える精算部と、を有し、
前記融通部は、前記需要予測情報を用いた前記判断部の結果に基づく前記要求情報への応答としての前記返答情報を用いて前記融通情報を生成する、
店舗支援システム。
【請求項１３】
資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する要求取得部と、
前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する融通部と、を有し、
前記融通情報は、少なくとも前記融通先の需要予測に関する需要予測情報に基づく情報であって、
前記需要予測情報を、前記要求情報と対比可能な態様で出力する対比部と、
前記需要予測情報と前記要求情報との対比結果から前記資源を融通することの妥当性を検証する検証部と、を更に有し、
前記融通部は、前記需要予測情報を用いた前記妥当性の検証結果に基づいて前記融通情報を生成することで、前記需要予測情報に基づく前記融通情報を生成する、
店舗支援システム。
【請求項１４】
資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する要求取得部と、
少なくとも前記融通先の需要予測に関する需要予測情報と既存の前記資源との対比結果から前記融通先で不足する前記資源を判断する判断部と、
前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する融通部と、
前記要求情報への応答として、融通可能な前記資源の状況を表す返答情報を前記融通元から受け付ける受付部と、
前記融通先への前記資源の融通を行った場合に、前記融通先と前記融通元との少なくとも一方に及ぼし得る効果を推定する効果推定部と、を有し、
前記融通部は、前記需要予測情報を用いた前記判断部の結果に基づく前記要求情報への応答としての前記返答情報を用いて前記融通情報を生成する、
店舗支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に店舗支援方法、プログラム及び店舗支援システムに関し、より詳細には、店舗の営業を支援する店舗支援方法、プログラム及び店舗支援システムに関する。
【背景技術】
【０００２】
特許文献１には、店舗情報管理装置と、複数の店舗業務端末と、を備えた店舗システムが記載されている。
【０００３】
この店舗システムにおいては、店舗業務端末ごとに作業開始時刻、作業終了時刻及び各端末への送信時刻を作業指示情報として、予め店舗情報管理装置に登録している。店舗情報管理装置は、タイマ装置の持つ時刻と、各店舗業務端末への送信時刻との一致判定処理を行い、一致した作業指示情報について作業指示情報を抽出し、作業指示送信ファイルを作成し店舗業務端末へ送信する。各店舗業務端末では、受信した作業指示送信ファイルに基づき、作業指示内容の画面表示を実行する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平１０−２０８１４８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、特許文献１に記載のシステムでは、例えば、繁忙期等において、作業指示を受ける作業者（店員）の数が足りない等、店舗の営業に必要な資源が不足することで、店舗の営業に支障が生じる可能性がある。
【０００６】
本開示は上記事由に鑑みてなされており、店舗の営業に必要な資源の不足により店舗の営業に支障が生じにくい、店舗支援方法、プログラム及び店舗支援システムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本開示の一態様に係る店舗支援方法は、要求取得処理と、判断処理と、融通処理と、受付処理と、精算処理と、を有する。前記要求取得処理は、資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する処理である。前記判断処理は、少なくとも前記融通先の需要予測に関する需要予測情報と既存の前記資源との対比結果から前記融通先で不足する前記資源を判断する処理である。前記融通処理は、前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する処理である。前記受付処理は、前記要求情報への応答として、融通可能な前記資源の状況を表す返答情報を前記融通元から受け付ける処理である。前記精算処理は、前記融通元に対して、少なくとも前記融通先への前記資源の融通に係る融通手当を含む報酬を与える処理である。前記融通処理では、前記需要予測情報を用いた前記判断処理の結果に基づく前記要求情報への応答としての前記返答情報を用いて前記融通情報を生成する。前記店舗支援方法は、１以上のプロセッサにより実行される。
本開示の一態様に係る店舗支援方法は、要求取得処理と、融通処理と、を有する。前記要求取得処理は、資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する処理である。前記融通処理は、前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する処理である。前記融通情報は、少なくとも前記融通先の需要予測に関する需要予測情報に基づく情報である。前記店舗支援方法は、対比処理と、検証処理と、を更に有する。前記対比処理は、前記需要予測情報を、前記要求情報と対比可能な態様で出力する処理である。前記検証処理は、前記需要予測情報と前記要求情報との対比結果から前記資源を融通することの妥当性を検証する処理である。前記融通処理では、前記需要予測情報を用いた前記妥当性の検証結果に基づいて前記融通情報を生成することで、前記需要予測情報に基づく前記融通情報を生成する。前記店舗支援方法は、１以上のプロセッサにより実行される。
本開示の一態様に係る店舗支援方法は、要求取得処理と、判断処理と、融通処理と、受付処理と、効果推定処理と、を有する。前記要求取得処理は、資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する処理である。前記判断処理は、少なくとも前記融通先の需要予測に関する需要予測情報と既存の前記資源との対比結果から前記融通先で不足する前記資源を判断する処理である。前記融通処理は、前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する処理である。前記受付処理は、前記要求情報への応答として、融通可能な前記資源の状況を表す返答情報を前記融通元から受け付ける処理である。前記効果推定処理は、前記融通先への前記資源の融通を行った場合に、前記融通先と前記融通元との少なくとも一方に及ぼし得る効果を推定する処理である。前記融通処理では、前記需要予測情報を用いた前記判断処理の結果に基づく前記要求情報への応答としての前記返答情報を用いて前記融通情報を生成する。前記店舗支援方法は、１以上のプロセッサにより実行される。
【０００８】
本開示の一態様に係るプログラムは、前記店舗支援方法を、１以上のプロセッサに実行させるためのプログラムである。
【０００９】
本開示の一態様に係る店舗支援システムは、要求取得部と、判断部と、融通部と、受付部と、精算部と、を有する。前記要求取得部は、資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する。前記判断部は、少なくとも前記融通先の需要予測に関する需要予測情報と既存の前記資源との対比結果から前記融通先で不足する前記資源を判断する。前記融通部は、前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する。前記受付部は、前記要求情報への応答として、融通可能な前記資源の状況を表す返答情報を前記融通元から受け付ける。前記精算部は、前記融通元に対して、少なくとも前記融通先への前記資源の融通に係る融通手当を含む報酬を与える。前記融通部は、前記需要予測情報を用いた前記判断部の結果に基づく前記要求情報への応答としての前記返答情報を用いて前記融通情報を生成する。
本開示の一態様に係る店舗支援システムは、要求取得部と、融通部と、を有する。前記要求取得部は、資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する。前記融通部は、前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する。前記融通情報は、少なくとも前記融通先の需要予測に関する需要予測情報に基づく情報である。前記店舗支援システムは、対比部と、検証部と、を更に有する。前記対比部は、前記需要予測情報を、前記要求情報と対比可能な態様で出力する。前記検証部は、前記需要予測情報と前記要求情報との対比結果から前記資源を融通することの妥当性を検証する。前記融通部は、前記需要予測情報を用いた前記妥当性の検証結果に基づいて前記融通情報を生成することで、前記需要予測情報に基づく前記融通情報を生成する。
本開示の一態様に係る店舗支援システムは、要求取得部と、判断部と、融通部と、受付部と、効果推定部と、を有する。前記要求取得部は、資源を用いて営業を行う店舗である融通先から、前記融通先で不足する前記資源に関する要求情報を取得する。前記判断部は、少なくとも前記融通先の需要予測に関する需要予測情報と既存の前記資源との対比結果から前記融通先で不足する前記資源を判断する。前記融通部は、前記要求情報に応じて、融通元から前記融通先に対して前記資源を融通するための融通情報を生成する。前記受付部は、前記要求情報への応答として、融通可能な前記資源の状況を表す返答情報を前記融通元から受け付ける。前記効果推定部は、前記融通先への前記資源の融通を行った場合に、前記融通先と前記融通元との少なくとも一方に及ぼし得る効果を推定する。前記融通部は、前記需要予測情報を用いた前記判断部の結果に基づく前記要求情報への応答としての前記返答情報を用いて前記融通情報を生成する。
【発明の効果】
【００１０】
本開示によれば、店舗の営業に必要な資源の不足により店舗の営業に支障が生じにくい、という利点がある。
【図面の簡単な説明】
【００１１】
【図１】図１は、実施形態１に係る店舗支援システムの構成を示す概略システム構成図である。
【図２】図２は、実施形態１に係る店舗支援方法の事前工程の使用例を示す概念図である。
【図３】図３は、同上の店舗支援方法の事前工程に関するフローチャートである。
【図４】図４は、同上の店舗支援方法の当日工程の使用例を示す概念図である。
【図５】図５は、同上の店舗支援方法の事後工程の使用例を示す概念図である。
【図６】図６は、同上の店舗支援方法において、融通元の候補としての店舗にてオファー情報が受諾された場合の概略シーケンス図である。
【図７】図７は、同上の店舗支援方法において、融通元の候補としての店舗にてオファー情報が拒否された場合の概略シーケンス図である。
【図８】図８は、実施形態２に係る店舗支援方法の使用例を示す概念図である。
【発明を実施するための形態】
【００１２】
（実施形態１）
以下、本実施形態に係る店舗支援方法、プログラム及び店舗支援システム１（図１参照）について、図１〜図７を参照して説明する。
【００１３】
（１）概要
本実施形態に係る店舗支援方法は、図１及び図２に示すように、店舗Ａ１の営業を支援する方法である。本実施形態では、店舗支援方法が、コンビニエンスストア、スーパーマーケット、百貨店、ドラッグストア、家電量販店又はホームセンター等の小売店の店舗Ａ１に導入される場合を例として説明する。
【００１４】
本実施形態に係る店舗支援方法は、この種の店舗Ａ１に関して、店舗Ａ１の営業に用いられる資源の融通を支援することにより、店舗Ａ１の営業を支援する。本開示でいう「資源」は、店舗Ａ１の営業に必要な資源であって、例えば、人員及び物品等を含む。資源としての人員は、店舗Ａ１の営業に関連する作業を実行する「作業者」であって、一例として、店舗Ａ１の店員（アルバイト及びパートタイマを含む）、配送業者、清掃業者及びメンテナンス業者等を含む。また、資源としての物品は、一例として、店舗Ａ１で販売される商品を含む。さらに、資源としての物品は、例えば、レジ（register）、複合機又は什器等の店舗Ａ１に設置される設備、レジ袋、レジロール紙、買物かご、清掃用具、キャンペーン等で配布されるノベルティグッズ、並びに商品の販売促進に用いるポップ及びチラシ等を含む。
【００１５】
すなわち、上述したような店舗Ａ１の営業に用いられる資源が、ある店舗Ａ１にて不足することがあれば、この店舗Ａ１での営業に支障をきたす可能性がある。具体的には、例えば、資源としての店員が不足していると、顧客のレジ待ちの時間が長くなったり、店舗Ａ１の清掃が行き届かなかったりと、店舗Ａ１での営業に支障をきたす可能性がある。同様に、例えば、資源としての商品が不足していると、顧客が所望する商品を購入できなかったり、商品を販売できないことで機会損失が生じたりと、店舗Ａ１での営業に支障をきたす可能性がある。
【００１６】
そこで、本実施形態に係る店舗支援方法では、このような店舗Ａ１の営業に用いられる資源の融通を支援することで、店舗Ａ１での営業に支障が生じにくくする。つまり、店舗Ａ１の営業に用いられる資源について不足が生じるような場合において、この店舗Ａ１を融通先Ａ１１として、融通元Ａ１２から、資源を融通先Ａ１１（店舗Ａ１）に融通する。本開示でいう資源の「融通」とは、資源をお互いの間でやりくりすること、つまり不十分な物事（不足する資源）を種々に工夫して都合をつけることを意味する。つまり、店舗支援方法では、例えば、資源に余裕のある融通元Ａ１２から、資源が不足する融通先Ａ１１に対して、資源を貸与又は譲渡することで、融通元Ａ１２と融通先Ａ１１との間で、資源をやりくりする。これにより、融通先Ａ１１である店舗Ａ１での資源の不足を解消又は軽減し、店舗Ａ１での営業に支障が生じにくくなる。
【００１７】
ここにおいて、融通元Ａ１２は、融通先Ａ１１とは別の店舗Ａ１であってもよいし、例えば、店舗Ａ１を展開するチェーン本部Ａ２、又は人材派遣会社Ａ３等であってもよい。融通元Ａ１２が融通先Ａ１１とは別の店舗Ａ１である場合、融通先Ａ１１の店舗Ａ１に融通される資源は、融通元Ａ１２である店舗Ａ１においても営業に用いられる資源である。例えば、資源が店員であれば、融通先Ａ１１で店員が不足する場合に、融通元Ａ１２の店員が、融通先Ａ１１に融通されることになる。
【００１８】
ところで、本実施形態に係る店舗支援方法は、上述したような資源の融通に関連して、店舗Ａ１の需要予測に関する需要予測情報Ｄ１（図２参照）を用いている。すなわち、店舗支援方法は、要求取得処理と、融通処理と、を有する。要求取得処理は、資源を用いて営業を行う店舗Ａ１である融通先Ａ１１から、融通先Ａ１１で不足する資源に関する要求情報Ｄ２（図２参照）を取得する処理である。融通処理は、要求情報Ｄ２に応じて、融通元Ａ１２から融通先Ａ１１に対して資源を融通するための融通情報Ｄ９（図２参照）を生成する処理である。融通情報Ｄ９は、少なくとも融通先Ａ１１の需要予測に関する需要予測情報Ｄ１に基づく情報である。
【００１９】
すなわち、上述した店舗支援方法によれば、融通先Ａ１１である店舗Ａ１の営業で用いられる資源が不足するような場合、融通先Ａ１１からの要求情報Ｄ２に応じて、融通情報Ｄ９を生成することができる。融通情報Ｄ９は、融通元Ａ１２から融通先Ａ１１に資源を融通するための情報であるので、これにより、融通情報Ｄ９に従って、融通元Ａ１２から融通先Ａ１１への資源の融通が可能となる。しかも、融通情報Ｄ９は、少なくとも需要予測情報Ｄ１に基づく情報であるため、融通情報Ｄ９には、融通先Ａ１１の需要予測に関する情報（需要予測情報Ｄ１）が反映されることになる。したがって、融通先Ａ１１である店舗Ａ１の需要予測を反映した適切な資源の融通が実現しやすく、結果的に、店舗Ａ１の営業に必要な資源の不足により店舗Ａ１の営業に支障が生じにくい、という利点がある。
【００２０】
また、本実施形態に係る店舗支援方法は、一例として、店舗支援システム１にて実行される。言い換えれば、店舗支援システム１は、上述した店舗支援方法を具現化するための一態様である。つまり、店舗支援システム１は、店舗Ａ１の営業に用いられる資源の融通を支援することで、店舗Ａ１での営業に支障が生じにくくする。本実施形態に係る店舗支援システム１は、要求取得部１２と、融通部２０と、を有する。要求取得部１２は、資源を用いて営業を行う店舗Ａ１である融通先Ａ１１から、融通先Ａ１１で不足する資源に関する要求情報Ｄ２を取得する。融通部２０は、要求情報に応じて、融通元Ａ１２から融通先Ａ１１に対して資源を融通するための融通情報Ｄ９を生成する。融通情報Ｄ９は、少なくとも融通先Ａ１１の需要予測に関する需要予測情報に基づく情報である。
【００２１】
ここにおいて、本実施形態に係る店舗支援システム１は、１以上のプロセッサ及び１以上のメモリを有するコンピュータシステムを主構成とする。言い換えれば、本実施形態に係る店舗支援方法は、コンピュータシステム（店舗支援システム１）上で用いられる。つまり、店舗支援方法は、プログラムでも具現化可能である。本実施形態に係るプログラムは、本実施形態に係る店舗支援方法を、１以上のプロセッサに実行させるためのプログラムである。
【００２２】
（２）詳細
以下、本実施形態に係る店舗支援方法、プログラム及び店舗支援システム１について詳しく説明する。
【００２３】
（２．１）前提
本実施形態では、店舗支援方法が適用される店舗Ａ１は、コーポレートチェーン（レギュラーチェーン）又はフランチャイズチェーンのようにチェーン展開されている複数の店舗Ａ１の１つであることと仮定する。つまり、店舗支援方法にて営業に用いる資源が融通される店舗Ａ１（融通先Ａ１１）は、チェーン展開されている複数の店舗Ａ１のいずれかの店舗Ａ１である。特に、本実施形態では一例として、店舗Ａ１がコンビニエンスストアである場合について説明する。この種の店舗Ａ１には、店舗Ａ１の管理を行うオーナＢ１，Ｂ２（図２参照）と、店舗Ａ１に雇用されている店員Ｃ１，Ｃ２（図２参照）と、が対応付けられている。
【００２４】
本開示でいう「融通先」は、（融通元Ａ１２から）資源の融通を受ける主体であって、資源を用いて営業を行う店舗Ａ１である。すなわち、営業に必要な資源が不足する店舗Ａ１があれば、この店舗Ａ１は、融通先Ａ１１として、店舗支援方法によって資源の融通を受ける主体となる。本実施形態では、上述したように、融通の対象となる「資源」が店員Ｃ１，Ｃ２であるので、店員Ｃ１が不足している店舗Ａ１が、融通先Ａ１１となる。
【００２５】
本開示でいう「融通元」は、（融通先Ａ１１に）資源を融通する主体である。すなわち、営業に必要な資源が不足する店舗Ａ１があれば、融通元Ａ１２は、この店舗Ａ１（融通先Ａ１１）に対して、店舗支援方法によって資源を融通する主体となる。ここで、融通元Ａ１２は、上述したように、融通先Ａ１１とは別の店舗Ａ１であってもよいし、例えば、店舗Ａ１を展開するチェーン本部Ａ２、又は人材派遣会社Ａ３等であってもよい。
【００２６】
本実施形態では一例として、融通元Ａ１２は、融通先Ａ１１とは別の店舗Ａ１を含むこととする。ただし、融通元Ａ１２と融通先Ａ１１とは、互いに関連性のある店舗Ａ１である。本実施形態では一例として、融通元Ａ１２及び融通先Ａ１１は、いずれも同一チェーンの店舗Ａ１であって、かつ近隣（例えば直線距離で５ｋｍ以内）に存在する店舗Ａ１である、という関連性を持つ。さらに、本実施形態では、人材派遣会社Ａ３も融通元となり得ることと仮定する。
【００２７】
また、本開示でいう「資源」は、店舗支援方法によって支援される融通の対象であって、上述したように、店舗Ａ１の営業に必要な資源であり、例えば、人員及び物品等を含む。本実施形態では一例として、融通の対象となる「資源」は、店舗Ａ１（コンビニエンスストア）の営業に必要な「人員」であることとする。より詳細には、本実施形態のように、融通元Ａ１２が（融通先Ａ１１とは別の）店舗Ａ１である場合においては、融通元Ａ１２で雇用されている店員Ｃ２が、融通の対象たる「資源」である。
【００２８】
また、以下では融通先Ａ１１である店舗Ａ１と、融通元Ａ１２である店舗Ａ１とを区別するために、融通先Ａ１１である店舗Ａ１を「店舗Ａ１１」、融通元Ａ１２である店舗Ａ１を「店舗Ａ１２」ということもある。
【００２９】
また、本開示でいう「店舗」は、不動産（施設）としての店舗Ａ１だけでなく、組織としての店舗Ａ１を含むこともある。例えば、組織としての店舗Ａ１には、店舗Ａ１の管理者（オーナＢ１，Ｂ２）、店舗Ａ１で雇用されている店員Ｃ１，Ｃ２が含まれてもよい。一例として、融通先Ａ１１から要求情報Ｄ２を取得する要求取得処理における要求情報Ｄ２の取得元である「融通先Ａ１１」は、不動産としての店舗Ａ１に限らず、店舗Ａ１のオーナＢ１等を指すこともある。同様に、店舗Ａ１２についても、不動産としての店舗Ａ１ではなく、店舗Ａ１２のオーナＢ２等を指すこともある。
【００３０】
また、本開示でいう「作業」は、店舗Ａ１において発生する作業であって、融通の対象である資源としての人員（店員Ｃ２）に業務として課され、人員によって実行される種々の作業を意味する。一般的に、このような「作業」は、タスク（task）とも呼ばれ、店舗Ａ１の営業に関連する作業である。店舗Ａ１がコンビニエンスストアであれば、作業の一例として、商品の陳列、棚卸、トイレ清掃、レジ対応、ホットスナック対応、電気ポットの湯の補充、ホットスナックの補充（作り置き）、ごみ袋の交換、商品の品出し及び消耗品の補充等がある。さらに、店舗Ａ１の内部で実行される作業だけでなく、例えば、店舗Ａ１の周辺道路の清掃等の、店舗Ａ１の外部で実行される作業も、「作業」に含まれる。
【００３１】
また、本実施形態においては一例として、融通先Ａ１１となり得る店舗Ａ１の数が、１００００店以上である場合を想定する。以下では、これら複数（多数）の店舗Ａ１のうちの１つが、融通先Ａ１１である場合について説明するが、実際には、複数の店舗Ａ１がそれぞれ融通先Ａ１１となり得る。すなわち、店舗支援方法は、複数の店舗Ａ１のそれぞれを支援の対象とし得るが、以下では、説明を簡単にするため、融通先Ａ１１が１つである場合を例に説明する。
【００３２】
（２．２）店舗支援システムの構成
次に、本実施形態に係る店舗支援システム１の構成について、図１を参照して説明する。
【００３３】
店舗支援システム１は、上述したように、店舗Ａ１の営業に用いられる資源の融通を支援することで、店舗Ａ１の営業を支援するシステムである。本実施形態では、上述したように、資源の融通先Ａ１１及び融通元Ａ１２は、いずれも同一チェーンの店舗Ａ１であって、かつ近隣に存在する店舗Ａ１である。また、本実施形態では、融通の対象となる資源は、店員Ｃ１，Ｃ２である。すなわち、本実施形態に係る店舗支援システム１は、同一チェーンの店舗Ａ１であって、かつ近隣に存在する店舗Ａ１間において、店舗Ａ１の営業に用いられる資源としての店員Ｃ１，Ｃ２の融通を支援するために用いられる。
【００３４】
本実施形態では一例として、店舗支援システム１は、チェーン本部Ａ２に設置されたサーバ装置である。チェーン本部Ａ２は、少なくとも融通先Ａ１１である店舗Ａ１を管轄する組織（施設）である。本実施形態では、融通先Ａ１１及び融通元Ａ１２は、同一チェーンの店舗Ａ１であるので、いずれもチェーン本部Ａ２によって管理されている。
【００３５】
また、本実施形態では、店舗支援システム１は、インターネット等のネットワークＮＴ１に接続されている。ネットワークＮＴ１には、融通先Ａ１１としての店舗Ａ１のオーナＢ１が使用する情報端末３１と、融通元Ａ１２としての店舗Ａ１のオーナＢ２が使用する情報端末３２と、が接続可能である。さらに、ネットワークＮＴ１には、人材派遣会社Ａ３のオペレータＢ３が使用する情報端末３３と、融通元Ａ１２としての店舗Ａ１に雇用されている店員Ｃ２が使用する情報端末３４と、が接続可能である。これらの情報端末３１〜３４は、例えば、スマートフォン、タブレット端末又はパーソナルコンピュータ等である。情報端末３１〜３４の各々は、例えば、通信事業者が提供する携帯電話網（キャリア網）又は公衆無線ＬＡＮ（Local Area Network）等を介してネットワークＮＴ１に接続されてもよい。
【００３６】
これにより、店舗支援システム１は、ネットワークＮＴ１を介して、少なくも情報端末３１〜３４と通信可能である。本開示でいう「通信可能」とは、有線通信又は無線通信の適宜の通信方式により、直接的、又はネットワークＮＴ１若しくは中継器等を介して間接的に、信号を授受できることを意味する。さらに、本実施形態では、複数の情報端末３１〜３４の間でも、相互に通信可能に構成されている。
【００３７】
ここにおいて、各店舗Ａ１には、ストアコンピュータ又はＰＯＳ（Point Of Sales）システム等が設置されている。ストアコンピュータ又はＰＯＳシステムは、それぞれ１つの店舗Ａ１に複数設けられていてもよい。ストアコンピュータは、店舗Ａ１の店員Ｃ１，Ｃ２又はオーナＢ１，Ｂ２等が所有する情報端末３１，３２，３４であってもよい。また、本実施形態では、ＰＯＳシステムは、ＩＤ−ＰＯＳデータを取り扱うことが可能な、いわゆる「ＩＤ−ＰＯＳ」である。ここでいう「ＩＤ−ＰＯＳデータ」は、ＰＯＳデータに顧客の識別情報（ＩＤ：identification）としての「顧客ＩＤ」が付加されたデータである。この種のＰＯＳシステム（ＩＤ−ＰＯＳ）は、顧客が買物を行う際に顧客の認証を行うことで、顧客の識別情報（顧客ＩＤ）を取得する。顧客の認証は、一例として、会員カード、ポイントカード又はクレジットカード等の各種カード等で実現されてもよいし、顧客の携帯情報端末との通信、又は生体認証（顔認証を含む）等によって実現されてもよい。
【００３８】
このようなストアコンピュータ又はＰＯＳシステムによれば、少なくとも店舗Ａ１における商品の購買履歴を実績データとして、ネットワークＮＴ１経由で、店舗支援システム１に送信することが可能である。特に、本実施形態では、ＰＯＳシステムは、ＩＤ−ＰＯＳデータを取り扱うことが可能であるため、例えば、会計が行われる度に、購入された商品の情報を、顧客の識別情報（顧客ＩＤ）と対応付けた状態で購買履歴として出力できる。
【００３９】
本実施形態では、店舗支援システム１は、上述したように要求取得部１２及び融通部２０を備えている。本実施形態では、店舗支援システム１は、需要予測部１１、対比部１３、検証部１４、効果推定部１５、原因推定部１６、作業指定部１７、探索部１８、受付部１９、通知部２１、評価部２２、通信部２３、収集部２４及びデータ格納部２５を更に備えている。つまり、店舗支援システム１は、需要予測部１１、要求取得部１２、対比部１３、検証部１４、効果推定部１５、原因推定部１６、作業指定部１７、探索部１８、受付部１９、融通部２０、通知部２１、評価部２２、通信部２３、収集部２４及びデータ格納部２５を備える。本実施形態では、店舗支援システム１は、上述したように、１以上のプロセッサ及び１以上のメモリを有するコンピュータシステム（ここではサーバ装置）を主構成とする。店舗支援システム１のうち、通信部２３及びデータ格納部２５以外の機能（需要予測部１１、要求取得部１２、対比部１３、検証部１４、融通部２０及び評価部２２等）は、１以上のプロセッサがプログラムを実行することによって具現化される。
【００４０】
需要予測部１１は、店舗Ａ１の需要を予測する需要予測処理を実行し、需要予測情報Ｄ１を生成する。需要予測処理で予測される店舗Ａ１の需要は、例えば、予測対象期間における、店舗Ａ１の売上高、客単価、ＬＴＶ（Life Time Value）の平均値、又は利益（粗利及び営業利益等を含む）等に関連する推定結果である。予測対象期間は、現在に対して将来に設定される期間であって、例えば、１日単位、１週間単位又は１か月単位等、任意の単位で設定される。需要予測処理で予測される需要は、店舗Ａ１ごとに予測されてもよいし、複数の店舗Ａ１について一括して予測されてもよい。本実施形態では一例として、需要予測処理において店舗Ａ１ごとに、需要が予測されて需要予測情報Ｄ１が生成される。
【００４１】
本開示でいう「推定」は、おしはかって定める（決める）ことを意味し、特に、人があれこれ考えて決めることに限らず、ある事実に基づいて何らかの決定を行うこと全般を含む。そのため、例えば、コンピュータシステムに対して入力情報が入力された場合に、コンピュータシステムが、入力情報に基づいて演算を行って何らかの情報を出力情報として出力していれば、コンピュータシステムで出力情報が「推定」されたことになる。すなわち、需要予測部１１であれば、後述する店舗Ａ１の運営情報が入力され、この運営情報に基づいて、予測対象期間の需要を特定することにより、店舗Ａ１の需要を推定することになる。
【００４２】
要求取得部１２は、資源を用いて営業を行う店舗Ａ１である融通先Ａ１１から、融通先Ａ１１で不足する資源に関する要求情報Ｄ２を取得する要求取得処理を実行する。
【００４３】
対比部１３は、需要予測情報Ｄ１を、要求情報Ｄ２と対比可能な態様で出力する対比処理を実行する。対比処理で用いられる需要予測情報Ｄ１は、需要予測情報Ｄ１そのものに限らず、需要予測情報Ｄ１に基づいて求まる情報であってもよい。例えば、需要予測情報Ｄ１から、予測対象期間における店舗Ａ１での資源の必要量（使用状況）が推定される場合、資源の必要量を需要予測情報Ｄ１として、要求情報Ｄ２と対比可能な態様で出力してもよい。つまり、売上高等の需要予測情報Ｄ１を、資源（本実施形態では店員Ｃ１）の必要数に換算して、対比処理での出力対象としてもよい。ここで、対比部１３が行う出力の態様には、例えば、データの出力（店舗支援システム１内での出力を含む）、送信、表示、音声出力、非一時的記録媒体への記録（書き込み）及び印刷（プリントアウト）等が含まれる。
【００４４】
検証部１４は、需要予測情報Ｄ１と要求情報Ｄ２との対比結果から資源を融通することの妥当性を検証する検証処理を実行する。ここでは、検証部１４は、対比部１３から出力される対比可能な態様の需要予測情報Ｄ１及び要求情報Ｄ２を用いて、検証処理を実行する。
【００４５】
効果推定部１５は、融通先Ａ１１への資源の融通を行った場合に、融通先Ａ１１と融通元Ａ１２との少なくとも一方に及ぼし得る効果を推定する効果推定処理を実行する。本実施形態では、融通先Ａ１１及び融通元Ａ１２はいずれも営業を行う店舗Ａ１であるので、効果推定処理で推定される効果は、融通先Ａ１１と融通元Ａ１２との少なくとも一方の営業に及ぼし得る効果である。
【００４６】
原因推定部１６は、融通先Ａ１１において資源が不足するに至った原因を推定する原因推定処理を実行する。
【００４７】
作業指定部１７は、資源として融通先Ａ１１に融通される人員（店員Ｃ２）に求める作業内容と作業スキルとの少なくとも一方を指定する作業指定情報Ｄ１１（図４参照）を受け付ける作業指定処理を実行する。
【００４８】
探索部１８は、所在情報に基づいて融通元Ａ１２を探索する探索処理を実行する。所在情報は、融通先Ａ１１に融通する資源の所在に関する情報である。探索処理では、融通元Ａ１２の候補となる店舗Ａ１の探索が行われる。
【００４９】
受付部１９は、要求情報Ｄ２への応答として、返答情報Ｄ６を融通元Ａ１２から受け付ける受付処理を実行する。返答情報Ｄ６は、融通可能な資源の状況を表す情報である。ここで、受付処理での返答情報Ｄ６の受付元である「融通元Ａ１２」は、不動産としての店舗Ａ１に限らず、店舗Ａ１のオーナＢ２等を指すこともある。
【００５０】
融通部２０は、要求情報Ｄ２に応じて、融通元Ａ１２から融通先Ａ１１に対して資源を融通するための融通情報Ｄ９を生成する融通処理を実行する。すなわち、融通部２０にて、融通情報Ｄ９が生成される。本実施形態では、融通部２０は、少なくとも検証部１４の検証結果、及び受付部１９が受け付けた返答情報Ｄ６等を用いて、融通情報を生成する。
【００５１】
通知部２１は、融通情報Ｄ９を融通先Ａ１１に通知する通知処理を実行する。ここで、通知部２１が行う通知の態様には、例えば、データの出力（店舗支援システム１内での出力を含む）、送信、表示、音声出力、非一時的記録媒体への記録（書き込み）及び印刷（プリントアウト）等が含まれる。
【００５２】
評価部２２は、融通先Ａ１１と、融通元Ａ１２と、資源として融通先Ａ１１に融通される人員（店員Ｃ２）との少なくともいずれかから、評価情報を受け付ける評価処理を実行する。評価情報は、資源の融通の評価に関する情報であって、融通先Ａ１１と、融通元Ａ１２と、資源としての店員Ｃ２との少なくともいずれかからの報告Ｄ１３，Ｄ１４，Ｄ１５（図４参照）に含まれ得る。
【００５３】
通信部２３は、直接的、又は他のネットワーク若しくは中継器等を介して間接的に、ネットワークＮＴ１に接続されている。通信部２３は、ネットワークＮＴ１に接続されているシステム又は端末との通信機能を有している。これにより、通信部２３は、ネットワークＮＴ１に接続されている情報端末３１〜３４、及び各店舗Ａ１のストアコンピュータ又はＰＯＳシステム等との間で、通信可能に構成される。
【００５４】
収集部２４は、通信部２３を用いて、ネットワークＮＴ１に接続されている複数（多数）のシステム又は端末から様々なデータを収集する。一例として、収集部２４では、店舗Ａ１に設置された各種センサ（カメラを含む）の検知結果、及びストアコンピュータ又はＰＯＳシステム等から、様々なデータを収集する。
【００５５】
データ格納部２５は、例えば、収集部２４で収集された様々なデータ等を格納する。また、データ格納部２５は、需要予測部１１、要求取得部１２、対比部１３、検証部１４、融通部２０及び評価部２２等での演算に必要な情報等を更に格納（記憶）する。さらに、データ格納部２５は、後述する需要予測処理で用いられる学習済みモデルについても格納する。データ格納部２５は、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）のような書き換え可能な不揮発性メモリを含む。
【００５６】
以上説明した店舗支援システム１の各部の動作の詳細については、「（２．３）店舗支援方法」の欄で説明する。
【００５７】
また、店舗支援システム１は、上記構成に加えて、ユーザインタフェース等を更に備えていてもよい。ただし、ユーザインタフェース等は、店舗支援システム１に必須の構成ではない。
【００５８】
ユーザインタフェースは、例えば、タッチパネルディスプレイを含み、ユーザの操作の受け付けと、ユーザへの情報の提示（表示）を行う。ユーザインタフェースは、タッチパネルディスプレイに限らず、例えば、キーボード、ポインティングデバイス、メカニカルなスイッチ、又はジェスチャセンサ等の入力装置を有していてもよい。また、ユーザインタフェースは、タッチパネルディスプレイに代えて、又はタッチパネルディスプレイと共に、音声入出力部を有していてもよい。
【００５９】
（２．３）店舗支援方法
以下、本実施形態に係る店舗支援方法について、図２〜図７を参照してより詳細に説明する。ここでは、店舗支援方法が店舗支援システム１にて実行される場合を例とする。
【００６０】
以下では一例として、ある店舗Ａ１にて、特定日に人員（店員Ｃ１）が不足するため、この店舗Ａ１を融通先Ａ１１として、融通元Ａ１２から資源としての人員（店員Ｃ２）を、特定日に融通先Ａ１１へ融通する場合を想定して説明する。特定日は一例として、「２０１９年１２月２０日」であることとする。特に、図２〜図４に例示するケースでは、融通元Ａ１２は、融通先Ａ１１とは別の店舗Ａ１であって、融通元Ａ１２で雇用されている店員Ｃ２が、特定日（１２月２０日）に、「資源」として融通先Ａ１１に融通される場合を想定している。ただし、これらの条件は、あくまで店舗支援方法を説明するための一つの具体例に過ぎず、店舗支援方法の適用範囲を制限する趣旨ではない。
【００６１】
以下では、店舗支援方法について、資源の融通に必要な融通情報Ｄ９を生成するまでの「事前工程」と、資源の融通を行う特定日（１２月２０日）に係る「当日工程」と、資源の融通を行った後の「事後工程」と、の３パートに分けて説明する。さらに、融通情報Ｄ９は、少なくとも融通先Ａ１１の需要予測に関する需要予測情報Ｄ１に基づく情報であるので、まずは需要予測情報Ｄ１を生成するための「需要予測処理」について説明する。
【００６２】
また、以下の説明において、例えば、チェーン本部Ａ２と店舗Ａ１との間でやり取りされるデータ（情報）は、実際には、店舗支援システム１とオーナＢ１，Ｂ２が使用する情報端末３１，３２との間で送受信されている。同様に、チェーン本部Ａ２と人材派遣会社Ａ３との間でやり取りされるデータ（情報）は、実際には、店舗支援システム１とオペレータＢ３が使用する情報端末３３との間で送受信されている。同様に、チェーン本部Ａ２又は店舗Ａ１と、店員Ｃ１，Ｃ２との間でやり取りされるデータ（情報）は、実際には、店舗支援システム１又はオーナＢ１，Ｂ２が使用する情報端末３１，３２と、店員Ｃ１，Ｃ２が使用する情報端末３４との間で送受信されている。より詳細には、個々の情報端末３１〜３４には、専用のアプリケーションソフト（プログラム）がインストールされており、このアプリケーションソフトを起動することにより、店舗支援システム１等との間でデータ（情報）の送受信が行われる。
【００６３】
言い換えれば、本実施形態に係る店舗支援方法は、コンピュータシステムのグラフィカルユーザインタフェース（ＧＵＩ：Graphical User Interface）上で用いられる。つまり、店舗支援方法は、コンピュータシステムを主構成とする情報端末３１〜３４にて、特定の操作画面を表示し、この操作画面上にてオーナＢ１，Ｂ２、オペレータＢ３又は店員Ｃ１，Ｃ２等の操作を受け付ける。これにより、以下に説明するような、例えば、チェーン本部Ａ２と店舗Ａ１との間でのデータ（情報）のやり取りが、実現される。
【００６４】
（２．３．１）需要予測処理
本実施形態では、需要予測情報Ｄ１を生成するための「需要予測処理」は、需要予測部１１にて実行される処理である。ここで、需要予測処理では、機械学習された学習済みモデルを利用して、店舗Ａ１の需要が予測される。
【００６５】
すなわち、需要予測部１１は、同一チェーンに属する（加盟する）多数の店舗Ａ１の実績データにて機械学習された学習済みモデルを利用して、店舗Ａ１の需要予測を行う。具体的には、需要予測部１１は、学習済みモデルを用いて、例えば運営情報を入力とし、需要予測情報Ｄ１を推定する。運営情報は、店舗Ａ１の運営状況に関する情報であって、例えば、品揃え（商品構成）に関する情報、具体的には、商品カテゴリごとの、ＳＫＵ（Stock Keeping Unit）数又はアイテム数等の情報を含む。
【００６６】
さらに、運営情報は、例えば、店舗Ａ１における購買傾向に関する情報、店舗Ａ１の周辺環境、並びに、店舗Ａ１の立地及び間取り等に関する情報を含み得る。運営情報は、店舗Ａ１周辺でのイベント（スポーツ又はコンサート等）の開催状況、気象条件（天候を含む）及び交通状況（通行止め等）等の、随時変化する動的な情報を更に含み得る。店舗Ａ１の周辺環境の具体例としては、店舗Ａ１から一定範囲（商圏）内における、総人口、年齢層別の人口、昼夜間の人口比、オフィス数、従業員数、駅の数、又は駅の利用者数等がある。また、店舗Ａ１の周辺環境の具体例としては、店舗Ａ１から一定範囲（商圏）内における、店舗Ａ１の競合店の数及び種別、又は、競技場若しくはコンサートホール等の集客効果のある施設の数及び種別等もある。店舗Ａ１の立地及び間取りの具体例としては、駐車場の有無、駐輪場の有無、駐車場台数、敷地面積、イートインスペースの有無、看板有無、又は幹線道路に面しているか否か等がある。
【００６７】
一方、学習済みモデルの生成に用いられる実績データは、学習対象期間における、店舗Ａ１の売上高、客単価、ＬＴＶの平均値、又は利益等に関連する情報である。学習対象期間は、現在に対して過去に設定される期間であって、例えば、１日単位、１週間単位又は１か月単位等、任意の単位で設定される。ここで、学習済みモデルの生成には、少なくとも複数の店舗Ａ１の実績データが用いられ、より好ましくは、同一チェーンに属する全店舗等の多数の店舗Ａ１の実績データが用いられる。
【００６８】
需要予測処理では、このような学習済みモデルを用いて、店舗Ａ１の需要に関する需要予測情報Ｄ１が生成される。本実施形態では、需要予測処理では店舗Ａ１ごとに需要予測情報Ｄ１が生成されるので、需要予測処理では、少なくともある店舗Ａ１の運営情報を入力とし、学習済みモデルを用いて、この店舗Ａ１の需要を予測する。本実施形態では一例として、需要予測処理にて需要が予測される対象となる予測対象期間は、１日単位で設定される。例えば、「２０１９年１２月２０日」といった予測対象期間が設定されることで、特定日である「２０１９年１２月２０日」の店舗Ａ１の需要が予測されることになる。
【００６９】
需要予測処理に用いられる運営情報は、店舗Ａ１に設置された各種センサ（カメラを含む）の検知結果、及びストアコンピュータ又はＰＯＳシステム等から、収集部２４が収集する情報により特定可能である。さらに、店舗Ａ１周辺でのイベントの開催状況、気象条件及び交通状況等の運営情報については、ネットワークＮＴ１に接続された各種のサーバから、収集部２４にて適宜収集可能である。また、学習済みモデルの生成（機械学習）に用いられる実績データについても、各店舗Ａ１のストアコンピュータ又はＰＯＳシステム等から、収集部２４が適宜収集可能である。
【００７０】
ところで、例えば、コンビニエンスストアのように、店舗支援方法が適用され得る店舗Ａ１の数が、１００店以上、１０００店以上、又は１００００店以上といった多数になり得る場合、学習済みモデルを用いた需要予測は特に有用である。
【００７１】
すなわち、通常、多数の店舗Ａ１は個々別々の条件の下で営業しているのであって、これら多数の店舗Ａ１にわたる膨大な量の情報を、ある特定の店舗Ａ１向けに反映するには、人の処理能力を遥かに上回る演算等が必要となり、人では到底実現し得ない。しかも、これらの多数の店舗Ａ１の運営及び経営に関する情報は、時間経過に伴って（例えば季節ごとに）随時変動するところ、多数の店舗Ａ１の最新の情報を考慮して需要予測をアップデートすることなど、人では到底なし得ない。さらに、このような膨大かつ変動する情報を処理する処理は、人は勿論のこと、一般的な情報処理装置であっても困難である。
【００７２】
本実施形態に係る店舗支援方法では、需要予測処理で使用される学習済みモデルの機械学習に、多数の店舗Ａ１に関する情報（実績データ等）が用いられるのであって、上述したような膨大かつ変動する情報であっても処理し得る。むしろ、機械学習においては、訓練データのデータ量が多いほどに、生成される学習済みモデルの精度の向上が期待できるので、多数の店舗Ａ１の情報を訓練データとして用いることは好都合である。このように、多数の店舗Ａ１を展開し得る業態においては、本実施形態に係る店舗支援方法は特に有用である。
【００７３】
（２．３．２）事前工程
次に、本実施形態に係る店舗支援方法のうち、資源の融通に必要な融通情報Ｄ９を生成するまでの「事前工程」について、図２及び図３を参照して説明する。図３は、事前工程に関する店舗支援方法の一例を示すフローチャートである。
【００７４】
ここでは、特定日としての「２０１９年１２月２０日」に、店舗Ａ１２から店舗Ａ１１に資源（店員Ｃ２）が融通される場合を想定している。そのため、事前工程は、時期としては特定日である「２０１９年１２月２０日」よりも前の任意の時期に行われる。ここでは一例として、事前工程は特定日の１週間前である「２０１９年１２月１３日」に行われることとする。
【００７５】
まず、事前工程の前提として、運営情報及び実績データ等の種々のデータが、収集部２４にて随時収集される（図３のＳ１）。収集されたデータに基づいて、「（２．３．１）需要予測処理」で説明した手順により需要予測処理が実行される（図３のＳ２）。
【００７６】
そして、「２０１９年１２月１３日」になると、図２に示すように、チェーン本部Ａ２の店舗支援システム１（図１参照）から、各店舗Ａ１に対して、需要予測処理で得られた予測結果、つまり需要予測情報Ｄ１が配信される（図３のＳ３）。このとき送信される需要予測情報Ｄ１は、特定日である「２０１９年１２月２０日」を予測対象期間とした場合の、例えば、店舗Ａ１での売上高、客単価、ＬＴＶの平均値、又は利益等を推定した結果を表す情報である。需要予測情報Ｄ１は、店舗Ａ１１だけでなく、店舗Ａ１２を含む複数の店舗Ａ１にそれぞれ送信される。ただし、需要予測情報Ｄ１は、店舗Ａ１ごとに生成されるため、送信先の店舗Ａ１の需要予測に係る需要予測情報Ｄ１が送信される。例えば、店舗Ａ１１には店舗Ａ１１の需要予測に係る需要予測情報Ｄ１が送信され、店舗Ａ１２には店舗Ａ１２の需要予測に係る需要予測情報Ｄ１が送信される。
【００７７】
需要予測情報Ｄ１を受信した店舗Ａ１のオーナＢ１，Ｂ２は、需要予測情報Ｄ１で表される、特定日である「２０１９年１２月２０日」の需要予測の結果を参考にして、店舗Ａ１の営業に必要な「資源」である人員（店員Ｃ１，Ｃ２）が足りるか否かを判断する。つまり、オーナＢ１，Ｂ２は、特定日（１２月２０日）について、需要予測の結果と、店員Ｃ１，Ｃ２のシフトとを対比しつつ、店員Ｃ１，Ｃ２が不足しているか否かを判断する。ここでいう「シフト」は、店舗Ａ１で雇用されている店員Ｃ１，Ｃ２ごとの勤務時間割である。
【００７８】
ここでは、店舗Ａ１１及び店舗Ａ１２のうち店舗Ａ１１においてのみ、店員Ｃ１の不足が生じることと仮定する。つまり、図２に示すように、店舗Ａ１１では、特定日（１２月２０日）のシフトによると、２名の店員Ｃ１１，Ｃ１２しか確保できておらず、特定日の需要予測の結果に照らせば、店員Ｃ１の数が不足する。一方、店舗Ａ１２では、特定日（１２月２０日）のシフトによると、４名の店員Ｃ２１〜Ｃ２４が確保できており、特定日の需要予測の結果に照らして、店員Ｃ２の数に余剰が生じている。このような状況において、店舗Ａ１１のオーナＢ１は、チェーン本部Ａ２に対して要求情報Ｄ２を送信する。具体的には、店舗Ａ１１のオーナＢ１が使用する情報端末３１から店舗支援システム１に対して、要求情報Ｄ２が送信される。
【００７９】
要求情報Ｄ２は、少なくとも送信元の店舗Ａ１１を特定するための識別情報、特定日（１２月２０日）を特定する時間情報、並びに、不足する資源、及びその不足量等を表す不足情報を含んでいる。さらに、本実施形態では、要求情報Ｄ２は、店舗Ａ１１で現状確保されている資源（既存の資源）の数量等の情報、及び作業指定情報Ｄ１１等も含んでいる。
【００８０】
このとき、要求取得部１２は、店舗Ａ１１から、店舗Ａ１１で不足する資源に関する要求情報Ｄ２を取得する要求取得処理を実行することになる（図３のＳ４）。一方で、店舗Ａ１１のオーナＢ１は、資源（店員Ｃ２）の融通を受けられない可能性を考慮して、店舗Ａ１１の店員Ｃ１に対して、追加で勤務に入れないか等、シフト調整Ｄ３を実施する。シフト調整Ｄ３についても、例えば、オーナＢ１が使用する情報端末３１と、店員Ｃ１が使用する情報端末３４との間でオンラインにて実施される。
【００８１】
チェーン本部Ａ２が店舗Ａ１１からの要求情報Ｄ２を取得すると、つまり、「要求あり」であれば（図３のＳ５：Ｙｅｓ）、店舗支援システム１は、対比部１３にて、需要予測情報Ｄ１を、要求情報Ｄ２と対比可能な態様で出力する対比処理を実行する。対比処理では、店舗Ａ１１に送信した需要予測情報Ｄ１と、同じ店舗Ａ１１から取得した要求情報Ｄ２と、を対比可能な態様で、検証部１４に出力する（図３のＳ６）。そして、対比部１３から出力される対比可能な態様の需要予測情報Ｄ１及び要求情報Ｄ２を受け取った検証部１４は、需要予測情報Ｄ１と要求情報Ｄ２との対比結果から、資源を融通することの妥当性を検証する検証処理を実行する（図３のＳ７）。
【００８２】
具体的には、検証処理では、売上高等の需要予測情報Ｄ１から推定される資源（店員Ｃ１）の必要数と、要求情報Ｄ２との対比結果から、店舗Ａ１１で資源（店員Ｃ１）が不足する事態にあるか否かを判断する。基本的には、需要予測情報Ｄ１から推定される資源の必要数に対して、現状確保されている資源（既存の資源）の数量が不足している場合には、店舗Ａ１１で資源が不足する事態にあると判断する。一方、需要予測情報Ｄ１から推定される資源の必要数以上の資源が、現状確保されている場合には、店舗Ａ１１で資源が不足する事態にないと判断する。
【００８３】
さらに、不足する事態であると判断された場合には、検証処理において、例えば、多数の店舗Ａ１の過去の実績データ等に基づいて、店員Ｃ１の作業手順の変更により現状の店員Ｃ１だけで実現できるオペレーション等、資源不足の解消策の検討を行う。一例として、店舗Ａ１１と共通項が多い店舗Ａ１において、品出しの優先順位を変更するオペレーションによって、店員Ｃ１の数が少ない繁忙期でも正常に営業を行った実績があれば、このようなオペレーションを、資源不足の解消策として検討する。検証処理において、資源が不足することが確認され、かつ適当な解消策がない場合には、資源を融通することの妥当性について、「妥当」と判断される。
【００８４】
一方で、検証処理において、資源が不足しないと判断されるか、又は適当な解消策があると判断された場合には、資源を融通することの妥当性について、妥当でない、つまり失当と判断される。要するに、本実施形態では、要求情報Ｄ２を出した店舗Ａ１１を含む複数の店舗Ａ１の過去の実績データ等に基づいて、店舗Ａ１１から取得した要求情報Ｄ２について妥当か否かが判断されることになる。
【００８５】
資源を融通することが「妥当」と判断されると（図３のＳ８：Ｙｅｓ）、店舗支援システム１は、効果推定部１５にて、効果推定処理を実行する（図３のＳ９）。効果推定処理では、融通先Ａ１１への資源の融通を行った場合に、融通先Ａ１１と融通元Ａ１２との少なくとも一方（の営業）に及ぼし得る効果を推定する。すなわち、店舗Ａ１１に対して資源としての人員（店員）を融通したと仮定して、融通しなかった場合に比較して、例えば、店舗Ａ１１での営業に波及し得る効果の程度を、効果推定処理で推定する。一例として、効果推定処理では、資源（店員）を融通しなかった場合と、資源（店員）を融通した場合との、融通を受けた側の店舗Ａ１１における売上高、客単価、ＬＴＶの平均値、又は利益等の差分（増加分）を、効果として推定する。
【００８６】
あるいは、店舗Ａ１１に対して資源としての人員（店員）を融通したと仮定して、融通しなかった場合に比較して、例えば、店舗Ａ１２での営業に波及し得る負（マイナス）の効果の程度を、効果推定処理で推定してもよい。一例として、効果推定処理では、資源（店員）を融通しなかった場合と、資源（店員）を融通した場合との、融通した側の店舗Ａ１２における売上高、客単価、ＬＴＶの平均値、又は利益等の差分（減少分）を、負（マイナス）の効果として推定する。店舗Ａ１２についての負の効果は、例えば、後述する受付処理で、融通元Ａ１２の候補としての店舗Ａ１に対してオファー情報Ｄ４に含めて送信される。これにより、店舗Ａ１２のオーナＢ２は、店舗Ａ１２についての負の効果を、後述する融通手当と対比すれば、店舗Ａ１２にとっての総合的な損得を評価できる。さらに、仮に、負の効果と融通手当とを差し引きしてマイナス（減収）となる場合でも、店舗Ａ１２のオーナＢ２は、例えば、店員Ｃ２の教育、他の店舗Ａ１での事例学習等の機会と捉え、融通元Ａ１２として店員Ｃ２の融通を引き受けてもよい。
【００８７】
それから、店舗支援システム１は、原因推定部１６にて、原因推定処理を実行する（図３のＳ１０）。原因推定処理では、融通先Ａ１１において資源が不足するに至った原因を推定する。すなわち、店舗Ａ１１における人材募集の実施の有無、人材募集の内容、及びシフト調整Ｄ３の実施の有無等を判断し、店舗Ａ１１において資源（店員）が不足するに至った原因がどこにあるのか、原因推定処理で推定する。一例として、原因推定処理では、人材募集を実施していないことで慢性的に人員が不足している等、特定日での資源の不足との間に一定以上の相関がある事象を、原因として推定する。
【００８８】
本実施形態では一例として、効果推定処理の推定結果、及び原因推定処理の推定結果は、融通情報Ｄ９に含めて融通先Ａ１１である店舗Ａ１に送信される。さらに、効果推定処理の推定結果、及び原因推定処理の推定結果は、実績としてデータ格納部２５に格納され、以降の検証処理等に利用される。
【００８９】
次に、店舗支援システム１は、作業指定部１７にて、作業指定情報Ｄ１１を受け付ける作業指定処理を実行する（Ｓ１１）。作業指定情報Ｄ１１は、資源として融通先Ａ１１に融通される人員（店員Ｃ２）に求める作業内容と作業スキルとの少なくとも一方を指定する情報である。ここでいう「作業内容」は、融通の対象としての資源である店員Ｃ２に業務として課され、店員Ｃ２が実行主体となって実行される作業の内容を特定する情報である。作業内容の一例として、商品の陳列、棚卸、トイレ清掃、レジ対応、ホットスナック対応、電気ポットの湯の補充、ホットスナックの補充（作り置き）、ごみ袋の交換、商品の品出し及び消耗品の補充等がある。また、ここでいう「作業スキル」は、融通の対象としての資源である店員Ｃ２に関して、作業の実行に要求されるスキルである。一例として、「作業スキル」は、店員Ｃ２に関して、初心者、レギュラ又はリーダ等で段階的に表される。あるいは、例えば、レジ対応の可否、棚卸の可否、又はホットスナックの補充の可否等のように、具体的に作業の可否によって「作業スキル」が表される。
【００９０】
本実施形態では一例として、作業指定情報Ｄ１１は、要求情報Ｄ２に含めて店舗Ａ１１から取得されることとする。つまり、店舗支援システム１としては、要求情報Ｄ２を取得した時点で、店舗Ａ１１から作業指定情報Ｄ１１を取得している。そのため、作業指定処理では、要求情報Ｄ２から作業指定情報Ｄ１１を抽出することにより、作業指定情報Ｄ１１を受け付けることになる。
【００９１】
それから、店舗支援システム１は、探索部１８にて、探索処理を実行する（図３のＳ１２）。探索処理では、少なくとも融通先Ａ１１に融通する資源の所在に関する所在情報に基づいて、融通元Ａ１２を探索する。すなわち、探索処理では、融通元Ａ１２の候補となる店舗Ａ１の探索が行われる。具体的には、探索処理では、要求情報Ｄ２で要求されている資源についての条件を満足する店舗Ａ１を探索する。つまり、本実施形態では、例えば、融通元Ａ１２の店舗には、融通先Ａ１１の店舗Ａ１との関係で、近隣（例えば直線距離で５ｋｍ以内）に存在することが求められる。さらに、要求情報Ｄ２にて特定される資源の不足量、及び作業指定情報Ｄ１１で特定される作業内容及び作業スキルを満足する人員（店員Ｃ２）を抱える店舗Ａ１が、融通元Ａ１２の候補として探索される。言い換えれば、作業指定情報Ｄ１１で特定される作業内容及び作業スキルを満足する人員（店員Ｃ２）の所在に関する所在情報に基づいて、融通元Ａ１２の候補としての店舗Ａ１が探索される。探索処理では、複数の店舗Ａ１が融通元Ａ１２の候補として探索されてもよい。
【００９２】
そして、店舗支援システム１は、受付部１９にて、受付処理を実行する（図３のＳ１３，Ｓ１４）。受付処理では、要求情報Ｄ２への応答として、融通可能な資源の状況を表す返答情報Ｄ６を融通元Ａ１２から受け付ける。
【００９３】
具体的には、受付処理では、図２に示すように、まず探索処理にて探索された融通元Ａ１２の候補としての店舗Ａ１に対し、チェーン本部Ａ２からオファー情報Ｄ４を送信する（図３のＳ１３）。オファー情報Ｄ４は、少なくとも要求情報Ｄ２の送信元の店舗Ａ１１を特定するための識別情報、特定日（１２月２０日）を特定する時間情報、並びに、不足する資源、及びその不足量等を表す不足情報を含んでいる。さらに、本実施形態では、オファー情報Ｄ４は、店舗Ａ１１で現状確保されている資源（既存の資源）の数量等の情報、及び作業指定情報Ｄ１１等も含んでいる。
【００９４】
オファー情報Ｄ４を受信した店舗Ａ１２のオーナＢ２は、需要予測情報Ｄ１で表される、特定日である「２０１９年１２月２０日」の需要予測の結果を参考にして、店舗Ａ１の営業に必要な「資源」である人員（店員Ｃ２）の融通が可能か否かを判断する。つまり、オーナＢ２は、特定日（１２月２０日）について、需要予測の結果と、店員Ｃ２のシフトとを対比しつつ、店員Ｃ２のシフトに余裕があるか否かを判断する。このとき、オーナＢ２は、店舗Ａ１２のシフトに含まれている店員Ｃ２、及び店舗Ａ１２のシフトに含まれていない店員Ｃ２に対して、店舗Ａ１１の勤務に入れないか等、シフト調整Ｄ５を実施する。ここで、シフト調整Ｄ５においては、オファー情報Ｄ４の内容が、オーナＢ２から店員Ｃ２に伝えられることが好ましい。シフト調整Ｄ５についても、例えば、オーナＢ２が使用する情報端末３２と、店員Ｃ２が使用する情報端末３４との間でオンラインにて実施される。
【００９５】
ここでは、店舗Ａ１２では、特定日（１２月２０日）のシフトによると、４名の店員Ｃ２１〜Ｃ２４が確保できており、特定日の需要予測の結果に照らして、２名の店員Ｃ２２，Ｃ２３が余分にシフトに含まれていると仮定する。この場合、店舗Ａ１２では店員Ｃ２のシフトに余裕があることとなり、資源（店員Ｃ２２，Ｃ２３）の融通が可能と判断される。店舗Ａ１２のオーナＢ２は、チェーン本部Ａ２に対して、オファー情報Ｄ４への応答として融通可能な資源の状況を含む返答情報Ｄ６を送信する。具体的には、店舗Ａ１２のオーナＢ２が使用する情報端末３２から店舗支援システム１に対して、返答情報Ｄ６が送信される。
【００９６】
返答情報Ｄ６は、融通可能な資源の状況を表す情報であって、例えば、資源の融通の可否、又は一部の資源のみ融通可能といった情報を含んでいる。一部の資源の融通が可能である場合、返答情報Ｄ６は、融通可能な資源の数量等の情報を含んでいてもよい。返答情報Ｄ６は、融通元Ａ１２及び融通先Ａ１１を特定するための識別情報、並びに、特定日（１２月２０日）を特定する時間情報を更に含んでいる。
【００９７】
このとき、受付部１９は、店舗Ａ１２から、要求情報Ｄ２への応答として、返答情報Ｄ６を受け付ける受付処理を実行することになる（図３のＳ１４）。チェーン本部Ａ２が店舗Ａ１２からの返答情報Ｄ６を取得すると、返答情報Ｄ６の内容から、オファー情報Ｄ４が受諾されたか否かを判断する（図３のＳ１５）。ここでは、店舗Ａ１２からの返答情報Ｄ６は、資源（店員Ｃ２２，Ｃ２３）の融通が可能であることを示すので、オファー情報Ｄ４が受諾されたことになる（図３のＳ１５：Ｙｅｓ）。
【００９８】
すなわち、店舗支援システム１は、資源の融通が可能であることを表す返答情報Ｄ６を取得して、オファー情報Ｄ４が受諾されたことになると（図３のＳ１５：Ｙｅｓ）、融通部２０にて融通情報Ｄ９を生成する融通処理を実行する（図３のＳ１６）。ここで、融通情報Ｄ９は、少なくとも検証処理（図３のＳ７）の検証結果、及び返答情報Ｄ６の内容を考慮して、生成されることになる。
【００９９】
融通情報Ｄ９は、融通元Ａ１２から融通先Ａ１１に対して資源を融通するための情報であって、例えば、要求情報Ｄ２で要求された資源の融通の可否、又は一部の資源のみ融通可能といった情報を含んでいる。一部の資源の融通が可能である場合、融通情報Ｄ９は、融通可能な資源の数量等の情報を含んでいてもよい。また、少なくとも一部の資源の融通が可能である場合には、融通される資源に関する情報についても、融通情報Ｄ９に含まれていることが好ましい。例えば、融通の対象となる資源が人員（店員Ｃ２２，Ｃ２３）である場合には、融通の対象となる人員（店員Ｃ２２，Ｃ２３）に関する人員情報、具体的には、店員コード、氏名、性別、年齢及び作業スキル等の情報が、融通情報Ｄ９に含まれていることが好ましい。融通情報Ｄ９は、融通元Ａ１２及び融通先Ａ１１を特定するための識別情報、並びに、特定日（１２月２０日）を特定する時間情報を更に含んでいる。また、本実施形態では、融通情報Ｄ９は、効果推定処理（図３のＳ９）の推定結果、及び原因推定処理（図３のＳ１０）の推定結果を更に含んでいる。
【０１００】
そして、生成された融通情報Ｄ９は、図２に示すように、チェーン本部Ａ２の店舗支援システム１から、融通先Ａ１１に対して送信される。つまり、店舗支援システム１は、通知部２１にて、融通情報Ｄ９を融通先Ａ１１に通知する通知処理を実行する（図３のＳ１７）。その結果、店舗Ａ１１（融通先）のオーナＢ１は、情報端末３１にて、融通情報Ｄ９の通知を受けることになり、特定日（１２月２０日）における資源の不足を、店舗Ａ１２（融通元）からの資源（店員Ｃ２２，Ｃ２３）の融通にて、解消できることを知る。これをもって、店舗支援方法における事前工程に係る一連の処理が完了する。
【０１０１】
一方、融通元Ａ１２の候補としての店舗Ａ１にてオファー情報Ｄ４が受諾されなかった場合には（図３のＳ１５：Ｎｏ（１回目））、図２に示すように、融通元の人材派遣会社Ａ３に対して、チェーン本部Ａ２からオファー情報Ｄ７を送信する（図３のＳ１８）。オファー情報Ｄ７の送信後は、店舗支援システム１は、受付部１９にて、人材派遣会社Ａ３からの返答情報Ｄ８を受け付ける受付処理を実行することになる（図３のＳ１４）。人材派遣会社Ａ３は、複数人のスタッフＣ３と雇用契約を締結しており、オファー情報Ｄ４に応じて、これら複数人のスタッフＣ３の中から、店舗Ａ１１に融通（派遣）するスタッフＣ３を選定する。具体的には、人材派遣会社Ａ３のオペレータＢ３は、情報端末３３にてオファー情報Ｄ７を受けると、オファー情報Ｄ７の内容に応じたスタッフＣ３を選定し、選定されたスタッフＣ３にオファーを出す。ここで、人材派遣会社Ａ３に雇用されているスタッフＣ３は、商品の品出し及びレジ対応といった作業を実行できるよう、事前に教育されていることが好ましい。
【０１０２】
その結果、融通先Ａ１１の近隣に店舗Ａ１が存在しない場合等、店舗Ａ１を融通元Ａ１２とするだけでは、不足する資源を十分に賄えないケースにおいても、資源の融通が可能となる。
【０１０３】
人材派遣会社Ａ３は、基本的には、潤沢なスタッフＣ３を確保することで、いずれのオファー情報Ｄ７に対しても受諾できる体制をとることが好ましいが、店舗Ａ１１の場所、日程等によっては、スタッフＣ３を融通（派遣）できない場合もある。その結果、人材派遣会社Ａ３にてオファー情報Ｄ７が受諾されなかった場合には（図３のＳ１５：Ｎｏ（２回目））、店舗支援方法としては、エラー処理に移行し（図３のＳ１９）、これをもって、店舗支援方法における事前工程に係る一連の処理が完了する。エラー処理においては、要求情報Ｄ２の送信元の店舗Ａ１１に対して、資源の融通ができない旨の通知を店舗支援システム１が行うことが好ましい。
【０１０４】
ただし、図２に示すチェーン本部Ａ２と人材派遣会社Ａ３との間でのオファー情報Ｄ７及び返答情報Ｄ８のやり取りは、あくまで融通元Ａ１２の候補としての店舗Ａ１にてオファー情報Ｄ４が受諾されなかった場合（図３のＳ１５：Ｎｏ（１回目））の措置である。そのため、融通元Ａ１２の候補としての店舗Ａ１にてオファー情報Ｄ４が受諾された場合（図３のＳ１５：Ｙｅｓ）、チェーン本部Ａ２と人材派遣会社Ａ３との間でのオファー情報Ｄ７及び返答情報Ｄ８のやり取りは行われない。
【０１０５】
また、検証処理において、資源を融通することが妥当でない、つまり失当と判断された場合（図３のＳ８：Ｎｏ）、店舗支援システム１は、エラー処理に移行する（図３のＳ１９）。その結果、店舗Ａ１１が、他の店舗Ａ１２からの資源の融通に頼り切ってしまうような、好ましくない事態を抑止する抑止力として働く。また、チェーン本部Ａ２がいずれの店舗Ａ１からも要求情報Ｄ２を取得しない場合、つまり、要求なしの場合には（図３のＳ５：Ｎｏ）、対比処理Ｓ６以降の処理を全てスキップして、店舗支援方法における事前工程に係る一連の処理が完了する。
【０１０６】
ところで、融通処理（図３のＳ１６）にて生成される融通情報Ｄ９は、少なくとも融通先Ａ１１の需要予測に関する需要予測情報Ｄ１に基づく情報である。言い換えれば、融通情報Ｄ９には、融通先Ａ１１である店舗Ａ１についての需要予測処理の結果である需要予測情報Ｄ１が反映されている。本実施形態に係る店舗支援方法では、２通りのアプローチにて、需要予測情報Ｄ１が融通情報Ｄ９に反映されている。
【０１０７】
１つ目のアプローチでは、需要予測情報Ｄ１に依拠した要求情報Ｄ２への応答としての返答情報Ｄ６に基づいて、融通情報Ｄ９を生成することで、需要予測情報Ｄ１を融通情報Ｄ９に反映している。すなわち、本実施形態では、要求情報Ｄ２は、需要予測情報Ｄ１と既存の資源とから求まる情報である。融通処理では、要求情報Ｄ２への応答としての返答情報Ｄ６を用いて融通情報Ｄ９を生成することで、需要予測情報Ｄ１に基づく融通情報Ｄ９を生成する。要するに、融通情報Ｄ９の生成に用いられる返答情報Ｄ６は、そもそも需要予測情報Ｄ１に依拠した要求情報Ｄ２への応答であって、言い換えれば、需要予測情報Ｄ１を反映した情報である。そして、このような返答情報Ｄ６を用いて融通情報Ｄ９が生成される以上、融通情報Ｄ９についても同様に、需要予測情報Ｄ１を反映した情報である。
【０１０８】
２つ目のアプローチでは、需要予測情報Ｄ１と要求情報Ｄ２との対比結果から資源を融通することの妥当性を検証する検証処理を経て、融通情報Ｄ９を生成することで、需要予測情報Ｄ１を融通情報Ｄ９に反映している。すなわち、融通処理では、需要予測情報Ｄ１を用いた妥当性の検証結果に基づいて融通情報Ｄ９を生成することで、需要予測情報Ｄ１に基づく融通情報Ｄ９を生成する。要するに、融通情報Ｄ９の生成に用いられる妥当性の検証結果は、そもそも需要予測情報Ｄ１に依拠した情報であって、言い換えれば、需要予測情報Ｄ１を反映した情報である。そして、このような妥当性の検証結果を用いて融通情報Ｄ９が生成される以上、融通情報Ｄ９についても同様に、需要予測情報Ｄ１を反映した情報である。
【０１０９】
また、図３に示すフローチャートは、一例に過ぎず、処理の順番が適宜変更されてもよいし、処理が適宜追加又は削除されてもよい。
【０１１０】
（２．３．３）当日工程
次に、本実施形態に係る店舗支援方法のうち、資源の融通を行う特定日（１２月２０日）に係る「当日工程」について、図４を参照して説明する。
【０１１１】
ここでは、特定日としての「２０１９年１２月２０日」に、店舗Ａ１２から店舗Ａ１１に資源（店員Ｃ２）が融通される場合を想定している。そのため、当日工程は、時期としては特定日である「２０１９年１２月２０日」に行われる。ただし、当日工程の一部の処理については、例えば、特定日の前日又は翌日のように、特定日の前後であって「事前工程」の後であって、「事後工程」の前の期間に行われてもよい。
【０１１２】
特定日としての「２０１９年１２月２０日」になると、図４に示すように、融通元Ａ１２である店舗Ａ１のオーナＢ２から、店員Ｃ２に対して、作業指定情報Ｄ１１が通知される。具体的には、店舗Ａ１２のオーナＢ２が使用する情報端末３２から店員Ｃ２が使用する情報端末３４に対して、作業指定情報Ｄ１１が送信される。このとき、作業指定情報Ｄ１１は、店舗Ａ１２の店員Ｃ２のうち、融通の対象となる店員Ｃ２２，Ｃ２３のみに通知されてもよい。作業指定情報Ｄ１１が通知されることで、店員Ｃ２２，Ｃ２３は、融通先Ａ１１にて実行すべき作業の内容を把握できる。作業指定情報Ｄ１１の通知については、特定日の前日等に実行されてもよい。
【０１１３】
また、特定日としての「２０１９年１２月２０日」には、資源としての店員Ｃ２２，Ｃ２３の融通Ｄ１２が実行される。つまり、融通の対象となる店員Ｃ２２，Ｃ２３は、融通先Ａ１１である店舗Ａ１に出勤することで、融通元Ａ１２から融通先Ａ１１への資源（店員Ｃ２２，Ｃ２３）の融通が実現される。そして、店員Ｃ２２，Ｃ２３は、店舗Ａ１１の店員Ｃ１１，Ｃ１２と共に、店舗Ａ１１にて作業を行う。ただし、店員Ｃ２２，Ｃ２３が行う作業は、基本的には、作業指定情報Ｄ１１にて事前に知らせている作業である。
【０１１４】
そして、店舗Ａ１１での店員Ｃ２２，Ｃ２３の作業が全て終了すると、店舗Ａ１１のオーナＢ１は、チェーン本部Ａ２に対して報告Ｄ１３の送信を行う。この報告Ｄ１３には、少なくとも評価情報が含まれている。評価情報は、資源の融通の評価に関する情報であって、ここでは特に、資源としての店員Ｃ２２，Ｃ２３の融通先Ａ１１での使用状況に係る情報である。一例として、評価情報には、融通された店員Ｃ２２，Ｃ２３の出勤時刻及び退勤時刻を含む勤務時間等の情報が含まれている。報告Ｄ１３は、店舗Ａ１１のオーナＢ１が使用する情報端末３１から店舗支援システム１に対して送信される。
【０１１５】
一方、融通の対象としての店員Ｃ２２，Ｃ２３は、店舗Ａ１１での作業を全て終了すると、店舗Ａ１２のオーナＢ２に対して報告Ｄ１４の送信を行う。この報告Ｄ１４には、少なくとも資源としての店員Ｃ２２，Ｃ２３の融通先Ａ１１での使用状況に係る評価情報が含まれている。店員Ｃ２２，Ｃ２３が送信する報告Ｄ１４の評価情報は、勤務時間の情報に加えて、店舗Ａ１１での店員Ｃ２２，Ｃ２３が実際に行った作業内容に関する情報等が含まれる。実際に行った作業内容に関する情報は、例えば、作業指定情報Ｄ１１通りの作業内容であったか否か等の情報である。一例として、作業指定情報Ｄ１１にてレジ対応のみが作業内容として示されている場合に、店舗Ａ１１にて清掃の作業を課されたケースでは、実際の作業内容が作業指定情報Ｄ１１通りでなかった旨が、評価情報としてアンケート方式で回答される。報告Ｄ１４は、店員Ｃ２２，Ｃ２３が使用する情報端末３４から店舗Ａ１２のオーナＢ２が使用する情報端末３２に対して送信される。
【０１１６】
また、融通元Ａ１２である店舗Ａ１のオーナＢ２は、店員Ｃ２２，Ｃ２３からの報告Ｄ１４を受けると、チェーン本部Ａ２に対して報告Ｄ１５の送信を行う。この報告Ｄ１５には、少なくとも店員Ｃ２２，Ｃ２３からの報告Ｄ１４の内容が含まれている。また、報告Ｄ１５には、店員Ｃ２２，Ｃ２３からの報告Ｄ１４に加えて、例えば、オーナＢ２の意見等が適宜含まれてもよい。報告Ｄ１５は、店舗Ａ１２のオーナＢ２が使用する情報端末３２から店舗支援システム１に対して送信される。
【０１１７】
これにより、チェーン本部Ａ２に設置された店舗支援システム１は、評価部２２にて、少なくとも融通先Ａ１１と、融通元Ａ１２と、資源として融通先Ａ１１に融通される人員（店員Ｃ２）との少なくともいずれかから、評価情報を受け付ける評価処理を実行する。つまり、チェーン本部Ａ２は、融通先Ａ１１からの報告Ｄ１３、及び融通元Ａ１２からの報告Ｄ１５を受けることで、報告Ｄ１３，Ｄ１５に含まれる評価情報を受け付けることになる。
【０１１８】
この段階で、チェーン本部Ａ２では、受け付けた評価情報に基づいて、資源の融通についての評価を行う。具体的には、店舗支援システム１は、評価部２２にて、評価情報に基づいて、資源の融通についての評価を実行する。このとき用いる評価情報は、特に資源としての店員Ｃ２２，Ｃ２３の融通先Ａ１１での使用状況に係る情報であるので、主として、資源を使用した融通先Ａ１１についての評価が行われる。
【０１１９】
例えば、評価部２２は、勤務時間の情報について、融通先Ａ１１からの報告Ｄ１３と、融通元Ａ１２からの報告Ｄ１５とで、ずれ（相違）が生じているか否かを判断する。一例として、融通先Ａ１１からの報告Ｄ１３に含まれる勤務時間が、融通元Ａ１２からの報告Ｄ１５に含まれる勤務時間よりも極端に短い場合等には、評価部２２は、融通先Ａ１１の評価点を下げる等の措置を行う。さらに、融通元Ａ１２からの報告Ｄ１５に誤りがある可能性を考慮して、例えば、報告Ｄ１３と報告Ｄ１５とでずれ（相違）が生じている場合、店舗Ａ１に設置された各種センサ（カメラを含む）の検知結果等と照合してもよい。一例として、防犯カメラ等のセンサで検知された勤務時間に照らして、報告Ｄ１３の信頼性が低い場合に限り、融通先Ａ１１の評価点を下げる等の措置がとられてもよい。また、評価部２２は、融通元Ａ１２からの報告Ｄ１５によって、作業指定情報Ｄ１１から逸脱した作業内容の作業が融通の対象としての店員Ｃ２２，Ｃ２３に課された可能性がある場合には、融通先Ａ１１の評価点を下げる等の措置を行う。その結果、融通先Ａ１１において、例えば、融通の対象としての店員Ｃ２２，Ｃ２３が不当に扱われるような、好ましくない事態を抑止する抑止力として働く。
【０１２０】
評価部２２での評価については、特定日の翌日等に実行されてもよい。
【０１２１】
（２．３．４）事後工程
次に、本実施形態に係る店舗支援方法のうち、資源の融通を行った後の「事後工程」について、図５を参照して説明する。
【０１２２】
ここでは、特定日としての「２０１９年１２月２０日」に、店舗Ａ１２から店舗Ａ１１に資源（店員Ｃ２）が融通される場合を想定している。そのため、事後工程は、時期としては特定日である「２０１９年１２月２０日」よりも後の任意の時期に行われる。ここでは一例として、事後工程は特定日の１週間後である「２０１９年１２月２７日」に行われることとする。
【０１２３】
「２０１９年１２月２７日」になると、図５に示すように、店舗Ａ１１のオーナＢ１は、チェーン本部Ａ２に対して評価Ｄ２１の送信を行う。このとき、オーナＢ１は、評価Ｄ２１と共に、チェーン本部Ａ２に対して、資源の融通に対する対価を「依頼料」として送信（送金）する。依頼料には、店員Ｃ２２，Ｃ２３の業務に対する対価として時給等の給与及び交通費等の一般手当てに加えて、融通に係る融通手当が含まれている。
【０１２４】
この評価Ｄ２１には、少なくとも評価情報が含まれている。評価情報は、資源の融通の評価に関する情報であって、ここでは特に、資源としての店員Ｃ２２，Ｃ２３の業務態度に係る情報である。一例として、評価情報には、融通された店員Ｃ２２，Ｃ２３の業務態度を、作業内容ごとに得点等で表す情報が含まれており、業務態度が良いほどに得点が高くなる。評価Ｄ２１は、店舗Ａ１１のオーナＢ１が使用する情報端末３１から店舗支援システム１に対して送信される。
【０１２５】
これにより、チェーン本部Ａ２に設置された店舗支援システム１は、評価部２２にて、少なくとも融通先Ａ１１から、評価情報を受け付ける評価処理を実行する。つまり、チェーン本部Ａ２は、融通先Ａ１１からの評価Ｄ２１を受けることで、評価Ｄ２１に含まれる評価情報を受け付けることになる。
【０１２６】
この段階で、チェーン本部Ａ２では、受け付けた評価情報に基づいて、資源の融通についての評価を行う。具体的には、店舗支援システム１は、評価部２２にて、評価情報に基づいて、資源の融通についての評価を実行する。このとき用いる評価情報は、特に資源としての店員Ｃ２２，Ｃ２３の業務態度に係る情報であるので、主として、資源としての店員Ｃ２２，Ｃ２３についての評価が行われる。例えば、評価部２２は、評価Ｄ２１に含まれる評価情報において、獲得した得点が高い場合には、店員Ｃ２２，Ｃ２３の評価点を上げる等の措置を行う。さらに、店員Ｃ２２，Ｃ２３の評価点は、融通元Ａ１２の評価点としてもよい。
【０１２７】
このように評価される店員Ｃ２２，Ｃ２３（又は融通元Ａ１２）の評価点に関する情報は、例えば、データ格納部２５に格納される。データ格納部２５に格納された店員Ｃ２２，Ｃ２３（又は融通元Ａ１２）の評価点は、例えば、チェーン本部Ａ２の管理下にある全ての店舗Ａ１で閲覧可能とすることが好ましい。また、データ格納部２５に格納された店員Ｃ２２，Ｃ２３（又は融通元Ａ１２）の評価点は、融通元Ａ１２を探索する探索処理に判定されてもよい。この場合、評価点の高い店員Ｃ２２，Ｃ２３が属する店舗Ａ１は、融通元Ａ１２の候補として探索されやすくなる。さらに、評価点の高い店員Ｃ２２，Ｃ２３又は店舗Ａ１には、表彰又は報奨制度等の手当てがなされてもよい。
【０１２８】
これにより、店員Ｃ１，Ｃ２又は店舗Ａ１においては、高い評価点を獲得することで、融通元Ａ１２として指名されやすくなったり、手当てを受け取ったりと、高い評価点を獲得することのモチベーションの向上につながる。その結果、融通元Ａ１２である店舗Ａ１が、例えば、融通手当欲しさに、業務に不慣れな店員Ｃ２のように、十分でない資源を融通するような、好ましくない事態を抑止する抑止力として働く。
【０１２９】
そして、チェーン本部Ａ２に設置された店舗支援システム１は、店舗Ａ１２に対して、報酬Ｄ２２を送信（送金）する。報酬Ｄ２２には、店員Ｃ２２，Ｃ２３の業務に対する対価として時給等の給与及び交通費等の一般手当てに加えて、融通に係る融通手当が含まれている。このとき、店舗Ａ１２には、報酬Ｄ２２と共に、チェーン本部Ａ２から、資源の融通についての評価結果が送信される。この評価結果は、事後工程において、評価部２２にて行われた、資源としての店員Ｃ２２，Ｃ２３についての評価の結果であって、例えば、店員Ｃ２２，Ｃ２３（又は融通元Ａ１２）の評価点を含んでいる。
【０１３０】
その後、店舗Ａ１２のオーナＢ２は、融通の対象としての店員Ｃ２２，Ｃ２３に対して、報酬Ｄ２３を送信（送金）する。報酬Ｄ２３には、店員Ｃ２２，Ｃ２３の業務に対する対価として時給等の給与及び交通費等の一般手当てが含まれている。ここで、報酬Ｄ２３には、融通手当の一部が含まれてもよい。
【０１３１】
また、チェーン本部Ａ２に設置された店舗支援システム１は、店舗Ａ１１に対しては、フィードバックＤ２４を送信する。フィードバックＤ２４は、資源の融通についての評価結果が含まれている。この評価結果は、当日工程において、評価部２２にて行われた、資源を使用した融通先Ａ１１についての評価の結果であって、例えば、融通先Ａ１１の評価点を含んでいる。
【０１３２】
（２．３．５）小括
次に、「事前工程」、「当日工程」及び「事後工程」を通しで行った場合の、店舗支援方法の全体の流れについて、図６及び図７を参照して説明する。各処理の詳細については、上述した通りであるので、ここでは全体の流れについて大まかに説明するにとどめる。図６では、融通元Ａ１２の候補としての店舗Ａ１にてオファー情報Ｄ４が受諾された場合（図３のＳ１５：Ｙｅｓ）を想定し、図７では、融通元Ａ１２の候補としての店舗Ａ１にてオファー情報Ｄ４が拒否された場合（図３のＳ１５：Ｎｏ）を想定する。
【０１３３】
図６の例では、まず事前工程において、チェーン本部Ａ２から、店舗Ａ１１に需要予測情報Ｄ１が送信され（Ｐ１）、店舗Ａ１２に需要予測情報Ｄ１が送信される（Ｐ２）。店舗Ａ１１からチェーン本部Ａ２に要求情報Ｄ２が送信されると（Ｐ３）、チェーン本部Ａ２は店舗Ａ１２にオファー情報Ｄ４を送信する（Ｐ４）。そして、店舗Ａ１２では、シフト調整Ｄ５として、店舗Ａ１２（オーナＢ２）から店員Ｃ２に対してオファー情報Ｄ４の内容が伝えられて（Ｐ５）、これに対する返答情報が店員Ｃ２から店舗Ａ１２（オーナＢ２）に送信される（Ｐ６）。それから、店舗Ａ１２からチェーン本部Ａ２に対して、「受諾」の返答情報Ｄ６が送信され（Ｐ７）、これを受けたチェーン本部Ａ２は、店舗Ａ１１に対して融通情報Ｄ９を送信する（Ｐ８）。
【０１３４】
次に、当日工程において、チェーン本部Ａ２から、融通の対象となる店員Ｃ２に対して作業指定情報Ｄ１１を送信する（Ｐ９）。このとき、厳密には、作業指定情報Ｄ１１は、店舗Ａ１２のオーナＢ２から店員Ｃ２に通知される。ただし、オーナＢ２に対しては、事前工程において、チェーン本部Ａ２からオファー情報Ｄ４と一緒に作業指定情報Ｄ１１が送信されているのであって、言い換えれば、作業指定情報Ｄ１１は、チェーン本部Ａ２から店舗Ａ１２を介して店員Ｃ２に送信される。そこで、図６では、作業指定情報Ｄ１１がチェーン本部Ａ２から店員Ｃ２に送信されるように表記している（Ｐ９）。そして、店員Ｃ２は店舗Ａ１１に融通され（Ｐ１０）、その後、チェーン本部Ａ２に対しては、店舗Ａ１１から報告Ｄ１３が送信される（Ｐ１１）。さらに、チェーン本部Ａ２に対しては、店員Ｃ２から報告Ｄ１４，Ｄ１５が送信される（Ｐ１２）。
【０１３５】
次に、事後工程においては、チェーン本部Ａ２から店舗Ａ１１に対して、フィードバックＤ２４が送信される（Ｐ１３）。また、チェーン本部Ａ２から店舗Ａ１２に対しては、報酬Ｄ２２が送信（送金）され（Ｐ１４）、店舗Ａ１２から店員Ｃ２に対しては、報酬Ｄ２３が送信（送金）される（Ｐ１５）。
【０１３６】
図７の例では、まず事前工程において、チェーン本部Ａ２から、店舗Ａ１１に需要予測情報Ｄ１が送信され（Ｐ２１）、店舗Ａ１２に需要予測情報Ｄ１が送信される（Ｐ２２）。店舗Ａ１１からチェーン本部Ａ２に要求情報Ｄ２が送信されると（Ｐ２３）、チェーン本部Ａ２は店舗Ａ１２にオファー情報Ｄ４を送信する（Ｐ２４）。そして、店舗Ａ１２では、シフト調整Ｄ５として、店舗Ａ１２（オーナＢ２）から店員Ｃ２に対してオファー情報Ｄ４の内容が伝えられて（Ｐ２５）、これに対する返答情報が店員Ｃ２から店舗Ａ１２（オーナＢ２）に送信される（Ｐ２６）。それから、店舗Ａ１２からチェーン本部Ａ２に対して、「拒否」の返答情報Ｄ６が送信され（Ｐ２７）、これを受けたチェーン本部Ａ２は、人材派遣会社Ａ３に対してオファー情報Ｄ７を送信する（Ｐ２８）。それから、人材派遣会社Ａ３からチェーン本部Ａ２に対して、「受諾」の返答情報Ｄ８が送信され（Ｐ２９）、これを受けたチェーン本部Ａ２は、店舗Ａ１１に対して融通情報Ｄ９を送信する（Ｐ３０）。
【０１３７】
次に、当日工程において、チェーン本部Ａ２から、人材派遣会社Ａ３に対して作業指定情報Ｄ１１を送信する（Ｐ３１）。このとき、厳密には、作業指定情報Ｄ１１は、人材派遣会社Ａ３のスタッフＣ３に通知される。そして、人材派遣会社Ａ３のスタッフＣ３は店舗Ａ１１に融通され（Ｐ３２）、その後、チェーン本部Ａ２に対しては、店舗Ａ１１から報告Ｄ１３が送信される（Ｐ３３）。さらに、チェーン本部Ａ２に対しては、人材派遣会社Ａ３のスタッフＣ３から報告が送信される（Ｐ３４）。
【０１３８】
次に、事後工程においては、チェーン本部Ａ２から店舗Ａ１１に対して、フィードバックＤ２４が送信される（Ｐ３５）。また、チェーン本部Ａ２から人材派遣会社Ａ３に対しては、報酬が送信（送金）される（Ｐ３６）。
【０１３９】
（３）変形例
実施形態１は、本開示の様々な実施形態の一つに過ぎない。実施形態１は、本開示の目的を達成できれば、設計等に応じて種々の変更が可能である。また、本開示で参照する図面は、いずれも模式的な図であり、図中の各構成要素の大きさ及び厚さそれぞれの比が、必ずしも実際の寸法比を反映しているとは限らない。また、実施形態１に係る店舗支援方法と同様の機能は、店舗支援システム１、（コンピュータ）プログラム、又はプログラムを記録した非一時的記録媒体等で具現化されてもよい。一態様に係るプログラムは、実施形態１に係る店舗支援方法を、１以上のプロセッサに実行させるためのプログラムである。
【０１４０】
以下、実施形態１の変形例を列挙する。以下に説明する変形例は、適宜組み合わせて適用可能である。
【０１４１】
本開示における店舗支援システム１は、コンピュータシステムを含んでいる。コンピュータシステムは、ハードウェアとしてのプロセッサ及びメモリを主構成とする。コンピュータシステムのメモリに記録されたプログラムをプロセッサが実行することによって、本開示における店舗支援システム１としての機能が実現される。プログラムは、コンピュータシステムのメモリに予め記録されてもよく、電気通信回線を通じて提供されてもよく、コンピュータシステムで読み取り可能なメモリカード、光学ディスク、ハードディスクドライブ等の非一時的記録媒体に記録されて提供されてもよい。コンピュータシステムのプロセッサは、半導体集積回路（ＩＣ）又は大規模集積回路（ＬＳＩ）を含む１ないし複数の電子回路で構成される。ここでいうＩＣ又はＬＳＩ等の集積回路は、集積の度合いによって呼び方が異なっており、システムＬＳＩ、ＶＬＳＩ（Very Large Scale Integration）、又はＵＬＳＩ（Ultra Large Scale Integration）と呼ばれる集積回路を含む。さらに、ＬＳＩの製造後にプログラムされる、ＦＰＧＡ（Field-Programmable Gate Array）、又はＬＳＩ内部の接合関係の再構成若しくはＬＳＩ内部の回路区画の再構成が可能な論理デバイスについても、プロセッサとして採用することができる。複数の電子回路は、１つのチップに集約されていてもよいし、複数のチップに分散して設けられていてもよい。複数のチップは、１つの装置に集約されていてもよいし、複数の装置に分散して設けられていてもよい。ここでいうコンピュータシステムは、１以上のプロセッサ及び１以上のメモリを有するマイクロコントローラを含む。したがって、マイクロコントローラについても、半導体集積回路又は大規模集積回路を含む１ないし複数の電子回路で構成される。
【０１４２】
また、店舗支援システム１における複数の機能が、１つの筐体内に集約されていることは店舗支援システム１に必須の構成ではない。店舗支援システム１の構成要素は、複数の筐体に分散して設けられていてもよい。さらに、店舗支援システム１の少なくとも一部の機能は、クラウド（クラウドコンピューティング）等によって実現されてもよいし、店舗支援システム１の機能は、クラウド（又はサーバ）及びエッジに分散して実現されてもよい。
【０１４３】
一例として、店舗支援システム１の機能が、各店舗Ａ１のストアコンピュータに分散して設けられている場合、チェーン本部Ａ２を介さずとも、複数の店舗Ａ１間で、直接的に資源の融通について調整が可能となる。
【０１４４】
反対に、実施形態１において、複数の装置に分散されている店舗支援システム１の少なくとも一部の機能が、１つの筐体内に集約されていてもよい。例えば、チェーン本部Ａ２に設置されたサーバ装置と情報端末３１〜３４とに分散されている店舗支援システム１の一部の機能が、１つの筐体内に集約されていてもよい。
【０１４５】
また、店舗支援システム１の用途はコンビニエンスストアに限らず、コンビニエンスストア以外の店舗Ａ１に店舗支援システム１が導入されていてもよい。
【０１４６】
また、実施形態１では、２通りのアプローチにて、需要予測情報Ｄ１が融通情報Ｄ９に反映されているが、この例に限らず、いずれか１つのアプローチのみで、需要予測情報Ｄ１が融通情報Ｄ９に反映されてもよい。例えば、需要予測情報Ｄ１に依拠した要求情報Ｄ２への応答としての返答情報Ｄ６に基づいて、融通情報Ｄ９を生成することのみで、需要予測情報Ｄ１を融通情報Ｄ９に反映してもよい。あるいは、需要予測情報Ｄ１と要求情報Ｄ２との対比結果から資源を融通することの妥当性を検証する検証処理を経て、融通情報Ｄ９を生成することのみで、需要予測情報Ｄ１を融通情報Ｄ９に反映してもよい。
【０１４７】
また、店舗Ａ１での商品の販売形態は、実施形態１のように、複数の商品が店内に陳列された状態で販売される形態に限らない。例えば、店舗Ａ１が、修理店又は保険代理店等のように、サービスを提供するような業態である場合には、商品の販売は行われない。さらに、複数の商品が店内に陳列された状態で販売される形態であっても、例えば、セルフレジ（Self-checkout）等を用いることにより、顧客が店員を介さずに精算を行う販売形態であってもよい。
【０１４８】
また、需要予測のための学習済みモデルの生成に用いられる訓練データは、１以上の店舗Ａ１についての実績データを含んでいればよい。ここで、訓練データが抽出される１以上の店舗Ａ１は、融通先Ａ１１又は融通元Ａ１２を含んでいてもよいし、融通先Ａ１１又は融通元Ａ１２を含まなくてもよい。つまり、前者の場合、融通先Ａ１１又は融通元Ａ１２を含む１以上の店舗Ａ１から抽出される訓練データを用いて、学習済みモデルが生成されることになる。
【０１４９】
また、需要予測部１１が、学習済みモデルを用いて店舗Ａ１の需要予測を行う需要予測処理において、運営情報を入力とすることは必須ではない。一例として、需要予測部１１は、単に日時情報（カレンダ情報を含む）を入力として需要予測を実行してもよい、この場合、例えば、過去の実績（傾向）から、金曜日は売上が相対的に高く、土曜日及び日曜日は売上が相対的に低い等の簡易な需要予測が可能である。
【０１５０】
また、需要予測処理では、機械学習された学習済みモデルを利用することは必須ではない。例えば、需要予測処理においては、単に、店舗Ａ１の過去の実績（履歴）に基づく統計処理等に基づいて、店舗Ａ１の需要が予測されてよい。
【０１５１】
また、実施形態１において店舗支援システム１で行っている一部の処理については、人が行ってもよい。一例として、資源を融通することの妥当性の検証（検証処理）については、検証部１４に代えて、人が行ってもよい。同様に、資源の融通についての評価については、評価部２２に代えて、人が行ってもよい。
【０１５２】
また、融通手当を含む依頼料又は報酬は、一例として、金銭（クレジット及び仮想通貨等を含む）に限らず、例えば、ポイント（点数）、物品、又は店舗Ａ１のメンテナンス等のサービスを含む特典等で実現されてもよい。
【０１５３】
また、評価処理では、評価部２２での評価に用いられる評価情報を、融通先Ａ１１と、融通元Ａ１２と、資源として融通先Ａ１１に融通される人員（店員Ｃ２）との少なくともいずれかから受け付ければよく、評価情報は申告制でなくてもよい。すなわち、報告Ｄ１３，Ｄ１４，Ｄ１５等に含まれる評価情報のように、人が申告する申告制の評価情報に限らず、例えば、店舗Ａ１に設置された各種センサ（カメラを含む）の検知結果が評価情報として用いられてもよい。この場合、一例として、店舗支援システム１は、融通の対象としての店員Ｃ２による作業（タスク）の実行をセンサにて検知し、その検知結果に基づいて、店員Ｃ２による作業の実行状況を表す作業ログを自動的に抽出する。
【０１５４】
また、実施形態１では、チェーン本部Ａ２が、融通元Ａ１２の候補としての店舗Ａ１に対するオファー情報Ｄ４を、人材派遣会社Ａ３に対するオファー情報Ｄ７よりも先に出す例を示したが、この構成は必須ではない。つまり、チェーン本部Ａ２は、人材派遣会社Ａ３に対するオファー情報Ｄ７を、融通元Ａ１２の候補としての店舗Ａ１に対するオファー情報Ｄ４よりも先に出してもよい。
【０１５５】
さらに、例えば、チェーン本部Ａ２が、融通用の非常勤スタッフを確保していてもよい。この場合、例えば、融通元Ａ１２の候補としての店舗Ａ１又は人材派遣会社Ａ３に代えて、チェーン本部Ａ２が、非常勤スタッフを資源として融通先Ａ１１に融通することが可能である。この場合において、チェーン本部Ａ２の非常勤スタッフと、融通元Ａ１２の候補としての店舗Ａ１の店員Ｃ２と、人材派遣会社Ａ３のスタッフＣ３と、のいずれが優先的に資源として融通先Ａ１１に融通されてもよい。チェーン本部Ａ２の非常勤スタッフについては、例えば、定期的（一例として半年ごと）に、商品の品出し又はレジ対応等の店舗Ａ１での作業に係る教育を受ける教育システムを採用することが好ましい。このような教育システムがあれば、非常勤スタッフにとっては、作業スキルを獲得及び維持できるメリットがある。
【０１５６】
また、実施形態１では、資源の融通を行うに際し、まず融通先Ａ１１（のオーナＢ１）が、需要予測情報Ｄ１に基づいて、資源が足りるか否かを判断し、資源が不足する場合に、チェーン本部Ａ２に対して要求情報Ｄ２を送信するが、この構成に限らない。例えば、まずチェーン本部Ａ２（店舗支援システム１）において、需要予測情報Ｄ１に基づいて、資源が不足する可能性がある店舗Ａ１１を推定し、不足すると推定された店舗Ａ１１に対して、資源の融通の示唆を行ってもよい。この場合、店舗Ａ１１（のオーナＢ１）においては、チェーン本部Ａ２からの示唆に従って、資源の融通が必要か否かを判断し、必要と判断すればチェーン本部Ａ２に対して要求情報Ｄ２を送信する。この場合においても、資源を融通するか否かは融通先Ａ１１で最終的に判断され、チェーン本部Ａ２（店舗支援システム１）においては、融通先Ａ１１から要求情報Ｄ２を取得する要求取得処理を行うことになる。
【０１５７】
また、実施形態１では、融通先Ａ１１（のオーナＢ１）は、融通元である店舗Ａ１２（のオーナＢ２）又は材派遣会社Ａ３（のオペレータＢ３）を介して、資源である人員の融通についての調整（交渉）を行うが、この構成に限らない。例えば、融通先Ａ１１（のオーナＢ１）は、融通元である店舗Ａ１２又は材派遣会社Ａ３を介さずに、資源である人員（店員Ｃ２又はスタッフＣ３）と直接的に、融通についての調整（交渉）を行ってもよい。これにより、例えば、資源である人員（店員Ｃ２又はスタッフＣ３）においては、予定が空いている日であれば、融通元である店舗Ａ１２又は材派遣会社Ａ３を介さずに、融通先Ａ１１への融通を受諾することができる。さらに、この場合においても、店舗支援システム１の機能が分散して設けられていれば、チェーン本部Ａ２を介さずとも、融通先Ａ１１（のオーナＢ１）は、資源である人員（店員Ｃ２又はスタッフＣ３）と直接的に、融通についての調整（交渉）が可能となる。
【０１５８】
（実施形態２）
本実施形態に係る店舗支援方法は、図８に示すように、融通の対象となる資源が設備Ｅ２である点で、実施形態１に係る店舗支援方法と相違する。以下、実施形態１と同様の構成については、共通の符号を付して適宜説明を省略する。
【０１５９】
すなわち、融通の対象となる資源は、上述したように、店舗Ａ１の営業に必要な資源であり、例えば、人員及び物品等を含み得る。本実施形態では一例として、融通の対象となる「資源」は、店舗Ａ１（コンビニエンスストア）の営業に必要な「設備」であることとする。つまり、資源は、融通先Ａ１１の営業に用いられる設備Ｅ２を含んでいる。より詳細には、融通元Ａ１２が（融通先Ａ１１とは別の）店舗Ａ１である場合においては、融通元Ａ１２に設置されている設備Ｅ２が、融通の対象たる「資源」である。図８では、資源としての設備Ｅ２として、レジ（register）を例示する。
【０１６０】
図８では、ある店舗Ａ１にて、特定日に設備Ｅ１（レジ）が不足するため、この店舗Ａ１を融通先Ａ１１として、融通元Ａ１２から資源としての設備Ｅ２（レジ）を、特定日に融通先Ａ１１へ融通する場合を想定する。すなわち、店舗Ａ１１では、既存の設備Ｅ１の台数（２台）を、特定日の需要予測の結果に照らせば、設備Ｅ１の数が不足する。一方、店舗Ａ１２では、既存の設備Ｅ２の台数（３台）を、特定日の需要予測の結果に照らせば、設備Ｅ２の数に余剰が生じている。このような状況において、店舗Ａ１１のオーナＢ１は、チェーン本部Ａ２に対して要求情報Ｄ２を送信する。
【０１６１】
需要予測情報Ｄ１の送信から融通情報Ｄ９の送信までの大まかな手順は、資源が人員（店員Ｃ２）である場合と共通である。ただし、資源が人員（店員Ｃ１，Ｃ２）の場合のように、シフト調整Ｄ３，Ｄ５は行われない。そして、特定日になると、資源としての設備Ｅ２は、融通元Ａ１２から融通先Ａ１１に融通される。設備Ｅ２のような資源については、資源（設備Ｅ２）を実際に融通元Ａ１２から融通先Ａ１１に移動させる必要がある。ここで、資源（設備Ｅ２）の運搬は、例えば、商品の配送用の運搬手段（トラック等）を利用して行ってもよい。
【０１６２】
実施形態２の変形例として、資源は、電力、ガス又は水道水等のライフラインを通して供給される資源を含んでいてもよい。電力、ガス又は水道水等の資源に関しては、実際に、電力、ガス又は水道水等の融通の記録だけでよく、実際に、融通元Ａ１２から融通先Ａ１１に資源を移動させる必要がない。また、資源は、有体物に限らず、権利（チケットの販売権等）又は電力等の無対物であってもよい。
【０１６３】
実施形態２で説明した種々の構成（変形例を含む）は、実施形態１で説明した種々の構成（変形例を含む）と適宜組み合わせて採用可能である。
【０１６４】
（まとめ）
以上説明したように、第１の態様に係る店舗支援方法は、要求取得処理と、融通処理と、を有する。要求取得処理は、資源を用いて営業を行う店舗（Ａ１）である融通先（Ａ１１）から、融通先（Ａ１１）で不足する資源に関する要求情報（Ｄ２）を取得する処理である。融通処理は、要求情報（Ｄ２）に応じて、融通元（Ａ１２）から融通先（Ａ１１）に対して資源を融通するための融通情報（Ｄ９）を生成する処理である。融通情報（Ｄ９）は、少なくとも融通先（Ａ１１）の需要予測に関する需要予測情報（Ｄ１）に基づく情報である。
【０１６５】
この態様によれば、融通先（Ａ１１）である店舗（Ａ１）の営業も用いられる資源が不足するような場合、融通先（Ａ１１）からの要求情報（Ｄ２）に応じて、融通情報（Ｄ９）を生成することができる。融通情報（Ｄ９）は、融通元（Ａ１２）から融通先（Ａ１１）に資源を融通するための情報であるので、これにより、融通情報（Ｄ９）に従って、融通元（Ａ１２）から融通先（Ａ１１）への資源の融通が可能となる。しかも、融通情報（Ｄ９）は、少なくとも需要予測情報（Ｄ１）に基づく情報であるため、融通情報（Ｄ９）には、融通先（Ａ１１）の需要予測に関する情報が反映されることになる。したがって、融通先（Ａ１１）である店舗（Ａ１）の需要予測を反映した適切な資源の融通が実現しやすく、結果的に、店舗（Ａ１）の営業に必要な資源の不足により店舗（Ａ１）の営業に支障が生じにくい、という利点がある。
【０１６６】
第２の態様に係る店舗支援方法は、第１の態様において、受付処理を更に有する。受付処理は、要求情報（Ｄ２）への応答として、融通可能な資源の状況を表す返答情報（Ｄ６，Ｄ８）を融通元（Ａ１２）から受け付ける処理である。融通処理では、返答情報（Ｄ６，Ｄ８）を用いて融通情報（Ｄ９）を生成する。
【０１６７】
この態様によれば、融通元（Ａ１２）から、融通可能な資源の状況を表す返答情報（Ｄ６，Ｄ８）を受け付けるので、融通元（Ａ１２）における融通可能な資源の状況を考慮した融通が可能となる。
【０１６８】
第３の態様に係る店舗支援方法では、第２の態様において、要求情報（Ｄ２）は、需要予測情報（Ｄ１）と既存の資源とから求まる情報である。融通処理では、要求情報（Ｄ２）への応答としての返答情報（Ｄ６，Ｄ８）を用いて融通情報（Ｄ９）を生成することで、需要予測情報（Ｄ１）に基づく融通情報（Ｄ９）を生成する。
【０１６９】
この態様によれば、需要予測情報（Ｄ１）に依拠した要求情報（Ｄ２）への応答としての返答情報（Ｄ６，Ｄ８）に基づいて、融通情報（Ｄ９）を生成することで、需要予測情報（Ｄ１）を融通情報（Ｄ９）に反映できる。
【０１７０】
第４の態様に係る店舗支援方法は、第１〜３のいずれかの態様において、通知処理を更に有する。通知処理は、融通情報（Ｄ９）を融通先（Ａ１１）に通知する処理である。
【０１７１】
この態様によれば、融通先（Ａ１１）は、通知された融通情報（Ｄ９）を根拠に資源の融通を期待し得る。
【０１７２】
第５の態様に係る店舗支援方法は、第１〜４のいずれかの態様において、評価処理を更に有する。評価処理は、融通先（Ａ１１）と、融通元（Ａ１２）と、資源として融通先（Ａ１１）に融通される人員との少なくともいずれかから、資源の融通の評価に関する評価情報を受け付ける処理である。
【０１７３】
この態様によれば、資源の融通の評価が可能となるので、融通先（Ａ１１）と融通元（Ａ１２）との少なくとも一方におけるモチベーションの向上につながる。
【０１７４】
第６の態様に係る店舗支援方法は、第１〜５のいずれかの態様において、効果推定処理を更に有する。効果推定処理は、融通先（Ａ１１）への資源の融通を行った場合に、融通先（Ａ１１）と融通元（Ａ１２）との少なくとも一方に及ぼし得る効果を推定する処理である。
【０１７５】
この態様によれば、融通先（Ａ１１）と融通元（Ａ１２）との少なくとも一方においては、資源の融通を受けることによる効果を判断しやすくなる。
【０１７６】
第７の態様に係る店舗支援方法は、第１〜６のいずれかの態様において、探索処理を更に有する。探索処理は、融通先（Ａ１１）に融通する資源の所在に関する所在情報に基づいて融通元（Ａ１２）を探索する処理である。
【０１７７】
この態様によれば、資源の所在に基づいて融通元（Ａ１２）の候補を絞り込むことが可能である。
【０１７８】
第８の態様に係る店舗支援方法は、第１〜７のいずれかの態様において、作業指定処理を更に有する。作業指定処理は、資源として融通先（Ａ１１）に融通される人員に求める作業内容と作業スキルとの少なくとも一方を指定する作業指定情報（Ｄ１１）を受け付ける処理である。
【０１７９】
この態様によれば、資源として融通される人員に求める作業内容と作業スキルとの少なくとも一方を指定することができ、融通先（Ａ１１）としては、所望の資源の融通を受けやすくなる。
【０１８０】
第９の態様に係る店舗支援方法は、第１〜８のいずれかの態様において、対比処理を更に有する。対比処理は、需要予測情報（Ｄ１）を、要求情報（Ｄ２）と対比可能な態様で出力する処理である。
【０１８１】
この態様によれば、需要予測情報（Ｄ１）と要求情報（Ｄ２）との対比結果から、資源の融通についての妥当性を推定しやすくなる。
【０１８２】
第１０の態様に係る店舗支援方法は、第９の態様において、検証処理を更に有する。検証処理は、需要予測情報（Ｄ１）と要求情報（Ｄ２）との対比結果から資源を融通することの妥当性を検証する処理である。融通処理では、需要予測情報（Ｄ１）を用いた妥当性の検証結果に基づいて融通情報（Ｄ９）を生成することで、需要予測情報（Ｄ１）に基づく融通情報（Ｄ９）を生成する。
【０１８３】
この態様によれば、需要予測情報（Ｄ１）と要求情報（Ｄ２）との対比結果から資源を融通することの妥当性を検証する検証処理を経て、融通情報（Ｄ９）を生成することで、需要予測情報（Ｄ１）を融通情報（Ｄ９）に反映できる。
【０１８４】
第１１の態様に係る店舗支援方法は、第１〜１０のいずれかの態様において、原因推定処理を更に有する。原因推定処理は、融通先（Ａ１１）において資源が不足するに至った原因を推定する処理である。
【０１８５】
この態様によれば、融通先（Ａ１１）においては、資源の融通を受けるに至った原因を判断しやすくなる。
【０１８６】
第１２の態様に係る店舗支援方法は、第１〜１１のいずれかの態様において、資源は、融通先（Ａ１１）の営業に用いられる設備を含む。
【０１８７】
この態様によれば、店舗（Ａ１）の営業に用いられる設備を融通することで、必要以上に設備を導入する必要がなくなる。
【０１８８】
第１３の態様に係る店舗支援方法は、第１〜１２のいずれかの態様において、融通元（Ａ１２）は、融通先（Ａ１１）とは別の店舗（Ａ１）を含む。
【０１８９】
この態様によれば、店舗（Ａ１）同士で資源の融通が可能となる。
【０１９０】
第１４の態様に係るプログラムは、第１〜１３のいずれかの態様に係る店舗支援方法を、１以上のプロセッサに実行させるためのプログラムである。
【０１９１】
この態様によれば、融通先（Ａ１１）である店舗（Ａ１）の需要予測を反映した適切な資源の融通が実現しやすく、結果的に、店舗（Ａ１）の営業に必要な資源の不足により店舗（Ａ１）の営業に支障が生じにくい、という利点がある。
【０１９２】
第１５の態様に係る店舗支援システム（１）は、要求取得部（１２）と、融通部（２０）と、を有する。要求取得部（１２）は、資源を用いて営業を行う店舗（Ａ１）である融通先（Ａ１１）から、融通先（Ａ１１）で不足する資源に関する要求情報（Ｄ２）を取得する。融通部（２０）は、要求情報（Ｄ２）に応じて、融通元（Ａ１２）から融通先（Ａ１１）に対して資源を融通するための融通情報（Ｄ９）を生成する。融通情報（Ｄ９）は、少なくとも融通先（Ａ１１）の需要予測に関する需要予測情報（Ｄ１）に基づく情報である。
【０１９３】
この態様によれば、融通先（Ａ１１）である店舗（Ａ１）の需要予測を反映した適切な資源の融通が実現しやすく、結果的に、店舗（Ａ１）の営業に必要な資源の不足により店舗（Ａ１）の営業に支障が生じにくい、という利点がある。
【０１９４】
上記態様に限らず、実施形態１及び実施形態２に係る店舗支援方法の種々の態様（変形例を含む）は、店舗支援システム（１）、プログラム及びプログラムを記録した非一時的記録媒体にて具現化可能である。
【０１９５】
第２〜１３の態様に係る構成については、店舗支援方法に必須の構成ではなく、適宜省略可能である。
【符号の説明】
【０１９６】
１  店舗支援システム
１２  要求取得部
２０  融通部
Ａ１  店舗
Ａ１１  融通先
Ａ１２  融通元
Ｄ１  需要予測情報
Ｄ２  要求情報
Ｄ６，Ｄ８  返答情報
Ｄ９  融通情報
Ｄ１１  作業指定情報
【要約】
【課題】店舗の営業に必要な資源の不足により店舗の営業に支障が生じにくい、店舗支援方法、プログラム及び店舗支援システムを提供する。
【解決手段】店舗支援方法は、要求取得処理と、融通処理と、を有する。要求取得処理は、資源を用いて営業を行う店舗Ａ１である融通先Ａ１１から、融通先Ａ１１で不足する資源に関する要求情報Ｄ２を取得する処理である。融通処理は、要求情報Ｄ２に応じて、融通元Ａ１２から融通先Ａ１１に対して資源を融通するための融通情報Ｄ９を生成する処理である。融通情報Ｄ９は、少なくとも融通先Ａ１１の需要予測に関する需要予測情報Ｄ１に基づく情報である。
【選択図】図２【図１】
0006785460.tif 000002
【図２】
0006785460.tif 000003
【図３】
0006785460.tif 000004
【図４】
0006785460.tif 000005
【図５】
0006785460.tif 000006
【図６】
0006785460.tif 000007
【図７】
0006785460.tif 000008
【図８】
0006785460.tif 000009