この領域で扱える課題
VENDOR DISCONNECT
複数ベンダーが分離しており、誰も全体を把握できない。制度変更の影響を検証する手段がない。
CLOSED NETWORK
外部ネットワーク遮断。クラウドAPIが使えない閉域環境でのシステム設計・AI活用。
SINGLE POINT OF FAILURE
特定の担当者1名に依存しているシステム。その人がいなくなると止まる構造の解消。
UNDOCUMENTED SYSTEM
仕様が担当者の頭の中にある。ドキュメントがない内製システムの構造解読と形式知化。
主な実績
MEDICAL — 現在進行中
賃金制度改定に伴う給与評価・試算基盤の構築
BEFORE
- 賃金テーブル設計ベンダーと給与計算ベンダーが分離
- 制度適用結果を誰も検証できない
- 管理職が給与構成の根拠を説明できない
- ベンダー間にデータ断絶が存在
AFTER
- Docker×SQL Serverで統合評価基盤を構築
- 職種別給与分布・制度変更影響を可視化
- 管理職が説明責任を果たせる状態に
- 行政報告用帳票生成まで自動化
判断のポイント：基幹システムがない環境でも、DockerでSQL Serverを立てれば動く。環境の制約を言い訳にしない設計。賃金テーブル・職種区分・手当体系の構造を見た瞬間に何が必要かわかった。「1日でできた。ただし25年かかった。」
Docker
SQL Server
データモデリング
ベンダー間調整
責任境界設計
MEDICAL — 現在進行中
閉域環境でのRPA×生成AI処理基盤の構築
電子カルテ環境は外部ネットワークから切り離された閉域ネットワーク上で運用されており、一般的なクラウド型AIが使えない。その制約の中で、ローカル動作する生成AIモデルを選定・導入設計し、RPAと組み合わせた処理基盤を構築した。
BEFORE
- クラウドAPIが使えない閉域環境
- データが複数システムに分散
- 特定管理者の能力に情報処理が依存
- 部署・職種の壁を越えた集約が困難
AFTER
- ローカル生成AIモデルで閉域環境に対応
- RPA×生成AIの連携処理フローを設計
- 数千名規模のデータ処理基盤を整備
- 部署・職種を越えた情報集約を実現
判断のポイント：「クラウドが使えないからできない」という状況を言い訳にしない。制約があるほど動ける。閉域環境でのAI活用は医療介護特有の課題で、ここに実装経験を持つ人間は少ない。
BizRobo（RPA）
生成AI（ローカル）
電子カルテ連携
閉域環境設計
MEDICAL — 現在進行中
SmartHR→給与計算→経理ソフト 連携基盤の設計・維持
SmartHR→エコミック（給与計算代行）→経理ソフトへのシステム連携を構築・維持。SmartHR側の仕様変更が頻発するため、データが届くまで仕様が不明という状態が常態化している。届いてから変換処理を組む対応を一人で担っている。
「届いたデータを見て変換処理を組める人間」が他にいない状態。仕様が固まるのを待たず、届いた段階で即座に対応できる設計能力と実装力が求められる。
これは技術の話ではなく、判断の話だ。
SmartHR
データ変換設計
給与計算連携
単独対応
製造業と医療介護、両側を知っている
製造業25年で身につけた判断軸が、医療介護の現場で直接機能している。
| 項目 | 製造業（前職） | 医療介護（現職） |
|---|---|---|
| システムの前提 | 内製が基本。基幹も内製 | 外注・パッケージが基本。データ変換すら外注 |
| DBの構造 | 部品中心・工程中心・規格値ベース | 人中心・時系列・例外が常態 |
| 止められるか | 計画停止が可能 | 止められない前提 |
| 介入の起点 | 技術的迷走・レガシー | ベンダー間断絶・制度未整備 |
「ここまでの情報が揃っていれば対応できる」という線引き、「この部分のメンテナンスはどこが担当か」という責任分界の設定。製造業で25年かけて身につけた判断軸が、データ変換すら外注せざるを得ない医療介護の環境で直接機能した。この結果として、これまで丸投げするしかなかった各担当が責任を持って引き受ける状態に変わった。
話せるテーマ
- 閉域環境でのRPA×生成AI活用設計（電子カルテ環境での実装経験）
- 複数ベンダーが分離した医療法人でのデータ統合設計
- 賃金制度改定・人事制度変更に伴うシステム基盤整備
- 止められない環境での移行設計（並行稼働・段階切り替え）
- 属人化したシステムの構造解読・形式知化・出口設計
- 医療介護における情報処理標準化と人材流動化の設計
- IT投資判断：内製継続か外注化かの見極め基準
コメントを残す