【都立病院の異変共有DXから考える】なぜ“良いシステム”が他部署・他社へ広がらないのか──横展開できる業務システム設計の考え方

東京都立広尾病院で導入された異変共有システムは、患者の異常兆候をリアルタイムで共有し、早期対応につなげる仕組みとして運用されています。

一方で、この仕組みは現状では広尾病院限定で運用されており、他の都立病院には展開されていません。都病院協会からは「民間病院にも共有してほしい」という声も上がっています。

この話は、医療業界だけの特殊な話ではありません。

多くの企業でも、

• 一部署では成功した
• 現場には定着した
• 担当者からの評価も高い

にもかかわらず、

• 他部署へ広がらない
• 別拠点で使われない
• グループ会社展開で止まる
• 結局“その現場専用”になる

というケースが起きています。

なぜ“良いシステム”なのに広がらないのでしょうか。

本コラムでは、「横展開できる業務システム」という視点から、フルスクラッチ開発で重要になる考え方を解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【記事要約】都立広尾病院の医療DX、現場の“迷い”を減らし異変共有を加速

都立広尾病院では、電子カルテやバイタルデータを連携する診療支援システム「ハイパー」を活用し、患者の異変をリアルタイムで共有している。特徴的なのは、看護師が「伝えるべきか迷う」ような微細な変化もシステム側が即時通知し、現場の忖度を減らしている点だ。通知タイミングは毎月の症例検討会で見直されており、運用を継続的に改善している。一方、この仕組みは現状では広尾病院限定で、他病院への展開は進んでいない。都病院協会からは民間病院への共有を望む声もあり、個別病院の知見を東京全体の医療DXへ広げられるかが課題となっている。

出典：日本経済新聞「都立病院 DX最前線（中） 患者の異変、即共有し救命 コードブルー発生を半減」2026年4月8日付朝刊

“良いシステム”と“広がるシステム”は違う

システム開発では、「現場に合うこと」が重要だとよく言われます。これは間違いではありません。実際、業務フローや運用に合わないシステムは定着しません。

しかし、ここで起きやすいのが、「その部署には最適化されたが、他では使えない」という問題です。

例えば、

• 特定担当者の運用ルール前提
• 特定部門だけの判断基準
• 一部メンバーしか理解できない入力方法
• 暗黙知ベースのワークフロー

などに寄りすぎると、他部署では運用ルールが合わず、定着しにくくなります。

これは特に、現場ヒアリングを丁寧に行ったフルスクラッチ開発ほど起きやすい問題でもあります。なぜなら、現場最適を突き詰めるほど、“その場専用”になりやすいからです。

つまり、

• 良いシステム
• 現場に刺さるシステム
• 横展開できるシステム

は、必ずしも同じではありません。ここを意識せずに開発すると、「高評価なのに広がらない」という状態になりやすくなります。

なぜ横展開で失敗するのか

システムの横展開が失敗する理由は、「機能不足」だけではありません。むしろ多いのは、“運用の差”です。

例えば同じ業務でも、

• 拠点ごとに管理粒度が違う
• 承認フローが違う
• 使用用語が違う
• 判断基準が違う
• 現場文化が違う

ということは珍しくありません。

製造業では工場ごとに運用が異なります。物流では拠点ごとの配送ルールがあります。小売では店舗ごとのオペレーション差があります。つまり、「同じ会社だから同じ業務」とは限らないのです。

そのため、一部署向けに強く最適化されたシステムを、そのまま横展開しようとするとズレが生まれます。結果として、

• カスタマイズが増え続ける
• 拠点ごとに仕様が分裂する
• 管理が複雑になる
• 保守コストが膨らむ

という状況になりやすくなります。これは、DX推進で非常によく起きる課題です。

“標準化”だけでは現場は動かない

横展開の話になると、「標準化」が重視されます。もちろん、一定の共通ルールは必要です。しかし、標準化を強く進めすぎると、今度は現場が使いづらくなるケースがあります。

例えば、

• 現場実態と入力項目が合わない
• 例外運用に対応できない
• 承認フローが過剰になる
• 必要以上に入力負荷が増える

といった問題です。
その結果、

• Excelへ逆戻り
• 独自運用の発生
• “形だけ入力”
• データ品質低下

につながることがあります。

つまり、横展開では、「統一すること」だけでなく、「現場差異をどこまで許容するか」が重要になります。ここを誤ると、全社導入したのに現場で使われなくなります。

横展開できるシステムは「共通部分」と「変えられる部分」を分けている

横展開に成功するシステムには共通点があります。
それは、

• 共通化する部分
• 現場ごとに調整できる部分

が整理されていることです。
例えば、

共通化しやすいもの
・マスタ管理
・権限管理
・ログ管理
・データ形式
・通知ルールの基本部分

現場ごとに変わりやすいもの
・承認フロー
・入力項目
・アラート条件
・表示項目
・業務優先順位

などです。

ここを最初から意識して設計しておくことで、あとから別部署・別拠点へ広げやすくなります。逆に、「まずは動けばよい」という考えだけで開発すると、あとから横展開する際に大規模改修が必要になります。

特にフルスクラッチ開発では自由度が高い分、“どこまで固定し、どこを柔軟にするか”の判断が非常に重要です。

「PoC止まり」が増える理由

近年はPoC（概念実証）から始まるDX案件も増えています。しかし、多くの企業で、

• PoCは成功した
• 一部署では成果が出た

にもかかわらず、その先へ進めないケースがあります。この理由の一つが、“横展開前提”で作られていないことです。PoC段階では、

• 特定担当者が頑張る
• 運用を人力で補う
• 一部例外を無視する

ことで成立している場合があります。しかし、全社展開ではそれが通用しません。
そのため、

• 他部署では運用できない
• 改修のたびに調整負荷が増える
• 説明コストが高い
• 現場差異を吸収できない

という問題が表面化します。つまり、PoC成功と全社導入成功は別物です。本当に重要なのは、「小さく成功した仕組みを、どう広げるか」です。

【関連記事】
ビジネスにおけるPoCとは？手順やメリット、デメリットについて解説

システムは“業務資産”として考える必要がある

業務システムは、一度導入したら終わりではありません。
むしろ、

• 他部署展開
• グループ会社導入
• 新規事業利用
• 他サービス連携
• 運用変更

などを通じて、長く使われていきます。
そのため、システム開発では「今の業務に合うか」だけでなく、「将来どこまで広げる可能性があるか」まで考えておく必要があります。これは単なる技術論ではありません。経営判断です。

例えば、

• どこまで共通化するか
• どこを現場裁量にするか
• どこまで変更可能にするか

によって、将来のDX推進スピードや保守負荷は大きく変わります。そして、この視点が不足すると、“良いシステムなのに広がらない”状態になりやすくなります。

まとめ

“良いシステム”が必ずしも“広がるシステム”になるとは限りません。むしろ、現場最適だけを重視すると、他部署や他拠点では使いづらくなるケースもあります。だからこそ、これからの業務システム開発では、

• 現場適合
• 横展開
• 運用差異
• 将来的な拡張

まで含めて考える必要があります。

特にフルスクラッチ開発では自由度が高い分、「どこまで共通化し、どこを柔軟にするか」という設計判断が重要になります。

システム投資で本当に差が出るのは、“今使えるか”だけではありません。システム投資では、“今使えるか”だけでなく、“あとから広げられるか”という視点が重要になります。

さいごに

業務システムは、「今の現場で動くか」だけで判断すると、あとから他部署展開や全社導入で苦労するケースがあります。

• 拠点ごとに運用が違う
• 部門ごとに判断基準が違う
• 将来的にグループ展開したい
• 新規事業でも活用したい

といった企業では、“その場専用”で終わらない設計が重要になります。
当社フレシット株式会社では、単に要望どおりに開発するのではなく、

• どこを共通化するべきか
• どこを現場ごとに変えられるようにするか
• 将来的にどこまで広がる可能性があるか

まで整理しながら、フルスクラッチ（オーダーメイド）でシステム開発を行っています。

• 複数システム連携
• 属人化した業務の整理
• 既存システムのリプレイス
• 部署ごとに異なる運用への対応

などにも柔軟に対応しています。

「一部署だけで終わらせたくない」「あとから全社展開できる形にしたい」「既製品では業務に合わない」そのようなお悩みがある場合は、ぜひ、当社フレシット株式会社へご相談ください。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら