発注とシフトは木曜に決まる。
食数は、当日の朝まで動く。

配食サービスと検索して出てくるのは、利用者向けの料金比較、自治体の見守り配食の案内、それに配達と請求の管理システムです。管理システムは、利用者ごとの予定表から配達の一覧と請求書を作るところまでを受け持ちます。「翌週、何食作ることになりそうか」を決める場面は、どのシステムも受け持っていません。決めているのは今も、事務机の紙の食数表と、電話を受けた人の記憶です。

配食の食数には、飲食店と違う構造があります。注文が曜日で固定されているので、数字の大半は最初から確定していることです。動かすのは休みの連絡で、これには3種類あります。日付の決まっている休み（ショートステイ、通院）。終わりの見えない休み（入院）。直前に分かる休み（帰省、家族の来訪、体調）。そして配食は弁当を置いてくる仕事ではありません。玄関で手渡して様子を確かめる、安否確認を兼ねた仕事です。名簿の反映が漏れると、休止中の家を訪ねて家族へ電話する空の安否確認になり、再開した人には夕方まで弁当が届かない。この2つは、廃棄よりも重い損です。

この設計のゴールは2つです。木曜15時に翌週の食数を確定する一回が、毎週きちんと終わること。そして休みと再開の電話が、切ったその場で食数表・配達リスト・請求の3ヶ所へ反映されることです。

設計の中心に置くのは、木曜15時の一回の確定です。翌週7日ぶんの昼・夕の食数を日別に確定し、その数がそのまま食材の発注書とパートのシフト表になります。締切を木曜15時に置くのは、米・冷凍・乾物の週1回の発注がそこで締まるからです。決めるのは店主で、仕組みが出すのは根拠の数字と期限だけです。

予測の前に、確定している数を使い切ります。曜日で決まった名簿から日別の基礎数を出し、届出済みの休止と休みを引く。ここまでは計算で、画面では緑で固まります。幅のある予測が受け持つのは「まだ連絡が来ていない休み」だけです。過去の実績を見ると、盆の週の休みの届は半分近くが発注締切のあとに届きます。だから盆入りの木曜昼は「41〜45食」のように下へ開いた幅になります。逆に、休止中の人の再開は予測しません。退院の日を決めるのは病院と家族で、こちらが当てにいく数字ではないからです。台帳が「金曜に長男へ確認」と期日を出し、確認が取れた日から食数の緑へ戻します。

発注は、幅の両端を食材の日持ちで使い分けます。米・冷凍・調味料のように翌週へ回せるものは幅の上限で頼み、肉・魚・葉物のように回せないものは下限で頼む。足りないぶんは週の途中の納品と買い足しで埋めます。予測が外れても、損の出方が小さい側に倒れるようにしておく設計です。

そしてこの案件では、予測より先に台帳を固めます。変更の電話を1回入力すれば、食数表・配達リスト・請求の3ヶ所へ同時に反映される。転記をやめることが先で、予測はそのあとです。欠配と誤配は金額の損というより信用と安全の損で、幅の精度をいくら上げても、名簿が古いままでは意味がないからです。ドライバーの配達リストには手渡しの記録を持たせ、不在時の連絡の手順と時刻もそこに残します。この記録は、自治体の見守り配食の実施報告にもそのまま使えます。

効果は金額と時間で測ります。使い切れずに捨てた食材の金額。週の途中でスーパーへ買い足しに走った回数。変更の連絡が3ヶ所へ反映されるまでの時間と、反映漏れによる欠配・誤配の件数。この3つを月次レポートに並べ、幅の広さを毎月直していきます。