医療業界のシステムを開発・導入するうえで、プロジェクトの成否をもっとも大きく左右するのが要件定義です。とくに医療・介護のシステムは、診療フローや法制度、保険請求、個人情報保護といった固有の要件を抱えるため、これをいかに正確に整理し、RFP（提案依頼書）や要件定義書に落とし込めるかが、現場に使われるシステムになるか、現場が混乱して使われないシステムになるかの分かれ目になります。実際、操作研修を機能説明に偏らせ、診療フローに沿った移行計画を要件に織り込まなかった結果、電子カルテの一斉移行初日に外来の待ち時間が平均3倍に膨らんだ失敗が起きています。
本記事は、医療業界のシステムのRFP・要件定義書・提案依頼書を、導入する医療機関の視点から具体的に解説する「要件定義特化」の記事です。現場ヒアリングとAsIs/ToBeモデルの描き方、医療特有の要件（保険請求・診療報酬改定・補助金・個人情報保護）の落とし込み、機能要件と非機能要件の整理、マルチベンダー環境での責任分界やデータ移行の要件、そして見積りの妥当性を判断する軸まで、医療の実務に即して掘り下げます。読み終えるころには、ベンダーに渡すRFPの骨子が描けるはずです。なお、全体像をまだ把握していない方は、まず医療業界のシステムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・医療業界のシステムの完全ガイド
診療フローのヒアリングとToBeモデルから始める
医療システムの要件定義は、「どんな機能が欲しいか」のリストアップから始めてはいけません。出発点は、現場が今どのように診療・ケアを回しているかを徹底的にヒアリングし、可視化することです。医療・介護の現場には、長年の慣行や診療科ごとの細かな運用、患者対応の例外処理が積み重なっています。これを無視して理想論で機能を決めると、現場の実態と噛み合わないシステムができあがります。
AsIsの診療・ケアフローを可視化するヒアリング
最初に行うべきは、現状（AsIs）の業務フローを可視化するヒアリングです。医師、看護師、薬剤師、医療事務、そして介護分野なら介護職員やケアマネジャーに、「患者・利用者の受付から会計までどう流れているか」「記録をどこに書き、どこへ転記しているか」「保険請求をどう作成しているか」「他の医療機関や薬局とどう連携しているか」を細かく聞き取ります。ここで重要なのは、マニュアルに書かれた建前ではなく、現場が実際に行っている運用や、属人的な例外処理まで拾うことです。
医療現場には、「この処置はベテラン看護師が手書きメモで管理している」「急患は通常フローと別の流れで処理する」といった、明文化されていない運用が必ずあります。これらを見落とすと、システムに移行した途端に現場が回らなくなります。介護現場では、介護ICTを「知らない」職員が74%という調査結果もあり、現場のリテラシーの実態までヒアリングで把握しておくことが、後の研修・定着計画にも生きてきます。AsIsの可視化は地道な作業ですが、ここで実態を正確につかむことが、要件の漏れを防ぎ、現場に使われるシステムを生む土台になります。
ToBeモデルで「あるべき診療業務の姿」を設計する
AsIsを可視化したら、次に描くのがToBeモデル、つまり「システムを導入した後、あるべき業務の姿」です。紙カルテで記録していた診療をシステムで一元管理し、転記を自動化し、保険請求まで連携させる。この新しい業務フローを具体的に設計したうえで、それを実現するために必要な機能を逆算します。ToBeを描かずに機能だけ決めると、機能はあっても業務がつながらない、という事態に陥ります。
電子カルテ一斉移行で外来が麻痺した失敗の本質は、まさにこのToBeモデルと、それに沿った移行・定着計画を要件に織り込まなかった点にあります。現場が日々どう診療を回しているかを起点にせず、機能の説明だけで移行を進めた結果、現場は操作に追われ、待ち時間が3倍に膨らみました。逆に、ToBeを丁寧に描き、診療フローに沿った実地訓練と段階移行を要件に組み込んだ医療機関は、混乱を最小限に抑えています。要件定義の出発点をToBeモデルに置くことが、現場の混乱を避ける最大の防衛策です。
医療特有の制度要件を機能要件に落とす方法
ToBeモデルを描いたら、いよいよ医療特有の制度要件を具体的な機能要件に落とし込みます。ここが医療システムの要件定義でもっとも難しく、かつ最重要の工程です。保険請求、診療報酬改定、補助金、個人情報保護といった制度要件は、ルールが複雑で改定も頻繁なため、曖昧なまま要件にすると後で必ず手戻りや法令違反のリスクが発生します。
保険請求・診療報酬改定・補助金の要件化
保険請求を要件化するには、自院がどの診療報酬点数を算定しているか、どの加算を取得しているかをすべて棚卸しする必要があります。そのうえで、レセプト作成・チェック機能が自院の算定実態に対応できるかを定義します。とくに重要なのが診療報酬改定への対応で、令和8年度改定では電子的診療情報連携体制整備加算（加算1=15点・加算2=9点・加算3=4点）のような新しい加算が設定されます。こうした改定に追随できる点数マスタの更新体制を、要件として明記しておくことが欠かせません。
補助金の要件も忘れてはいけません。電子処方箋の導入には国の補助最大194,000円、自治体上乗せで最大29.1万円が、介護ICT導入支援には職員数に応じて最低100万円相当が用意されています。これらの補助金には対象となるシステム要件や申請手続きが定められているため、補助対象となる仕様を要件に組み込むことで、実質的な負担を下げられます。補助金の適用可否を要件定義の段階で確認しておくことが、投資計画の精度を左右します。
マルチベンダー連携とデータ移行・過渡期の要件化
医療システムは、電子カルテ・レセコン・検査機器・薬局システムなど、複数のベンダーの製品が連携して動くマルチベンダー環境になりがちです。要件定義では、どのシステムとどのデータを、どの方向に、どのタイミングで連携するかを定義するだけでなく、障害が起きたときに「どのベンダーが原因切り分けの責任を負うのか」という責任分界点を明確にしておくことが重要です。これを曖昧にすると、トラブルのたびに自院が複数ベンダーの間で板挟みになり、原因切り分けを強いられます。
もう一つの泥臭い論点が、データ移行と過渡期の連携です。旧システムから新システムへ患者データを移すとき、クレンジングが不十分だと誤ったデータが表示される事故が起きます。新旧システムが混在する移行期間中、どちらを正としてどう連携するかも要件に織り込む必要があります。実際、安さを優先して既存システムと連携できないシステムを選び、二重入力が発生したうえに入れ替え費用と移行負担が二重にかかり、投資が全損になった失敗もあります。データ移行・過渡期連携・責任分界を要件に明記することが、こうした事故を防ぐ鍵です。
機能要件と非機能要件（個人情報保護）の整理
要件定義書は、機能要件と非機能要件の両方を網羅する必要があります。機能要件は「何ができるか」、非機能要件は「どれだけの品質・安全性で動くか」を定めるものです。医療システムでは、診療を支える機能要件に目が行きがちですが、患者の生命と最も機微な個人情報を扱うがゆえに、非機能要件、とりわけセキュリティと可用性は決しておろそかにできません。
機能要件を必須・優先・将来で分類する
機能要件は、ただ列挙するのではなく、優先度を付けて分類することが重要です。「これがないと診療・請求が回らない」必須機能（診療記録・レセプト・処方・権限管理）、「効果は大きいが初期になくても運用できる」優先機能（予約・チャットボット・データ分析）、「将来追加でよい」機能の三段階に分けます。医療システムはオーダーメイドにすると小規模でも数百万円から、大規模では数千万円以上に費用が膨らむため、この優先度付けが予算管理の生命線になります。
優先度を付けておくと、見積りが予算を超えた場合に、どの機能を初期リリースから外すかを冷静に判断できます。すべてを必須にしてしまうと、予算オーバー時に削るものがなくなり、プロジェクトが頓挫します。逆に優先度が明確なら、まず必須機能でリリースし、効果を見ながら優先機能を追加する段階的なリリース計画が立てられます。機能の具体的な内容については、関連記事もあわせてご覧ください。
非機能要件（セキュリティ・可用性・BCP）
非機能要件では、セキュリティ・可用性・BCP（事業継続）を定義します。セキュリティは、最も機微な医療情報を扱う医療システムでは最優先の要件です。職種別のアクセス権限制御、通信の暗号化、アクセス監査ログ、不正アクセス対策などを、厚生労働省のガイドラインなどを参照しつつ要件化します。設定ミスで患者の個人情報が外部から閲覧可能になった事故もあり、誰が設定を担い、どうレビューするかまで要件に含めるべきです。
可用性とBCPも、医療では特に重みを持ちます。システムが止まると診療そのものが止まり、患者の安全に直結するため、稼働率の目標、障害時の復旧時間、バックアップ体制を定めます。加えて、システム障害やサイバー攻撃でシステムが使えなくなったときに、紙で診療を続けるアナログ運用のフローを明文化しておくことも、医療ならではの重要な要件です。停電や通信障害を想定した紙運用への切り替え手順と、定期的なアナログ訓練を要件に盛り込むことで、最悪の事態でも患者を守れます。非機能要件を機能要件と同じ熱量で詰めることが、医療システムの安全性を担保します。
RFPに盛り込む項目と見積り妥当性の判断
要件定義書がまとまったら、それをベースにRFP（提案依頼書）を作成し、複数のベンダーに提案を依頼します。RFPの質が、集まる提案と見積りの質を決めます。曖昧なRFPには曖昧な見積りしか返ってこず、横並びの比較ができません。医療システムは費用幅が大きく、補助金や診療報酬という独自の回収ロジックも絡むため、RFPで土俵を揃えることが、見積りの妥当性を判断する大前提になります。
RFPに必ず盛り込むべき項目
RFPには、最低限以下の項目を盛り込みます。プロジェクトの目的とKPI（記録時間の削減や待ち時間の短縮など）、現状（AsIs）と目指す姿（ToBe）の業務フロー、機能要件（必須・優先・将来の分類付き）、非機能要件（セキュリティ・可用性・BCP）、既存システムとの連携要件とマルチベンダーの責任分界、データ移行の方針、予算とスケジュール、そして開発・運用・保守の体制要求です。医療特有の保険請求・診療報酬改定対応・補助金要件は、RFPの中核として具体的に記述します。
とくに見落とされがちなのが、導入後の運用・定着支援の体制要求です。医療システムは納品して終わりではなく、現場が使いこなせて初めて効果が出ます。導入時の実地訓練、移行初日のサポート体制、稼働後の利用ログ分析や設定改善といった伴走を、RFPで明確に求めることが有効です。納品時点で支援が終わり、利用率が下がって投資が無駄になる悪循環を避けるには、オンボーディングと継続伴走を体制要求に含めることが防衛策になります。
見積りの妥当性を判断する軸
集まった見積りの妥当性を判断するには、まず相場観を持つことです。クラウド型の電子カルテは初期約10万〜数十万円・月額1万〜数万円、オンプレミス型は初期200万〜500万円・月額2万〜4万円が目安です。介護ソフトはカイポケ月額5,000円〜などSaaSで軽く始められます。一方、自院独自の要件をフルカスタマイズで作る場合は費用が大きく膨らみます。見積りがこの相場から大きく外れている場合は、その理由を確認します。安すぎる場合は連携やセキュリティ要件が漏れている可能性、高すぎる場合は不要な要件が含まれている可能性があります。
次に、見積りの内訳を精査します。データ移行費や並行稼働の費用、保守費が一式でまとめられている場合は、内訳の開示を求めます。とくにデータ移行や移行期の並行稼働には隠れたコストが潜みやすく、ここを見積もれずに破綻するケースがあります。機能ごと・工程ごとに工数と単価が示されていれば、どこにコストがかかっているかが見え、追加要件が発生したときの単価ルールも事前に取り決められます。riplaはフルスクラッチ受託と国内開発の立場から、要件の透明な整理と、見積り内訳を明示する進め方を重視しています。要件定義の精度が、見積りの妥当性判断の精度を決めるのです。
体制図と実開発チームを要件で確認する
見積りの金額や内訳と並んで、RFPで必ず確認したいのが「誰が実際に開発・保守するのか」という体制の実態です。提案のプレゼンにはエース級の担当者が登場したのに、実際の開発は経験の浅い別チームが担い、稼働後に障害が頻発する、というギャップは医療システムでも起こりえます。患者の安全に関わる医療システムでこの種の体制ギャップが生じると、影響は経営や信頼の問題にとどまりません。
これを防ぐには、RFPで体制図の提出を求め、プロジェクトマネージャーは誰か、実装を担うエンジニアは誰か、保守フェーズの担当はどうなるかを明記させることが有効です。可能であれば、提案段階で実際の開発責任者と面談し、自院の診療フローやセキュリティ要件への理解度を確かめます。プレゼンの巧拙ではなく、実開発体制の実態を要件として確認できる項目をRFPに盛り込むことが、稼働後のトラブルを防ぐ防衛策になります。要件定義は機能や費用だけでなく、「誰が作るか」という体制の透明性まで担保して初めて完成するのです。
まとめ
医療業界のシステムの要件定義・RFP・提案依頼書は、機能の列挙からではなく、診療・ケアフローの現場ヒアリングでAsIsを可視化し、ToBeモデルを描くことから始めるのが鉄則です。そのうえで、保険請求・診療報酬改定・補助金・個人情報保護という医療特有の制度要件を漏れなく落とし込み、機能要件を必須・優先・将来で分類し、セキュリティ・可用性・BCP（紙運用を含む）といった非機能要件も詰める。これらをRFPに連携要件・マルチベンダー責任分界・データ移行方針・運用伴走の体制要求まで明記すれば、提案を横並びで比較でき、相場に照らして見積りの妥当性も判断できます。
電子カルテ一斉移行で外来が麻痺した失敗が示す通り、要件定義の質はそのまま現場の混乱の有無に直結します。現場の診療実態を正確に映した要件こそが、現場に使われるシステムを生みます。riplaはフルスクラッチ受託と国内開発を組み合わせ、現場ヒアリングからToBeモデル作成、制度要件の落とし込み、RFP作成までを医療機関と協働で支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。