「費用相場はだいたい分かった。あとは何社かに見積もりを取って、いちばん条件のいいところに頼むだけ」——医療DXシステムの導入を検討している院長先生や事務長の方が、ここで手を止めてしまうケースは少なくありません。いざ問い合わせフォームを前にすると、「自院は何を、どこまで作りたいのか」を自分の言葉で説明できないことに気づくからです。
口頭で「うちの受付業務を効率化したい」と伝えても、ベンダーごとに想像する中身はバラバラです。その結果、戻ってくる見積もりは前提が揃わず、金額だけ見ても比較になりません。さらに厄介なのは、要件が曖昧なまま発注に進むと、開発の途中で「これも必要だった」「あれは想定外だった」となり、追加費用がじわじわ膨らんでいくことです。IT専任者がいない医療機関では、この「最初の整理」を誰がどう進めればいいのかが、そもそも分からないという声をよく聞きます。
ですが、ご安心ください。発注前に院内で固めておくべきことは、専門用語を覚えなくても、決まった順序に沿って進めれば整理できます。大切なのは「費用がいくらか」を調べることではなく、「自院が何を、どこまで、どんな優先順位で作りたいか」を1枚の資料にまとめてからベンダーに連絡することです。同じ前提を全社に渡せれば、見積もりは比較可能になり、予算オーバーや追加費用の芽を発注前に潰せます。
本記事では、医療システム開発を発注する前に院内で確認すべき7項目を、相場の答えではなく「院内で何を決め、何を集めるか」という準備手順として解説します。IT担当がいなくても作れる「要件メモ1枚」の作り方、それを使って複数ベンダーに同じ前提で見積もりを依頼する進め方、つまずきやすいポイントの回避策まで、発注前の最初の一歩を順を追って案内します。なお、費用レンジそのものや見積もりの読み解き方の詳細は別記事に譲り、本記事は「ベンダーに連絡するまでの院内準備」に絞ってお伝えします。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
なぜ医療DXは「発注前の要件整理」で費用と成否が決まるのか
費用相場を調べても、いざ見積もりを取ると金額がバラバラで比較できない——この「詰まり」の正体は、ベンダーの良し悪しではなく、自院の要件が固まっていないことにあります。前提が揃わない状態で複数社に見積もりを依頼すると、各社が思い思いの前提で計算するため、そもそも比べられる土俵に乗らないのです。
「言い値」と「追加費用」は要件の曖昧さから生まれる
システム開発の見積もりは、「何を、どこまで作るか」という範囲（スコープ）が決まって初めて精度が出ます。逆に言えば、範囲が曖昧なまま依頼すると、ベンダーは2つのうちどちらかで対応せざるを得ません。1つは「安全側に多めに見積もる」、もう1つは「最小限で見積もっておき、後から追加で精算する」というやり方です。前者は割高な見積もりになり、後者は契約後に「それは別料金です」という追加費用が次々と発生します。医療機関で「言った言わない」のトラブルや予算オーバーが起きやすいのは、この曖昧さが原因であることがほとんどです。
実際、システム開発の専門メディアでも、発注前に「目的・現状の業務フロー・利用者・必要な機能・予算・希望時期」を簡単にでも書き出しておくと、発注後のやり取りが格段にスムーズになると指摘されています（システム開発の発注工程と流れ｜SucSak）。つまり、見積もりがブレるかどうかは、ベンダーに連絡する「前」の院内準備で大きく決まるということです。
医療システムの場合、これに加えて電子カルテやレセプトコンピュータ（レセコン）との連携、患者データの移行、医療特有のセキュリティ要件といった「医療ならではの前提」が絡みます。これらを発注前に整理せずに進めると、後から「連携が必要だった」「移行データの形式が合わない」といった想定外が見積もりを押し上げてしまいます。
費用相場・見積もり比較の基礎は別記事で
本記事は「発注前の院内準備」に焦点を当てるため、費用レンジそのものや見積もりの妥当性の見極め方は扱いません。これらをまだ確認していない方は、先に以下の記事で全体像を把握しておくと、本記事の準備手順がより活きてきます。
- 規模別の費用感や見積もりに影響する要素を知りたい方は、医療DXシステム開発の費用相場2026｜発注前に確認する7項目をご覧ください。
- 複数社の見積もりをどう読み比べるかを知りたい方は、医療システム開発の見積もり比較｜適正価格を見抜く7つの確認項目が参考になります。
費用の答え合わせはこれらの記事に任せ、本記事では「比較できる見積もりが返ってくる状態」を作るための準備に集中します。
ベンダーに連絡する前に院内で固める「発注前に確認する7項目」
ここからが本題です。発注前に確認すべき7項目を、「相場はいくらか」という問いではなく、「院内で何を決め、何を集めるか」というワークとして捉え直します。それぞれの項目を「院内で確認する問い」「集める情報・様式」「決め方のコツ」の3点で具体化していきます。これらを順に埋めていくことが、要件を固める最短ルートです。
スコープを決める（項目1〜3）
最初の3項目は、システムの「範囲」を決めるための問いです。範囲が決まらないと見積もりは比較できないため、ここがもっとも重要なステップになります。
項目1: 対象業務と優先順位を決める
- 院内で確認する問い: 「今いちばん困っている業務は何か」「このシステムで解決したい業務はどれか」
- 集める情報: 効率化したい業務の一覧（例: 受付・予約、会計、診療記録の入力、患者への案内など）。それぞれの現状の困りごと
- 決め方のコツ: 「全部やりたい」となりがちですが、最初から全業務を対象にすると費用も期間も膨らみます。「絶対に必要（must）」「あれば嬉しい（want）」の2段階で優先順位を付け、まずは must に絞って範囲を描くと、見積もりが現実的になります。
項目2: 既製品（パッケージ）かカスタム開発かの方向性を持つ
- 院内で確認する問い: 「市販の電子カルテや予約システムで足りるのか」「自院独自のやり方を再現する必要があるのか」
- 集める情報: 現在使っているシステム名、不満点、どうしても譲れない独自の運用
- 決め方のコツ: 既製品で済むならコストも導入期間も抑えられます。カスタム開発が必要かどうかは「独自運用が患者満足や収益に直結するか」で判断します。この段階では結論を出し切る必要はなく、「どちらに寄せたいか」の希望をベンダーに伝えられれば十分です。
項目3: 連携対象を洗い出す
- 院内で確認する問い: 「このシステムは、既にある電子カルテ・レセコン・予約システムとデータをやり取りする必要があるか」
- 集める情報: 現在稼働しているシステムの名称・メーカー・バージョン。連携したいデータの種類（患者情報、予約、会計など）
- 決め方のコツ: 連携の有無は見積もりを大きく左右します。後から「連携が必要だった」と判明すると追加費用の原因になるため、現時点で稼働中のシステムをすべて書き出しておきましょう。メーカーやバージョンが分からない場合は、保守契約書や納品書に記載されていることが多いので確認します。
医療特有の前提を確認する（項目4〜5）
次の2項目は、医療機関だからこそ外せない前提です。一般的な業務システムと違い、ここを見落とすと法令対応やデータ移行で手戻りが発生します。
項目4: 標準規格・セキュリティ要件を確認する
- 院内で確認する問い: 「将来の電子カルテ標準化やデータ連携に対応する必要があるか」「患者情報の取り扱いで守るべきルールは何か」
- 集める情報: 取り扱う個人情報・医療情報の範囲、現在のセキュリティ対策（アクセス制限、バックアップなど）
- 決め方のコツ: 厚生労働省はデジタル庁と連携し、国際標準規格「HL7 FHIR（エイチエルセブン・ファイア）」を採用したクラウド型の標準型電子カルテの開発を進めており、2025年3月に一部の診療所でα版の提供が始まっています（厚生労働省が進める「標準型電子カルテ」とは｜エムスリーデジカル）。今後、異なるメーカー間でのデータ連携が前提になる流れがあるため、「将来の連携に対応できる作りにしたいか」という希望をベンダーに伝えられるよう、方向性を持っておくと安心です。医療情報を扱う以上、安全管理のガイドライン遵守は前提となるため、自院がどんな情報を扱うかは整理しておきましょう。
項目5: データ移行の範囲を決める
- 院内で確認する問い: 「既存システムのどのデータを、新システムに引き継ぐ必要があるか」「過去何年分を移行するか」
- 集める情報: 移行したいデータの種類と量、現在のデータ形式（分かる範囲で）
- 決め方のコツ: データ移行は見積もりで見落とされやすく、後から大きな追加費用になりやすい項目です。「全部移行」は安全に見えて高額になりがちなので、「直近◯年分だけ移行し、古いデータは旧システムで参照可能にする」といった割り切りも選択肢に入れて、移行範囲を先に決めておきます。
運用と制度を見据える（項目6〜7）
最後の2項目は、開発が終わった「後」を見据えるための問いです。導入時の費用だけでなく、運用フェーズの安心感に直結します。
項目6: 保守・サポートの範囲を確認する
- 院内で確認する問い: 「導入後のトラブル対応・操作問い合わせは誰が、どこまで対応してくれるのか」「対応時間帯は診療時間に合っているか」
- 集める情報: 想定する利用時間帯、トラブル時に許容できる停止時間、院内で対応できる範囲
- 決め方のコツ: 医療現場ではシステム停止が診療に直結するため、保守・サポートの手厚さは重要です。初期費用が安くても、保守費用や対応範囲が手薄だと運用で困ります。「平日日中のみか、診療時間に合わせた対応か」「電話・リモート・訪問のどれに対応するか」を確認できるよう、自院の希望を整理しておきましょう。
項目7: 補助金・制度活用の可否を確認する
- 院内で確認する問い: 「導入にあたって使える補助金や支援制度はあるか」「申請のスケジュールは開発スケジュールと合うか」
- 集める情報: 検討中の補助制度、申請期限、自院が対象になりそうか
- 決め方のコツ: 補助金は申請時期や対象要件が決まっているため、開発を進める前に確認しておくと予算計画が立てやすくなります。制度の詳細や費用への具体的な影響については、費用相場を扱った記事の方が詳しいため、そちらと併せて確認してください。本記事では「補助金の有無を発注前に整理しておく」という準備の観点にとどめます。
これら7項目を順に確認していけば、「何を、どこまで作りたいか」がかなりはっきりしてきます。次は、これを1枚の資料にまとめる方法を見ていきましょう。
IT担当がいない医療機関のための「要件メモ1枚」の作り方
7項目を確認したら、それを1枚の資料（ここでは「要件メモ」と呼びます）にまとめます。立派な仕様書を作る必要はありません。専門知識がなくても、誰に何を聞き、どの順でまとめればよいかが分かれば、A4で1〜2枚の要件メモは十分に作れます。これが本記事でいちばんお伝えしたい「最初の一歩」の中身です。
まず「現状の困りごと」と「やめたい作業」から書き出す
要件メモは、いきなり「欲しい機能」から書こうとすると手が止まります。順番を逆にして、「今、何に困っているか」「やめたい・減らしたい作業は何か」から書き出すのがコツです。
例えば「予約の電話対応で受付が手一杯」「会計待ちの行列が長い」「紙のカルテを探すのに時間がかかる」といった、現場の生の困りごとです。困りごとを書き出してから「では、それを解決するには何が必要か」と考えると、機能の要件が自然に見えてきます。最初から技術的な機能名を考える必要はありません。
このとき、現状の業務の流れ（業務フロー）を簡単に書き出しておくと、ベンダーに説明する際にとても役立ちます。「患者が来院してから会計を終えて帰るまで、どんな手順を踏んでいるか」を箇条書きで並べるだけで十分です。図にできればなお良いですが、文章の箇条書きでも構いません。
1枚にまとめる項目
要件メモには、先ほどの7項目で確認した内容を、以下の項目に整理して書き込みます。これがそのままベンダーへ渡す「同じ前提」になります。
- 目的: このシステムで何を実現したいか（1〜2行で。例: 受付業務の負担を減らし、患者の待ち時間を短縮する）
- 対象業務と優先順位: must（必須）と want（できれば）に分けて列挙
- 現状の業務フロー: 主要な業務の流れを箇条書きで
- 連携対象: 現在稼働中のシステム名・メーカー（分かる範囲で）
- データ移行: 引き継ぎたいデータの種類と範囲（例: 直近3年分の患者基本情報）
- 医療特有の前提: 取り扱う情報の範囲、将来の標準化対応の希望
- 保守・サポートの希望: 対応時間帯、許容できる停止時間
- 予算上限と希望時期: 上限の目安と、いつまでに稼働させたいか
すべての欄を完璧に埋める必要はありません。分からない欄は「未定・ベンダーに相談したい」と書いておけば、それも立派な情報になります。空欄のままにせず「ここは相談したい」と明示するだけで、見積もりの精度は上がります。
院内の合意形成
要件メモを作る過程で意外と難所になるのが、院内の意見をまとめることです。院長・事務長・現場スタッフ・医事課では、それぞれ見ている景色が違います。現場が「予約が大変」と感じていても、院長は「収益管理を強化したい」と考えているかもしれません。
合意形成のコツは、ヒアリングの順番を工夫することです。まず現場スタッフから「困りごと」を集め、次に医事・経理から「数字や運用上の制約」を聞き、最後に院長と「優先順位と予算の上限」をすり合わせる、という順序が進めやすいでしょう。集めた意見を要件メモのドラフトに落とし込み、最後に関係者で一度目を通して「この前提でベンダーに見積もりを依頼する」という合意を取れば、後の「言った言わない」を大きく減らせます。
要件メモは一度で完璧に仕上げる必要はありません。ドラフトを作って関係者に見せ、抜けを補う、という流れで2〜3回更新すれば、発注に使える資料になります。
同じ要件メモで複数ベンダーに見積もりを依頼するときの進め方
要件メモが固まったら、いよいよ複数ベンダーへの見積もり依頼です。ここでの目的はただ一つ、「全社に同じ前提を渡し、比較できる見積もりを受け取ること」です。
問い合わせ時に必ず添える情報と、避けたい曖昧表現
問い合わせフォームや初回相談では、口頭の説明だけで済ませず、作成した要件メモを添付・共有しましょう。これにより、各社が同じ情報をもとに見積もるため、前提のズレが大幅に減ります。なお、こうした「発注者が開発会社に提案を依頼する資料」は、システム開発の世界ではRFP（提案依頼書）と呼ばれます（RFPとは？要件定義書やRFIとの違い｜システム幹事）。要件メモは、その簡易版だと考えれば十分です。立派な様式である必要はなく、「同じ前提を全社に渡す」という役割を果たせれば目的は達成できます。
問い合わせ時に必ず伝えたいのは、次の情報です。
- システムの目的と、対象業務（must / want の優先順位つき）
- 連携が必要なシステムの有無
- データ移行の希望範囲
- 予算の上限の目安と、希望する稼働時期
- 保守・サポートに求める水準
逆に、避けたいのは次のような曖昧表現です。
- 「いい感じに効率化したい」→ どの業務を、どう改善したいかを具体化する
- 「最新のシステムにしたい」→ 必要な機能を優先順位つきで示す
- 「予算は相談で」→ 上限の目安を伝える（範囲でも構いません。例: ◯◯万円〜◯◯万円）
予算を伝えると足元を見られるのでは、と心配する方もいますが、上限の目安を共有した方が、ベンダーは「その範囲で何ができるか」を現実的に提案でき、結果的に比較しやすい見積もりが返ってきます。
比較の詳細は別記事で
複数社から見積もりが返ってきたら、次は読み比べる段階です。同じ要件メモで依頼していれば、各社の見積もりは比較可能な土俵に乗っています。あとは、項目の抜け漏れや前提の違い、追加費用の発生条件などを丁寧に確認していきます。
見積もりの具体的な読み比べ方や、適正価格を見抜くための確認項目については、医療システム開発の見積もり比較｜適正価格を見抜く7つの確認項目で詳しく解説しています。要件メモで「同じ前提」を作ったうえで、こちらの記事を使って比較に進むと、判断がぐっとしやすくなります。
発注前準備でつまずきやすいポイントと回避のコツ
最後に、要件を固める段階で起きがちな失敗と、その回避策をまとめます。多くは「先に決めておけば防げた」ものばかりです。発注前に目を通しておくことで、追加費用や予算オーバーの芽を事前に潰せます。
-
全部入りにしてしまう: 「せっかくだから」とあらゆる機能を盛り込むと、費用も期間も膨らみ、現場が使いこなせないシステムになりがちです。回避策は、must と want を分け、まずは must に絞って範囲を描くこと。want は次のフェーズに回す前提で考えると、初期投資を抑えられます。
-
現場の声を聞かずに決めてしまう: 経営層だけで仕様を決めると、実際に使う現場スタッフの業務に合わず、導入後に使われないシステムになることがあります。回避策は、要件メモを作る段階で必ず現場の困りごとを拾うこと。日々その業務をしている人がいちばん課題を知っています。
-
連携を後回しにする: 既存の電子カルテやレセコンとの連携を「後で考えよう」とすると、見積もり後に大きな追加費用として跳ね返ります。回避策は、稼働中のシステムを発注前にすべて洗い出し、連携の要否を要件メモに明記すること。
-
データ移行の範囲を詰めない: 「全部移行」と曖昧にしたまま進めると、データ量や形式によって費用が大きく変動します。回避策は、移行する期間・種類を先に決めること。古いデータは旧システムで参照可能にする、といった割り切りも有効です。
-
補助金の確認を後回しにする: 開発を進めてから補助金の申請期限に気づくと、計画全体が崩れます。回避策は、使えそうな制度の申請時期を、発注前のスケジュール検討に組み込んでおくこと。
これらはいずれも、要件メモを丁寧に作る過程で自然に潰せるものです。医療システム特有の法規制やセキュリティ、外注前の確認事項をより広く押さえておきたい方は、医療AI・医療DXシステムを外注する前に確認すべきことも併せて確認しておくと、抜け漏れを減らせます。
まとめ——要件を1枚に固めてから、自信を持って見積もり依頼へ
医療DXシステムの発注でつまずく原因の多くは、費用相場の理解不足ではなく、「自院が何を、どこまで作りたいか」が固まっていないことにあります。本記事でお伝えした流れを、改めて整理します。
- 発注前に確認する7項目を院内で固める: スコープ（対象業務・優先順位・既製品かカスタムか・連携対象）、医療特有の前提（標準規格やセキュリティ・データ移行範囲）、運用と制度（保守サポート・補助金）を、「何を決め、何を集めるか」のワークとして確認する
- 要件メモ1枚にまとめる: 困りごとから書き出し、目的・対象業務・連携・移行・予算上限などを1枚に整理する。分からない欄は「相談したい」と明記すれば十分
- 同じ要件メモで複数ベンダーに依頼する: 全社に同じ前提を渡すことで、比較可能で予算内に収まりやすい見積もりが返ってくる
この準備を済ませておけば、問い合わせフォームの前で手が止まることはなくなります。「自院の要件はこれです」と1枚の資料を示せる状態こそが、追加費用や予算オーバーの芽を発注前に潰し、納得のいくベンダー選びにつながる最初の一歩です。
なお、費用レンジの全体像は医療DXシステム開発の費用相場2026｜発注前に確認する7項目、見積もりの読み比べ方は医療システム開発の見積もり比較｜適正価格を見抜く7つの確認項目で詳しく解説しています。本記事の要件メモを手に、これらの記事を活用して、自信を持って見積もり依頼へ進んでください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 要件メモの全項目を埋めきれなくても、ベンダーに問い合わせてよいですか？
「ここはベンダーに相談したい」と明記すれば問題ありません。空欄のまま送ると前提が揃わず見積もりがブレますが、未定事項を明示することでベンダーは相談前提で回答でき、曖昧なまま進むより見積もりの精度は上がります。
- 「必須（must）」と「できれば（want）」をどう仕分けるか、基準を教えてください。
「これがなければ現場の業務が回らない」ものをmustとし、「あれば便利・効率が上がる」ものをwantと分類するのが基本です。予算や期間の制約が明確でない段階はmustを絞り込むだけで十分で、wantは次フェーズの候補として記録しておけば比較見積もりに使えます。
- 稼働中のシステムのメーカーやバージョンが分からない場合、連携情報はどう集めればよいですか？
保守契約書・納品書・システム管理会社への問い合わせで確認できることがほとんどです。それでも不明な場合は「システム名は〇〇だが詳細は確認中」と記載してベンダーに共有すれば、見積もり段階で必要な確認をベンダーがサポートしてくれます。
- 補助金の確認は、ベンダーへの問い合わせ前と後、どちらのタイミングでするべきですか？
問い合わせ前が原則です。補助金には申請期限と対象要件があり、開発スケジュールと申請タイミングが噛み合わないと活用できなくなります。要件を固める段階で使える制度の申請期限を確認し、スケジュールに組み込んでおきましょう。
- 見積もりは何社に依頼するのが適切ですか？
3社程度が現実的な目安です。1社では比較ができず、5社以上になると要件メモ共有・質疑対応の工数が増えて準備が形骸化しやすくなります。同じ要件メモを渡せる状態を作ってから依頼することが、比較精度を保つうえで最も重要です。
