介護・福祉業界のシステムのRFP/要件定義書/提案依頼書について

介護・福祉業界でシステムの刷新や新規導入を進めるとき、成否を最初に左右するのが、RFP（提案依頼書）と要件定義の質です。ベンダーに「介護記録と請求ができるシステムを作ってほしい」と漠然と依頼しただけでは、現場の動線に合わない、加算改定に追従できない、既存の記録が移行できない、といったトラブルが後から噴出します。何を実現したいのか、どんな制約があるのかを言語化し、機能要件と非機能要件としてベンダーに正確に伝えることが、現場に使われるシステムを手に入れる前提条件になります。

本記事は、介護・福祉業界のシステムにおけるRFP・要件定義書・提案依頼書の作り方を、発注する事業者側の視点から解説する「要件定義特化」の内容です。機能要件の洗い出し方、可用性・セキュリティといった非機能要件、データ移行と過渡期連携の要件、そして加算・補助金・複数ベンダーの責任分界（SLA）まで、介護・福祉に固有の論点を具体的に掘り下げます。なお、介護・福祉業界のシステムの全体像をまだ把握していない方は、まず介護・福祉業界のシステムの完全ガイドから読むことをおすすめします。全体像を踏まえると、要件の優先順位がつけやすくなります。

▼全体ガイドの記事
・介護・福祉業界のシステムの完全ガイド

機能要件の洗い出しと優先順位づけ

RFPと要件定義の出発点は、機能要件の洗い出しです。介護・福祉システムでは、ケア記録・バイタル管理・国保連請求・加算管理・LIFE連携・シフト管理など、必要な機能が多岐にわたります。これらをただ列挙するのではなく、自施設の業務フローに沿って「誰が、いつ、何のために使うのか」を起点に整理することが重要です。現場の動線を無視した機能リストは、結局使われないシステムを生みます。

機能要件を正しく洗い出すには、まず現状（AsIs）の業務を可視化する必要があります。ケアスタッフ・看護師・ケアマネジャー・事務職員といった関係者に「実際にどう記録し、どう請求し、どこに無駄や手戻りがあるか」を細かくヒアリングします。介護関係者を対象にした調査では、ICTを「知らない」が74%という結果が示すとおり、現場はシステムに不慣れなことが多いため、現状の困りごとを起点に「これが楽になる」という形で要件を語ってもらうことが大切です。

ヒアリングで可視化したAsIs業務をもとに、あるべき業務の姿（ToBe）を描き、その実現に必要な機能を要件として定義します。この「現場起点でToBeを描く」工程を飛ばし、ベンダーに開発を丸投げすると、現場の実態と噛み合わないシステムができあがります。要件定義書には、各機能が「どの業務課題を解決するためのものか」を紐づけて記載しておくと、ベンダーとの認識のズレを防げます。

洗い出した機能要件は、すべてを同列に扱わず、優先順位をつけることが肝心です。「これがないと業務が回らない必須機能」と「あると便利だが後回しでよい機能」を明確に分けます。要件定義書では、各機能に「必須・推奨・任意」といった区分を付すことで、ベンダーが提案や見積もりを組み立てやすくなり、予算超過時にどこを削るかの判断もしやすくなります。

優先順位づけは、段階的な導入計画にも直結します。まず必須機能で小さく始め、効果を検証してから機能を拡張していく進め方は、ICTに不慣れな現場の定着を助けます。一度にすべてを盛り込もうとすると、開発費が膨らむだけでなく、現場が機能を使いこなせず利用率が下がるリスクも高まります。要件定義の段階で「何を最初に作り、何を後から足すか」のロードマップを描いておくことが、無理のない導入につながります。

いきなり完成度の高いRFP（提案依頼書）を書こうとすると、市場にどんな選択肢があるかが分からず、要件が独りよがりになりがちです。そこで有効なのが、本格的なRFPの前にRFI（情報提供依頼書）でベンダーから情報を集める段階を設けることです。複数のベンダーに、自施設の概要と課題を伝えたうえで、対応可能な機能・概算費用・導入実績といった情報を提供してもらいます。これにより、現実的な要件と予算感をつかめます。

RFIで得た情報をもとに、自施設にとって本当に必要な要件を見極め、RFPを作り込んでいきます。この二段階のプロセスを踏むことで、市場の実態とかけ離れた要求や、逆に重要な要件の見落としを防げます。介護・福祉システムは制度や機器との連携が複雑なため、ベンダーの知見を早い段階で取り込むことが、要件定義の精度を高めます。RFIの段階で複数社と接点を持っておくと、後の提案比較もスムーズになります。

非機能要件とセキュリティ・可用性の定義

機能要件と並んで重要なのが、非機能要件です。介護・福祉システムは、利用者の健康情報という機微な個人情報を扱い、24時間365日のケアを支える基盤であるため、セキュリティと可用性の要件を明確に定義しなければなりません。これらを曖昧にしたままだと、情報漏えいやシステム停止といった重大なトラブルにつながります。非機能要件こそ、RFPで具体的に記載すべき領域です。

介護・福祉システムが扱う情報は、利用者の病歴・服薬・要介護度といった極めて機微なものです。要件定義では、職種や役割に応じて閲覧・編集できる範囲を制限するアクセス権限管理を明確に定義する必要があります。誰がいつどの情報にアクセスしたかを記録する監査ログも、不正アクセスや情報漏えいの検知・抑止のために欠かせません。設定をベンダー任せにした結果、患者の個人情報が外部から閲覧できる状態になっていた、という他業界の失敗事例もあり、権限設定の要件は発注側が主体的に定義すべきです。

あわせて、データの暗号化、バックアップ、不正アクセス対策といったセキュリティ要件を、RFPに具体的なレベルで記載します。クラウド型を採用する場合は、データの保管場所や、提供事業者のセキュリティ認証の有無も確認事項です。介護・福祉は地域の信頼を基盤とする事業であり、一度の情報漏えいが事業継続に致命的な打撃を与えます。セキュリティ要件は「コスト」ではなく「事業を守る投資」として位置づけ、妥協なく定義することが求められます。

介護・福祉のケアは止められないため、システムの可用性（稼働の安定性）も重要な非機能要件です。要件定義では、目標とする稼働率や、障害発生時の復旧目標時間を明示します。しかし、どれほど可用性を高めても、システム障害やサイバー攻撃でケア情報にアクセスできなくなる事態はゼロにはできません。そこで重要になるのが、システム停止を前提とした業務継続計画（BCP）の要件です。

具体的には、システムが使えない間も最低限のケアを継続できるよう、紙の記録フォーマットや手作業の運用フローをあらかじめ用意しておく要件を盛り込みます。停電やネットワーク障害を想定した「アナログ（紙）運用」への切り替え手順を明文化し、定期的に訓練しておくことが、利用者の安全を守ります。デジタル化を進めるからこそ、その停止に備えるBCPまでを要件に含める。これが、現実的で堅牢な介護・福祉システムの要件定義です。

データ移行と過渡期連携の要件

既存システムから新システムへ移行する場合、データ移行はもっともトラブルが起きやすい工程です。利用者の基本情報、ケア記録、ケアプラン、請求履歴といった蓄積データを、いかに正確かつ安全に移すか。この要件を曖昧にしたまま進めると、移行後にデータの欠落や誤表示が発生し、現場が混乱します。要件定義では、移行対象のデータ範囲、移行方法、移行後の検証手順を具体的に定めておく必要があります。

データ移行で見落とされがちなのが、移行前のデータクレンジング（整理・洗浄）です。長年運用してきた既存システムには、重複した利用者データや、古い形式のまま残った記録が混在していることが珍しくありません。クレンジングを実施せずに移行すると、誤ったデータがそのまま新システムに引き継がれ、誤表示や請求ミスの原因になります。他業界では、クレンジング未実施で未納データが誤表示されたという事例もあり、要件として明確に位置づけるべき工程です。

要件定義では、どのデータを移行し、どのデータは移行せずアーカイブするかの線引きを明確にします。すべての過去データを完璧に移行しようとすると、コストと工数が膨大になります。法令上の保存義務がある期間のデータと、参照頻度の低い古いデータを区別し、移行範囲を現実的に定めることが、コストと品質のバランスを取る鍵です。移行後には、サンプルデータの突合による検証手順まで要件に含めておくと、移行品質を担保できます。

システムの切り替えは、ある日を境に一斉に行うとリスクが高くなります。要件定義では、新旧システムを一定期間並行稼働させる過渡期を想定し、その間のデータ連携をどうするかを定めておくことが望ましいです。新旧が混在する期間に、記録や請求のデータをどう整合させるか。この過渡期連携の設計が甘いと、現場は二重入力を強いられ、混乱が生じます。

他業界では、電子カルテを一斉移行した初日に、操作に偏重した研修しか行っていなかったために外来の待ち時間が平均3倍に膨らみ、クレームが殺到した事例があります。介護・福祉でも、十分な移行計画と現場研修なしに一斉切り替えを行えば、同様の混乱が起きかねません。要件には、段階的な切り替えと並行稼働期間、そしてその間の運用ルールを盛り込み、移行リスクを抑える設計にすべきです。riplaはフルスクラッチ受託と国内開発の立場から、こうした泥臭い過渡期連携の設計を含めて要件整理を支援しています。

加算・補助金・責任分界（SLA）の要件記載

介護・福祉システムの要件定義には、この業界に固有の制度的な論点を織り込む必要があります。介護報酬の加算体系、ICT導入支援などの補助金、そして複数ベンダーが関わる場合の責任分界（SLA）。これらは一般的な業務システムにはない、介護・福祉ならではの要件です。RFPにこれらを明記しておくことで、提案の質と、導入後の安心感が大きく変わります。

介護報酬は3年ごとに改定され、加算の新設・変更が頻繁に行われます。要件定義では、こうした制度改定にシステムがどう追従するか、その対応がどの範囲まで保守契約に含まれるかを明記する必要があります。LIFE対応や、令和8年度改定で設定される電子的診療情報連携体制整備加算（加算1=15点・加算2=9点・加算3=4点）など、最新制度への対応を要件に含めておくことで、導入後に「制度が変わったが対応してもらえない」という事態を避けられます。

補助金の活用も、要件と予算計画に織り込むべき要素です。介護分野のICT導入支援事業は職員数に応じ最低100万円相当の補助枠があり、電子処方箋関連では最大194,000円、自治体の上乗せにより最大29.1万円といった補助が用意されています。補助金の対象となる機器・ソフトの要件を満たすよう仕様を設計し、申請のスケジュールと整合させることで、初期負担を抑えられます。RFPの段階で補助金活用の意図を示しておくと、ベンダーから対象要件に沿った提案を引き出せます。

介護システムは、記録ソフト・見守りセンサー・ナースコール・通信回線など、複数のベンダーや機器が組み合わさって動くことが珍しくありません。こうしたマルチベンダー環境では、障害が起きたときに「どこに原因があるのか」の切り分けが難しく、各社が責任を押し付け合って復旧が遅れるリスクがあります。他業界では、接続エラーのたびに発注側が原因の切り分けを強いられる実態が報告されています。

これを防ぐため、要件定義書とSLA（サービス品質保証）に、各ベンダーの責任範囲と責任分界点を明記します。障害発生時の一次対応窓口を一本化し、切り分けの主導権を誰が持つかを契約で定めておけば、トラブル時の混乱を避けられます。安さを優先して既存機器との連携を軽視した結果、連携できず二重入力が発生し、結局システムを入れ替えて移行負担が二重にかかった、という他業界の失敗もあります。連携要件と責任分界は、RFPで妥協してはならない論点です。

要件定義で見落とされがちなのが、導入後の保守・伴走・教育の範囲です。介護現場はICTに不慣れな職員が多く、納品時点でベンダーの伴走が終わると、使いこなせないまま利用率が下がる悪循環に陥ります。要件には、導入後の操作研修・問い合わせ対応・利用状況の点検といった伴走支援を、どの範囲まで・どの頻度で提供するかを具体的に記載すべきです。これを契約に盛り込んでおくことで、「導入して終わり」を防げます。

あわせて、職員の入れ替わりに備えた新人教育の仕組みや、マニュアルの整備・更新についても要件として位置づけておくと安心です。人の出入りが多い介護現場では、教育の仕組みがなければ、せっかく定着したシステムも数年で形骸化しかねません。保守・伴走・教育を「おまけ」ではなく明確な要件として定義することが、長く使われるシステムを手に入れる条件です。riplaはフルスクラッチ受託と国内開発の立場から、こうした導入後の定着まで見据えた要件整理を重視しています。

要件定義で意外と抜けやすいのが、完成したシステムをどう検収するかという基準です。「要件どおりに作られているか」を発注側が確認するための検収基準とテスト要件を、あらかじめ定義しておく必要があります。これがないと、納品されたシステムが要件を満たしているかを客観的に判断できず、「言った・言わない」の水掛け論になりかねません。各機能が期待どおり動くことを確認する受け入れテストの観点を、要件として明文化しておくことが大切です。

とりわけ介護・福祉システムでは、請求データが正しく生成されるか、加算の算定要件チェックが機能するか、既存機器との連携が想定どおり動くかといった、業務に直結する部分のテストが重要です。本番稼働の前に、実際の業務データを使ったテストを行い、現場の代表者が操作して問題がないかを確認する受け入れの工程を要件に含めておきます。この検収・テストの設計が甘いと、稼働後に不具合が次々と発覚し、現場が混乱します。要件定義は、作る要件だけでなく「確かめる要件」まで含めて完成すると考えるべきです。

受け入れテストでは、正常に動くケースだけでなく、入力ミスや想定外の操作が起きたときにシステムが適切に振る舞うかも確認します。介護現場はICTに不慣れな職員が多いため、誤操作を防ぐ仕組みや、間違えてもデータが壊れない設計が求められます。テストの観点を要件として具体的に列挙し、合格基準を発注側とベンダーで合意しておくことで、検収の客観性が担保されます。こうした地道な要件の積み重ねが、稼働後のトラブルを最小限に抑える土台になります。

まとめ

介護・福祉業界のシステムにおけるRFP・要件定義は、現場ヒアリングでAsIs業務を可視化し、必須・任意を分けて機能要件の優先順位をつけることから始まります。そのうえで、個人情報保護と権限・監査ログ、可用性とBCPといった非機能要件、データクレンジングと過渡期連携を含むデータ移行要件、そして報酬改定・補助金・マルチベンダーの責任分界（SLA）という介護・福祉固有の論点を、漏れなく要件に織り込むことが、現場に使われ続けるシステムへの近道です。

要件定義で大切なのは、機能の網羅性よりも「現場の業務から逆算し、制度とリスクに備えた要件を言語化できているか」という視点です。電子カルテ一斉移行による外来麻痺や、連携軽視による二重入力といった他業界の失敗は、要件定義の甘さがもたらす代償を物語っています。riplaはフルスクラッチ受託と国内開発を組み合わせ、現場ヒアリングからToBe設計、データ移行・SLA設計までを一貫して支援します。要件整理の前提として、全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。