個人開発の計算ツールは、なぜ病院で使えなかったのか
技術は通った。止まったのは、別の壁。
はじめに
お疲れ様です。
アースキーです😊
先日、私が個人開発した計算ツールが、勤務先の病院で「院内では使えません」と却下されました。
セキュリティは、固めたつもりでした。
それでも、通らなかった。
「個人開発でここまで作れる時代に、なぜ？」🤔
今回はこのリジェクト（突き返し）体験を、漫画と図解で整理してみます。
これは失敗談ではなく、作ったものを現場に届けるための「手順」の話です。
1. 院内でも使えたら、と思った
きっかけは、腎機能（＝腎臓が薬を体の外へ出す力のこと）の計算を、毎回手作業でやっている現場の風景でした。
自分用に作ったツールが動いたとき、素直に思ったんです。
「これ、職場のみんなも使えたら便利だよね😊」と。
2. 技術の壁は、越えていた
打診の前に、自分なりの安全対策は整えていました。
・完全オフライン動作（外部への通信ゼロ）
・患者さんの個人情報は入力欄ごと持たない
・「あくまで参考値」の注意書きを明記
実物の画面がこちらです。
※画面の数値はサンプルです。実際の薬の量の判断では、eGFRの数値をそのまま使わず、体格をふまえた別の指標（CCrなど）での確認が前提になります。
3. それでも、通らなかった
結果は、リジェクト（却下）でした。
理由は、ツールの出来ではありません。
「法人のツールではないこと」「正規の採用手順を通っていないこと」——つまり、技術とはまったく別の話でした。
正直、漫画のトリカと同じ気持ちが、私の中にもいました。
でも、落ち着いて考えると、組織側の言い分には筋が通っています。
今思うとあの判断をくださるシステム系の存在は大きいです😊
4. 止まったのは「別の壁」だった
整理すると、壁は2枚ありました。
技術の壁は、個人開発でも越えられます。
でも組織の壁——誰が作ったか、誰が責任を負うか、誰が守り続けるか——は、技術をいくら磨いても1ミリも動きません。
レイヤーが違うからです。
5. 道がないのではなく、順番がある
じゃあ、個人開発者に道はないのかというと、そうではありません。
一般には、情報システム部門への確認や、院内での採用審査・管理体制の整備といった正規の手順に乗せる道があります。
時間はかかりますが、「禁止」ではなく「順番」の話なんですよね
6. 「私が辞めたら、誰が引き継ぐの？」
さらに、自分では気づけなかった盲点も教えてもらいました。
作った本人がいなくなったら、そのツールは誰も直せない。誰も守れない。
このツールの中身を知っているのは、私だけです。
「組織で持つ」ことの意味が、ここで初めて腹に落ちました。
7. 【重要】病院の慎重さには、法律の裏付けがある
あとから調べて分かったのですが、病院側の判断は「なんとなく保守的」なのではありません。
きちんと法制度の裏付けがあります。
・薬機法（＝医薬品や医療機器のルールを定めた法律）: そのプログラムが「医療機器」にあたるかどうか、確認が要る
・医療法施行規則 第14条第2項（2023年〜）: 病院の管理者は、サイバーセキュリティ確保の措置が法令上の義務
・医療情報システムの安全管理に関するガイドライン（厚労省）: 管理していないソフトの持ち込みを統制する実務ルール
出典はこちらです。
・プログラムの医療機器該当性に関するガイドライン（PMDA掲載）
・医療機器プログラムについて（厚労省）
・医療情報システムの安全管理に関するガイドライン（厚労省）
つまり、あの慎重さは思考停止ではなく、患者さんを守るための設計でした。
（ここは後日記事にしていこうと思います。）
8. それでも、作ることはやめない
院内で使えなくても、自分が学ぶために作るのは、誰にも止められません。
次は、自分の学習用に「全部盛り」の計算ノートを、自分専用として作ってみるつもりです。
同じことをやってみたい方のために、今回の学びをチェックリストにしました。
保存して使ってください。
読者のあなたに渡せる一歩は、これだけです。
院内に持ち込みたくなったら、作る前でも作った後でもいいので、まず「正規の手順はありますか」と一言聞いてみる。
おわりに
作るのは、自由。
届けるには、手順がある。
今回の提出で、「個人開発でここまでできる」を実物で見てもらえたこと自体は、達成でした。
見せてもらう側から、見せる側へ。
今度は私が、誰かのレベルを引き上げる側になっていきます。
あなたの職場にも、正規の手順はありますか。
もしこの記事が少しでも役に立ったら、身近な医療従事者の仲間やSNSでシェアしていただけると嬉しいです。
とても共感できる内容でした。
医療機関では、専属ベンダーやシステム部門が運用・保守を担っているケースが多くあります。
そのため、アプリ開発は「作って終わり」ではなく、その後の運用・保守こそが大きな課題になります。
特に最近は、医療機関向けのサイバーセキュリティ対策が一段と厳しくなりました。
サイバーセキュリティチェックリストの要件を満たしていなければ改善指導が行われ、場合によっては行政指導の対象になることもあります。
そのため、セキュリティ対策は継続的なアップデートが欠かせません。
さらに、端末のOSがバージョンアップされるたびに、アプリ側もアップデートして互換性を維持する必要があります。
こうした継続的な対応を考えると、医療機関向けのシステムは開発そのものよりも、その後の運用・保守にかかる負担のほうが大きいと言っても過言ではありません。
改めて、医療システムは「開発して終わり」ではなく、長期的な運用を前提に設計・維持していくことが重要だと感じました。
「自分が辞めたら誰が引き継ぐのか」という指摘は、組織のシステム運用において本当に重い言葉ですね。個人開発のツールがどれだけ優秀で安全であっても、作った本人がいなくなった途端にブラックボックス化し、万が一の不具合の際に誰も責任を取れなくなってしまう。組織としてツールを導入するということは、単に「便利さ」だけでなく、その後の「運用と保守の責任」を丸ごと引き受けることなのだと、改めて気づかされました。リジェクトされたことを単なる却下で終わらせず、その裏にある組織側の筋道を冷静に整理されている姿勢が素晴らしいです。