【都立病院の電子カルテ統一から見える課題】「便利だから追加」が危ない？“使い続ける前提”が抜けたシステムが抱える運用負債とは

東京都立病院機構では、病院ごとに個別最適化されていた電子カルテの統一が進められています。

その背景として語られていたのが、「その時は便利でも、ずっと使い続ける視点が薄かった」という考え方です。現場ごとの要望に応じたカスタマイズは、短期的には業務効率を高めます。しかし、その積み重ねによって、更新費用や運用保守負担が増え、全体管理が難しくなるケースは少なくありません。

これは医療業界だけの話ではありません。

多くの企業でも、「現場が使いやすくなるから」という理由で機能追加を繰り返した結果、運用が複雑化し、改修コストが膨らみ、システム全体を把握しづらくなっているケースがあります。

本コラムでは、「便利だから追加」を繰り返すことで生まれる運用負債について、フルスクラッチ開発の視点から解説します。

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

【記事要約】都立病院の電子カルテ統一が示す、“便利なカスタマイズ”の落とし穴

東京都立病院機構は、病院ごとに個別最適化されていた電子カルテの統一を進めている。背景には、「その時は便利でも、本当に長く使い続けるのか」という視点の不足があったという。現場ごとの要望に応じたカスタマイズは業務効率を高める一方、保守費用や更新負担を増やし、全体最適を難しくしていた。独立行政法人化により、予算消化ではなく経営責任が求められる中、同機構は標準化や内製化を通じて、持続可能なシステム運営への転換を進めている。

出典：日本経済新聞「都立病院 DX最前線（下）電子カルテ統一、狙いはガバナンス強化安藤理事長に聞く　費用削減効果、2～3年で」2026年4月9日付朝刊

なぜシステムは“使いづらく”なっていくのか

業務システムは、導入直後よりも数年後の方が使いづらくなるケースがあります。
その大きな原因のひとつが、「現場要望ベースの機能追加」です。

例えば、以下のようなケースです。

• この項目を追加したい
• この画面だけ入力ルールを変えたい
• この部署だけ承認フローを増やしたい
• CSV出力形式を独自仕様にしたい
• 特定顧客向けの例外処理を入れたい

ひとつひとつは合理的に見えます。

実際、その時点では業務効率が上がることもあります。しかし、問題は「その追加が5年後、10年後も必要なのか」という視点が抜けやすいことです。短期的な便利さを優先すると、システム全体の整合性が徐々に崩れていきます。

結果として、

• 画面ごとに仕様が違う
• 同じ意味のデータが複数存在する
• 改修時の影響範囲が読めない
• 新しい担当者が理解できない
• 更新時に大規模な作り直しが必要になる

といった状態に陥ります。

これは単なる「古いシステム」の問題ではありません。
“追加し続けた結果、複雑化したシステム”に起きる問題です。

「便利だから追加」が積み重なる理由

では、なぜ企業はこの状態になってしまうのでしょうか。

理由のひとつは、「その場で困っている課題」を優先するからです。
現場には日々の業務があります。

・入力に時間がかかる。
・確認作業が多い。
・Excel転記が面倒。
・承認フローが合わない。

こうした課題に対して、システム側を調整すれば、すぐに改善効果が出ます。

そのため、「この機能を追加しましょう」「この部署だけ例外対応しましょう」という判断が積み重なっていきます。

ただし、その時に見落とされやすいのが、“運用し続けるコスト”です。
システムは作って終わりではありません。

• 運用保守
• 改修
• バージョンアップ
• 他システム連携
• 権限管理
• データ移行
• 引き継ぎ

など、長期的に維持され続けます。
つまり、本当に重要なのは「作れるか」ではなく、「維持し続けられるか」です。

【関連記事】
Excel管理に限界を感じていませんか？脱Excelの方法を解説します。

フルスクラッチ開発でも同じ問題は起こる

ここで誤解されやすいのが、「フルスクラッチなら自由に作れるから大丈夫」という考えです。確かに、フルスクラッチ開発は柔軟性があります。自社業務に合わせて設計できるため、SaaSでは実現しづらい運用にも対応できます。

しかし、自由度が高いからこそ、“何でも追加できてしまう”危険性もあります。
実際、フルスクラッチ開発で失敗するケースの多くは、「要望を断らなかったこと」です。

• 現場ごとの例外対応
• 個別顧客向け仕様
• 一時的運用への最適化
• 過去業務をそのまま再現

こうした積み重ねによって、システム全体が複雑化していきます。

結果として、

• 改修のたびに時間がかかる
• 一部変更で別機能が壊れる
• 担当エンジニアしか理解できない
• 新機能追加が難しくなる

という状態になります。

つまり、フルスクラッチ開発で重要なのは、“自由に作れること”ではありません。
「何を追加しないか」を判断できることです。

長く使えるシステムは“例外”を増やしすぎない

長期運用されているシステムには共通点があります。それは、“例外が整理されている”ことです。

例えば、

• データの持ち方が統一されている
• 権限ルールが整理されている
• 承認フローが標準化されている
• 入力ルールが共通化されている

といった状態です。

逆に、運用負債が大きいシステムほど、

• 部署ごとに処理が違う
• 取引先ごとに画面が違う
• 人によって操作方法が違う
• 特定担当者だけが理解している

という状況になりやすくなります。

もちろん、業務には現実的な例外があります。
ただし、その例外を無制限にシステムへ取り込むと、将来的な保守性を大きく損ないます。

そのため、システム開発では、「本当にシステムで吸収すべきか」「運用ルール側で整理できないか」「将来的にも必要な運用なのか」を見極める必要があります。

“現場最適”だけでは全体が苦しくなる

システム開発では、「現場の声を聞くこと」が重要だといわれます。これは間違いではありません。

しかし、現場最適だけで設計すると、全体運用が崩れていきます。

例えば、「営業部には便利でも、管理部には確認作業が増える。」「一部部署には効率的でも、他部署とのデータ連携が難しくなる。」

現場単位では改善でも、会社全体では複雑化になるケースは少なくありません。

だからこそ、システム開発では、

• 全社共通で管理すべきもの
• 部署ごとに分けるべきもの
• 将来変更されやすいもの
• 長期間維持されるもの

を整理しながら設計する必要があります。
特に、複数部門が利用する基幹システムでは、この視点が非常に重要です。

「今便利」より「将来も運用できる」が重要になる

システム導入時は、「業務を楽にしたい」という視点が強くなります。
しかし、本当に差が出るのは数年後です。

• 担当者が変わった時
• 組織変更が起きた時
• 拠点が増えた時
• 新サービスが始まった時
• 他システムと連携する時

こうした変化に耐えられるかどうかで、システムの価値は大きく変わります。
そのため、システム開発では「追加できる柔軟性」だけでなく、

• シンプルに維持できるか
• 全体を把握しやすいか
• 改修しやすいか
• 引き継ぎしやすいか

という視点が欠かせません。
“今便利”だけで作られたシステムは、将来的に大きな負担になる可能性があります。

まとめ

「便利だから追加する」という判断は、短期的には正しいことがあります。しかし、その積み重ねが、将来的な運用負担や改修コストにつながるケースは少なくありません。

特に、長く使われる業務システムでは、「今の使いやすさ」だけではなく、

• 将来変更に対応できるか
• 保守しやすいか
• 全体で統一管理できるか
• 特定担当者に依存しないか

といった視点が重要になります。

システム開発は、単に機能を追加することではありません。「長く運用できる状態をどう維持するか」まで含めて考えることで、数年後の運用負担や改修リスクは大きく変わっていきます。

さいごに

システム開発では、「現場が便利になるか」という視点はもちろん重要です。
一方で、実際の運用では、

• 数年後も保守しやすいか
• 担当者変更に耐えられるか
• 他システムとの連携に対応できるか
• 業務変更時に柔軟に見直せるか

といった、“使い続ける前提”での設計が、後々大きな差になります。

特にフルスクラッチ（オーダーメイド）開発は自由度が高いため、「何を作るか」だけではなく、「何を増やしすぎないか」を整理しながら進めることが重要です。

当社フレシット株式会社では、単に要望をそのまま形にするのではなく、将来的な運用・改修・拡張まで見据えながら、業務整理や要件定義の段階から伴走しています。

「現場ごとの要望が増え続けている」
「システムが複雑化して改修しづらい」
「長く運用できる形で見直したい」

そのようなお悩みがありましたら、ぜひ一度ご相談ください。

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