利用者管理システム開発の発注/外注/依頼/委託方法について

利用者管理システムの発注・外注は、利用者台帳を中心に記録・計画・請求・家族や関係機関との情報共有までの業務範囲を定め、クラウド導入、パッケージのカスタマイズ、個別開発から自社に合う方法を選ぶことが成功の近道です。

「Excelや紙の台帳をシステム化したい」「既存の介護記録・請求ソフトと二重入力をなくしたい」と考えても、何をどこまで委託すればよいか、見積もりの金額が妥当かを判断するのは簡単ではありません。この記事では、利用者管理システムを発注・外注する際の発注形態の選び方、RFPと要件の整理、契約形態、費用相場、委託先の選定、見積比較のポイントを実務の順番に沿って解説します。

▼全体ガイドの記事
・利用者管理システム開発の完全ガイド

利用者管理システムの発注・外注で最初に決めること

発注前に決めるべきなのは、画面の見た目よりも、どの情報を正とし、どの業務へ再利用するかです。利用者情報の入力先が曖昧なまま開発会社へ相談すると、台帳はできても記録や請求との連携が残り、期待した効果が出にくくなります。

利用者管理システムは、氏名や住所だけを検索する名簿ではありません。基本情報、家族・緊急連絡先、保険情報、要介護度、ADL、服薬や医療に関する情報、同意状況を一度登録し、ケア記録、計画書、予約・入退所、請求、監査用帳票へ正しく渡す共通マスタとして設計します。利用者の登録や変更が複数の画面に反映される仕組みを先に決めると、入力漏れや転記ミスを減らしやすくなります。

たとえば入所時に登録した保険情報が請求側に連携され、退所後も履歴として参照できる状態が理想です。2025年4月にペースノート老健とケアカルテのAPI連携が開始され、利用者基本情報や保険情報をワンクリックで反映できるようになった事例は、システムの価値が入力画面の数ではなく、業務間のデータ連携にあることを示しています（出典: 株式会社ペースノート、2025年）。

発注担当者だけで要件を作ると、決裁者が重視する投資効果、現場が重視する入力のしやすさ、情報システム部門が確認するセキュリティや保守条件が抜けます。事業責任者、現場の代表、請求担当、情シスまたは個人情報管理責任者を集め、要件を決める会議体を最初に作ります。

現状の業務を「利用開始」「日々の記録」「計画の更新」「請求」「退所・情報提供」に分け、誰が、いつ、何を入力し、誰が承認するかを確認します。職員数や拠点数だけでなく、利用者数、サービス種別、既存ソフト、紙で残す書類、家族への情報提供方法まで書き出すと、外注範囲を過不足なく定義できます。

発注形態はどれを選ぶ？クラウド・カスタマイズ・個別開発の違い

結論として、標準的な介護・福祉業務を早く安定させたい場合はクラウドやパッケージを優先し、既存システムとの連携や独自業務が効果の中心ならカスタマイズを検討します。多拠点・多法人で独自の利用者ポータルや基幹連携まで必要な場合に限り、個別開発を候補にするのが現実的です。

クラウド型はサーバーを自社で用意せず、月額料金で利用する方式です。バックアップ、法改正に伴う更新、障害対応をベンダーに任せやすく、初期投資を抑えながら導入できます。一方で、項目名や帳票、承認フローを製品の標準に合わせる場面があるため、現場のこだわりをすべて追加機能にしない判断が必要です。

発注時は「利用者台帳があるか」だけでなく、記録・計画・請求とのデータ連携、利用者数や職員数による料金変更、CSV出力、データ移行、解約時の返却条件を確認します。クラウドは安全で、オンプレミスは危険という単純な比較ではなく、アクセス権限、認証、ログ、バックアップ、委託先の運用体制を同じ基準で評価します。

標準の介護記録や請求機能は既製品を使い、利用者台帳、家族連絡、予約、ベッド管理、法人内の拠点共有など不足する部分だけを追加する方法です。ゼロから全機能を作らないため、初期費用と開発期間を抑えながら、自社の重要な業務には合わせやすくなります。

連携を依頼するときは、APIの有無だけでなく、どの項目をどちら向きに連携するか、更新日時と重複判定をどう扱うか、エラー時に誰が再送するかまで決めます。APIがない場合に画面のスクレイピングで代替すると、相手製品の画面変更で壊れやすいため、標準APIやCSVを優先します。

スクラッチ開発は、多数の拠点・法人をまたぐ共通台帳、医療と介護を横断するデータ連携、独自の家族向け画面、既存基幹との複雑な連携が必要な場合に適します。ただし、要件が固まっていない状態で全機能を一括発注すると、仕様変更、データ移行、制度改定対応が重なり、予算と納期が膨らみやすくなります。第1段階を利用者マスタと権限、第2段階を記録・請求連携というように分けます。

ローコードは台帳、申請、通知などを短期間で試作しやすい一方、複雑な請求、厳密な訂正履歴、複数サービス間の整合性、長期保守では専門的な設計が必要です。試作の速さだけで決めず、データの持ち出し、ライセンス変更、障害時の復旧、担当会社を変更するときの引き継ぎまでRFPに記載します。

RFPと要件整理はどのように進める？

RFPとは、発注者が開発会社やベンダーへ提示する提案依頼書です。良いRFPは機能一覧を並べるだけでなく、解決したい業務課題、対象範囲、現行環境、データ、連携、運用、納品物、評価基準を同じ資料にまとめます。提案会社が同じ前提で見積もれるため、価格と提案内容を比較しやすくなります。

まず、紙台帳、Excel、既存の介護記録ソフト、請求ソフト、会計や給与などを洗い出します。そのうえで、利用開始時の情報登録、日々の記録、計画の承認、月末請求、退所後の保存までを時系列に並べ、入力・参照・承認・出力の担当者を明記します。

各機能を「必須」「できれば必要」「今回は対象外」に分けることも重要です。たとえば利用者の重複登録防止、権限、監査ログ、保険期限のアラートは必須にし、AIによる記録要約や家族向けポータルは効果を検証してから第2段階に回す方法があります。要望を全部盛りにせず、導入初日に必要な範囲を明確にします。

利用者台帳の項目は、氏名、住所、生年月日、連絡先だけで終わらせません。家族・緊急連絡先、保険者番号、負担割合、認定期間、医療・服薬情報、ADL、同意取得状況、契約書類、利用開始・終了日、退所後の保存期間まで、業務で使う単位に分けて定義します。自由記述だけにすると集計や連携が難しくなるため、選択肢、必須条件、変更履歴の残し方も決めます。

権限は「見られるか」だけでなく、閲覧、登録、修正、承認、印刷、CSV出力を分けます。施設、法人、職種、担当ケースなどの単位で最小権限を設定し、退職者や異動者のアカウント停止、緊急時のアクセス、操作ログの保存期間をRFPへ入れます。医療情報を扱う場合は、厚生労働省が2026年6月に改訂した「医療情報システムの安全管理に関するガイドライン第7.0版」も確認し、委託先の責任分界を明記します（出典: 厚生労働省、2026年）。

2026年4月以降、標準化対応が完了した市町村から介護情報基盤へのデータ送信が始まり、2028年4月には介護情報基盤を経由した情報共有の本格運用開始が予定されています（出典: 厚生労働省「介護情報基盤に係る自治体説明会」資料、2026年）。すべてを今すぐ作り替えるという意味ではありませんが、将来の標準連携を妨げないデータ項目、同意、アクセス制御、APIの設計は発注段階から確認します。

RFPには、対応予定のケアプランデータ連携標準仕様、CSVやAPIの仕様書、連携できる項目、エラー通知、データの更新責任を記載します。また、契約終了時に誰が、どの形式で、どの期間にデータを返却するか、バックアップの削除証明を出せるかも確認します。移行しやすいデータ形式を最初から選ぶことは、将来のベンダーロックインを抑える対策になります。

契約形態と開発を進める手順をどう設計する？

契約は「開発会社へ任せる書類」ではなく、要件変更、成果物、検収、障害対応、知的財産、データ管理のルールです。要件が十分に固まっているか、発注者側が開発中に優先順位を変える可能性があるかによって、請負契約と準委任契約の使い分けを検討します。

請負契約は、合意した成果物を完成させ、検収を受けることを中心に責任を定める契約です。画面、機能、テスト結果、操作マニュアルなどを成果物として明確にしやすい一方、契約後の追加要望は変更管理が必要です。何をもって完成とするか、検収期間、修正対応の範囲を契約書や個別仕様書に残します。

準委任契約は、専門人材の稼働や業務遂行を委託する形で、要件を検証しながら進める開発に向きます。利用者や現場の意見を試作品で確かめる段階では有効ですが、納品される機能、稼働時間、報告、品質確認の方法が曖昧にならないようにします。どちらが適切かは法務・契約担当とも相談し、名称だけで判断しないことが大切です。

利用者管理システムでは、最初から全機能を固定するより、要件定義または小規模なPoCを先行し、その成果をもとに本開発を契約する段階方式が安全です。第1段階では利用者マスタ、重複判定、権限、検索、CSV出力を確認し、第2段階で記録・請求・予約などの連携を追加する流れが考えられます。

工程ごとに、担当者、期限、入力データ、成果物、承認者、次工程へ進む条件を決めます。試験では正常系だけでなく、同姓同名、保険情報の更新、退所後の閲覧、権限外の検索、通信障害、連携エラーを確認します。現場の代表が実データに近いサンプルで受入テストを行うと、稼働後の手戻りを抑えられます。

納品時に動けば終わりではありません。利用者情報を扱うシステムは、法改正、OSやブラウザの更新、脆弱性、職員の異動、拠点追加に継続対応します。月額保守に含まれる問い合わせ、障害復旧の目標時間、バックアップ、セキュリティ更新、制度改定対応、追加開発の単価を分けて確認します。

障害時には、誰が一次受付をし、どの情報をどの経路で連絡し、紙運用へ切り替えるかを決めます。個人情報の漏えいが疑われる場合の報告、アクセス遮断、ログ保全、利用者や家族への説明も含めたインシデント対応手順を、開発会社の保守範囲と自社の運用範囲に分けておきます。

利用者管理システムの費用相場と見積もり内訳

費用は、利用者管理だけを使うのか、記録・計画・請求・予約・外部連携まで含めるのかで大きく変わります。以下の金額は、公開されている介護ソフトの価格と類似する業務システムの情報をもとにした目安です。「利用者管理システム単独」の公的な統計ではないため、スクラッチのレンジは推定として扱い、最終判断は同じ要件で取った個別見積もりで行います。

ITreviewが2026年に掲載する介護ソフトの相場では、小規模事業所向けが初期費用0〜10万円、月額5,000〜15,000円、中規模向けが初期10〜30万円、月額15,000〜40,000円、大規模法人向けが初期30万円以上、月額50,000円以上です（出典: ITreview「介護ソフト（介護記録管理）」、2026年）。利用者管理に絞った場合でも、拠点数、利用者数、連携、研修、データ移行の条件が変わるため、そのまま自社の価格と断定しません。

公開料金の比較例として、カイポケの通所介護向けは月額25,000円、初期費用・サポート費用0円で、職員・利用者・端末数による追加料金なしと案内されています（税別、出典: 株式会社エス・エム・エス「カイポケ通所介護の利用料金」、2026年確認）。トリケアトプスは初期費用0円で、サービス種別により利用者1人あたり月220〜440円などの従量課金と上限額を公開しています（出典: トリケアトプス公式料金ページ、2026年確認）。このような公開価格は比較の起点になりますが、独自の移行・連携費用が含まれるかは別途確認します。

パッケージを法人向けに設定する場合は、初期設定、権限設計、帳票変更、拠点追加、既存ソフトとのAPI・CSV連携、マスタ整備、データ移行、操作研修を分けて見積もります。類似する法人・多拠点向けでは、設定・導入支援を含む初期費用30万〜200万円程度、月額5万〜30万円程度が目安になることがありますが、これは個別要件を前提とした幅のある参考レンジです。

特に移行費用は、元データの形式と品質で変わります。Excelが拠点ごとに分かれ、同じ利用者が異なる氏名表記や旧住所で登録されている場合、名寄せ、重複確認、欠損補完、本人確認の工数が発生します。「移行一式」とまとめず、対象件数、項目、変換ルール、検証回数、現場確認の担当を見積書に記載してもらいます。

複数サービス、既存基幹、権限・監査、外部API、データ移行を含むスクラッチ開発は、初期500万〜2,000万円程度、開発期間6〜15か月程度が一つの推定レンジです。ただし、これは「利用者管理システム」専用の公開統計ではなく、一般的な業務システムの目安を医療・介護の要件に合わせて補正したものです。小規模な台帳だけであれば下回ることも、医療情報連携や多法人統合で上回ることもあります。

見積書では、要件定義、UI・データ設計、開発、API連携、セキュリティ対策、テスト、移行、研修、リリース支援、保守を項目別に出してもらいます。さらに、クラウド利用料、バックアップ、監視、端末、認証サービス、法改正対応、追加拠点の費用を月額・年額で分け、3年または5年の総額を比較します。初期費用の安さだけで発注すると、後から必要な費用が見えにくくなります。

委託先の選び方と見積比較のポイント

委託先は、知名度や提示価格だけでなく、利用者情報を扱う業務への理解、既存システムとの連携力、導入後の支援体制で選びます。完成済み製品を導入するベンダーと、ゼロから個別開発するSI会社は役割が異なるため、同じ提案書の中で何を提供する会社なのかを確認します。

候補会社には、同じサービス種別の導入実績、利用者情報の移行件数、既存の記録・請求ソフトとの連携実績、標準仕様への対応状況を確認します。実績の社名だけでなく、どの課題を、どの期間で、何人・何拠点に導入し、稼働後にどの指標が改善したかまで聞くと、提案の再現性を見極めやすくなります。

デモでは、利用者登録から記録、計画、請求への連携を一連の流れで見せてもらいます。同姓同名の検索、保険情報の更新、権限外データの表示、退所後の履歴、スマートフォン入力、通信が不安定な場所での動作など、実際の業務に近いシナリオで確認します。会社の営業担当だけでなく、導入後のサポート責任者にも同席してもらうと安心です。

相見積もりは、同じRFP、同じサンプルデータ、同じ対象拠点、同じ納期で依頼します。比較表には、初期費用、月額・年額、保守、データ移行、連携、研修、追加開発、端末、法改正対応、解約・データ返却を並べます。安い会社の機能不足を後から別発注する可能性があるため、機能の有無だけでなく、標準対応かオプションか、追加費用の算定方法まで記録します。

価格差が大きい場合は、単価の違いよりも、見積もりに含まれる範囲を確認します。要件定義が含まれず、本開発だけを安く提示しているケース、移行データの整備を発注者側の作業としているケース、保守や制度改定対応が別料金のケースがあります。質問への回答速度、リスクの説明、できないことを明示する姿勢も、契約後の信頼性を判断する材料です。

個人情報を扱うため、通信・保存時の暗号化、二要素認証、脆弱性対応、バックアップ、監査ログ、権限管理、委託先の再委託、データ保管場所、障害時の復旧目標を確認します。セキュリティチェックシートの提出だけでなく、実際のログ画面やアカウント削除の手順、復元テストの実施頻度まで聞くと、運用の実効性を確認できます。

契約終了時には、利用者データをCSVや標準形式で全件返却できるか、画像・添付書類・操作ログも対象か、返却後にベンダー側の複製を削除するかを確認します。保守会社を変更できない理由がデータ形式にあると、将来の選択肢が狭まります。発注時点でデータの所有権、利用権、バックアップ、再委託、秘密保持を契約に落とし込みます。

導入を失敗させないための運用設計

発注の成否は、納品日に決まるのではなく、現場が正しいデータを入力し、必要な人が必要な範囲で使い続けられるかで決まります。導入前に移行・教育・問い合わせ・評価の運用を決め、稼働後の改善を発注範囲に含めておきます。

全拠点を一度に切り替えると、業務の違い、データの欠損、職員の習熟度の差が同時に表面化します。まず代表的な1事業所または1サービスで、利用者登録、検索、記録、請求連携の一連の流れを試し、入力時間、二重入力の件数、問い合わせ、請求エラー、利用率を測ります。

PoCでは、成功条件を「使えた」だけにしません。たとえば、利用者情報の二重登録を一定割合減らす、月末の転記時間を削減する、必須項目の未入力を減らすといった測定可能な条件にします。結果をもとに画面や権限を修正してから、次の拠点へ展開します。

データ移行は、元データのバックアップ、項目の対応表、名寄せ、テスト移行、本番移行、件数照合、現場確認の順に進めます。同姓同名や表記ゆれを自動判定だけで確定せず、候補を現場担当者が確認します。移行後に紙や旧Excelを誰が更新するのかを放置すると、新旧データが再び分裂します。

研修は全員に同じ説明を一度するだけでなく、管理者、入力担当、請求担当、閲覧のみの職員に分けます。操作マニュアル、短い動画、問い合わせ窓口、よくある質問を用意し、旧運用をいつ終了するかを決めます。例外的に紙へ戻す場合も、後から誰がシステムへ反映するかを明確にします。

導入後90日は、利用者登録にかかる時間、重複登録の件数、記録の未入力、請求前の修正件数、問い合わせ件数、ログイン率、職員の習熟度を定期的に確認します。削減した時間だけでなく、情報の正確性、監査資料を探す時間、家族への回答の速さなど、経営・現場・管理の複数の指標で効果を評価します。

AIで記録の要約や検索を補助する場合も、ケア判断や請求確定を自動化する前提にはしません。利用者本人への説明や同意、出力の確認、誤りの訂正、承認者の記録を設け、人が最終確認する運用にします。システムを導入する目的は入力を機械へ置き換えることではなく、利用者情報を正確に引き継ぎ、ケアと事務の品質を上げることです。

利用者管理システムの発注・外注でよくある質問

発注前に多く寄せられる疑問を、費用・開発方式・セキュリティ・導入期間の観点から回答します。自社の条件によって最適解は変わるため、回答をそのまま仕様にせず、RFPの確認項目として活用します。

標準的なクラウド型は、公開相場として初期0〜30万円、月額5,000〜5万円程度が目安です。独自の権限、複数拠点、データ移行、API連携、帳票、研修を含むパッケージ設定は30万〜200万円程度、複数サービスを個別開発する場合は500万〜2,000万円程度を推定レンジとして考えますが、いずれも要件で変動します。

標準業務を早く安定させたい、法改正やバックアップを任せたい場合はクラウドやパッケージが向きます。多拠点・多法人の独自業務や複雑な連携が競争力に直結する場合は、パッケージのカスタマイズや段階的なスクラッチ開発を検討します。

現行業務、対象範囲、必須機能、データ項目、連携先、予算と納期の前提は自社で整理できます。要件の漏れや優先順位に不安がある場合は、開発会社と契約する前に、要件定義だけを第三者へ支援してもらう方法もあります。RFPには提案会社へ確認したい質問と、評価基準も入れます。

クラウドかオンプレミスかだけで安全性は決まりません。二要素認証、最小権限、暗号化、操作ログ、脆弱性対応、バックアップ、復旧手順、委託先との責任分界を確認し、自社の個人情報保護規程と照らし合わせて判断します。医療情報を扱う場合は、厚生労働省の安全管理ガイドラインに沿った確認項目を契約前に整理します。

小規模なクラウド導入は2週間〜2か月、パッケージの設定や連携を含む導入は1〜6か月程度が目安です。複数サービス・多拠点のスクラッチ開発は、要件整理から本番移行まで6〜15か月程度になることがあります。データの名寄せ、現場の検証、研修を後回しにすると期間が延びるため、開発期間だけでなく準備期間も計画します。

まとめ

利用者管理システムを発注・外注するときは、台帳の画面を作ることから始めず、利用者情報を記録・計画・請求・家族や関係機関との情報共有へつなぐ業務基盤として範囲を定めます。標準業務が中心ならクラウドやパッケージ、独自連携が重要ならカスタマイズ、独自性が高い場合に段階的な個別開発を選びます。

現行業務と導入後のフロー、利用者マスタの項目、権限と監査ログ、既存ソフトとの連携、データ移行、標準仕様、保守、障害対応、データ返却をRFPに入れます。見積もりは初期費用だけでなく、月額・保守・研修・追加開発を含む3年または5年の総額で比較し、同じ条件で複数社へ依頼します。

最初に、1事業所の代表的な業務を選び、紙・Excel・既存ソフトに分散している情報と二重入力を洗い出します。そのうえで、必須範囲を小さく定め、RFP、デモ、相見積もり、PoC、段階導入の順に進めると、費用とリスクを管理しやすくなります。利用者と職員の双方にとって使い続けられる仕組みになるよう、開発会社と運用の責任分担まで話し合うことが重要です。

▼全体ガイドの記事
・利用者管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。