介護施設の喫食管理システム開発

CASE STUDY ・介護業界・喫食変更を請求までつなぐには｜介護施設向けCareMeal開発事例（仮称）

※ 機密保持のため、企業名・プロジェクト名・システム画面は仮名およびモックに置き換えています。

01CLIENTお客様について

匿名化した介護・福祉施設運営者の、喫食管理基盤。

本事例は、AMELAの移行記録と匿名化したCareMealの開発ストーリーをもとに構成しています。プロジェクト名と顧客名は機密保持のため匿名化しており、実在の顧客名や施設名の公開を前提にしていません。

施設、給食業者、本部の三者が、入居者ごとの食事予約から発注、喫食実績、請求までを同じ業務フローで扱うための範囲を整理しました。

02CHALLENGE解くべき設計課題

喫食管理で重要なのは、画面に食数を入力できることだけではありません。誰が変更し、いつ確定し、どの発注と請求へ反映したかを追える状態にします。

03ARCHITECTURE共に築いた構成

CareMealでは、施設向けの食事予約、給食業者向けの発注確認、本部向けの統計・請求を一つの基盤に構成しました。開発ストーリーに記載された構築期間は8か月、総工数は42人月です。これは開発範囲を把握するための記録であり、作業時間や請求差異の改善値ではありません。

技術スタックはReact、Ant Design、NestJS、MySQL、SAML SSOです。食種、アレルギー、体調情報などの扱いは、施設側の運用基準、個人情報保護、権限設計と合わせて決める必要があります。システムは医療・栄養上の判断や食事提供の安全性そのものを保証するものではありません。

Execution8ヶ月期間42人月総工数

04IMPACT生み出す価値

本事例で確認できるのは、施設、給食業者、本部の三者が、予約から請求まで同じ喫食状態を引き継ぐための画面とデータの流れです。発注工数、請求工数、食材ロス、残業、事故やヒヤリハットの改善率は、本公開範囲で測定・掲載していません。

根拠は、AMELAの移行記録、匿名化したCareMealの開発ストーリー、食事予約・発注・統計／請求の動作デモです。対象期間は新規構築期間であり、稼働後の食数や業務成果を示す期間ではありません。

開発期間と工数は移行元の開発ストーリーに記載された値です。安全性や業務成果の保証値ではなく、効果を判断する場合は自社の対象施設、期間、作業条件、差異の数え方を別途定義してください。

変更イベント	入力・確認する担当	締め条件	後続で確認する情報
喫食・欠食の変更	施設職員	給食業者へ渡す締め時刻まで	発注数量、提供予定、請求対象
食種の変更	施設職員	変更理由と適用日を確定	食種別数量、献立確認、実績
発注数量の差異	給食業者と施設職員	調理・配送前に双方で確認	確定数量、変更履歴、提供実績
喫食実績の確定	施設職員と本部担当者	月次請求の締め前	事業所別集計、請求対象、差異