製薬企業の患者・医師管理システム フルスクラッチ刷新
製薬・医療業界では、患者の登録・管理・照会をSalesforceで運用している企業が少なくない。Salesforceはカスタマイズ性の高さが売りだが、「医療の現場に合わせる」と言うより「Salesforceの制約に業務を合わせる」という逆転がいつの間にか起きている。
ライセンスコスト。UIのブランド統一不能。カスタマイズの上限。「現場の動線」と「システムの動線」がずれ続けたまま、運用を続けている。
さらに、医療の現場にはFAXがある。紙の文化がデジタルシステムと並走している。その「橋渡し」が手作業のままになっていることは、珍しくない。
プロジェクトが始まり、要件を整理し始めてわかったのは、ひとつの不思議な事実だった。
既存システムが長年使ってきたSalesforceには、公式の要件定義書に記載されていない、FAX受領・確認フローが存在していた。ライブユーザー向けの運用の中で自然発生した機能だ。正式なドキュメントには一行も書かれていないのに、毎日誰かがそれを使って仕事をしている。
新しいシステムは、その「見えない機能」も動かさなければならなかった。
方針はシンプルにした。「Salesforceの外に出る。外部クラウドにも頼らない。」
患者データはクライアント側のオンプレサーバーで完全管理する。フルスクラッチで、React.js + Nest.jsで、作り直す。
ただ、一番難しかったのは技術より前にあった。「仕様書に存在しない業務フローをどうシステムに落とし込むか」だ。
Salesforceのカスタマイズを深掘りして対応する選択肢もあった。でも要件を整理したとき、そのアプローチはSalesforceの制約に縛られ続けることを意味していた。制約の外に出ることそのものが目的だったから、フルスクラッチを選んだ。
画面数が多い案件だった。ChatGPTなどを使ってUI画面を生成し、生成したベースに手直しを加えるスタイルを採用した。さらに、今回のプロジェクトにはもうひとつのAI活用があった——コトリノの内田が過去の仕様書をAIで検索できるRAGツール（officebrain）を独自に開発し、チームに提供した。「仕様書を探す時間」が消えた。
FAX送受信を外部APIサービスと接続し、受領確認フローをシステム内に組み込んだ。デジタルシステムに「FAXの文化」を丸ごと入れる実装は、医療業界固有の制約との格闘だった。正直、ここが一番時間がかかった。
入力画面を全面刷新。Material UIで統一されたデザインシステムの上に、Salesforceの画面をなぞったのではなく、現場の動線から再設計した画面が乗っている。患者登録から担当医師の紐付け、連絡先管理まで、一続きのフローで完結する。
マスターデータとのCSV連携をSFTP経由で自動化した。以前は手作業で行っていた送受信が、スケジュール実行に変わった。帳票出力もSalesforceのレポート機能から自社実装へ。様式のカスタマイズが、システム管理者の手で直接できるようになった。
FAXの送受信を外部APIと接続し、受領確認フローをシステムの中に入れた。「Salesforceの画面を開いて確認する」という行き来がなくなった。仕様書にも書かれていなかった業務が、初めてシステムの中で見える形になった。
| Before | After | ||
|---|---|---|---|
| 患者データ管理 | Salesforce依存（ライセンスコスト・カスタマイズ制約あり） | → | 自社システムで完全管理 |
| マスターデータ連携 | 担当者が手動でCSV操作 | → | SFTP経由で自動送受信 |
| FAX業務 | 受領確認を別系統で手作業管理 | → | APIで自動化・システム内で完結 |
| 帳票出力 | Salesforceのレポート機能に依存 | → | 自社実装・様式カスタマイズ可 |
| UI統一性 | 機能ごとに画面の作りが異なる | → | MUIで全画面統一 |