Medistock：クリニックの在庫管理

これは何か

Medistock は、あるクリニックグループが薬剤在庫を回すために使っているシステムです。医薬品はそれぞれ固有の有効期限と保管条件を持つロットとして入荷し、同じ品目が同時に3つの場所に存在します。つまり「在庫はいくつあるか」は、ひとつの数字では決して答えられません。このプロダクトは拠点ごと・ロットごとにその問いへ答え、期限切れの後ではなく前に警告し、その答えをそのまま発注につなげます。

課題

クリニックは医薬品をスプレッドシートで管理していました。拠点ごとの在庫数は最後まで突き合わず、ロット番号と有効期限は手書きで管理され、発注の必要は品切れになってから気づくのが常でした。この2つの失敗の代償は、非常に具体的です。期限を過ぎたロットは全額が償却になり、インスリンのような品目の欠品は在庫の問題ではなく臨床の問題になります。

弊社のアプローチ

先入れではなく「先に期限が来るものから出す（FEFO）」を軸に設計し、有効期限を誰かが確認しに行く日付ではなく、画面が常に示している状態として扱いました。在庫は品目ごとの数量ではなく、ロット単位・拠点単位でモデル化しています。期限ウォッチリストも、拠点間の移動も、規制医薬品の登録簿も、同じデータから生まれるのはそのためです。コンプライアンス規則は品目ではなくカテゴリに紐づくので、薬剤師は抗生物質を318回ではなく1回設定するだけで済みます。

どう進めたか

1. 01

   まずスプレッドシートの前に座った

   何かを描き始める前に、実際に使われているファイルを、その場しのぎの工夫も含めて読み込みました。現場が手で足していった列こそが要件です。ロット管理も、コールドチェーンの表示も、入荷時のダブルチェックも、そこから出てきました。

2. 02

   画面より先にロットと拠点をモデル化した

   本当の設計判断はデータモデルにありました。在庫が品目に付いた数量ではなく「複数の場所にあるロットの集合」になった瞬間、FEFOの並び順も、期限アラートも、拠点間移動も、ロット単位の隔離も、4つの機能ではなくひとつの構造から落ちてきます。

3. 03

   1画面につき、主たるアクションはひとつ

   何時間も向き合う業務ツールなので、装飾より情報密度を優先し、色はステータスのためだけに使いました。どの画面も次の行動を名指しします。ダッシュボードは危険な品目を指し、品目ページは発注を提案し、レポートは償却を原因別に分けて手を打てる形にします。

4. 04

   本番と同じ量でフロントエンドを組んだ

   3拠点・4,000超のSKUは、テーブルがテーブルでなくなる規模です。最初からその量に対して実装したので、絞り込みも、ロットの展開も、書き出しも、デモと同じ挙動を薬局の現場でも保ちます。