プロジェクトでの変化
- 予約フロー現場運用に乗る形で整理
- プラットフォーム化複数施設展開を前提に設計
- リリース計画スケジュールで着地
課題
医療現場の予約システムは、運用に合っていなければ電話に戻ります。導入しても使われない、では意味がありません。予約・確認・キャンセルの流れは、現場スタッフ・管理者・患者の3者すべてに関わります。誰か一人にとって使いにくいだけで、運用は崩れます。さらに複数施設での利用も見えていたため、施設が増えるたびに手間が膨らむ構造は避ける必要がありました。現場の業務を崩さず、そのうえで横に広げられること。これが要件の中心でした。
アプローチ
- 01 現場ヒアリングを通じて予約・受付・キャンセルの動線を整理しました
- 02 Laravel + PHP で予約管理・通知・帳票の機能を設計しました
- 03 AWS上で施設追加に耐えるインフラ構成を組みました
- 04 管理者・現場スタッフ・利用者の3視点で要件を整理しました
- 05 リマインド通知や来院確認など、現場負荷を下げる補助機能を初期から組み込みました
- 06 段階展開を前提とした設計レビューを設計フェーズで実施し、後付けの作り直しコストを抑えました
成功要因
- 現場ヒアリング起点の動線整理
- 予約・受付・キャンセルの動線を現場ヒアリングから整理し、机上設計だけで決めませんでした。
- 三視点での要件整理
- 管理者・現場スタッフ・利用者の3視点で要件を切り分け、片側の都合に偏らない設計を保ちました。
- 施設追加を前提とした構成
- AWS上で施設追加に耐えるインフラを組み、複数施設展開を後付けで考えなくて済むようにしました。
- 電話運用への揺り戻し回避
- 現場運用に乗らないと電話運用に戻ってしまう前提を共有し、業務フロー側を崩さない範囲で機能を組みました。
ソリューション
Laravel ベースのプラットフォームを AWS 上に構築し、施設が増えても耐える構成にしました。要件定義から設計、進行管理まで通しで担当しています。設計で意識したのは、電話に戻らせないことです。現場の業務フローをなぞって動線を整理し、スタッフが納得して使える形に落としました。リリースは計画どおりの日程で迎えています。
