歯科医院のシステム開発外注｜レセコン連携を発注前に確かめる手順

歯科向けの予約システムを一通り比較して、それでも決められないまま検索を続けている。おそらくその原因は、製品の機能や料金ではなく「自院のレセコンとつながるかどうか」が最後まで確定しないことにあります。比較サイトの対応可否欄は自院で使っている製品の型番まではカバーしておらず、問い合わせても「個別に確認が必要です」と返ってくる。そこで話が止まってしまいます。

歯科医院のシステム開発外注が難しいのは、技術の話が難しいからではありません。投資判断に必要な事実（連携できるのか、どこまでできるのか）を、発注前に自分で確かめる方法が知られていないからです。連携範囲が確定しないまま見積を取ると、A 社は 150 万円、B 社は 480 万円といった数倍の開き方をします。院長からすればどちらが正しいのか判断できず、結局は営業担当者の説明の説得力で決めることになってしまいます。

この状態は、発注側が一手間を先に打つだけで大きく変わります。連携の可否を握っているのは開発会社ではなく、レセコン（電子カルテ）を提供しているメーカーです。メーカーに数項目を照会して回答を文書で受け取っておけば、その回答を添えて相見積を依頼できます。同じ前提で見積が並ぶため、金額差の理由が読めるようになり、SaaS で足りるのか作るべきなのかという上流の判断も自分の言葉でできるようになります。

本記事では、歯科医院に固有のシステム要件の整理から、レセコン・電子カルテ連携の可否を発注前に確認する具体的な手順、SaaS と独自開発の判断軸、費用が割れる理由、医療情報を扱う外注先の見極め方、そして発注までの 5 ステップまでを順に解説します。読み終えたときに、次に誰へ何を聞けばよいかが決まっている状態を目指します。

歯科医院がシステム開発の外注を検討するようになる背景

まず、自分の医院が今どの地点にいるのかを地図の上に置くところから始めます。歯科医院がシステム開発の外注を検討し始めるタイミングには共通のパターンがあり、そこを言語化しておくと、後の判断が一段ラクになります。

手作業の予約・リコール運用が限界に達するタイミング

多くの医院は、開業当初はレセコン付属の予約機能と紙の台帳、電話対応の組み合わせで十分に回ります。それが破綻するきっかけは、だいたい次の 3 つのいずれかです。

• 分院展開・チェア増設: 拠点をまたいで患者データと予約枠が分断され、「どちらの医院に来ているか分からない患者」が生まれる
• スタッフの増員と入れ替わり: 属人的に運用されていた予約ルール（この処置なら 45 分、この先生は木曜午後は自費のみ、など）が引き継がれず、枠の取り方が人によって変わる
• キャンセル・リコール対応の負荷: 電話とハガキでの呼び戻しが物理的に追いつかなくなる

このうち、経営インパクトが数字で見えやすいのがキャンセルとリコールです。歯科医院のキャンセル率は無断キャンセルで 5% 以下、連絡ありを含めたトータルで 10% 以下が目標水準とされており、1 日 40 枠・月 22 日診療・平均単価 7,000 円のモデルではキャンセル率 10% で年間約 739 万円の機会損失に相当すると試算されています（医療DXガイド）。自費中心の医院では損失額はさらに大きくなります。

リコールも同様です。歯科医院のリコール率の全国平均は約 60% とされ、LINE や SMS での自動配信を導入した医院では 80% 前後に到達しているという報告があります（歯科経営のミカタ）。ここには、仕組みを入れるかどうかで 20 ポイント前後の差が生まれる余地があるということになります。

これらの数値は業界メディアが公開しているモデルケースであり、医院ごとの実態は診療科目構成や地域によって変わります。ただ、「手作業のままでいることにもコストがかかっている」ことを金額で置いてみるという作業は、投資判断の前提として有効です。システム導入の是非を「費用がかかる/かからない」ではなく「どちらのコストが大きいか」という比較で考えられるようになります。

SaaS比較だけでは決着しない歯科医院DXの典型パターン

歯科医院向けの予約システムやリコール支援ツールは SaaS として数多く提供されており、多くの医院はまずそこから検討を始めます。それで決着がつくならそれが最善です。SaaS で足りる医院がわざわざ開発を外注する理由はありません。

一方で、比較を尽くしても決まらない医院には次のような共通点があります。

この 5 つのうち、後の判断をすべて左右するのが 1 番目のレセコン連携です。連携できないと分かれば、SaaS を使うにしても患者情報の二重入力が前提になり、そのコストを織り込んだ比較に切り替える必要があります。逆に連携できると分かれば、独自開発ではなく SaaS と連携部分だけの受託開発という中間解が視野に入ります。

つまり、「作るべきかどうか」を考える前に「つながるかどうか」を確定させる順序が正しいということです。多くの記事がこの順序を逆に扱っているため、費用相場を読んでも判断が進まないという状態が生まれます。

歯科医院のシステムに固有の要件｜予約・リコール・レセコン連携

連携できるかを確認するには、その前に「何を連携したいのか」が言語化されている必要があります。ここでは、汎用の予約システムと歯科医院向けの要件がどこで分岐するのかを具体化します。このセクションの内容は、そのまま要件メモの下書きとして使えるように書いています。

チェア・担当者単位で組む予約枠の難しさ

飲食店や美容室の予約システムと歯科医院の予約が決定的に違うのは、枠が二重の制約を持っている点です。

• チェア（ユニット）の制約: 物理的な台数が上限。X 線撮影が必要な処置は特定のチェアに限られることもある
• 担当者の制約: 歯科医師・歯科衛生士それぞれの稼働。歯科衛生士が主担当のメンテナンス枠と、歯科医師の確認が必要な枠は扱いが異なる

このため、「チェアは空いているが担当者が埋まっている」「担当者は空いているがチェアが足りない」という状態が日常的に発生します。汎用の予約システムはリソースを 1 軸でしか扱えないものが多く、ここで最初の壁が来ます。

さらに歯科特有の事情として、次の要件が加わります。

要件メモを作るときは、この表の各行に対して「自院で必要か / 不要か / 現状どうしているか」を書き込んでいく形が扱いやすいです。開発会社に見せる資料としても、SaaS の適合性を判断する材料としてもそのまま使えます。

リコール（定期検診の呼び戻し）を仕組みにする要件

リコールは、歯科医院の収益構造に直結する一方で、仕組み化の難易度が高い領域です。単に「〇ヶ月後に一斉送信する」だけでは機能しません。

仕組みにするうえで決めておくべき項目は次のとおりです。

• リコール間隔の個別設定: 全員一律 3 ヶ月ではなく、歯周病の進行度・カリエスリスクに応じて 1 / 3 / 6 ヶ月と分ける。この分類をどこに保持するのか（レセコン側か、新システム側か）
• 対象者の抽出条件: 最終来院日、前回処置内容、未完了の治療計画の有無、中断患者かどうか
• 通知チャネルの優先順位: LINE → SMS → ハガキ → 電話、といった順序と、それぞれの到達失敗時の扱い
• 通知の停止条件: すでに次回予約が入っている患者、転院済みの患者、通知を辞退した患者を除外する仕組み
• 効果測定: 送信数・開封数・予約成立数をどう記録するか

このうち、レセコン連携の可否に直結するのが「対象者の抽出条件」です。最終来院日や処置内容はレセコン側に蓄積されているデータであり、新システムがそれを参照できなければ、抽出のために手作業で名簿を作る運用に逆戻りします。リコールを本気で仕組み化するなら、レセコンからのデータ取得は避けて通れないという関係になっています。

保険・自費が混在する患者管理と会計まわりの要件

歯科医院の患者管理は、保険診療と自費診療が同一患者に混在する点が特徴です。ここも汎用の顧客管理ツールでは扱いづらい部分です。

ここで重要なのは、すべてを新システムに統合しようとしないことです。会計とレセプト業務はレセコンの中核機能であり、そこに手を入れると開発費も保守リスクも一気に跳ね上がります。「予約・リコール・患者コミュニケーションは新システム、診療録と会計・レセプトはレセコン」という役割分担を最初に引いておくと、後の要件がぶれにくくなります。

レセコン・電子カルテ連携の可否を発注前に確かめる手順

ここが本記事の中核です。要件が言語化できたら、次は「その連携が技術的に可能か」を発注前に自分で確かめます。この作業を先に済ませておくかどうかで、その後の見積の精度と交渉の主導権が大きく変わります。

連携方式は4類型｜API・CSV・データベース直接・RPA

レセコン・電子カルテとの連携方式は、大きく 4 つに分類できます。それぞれ実現難易度・コスト・保守リスクが異なります。

現実的な優先順位は上から順です。公開 API があるならそれが最善で、なければファイル入出力を検討します。データベース直接参照と RPA は、動かせても長期的な保守リスクを抱え込む選択肢であることを理解したうえで採用を判断してください。特にデータベース直接参照は、レセコンの保守契約で禁止されている場合があり、トラブル発生時にメーカーのサポートを受けられなくなる可能性があります。

なお、連携方式は「どちらの方向にデータが流れるか」でも整理が必要です。

• 片方向（レセコン → 新システム）: 患者マスタや来院履歴を読み取るだけ。リスクが低く、実現しやすい
• 片方向（新システム → レセコン）: Web 予約の内容をレセコンの予約欄に書き込む。書き込みは読み取りより難易度が高い
• 双方向: 両方向の同期。整合性の担保（どちらを正とするか、競合時の扱い）が必要で、コストが跳ね上がる

リコールの仕組み化が目的なら、多くの場合は「片方向の読み取り＋日次同期」で足ります。最初から双方向リアルタイム連携を要望として出すと、必要以上に高い見積が返ってくることになります。

確認先は開発会社ではなくレセコンメーカー

ここが最も重要なポイントです。連携できるかどうかの答えを持っているのは、開発会社ではなくレセコン（電子カルテ）メーカーです。

開発会社は「他社製品との連携実績はあります」「調査してみないと分かりません」としか答えられません。それは不誠実だからではなく、仕様の開示権限がメーカー側にあるためです。したがって、発注者である医院がメーカーに直接照会するのが最短経路になります。

保守契約を結んでいるメーカーのサポート窓口、または導入時のディーラー担当者宛に、次の内容を書面（メールで可）で照会してください。回答も書面で受け取ることが重要です。相見積の際に、全社に同じ資料として配布できるからです。

照会文のテンプレート

いつもお世話になっております。〇〇歯科医院の〇〇です。

現在、予約管理およびリコール（定期検診の呼び戻し）業務の効率化を目的として、外部システムの導入または開発を検討しております。貴社製品との連携可否について、下記の点をご教示いただけますでしょうか。

1. 弊院で利用している製品名・バージョン（〇〇／Ver.〇〇）について、外部システムとの連携用の API または連携インターフェースの提供はございますか。ある場合、仕様書の開示条件（費用・契約・NDA の要否）をご教示ください。
2. API の提供がない場合、患者マスタ・来院履歴・予約情報を CSV 等のファイル形式で出力する機能はございますか。出力可能な項目一覧と、出力の実行方法（手動／自動スケジュール）をご教示ください。
3. 外部システムからの予約情報の書き込み（取り込み）に対応する機能はございますか。
4. 上記の連携を行う場合、保守契約上の制約（禁止事項・サポート範囲の変更）はございますか。特に、データベースへの直接アクセスの可否についてご教示ください。
5. 今後のバージョンアップにおいて、上記の連携仕様の互換性はどの程度維持される想定でしょうか。
6. 貴社にて連携実績のある外部システムベンダーがございましたら、差し支えない範囲でご教示ください。

お忙しいところ恐れ入りますが、書面にてご回答いただけますと幸いです。

この 6 項目の回答が揃うと、状況は一変します。1 と 2 の回答で連携方式が確定し、3 の回答で片方向か双方向かが決まり、4 と 5 で保守リスクの範囲が見え、6 で発注先候補が具体的に増えます。この回答書は、そのまま相見積の共通仕様書として機能します。

回答に時間がかかる場合もありますが、数日から数週間の待ち時間は、数百万円の投資判断の精度と引き換えなら十分に見合います。並行して要件メモの作成を進めておけば、待ち時間が無駄になることもありません。

連携が難しいと分かったときの代替設計

照会の結果、「API はない、CSV 出力は患者マスタのみ、書き込みは不可」といった制約が判明することは珍しくありません。ここで検討を止める必要はありません。制約を前提にした設計に切り替えます。

最後の「レセコン更改のタイミングに合わせる」は、中長期的には有力な選択肢です。医療情報の標準化は国の施策として進んでおり、国際標準規格 HL7 FHIR を採用した標準型電子カルテや、全国の医療機関が診療情報を相互に共有する電子カルテ情報共有サービスの整備が進められています。電子カルテ情報共有サービスの全国展開・本格運用は、厚生労働省の医療等情報利活用ワーキンググループで 2026 年度の冬（2027 年 1・2 月頃）を目指す方針が示されています（GemMed、2026年4月）。

ただし、これらの標準化は主に病院・医科診療所を中心に進んでおり、歯科向けの製品でいつどこまで対応が広がるかは製品ごとに異なります。「数年待てば自動的に解決する」と考えるのはリスクがありますので、現時点で取り得る手段の中で最善を選ぶ姿勢が現実的です。

SaaS導入と独自開発、どちらを選ぶかの判断軸

連携可否という事実が手元に揃ったところで、初めて「作るべきか」の判断が成立します。ここでは「作らない」選択肢を正面から含めた三択で整理します。

SaaSで足りる歯科医院の条件

次の条件に多く当てはまる医院は、独自開発に進まず SaaS を採用したほうが総合的な費用対効果が高くなります。

• 単一拠点で、チェア数が 5 台程度までである
• 予約枠のルールが標準的で、処置ごとの所要時間の可変設定と担当者の割り当てができれば足りる
• レセコンとの連携が「患者マスタの片方向取り込み」で足りる、あるいは連携なしでも運用が回る
• 過去データの移行が必須ではなく、導入時点から新規に積み上げていける
• 院内に運用を回す担当者（受付リーダー等）がいて、標準機能に業務側を合わせる意思がある

SaaS を選ぶ最大の利点は、費用ではなく保守と機能改善をベンダー側が担い続ける点にあります。歯科医院のシステムは 5 年、10 年と使うことになります。自前で作れば、その期間の保守責任は医院側に残ります。

一般論として、予約業務そのものが医院の競争力の源泉になっているのでなければ、標準的な予約受付や空き枠管理は短期間・低コストで導入できる SaaS が適しているとされています（ITキャピタル）。

独自開発（スクラッチ）に踏み切る条件

逆に、次のような状況では独自開発が合理的な選択肢になります。

• 複数拠点で患者データと予約枠を統合的に扱う必要があり、SaaS のテナント設計では表現できない
• 自費診療のカウンセリングから成約・分割払い管理までを一連の業務として設計したい
• レセコン以外の院内システム（技工所との連携、CT 画像管理、在庫管理など）との接続が要件に含まれる
• 医院独自の運用（予防プログラムの体系、サブスクリプション型のメンテナンス契約など）がすでに確立しており、それがそのまま差別化要因になっている
• 5 年以上の利用を前提に投資回収を考えられる

判断の実務では、独自開発の総額と SaaS の 5 年分の総額を並べて比較します。SaaS の月額が 3 万円なら 5 年で 180 万円です。この金額と、独自開発の初期費用＋保守費 5 年分を比べたうえで、差額に見合う価値（統合による業務削減時間、リコール率の改善見込みなど）があるかを検討します。

パッケージとスクラッチの選定に関する一般的な判断フレームについては、スクラッチ開発の外注判断基準で費用・工期・拡張性の観点から整理しています。歯科固有の事情と汎用の選定基準を行き来しながら検討すると、判断が安定します。

SaaS＋連携開発というハイブリッドの中間解

見落とされがちですが、実際にはこの中間解が最も現実的な着地点になるケースが多くあります。

構成: 予約・リコールの本体機能は SaaS を使い、レセコンとの連携部分（データの取り込み・変換・同期）だけを受託開発する。

この選択肢を検討するには、SaaS 側にも「外部データを取り込めるか」を照会する必要があります。レセコンメーカーへの照会と同じ要領で、SaaS ベンダーにも「CSV インポート機能の有無」「API の提供有無」「取り込み可能な項目」を確認しておきます。両側の口が確認できれば、その間をつなぐ開発だけで済みます。

三択のいずれを選ぶにせよ、判断の根拠は連携可否の事実です。事実を確定させずに三択を検討しても、どの選択肢も「たぶん大丈夫」の域を出ません。

歯科医院のシステム開発外注の費用相場と、見積が割れる理由

費用の話に入ります。ただし相場の一覧を眺めるだけでは判断材料になりません。ここでは相場を押さえたうえで、「なぜ同じ要望で見積が数倍割れるのか」を分解します。

システム種類別の費用レンジ

歯科医院向けのシステムについて、公開されている費用の目安は次のとおりです。

（出典: GXO）

同じ資料では、医院規模別の導入費用の目安として、小規模医院で初期 100〜300 万円・月額 3〜10 万円、中規模で初期 300〜600 万円・月額 8〜20 万円、大規模で初期 500〜1,500 万円・月額 15〜50 万円といったレンジが示されています。加えて、データ移行（10〜30 万円）、スタッフ研修（5〜15 万円）、ネットワーク整備（5〜20 万円）、周辺機器（5〜20 万円）が別途発生する点にも注意が必要です。

業種を問わない予約システム開発の費用感としては、小規模な機能追加で 30〜100 万円（1〜3 ヶ月）、一般的な予約管理システムで 100〜300 万円（3〜6 ヶ月）、複数拠点・外部連携を伴う場合で 300〜800 万円（4〜10 ヶ月）、大規模プラットフォームで 800 万円以上（6 ヶ月〜1 年以上）が目安とされています（ITキャピタル）。

これらはあくまで目安であり、医院ごとの要件で大きく変動します。重要なのは、レンジの中のどこに着地するかを決めるのが要件の書き方だという点です。

同じ要望でも見積が数倍割れる4つの要因

「予約とリコールを効率化したい。レセコンとつながってほしい」という同じ要望を 3 社に伝えても、見積は 150 万円から 500 万円超まで開きます。その差は主に次の 4 点から生まれます。

1. 連携範囲の解釈差

最大の要因です。「レセコンとつながる」という言葉を、A 社は「患者マスタを日次で片方向に取り込む」と解釈し、B 社は「予約情報を双方向でリアルタイム同期する」と解釈します。後者は前者の数倍の工数がかかります。

先ほど紹介したメーカーへの照会結果を添付し、「片方向・日次同期・CSV 経由」と明記すれば、この解釈差は消えます。連携可否の確認が費用の確度に直結するというのは、この意味です。

2. 既存データ移行の有無と品質保証の範囲

過去の患者マスタ・リコール履歴を移行するのか、するとして何件・何年分か。移行後のデータ検証をどこまで開発会社が担うのか（全件照合か、サンプル検証か）。ここが曖昧だと、見積に含める会社と含めない会社が出ます。

3. 保守運用費が見積に含まれているか別建てか

初期費用だけを比較すると、保守を別建てにしている会社が安く見えます。必ず「初期費用」と「年間保守費」を分けて提示するよう依頼し、5 年間の総額で比較してください。

4. 稼働環境と可用性要件

院内サーバーで動かすのか、クラウドで動かすのか。診療時間中に止まらないことをどこまで保証するのか。バックアップの世代管理と復旧目標時間はどうするのか。医療機関のシステムは止まると診療が止まるため、この要件の置き方で構成が変わり、費用も変わります。

相見積を依頼する際は、この 4 点について自院の前提を明記した資料を全社に同じ内容で配布します。そうすることで初めて、金額差が「見積の前提の違い」ではなく「会社ごとの生産性・単価の違い」として読めるようになります。

請負契約と準委任契約の使い分け

契約形態も費用の見え方を左右します。歯科医院のシステム開発では、フェーズごとに使い分けるのが一般的です。

要件が固まっていない段階で請負契約を結ぼうとすると、開発会社はリスク分を上乗せした見積を出さざるを得ません。逆に、要件定義だけを準委任で切り出し、要件が固まってから開発を請負で発注する二段構えにすると、双方にとって見通しが立てやすくなります。

要件定義フェーズを準委任で切り出す場合は、そのフェーズの成果物（要件定義書・画面設計・連携仕様書）を明確に定義し、成果物の著作権が医院側に帰属することを契約に明記しておきます。そうしておけば、開発フェーズを別の会社に発注する選択肢も残せます。

保守運用費とIT導入補助金の扱い

保守運用費は、システムを使い続ける限り発生し続ける費用です。一般的に、年間保守費は初期費用の 10〜15% 程度を目安とする考え方が広く用いられています。ただし、含まれる内容は会社によって大きく異なります。

見積を受け取ったら、保守費に何が含まれるかを分解して確認してください。

• 障害発生時の対応（受付時間・応答時間・復旧目標）
• サーバー・クラウド利用料
• OS・ミドルウェアのセキュリティ更新
• レセコン側のバージョンアップに伴う連携部分の改修
• 軽微な仕様変更（何時間分まで含まれるか）
• 問い合わせ対応の窓口と件数上限

特に 4 番目のレセコン側バージョンアップへの追随は、歯科医院のシステムでは必ず発生します。ここが保守契約に含まれていないと、レセコンを更新するたびに追加費用が発生することになります。契約前に必ず確認してください。

補助金については、従来「IT導入補助金」と呼ばれていた制度が 2026 年は「デジタル化・AI導入補助金2026」として実施されています。通常枠では、ITツールが対応する業務プロセス数に応じて補助額 5 万円〜450 万円、補助率は 1/2 以内（最低賃金近傍の事業者は 2/3 以内）とされています（デジタル化・AI導入補助金2026 通常枠）。

ここで発注前に理解しておくべき制約があります。補助対象となるのは、IT導入支援事業者が事務局に登録申請を行い、承認を受けた「登録ITツール」に限られます。登録されていないITツールは交付申請ができません（ITツールの登録申請）。

つまり、医院専用にゼロから作るフルスクラッチの受託開発は、原則としてこの補助金の対象外になります。補助金の活用を前提に検討するのであれば、登録済みの SaaS 製品を軸に据える設計が現実的です。先ほど紹介した「SaaS＋連携開発」のハイブリッドを選ぶ場合も、SaaS 部分と連携開発部分で補助対象の扱いが分かれる可能性がありますので、IT導入支援事業者に事前確認してください。

補助金の制度内容・公募スケジュールは年度ごとに変わります。申請を検討する際は必ず公式サイトの最新の公募要領を確認し、IT導入支援事業者に相談したうえで進めてください。

医療情報を扱う外注先の見極め方と発注側の責任

システム開発の外注では「良い会社を選ぶ」ことに関心が向きがちですが、医療情報を扱う場合はその前に、発注側が負う責任の範囲を理解しておく必要があります。

医療情報の外部委託で歯科医院側が負う管理責任

厚生労働省が公表している「医療情報システムの安全管理に関するガイドライン 第6.0版」では、医療情報システムの安全管理に関する責任は医療機関等の運営上の責任であるとされ、外部の事業者に業務を委託した場合でも、医療機関側の管理責任がなくなるわけではないという考え方が示されています。企画管理編では、委託先として適切な事業者を選定する基準や、契約時に明確化すべき責任分界点・役割分担についての指針が示されています（医療情報システムの安全管理に関するガイドライン 第6.0版 企画管理編）。

これを実務に落とすと、発注時に開発会社へ確認・要求すべき事項は次のようになります。

これらは契約書または覚書に明記しておくべき項目です。開発会社にこの一覧を渡し、「各項目について貴社の標準的な対応を教えてください」と依頼すると、その回答の具体性から医療情報の取り扱い経験の有無が見えてきます。

医療・介護分野全般の外部委託における個人情報の取り扱いについては、医療・介護のシステム開発の外部委託で発注時の注意点を整理していますので、歯科に限らない広い文脈も併せて確認いただくと理解が深まります。

歯科・医療の開発実績を確認する具体的な質問

「医療系の開発実績があります」という説明は、そのままでは判断材料になりません。実績の中身を掘り下げる質問を用意しておきます。

1. どのレセコン・電子カルテ製品との連携経験がありますか。製品名とバージョンを教えてください → 自院と同じ製品の経験があれば理想的です。なくても、複数メーカーの経験があれば対応力の裏付けになります
2. その連携はどの方式で実現しましたか（API / CSV / データベース直接 / RPA） → 方式ごとの得意・不得意が見えます。すべてを「データベース直接参照」で実現している会社は保守リスクの評価が甘い可能性があります
3. その際、レセコンメーカーとはどのようにやり取りしましたか → メーカーとの折衝経験の有無は大きな差になります。「医院側にお願いしました」という回答でも構いませんが、その場合は医院側の作業負荷を見積に織り込む必要があります
4. 歯科医院向けの案件で、稼働後に発生したトラブルとその対応を教えてください → 成功事例よりも、失敗とその後の対応のほうが会社の実力を示します
5. 保守フェーズで、レセコンのバージョンアップに追随した経験はありますか → 長期的な付き合いができるかを測る質問です
6. 診療時間中のリリースやメンテナンスをどう扱いますか → 医療機関の稼働特性を理解しているかが分かります

回答を受け取ったら、可能であれば導入先の医院に話を聞かせてもらえないかを打診してみてください。守秘義務で難しい場合もありますが、応じてもらえる会社は実績への自信の表れと考えられます。

撤退リスク・ソースコード帰属・保守の引き継ぎ

レセコンは 10 年単位で使われることもあり、システムも同様に長期の利用が前提になります。その間に開発会社が事業を縮小したり、担当者が離職したりする可能性は現実的に考慮すべきリスクです。

備えとして、契約時に次の 3 点を押さえておきます。

1. ソースコードの帰属と引き渡し

開発したソースコードの著作権が医院側に帰属するのか、開発会社に帰属して医院は利用許諾を得るだけなのかを契約で明確にします。医院側に帰属する場合でも、実際にソースコードの引き渡しを受けられる条件（納品時か、契約終了時か）を定めておきます。

2. ドキュメントの納品範囲

ソースコードだけを受け取っても、別の会社が引き継ぐことはできません。次のドキュメントを納品物として契約に含めます。

• 要件定義書・画面設計書
• レセコン連携の仕様書（データ項目の対応表、変換ルール、実行スケジュール）
• 環境構築手順書（サーバー構成、必要なアカウント一覧）
• 運用手順書（日次のバッチ確認、障害時の一次対応）

特にレセコン連携の仕様書は、引き継ぎの成否を左右します。連携部分は自院固有の作り込みが集中する箇所であり、ここが文書化されていないと、後任の会社は解析からやり直すことになります。

3. 保守の引き継ぎ条件

契約終了時の引き継ぎ協力義務を契約に含めます。引き継ぎ期間、対応工数、費用の扱いをあらかじめ定めておくと、実際に切り替えが必要になったときの交渉が円滑になります。

これらは「開発会社を疑う」ためのものではありません。医院の資産を医院が管理できる状態に保つための、当然の取り決めです。誠実な開発会社であれば、こうした要望に難色を示すことはありません。

発注までの5ステップと、院長・事務長の時間の作り方

最後に、ここまでの内容を実行順序に並べ直します。診療の合間に進めることを前提とした、現実的な進め方です。

発注準備の5ステップ

ステップ 2 と 3 は並行して進められます。照会の回答を待つ間に要件メモを仕上げておけば、回答が届いた翌週には相見積を依頼できます。

ステップ 5 の「小さく試す範囲を決める」は特に重要です。歯科医院のシステムは、実際に運用してみないと分からないことが多くあります。第一弾で得た知見を第二弾の要件に反映できるよう、契約を分割しておくと失敗の規模を小さく抑えられます。

診療の合間で進めるための社内体制と時間配分

院長が一人で全部を抱えると、診療の合間に潰れて進まなくなります。役割を分けます。

意思決定者を複数にすると、開発会社が誰の意見を優先すべきか分からなくなり、手戻りが増えます。一方で、運用の可否は現場が判断したほうが精度が上がります。「決めるのは院長、使えるかを判断するのは現場」という切り分けが機能します。

打ち合わせの時間は、診療後の固定枠で確保するのが現実的です。「毎週木曜 19:00 から 60 分」のように曜日と時刻を固定し、開発会社にも事前に伝えておきます。都度調整にすると、日程調整のやり取りだけで数日を消費します。

時間の見通しとしては、要件定義フェーズで週 1 回・60〜90 分の打ち合わせが 4〜8 回程度、その間の宿題（画面レイアウトの確認、業務ルールの整理）に週 1〜2 時間程度を見込んでおくと大きく外しません。開発フェーズに入れば頻度は下がりますが、テストフェーズでは再び現場スタッフの時間が必要になります。

要件定義だけ外部人材に入ってもらう選択肢

それでも時間が確保できない、あるいは開発会社との会話に不安がある場合、要件定義フェーズだけ外部の人材に入ってもらう方法があります。

依頼する範囲

• 現状業務のヒアリングと業務フロー図への整理
• 要件の言語化と優先順位付けの支援
• レセコンメーカーへの照会内容の設計と、回答内容の技術的な解釈
• 相見積用の要件資料（RFP）の作成
• 見積内容の技術的な妥当性チェック、開発会社への逆質問の設計

この選択肢が向いているケース

• 投資規模が大きく（数百万円以上）、判断を誤ったときの影響が大きい
• 複数拠点の統合など、要件が複雑で自院だけでは整理しきれない
• 開発会社の提案内容が妥当かどうかを判断できる人が院内にいない

依頼先の選び方

システム開発会社ではなく、開発会社から独立した立場の業務委託エンジニアや PM に依頼するのが基本です。開発会社に要件定義から依頼すると、その会社が実装しやすい方向に要件が寄る可能性があります。「発注者側の立場で要件を整理する人」と「実装する会社」を分けておくと、相見積の比較が公正になります。

契約形態は準委任契約とし、期間を区切って（例: 2 ヶ月間、週 1 回の稼働）依頼します。稼働時間ベースで費用が決まるため、範囲を絞れば費用は抑えられます。要件定義の精度が上がることで、後の開発費の見積精度と手戻りの削減につながれば、十分に回収できる投資になり得ます。

歯科医院のシステム開発外注は、レセコン連携という技術的な前提が確定するかどうかで難易度が大きく変わります。まずはレセコンメーカーへの照会という一手から始めてみてください。回答が手元に届いた時点で、判断に必要な情報の半分は揃っています。

関連情報

相見積を依頼する際の要件資料の書き方に迷われた場合は、システム開発 提案依頼書（RFP）テンプレートをご活用ください。課題・機能要件・予算など、発注時に伝えるべき項目を記入例つきで整理しています。

要件の整理段階からご相談いただけます。開発の発注可否がまだ固まっていない段階でも、お問い合わせフォームよりお気軽にお声がけください。

業種別の DX 発注については、動物病院・ペット事業のDX開発でも SaaS と独自開発の判断ガイドを掲載しています。予約・カルテ・リコールという業務構造が近く、判断の進め方の参考になります。