介護・福祉システムの要件定義は、現場業務の可視化、必須機能の優先づけ、制度や移行リスクの整理の順に進めると、現場に合うシステムにつながります。
機能要件、非機能要件、データ移行、制度と責任分界の要件を順に見ていきます。全体像は介護・福祉業界のシステムの完全ガイドで確認できます。
▼全体ガイドの記事
・介護・福祉業界のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
機能要件の洗い出しと優先順位づけ
RFPと要件定義は、まず機能要件の洗い出しから始めます。介護・福祉システムには、ケア記録やバイタル管理、国保連請求、加算管理などの機能があります。
LIFE連携やシフト管理も、必要な機能の例です。機能を並べるだけでなく、誰がいつ何のために使うかを業務フローに沿って整理します。現場の動線を無視した機能リストでは、結局使われないシステムになりかねません。
現場ヒアリングによるAsIs業務の可視化
機能要件を決める前に、まず現状（AsIs）の業務を可視化しておきます。職種ごとの記録や請求の流れを追い、無駄や手戻りがどこにあるかを確かめます。
- 関係者への聞き取り：ケアスタッフ、看護師、ケアマネジャー、事務職員が対象です。
- 困りごとを起点にする：「これが楽になる」と思える要望を、現状の困りごとから引き出すこと。
介護関係者の調査では、ICTを「知らない」とした人が74%でした。そのため、システムに不慣れな現場では、困りごとを起点に要望を聞くことが大切です。
可視化した業務をもとに、あるべき姿（ToBe）と必要な機能を定めます。そのうえで、要件定義書では各機能と解決する業務課題を結びつけます。
ToBeを描かないまま開発をベンダーに丸投げすると、現場の実態と噛み合わないシステムができあがります。
必須・任意の区分と優先順位づけ
洗い出した機能を同じ扱いにすると、予算超過時に何を削るかの判断が難しくなります。そこで、業務に欠かせないものと後回しにできるものに分け、要件定義書で優先度を明示します。
- 必須：これがないと業務が回らない機能です。
- 推奨・任意：必須ではない機能です。その優先度も要件定義書に示します。
「必須・推奨・任意」と区分しておくと、ベンダーは提案や見積もりを組み立てやすくなります。さらに、予算を超えたときに削る機能も判断できます。
優先順位づけは、段階的な導入計画に直結します。必須機能から始めて効果を確かめてから拡張すると、ICTに不慣れな現場の定着を助けます。
一度にすべてを盛り込むと、費用が膨らむうえ、現場が使いこなせず利用率が下がる恐れもあります。
要件定義の段階で、最初に作る機能と後から加える機能のロードマップを描いておきます。このロードマップに沿って進めると、無理のない導入につながります。
RFIによる情報収集とRFPの作り込み
市場の選択肢が分からないままRFP（提案依頼書）を書くと、要件が独りよがりになりがちです。そこで、先にRFI（情報提供依頼書）で情報を集めます。
- 施設の概要と課題：複数のベンダーに共有する情報です。
- 対応機能・概算費用・導入実績：各社に情報提供を求める項目。
集めた情報から、現実的な要件と予算感をつかみ、自施設に必要な要件を見極めてRFPを作ります。二段階で進めれば、重要な要件の見落としも防げます。
介護・福祉システムは、制度や機器との連携が複雑です。そのため、早い段階で複数社の知見を得ておくと、要件の精度が上がり、後の提案比較でも比べる観点がそろいます。
非機能要件とセキュリティ・可用性の定義
機能要件と同じくらい大切なのが、非機能要件です。介護・福祉システムは健康情報を扱い、24時間365日のケアを支えます。だからこそ、非機能要件も機能要件と同じくらい重要になります。
セキュリティや可用性が曖昧なままだと、情報漏えいやシステム停止につながります。そのため、RFPには非機能要件を具体的に記載します。
個人情報保護と権限・監査ログの要件
利用者の病歴、服薬、要介護度は機微な情報です。そのため、閲覧や編集できる範囲を職種や役割に応じて制限しておく必要があります。
- アクセス権限：職種や役割ごとの閲覧・編集範囲。
- 監査ログ：誰がいつ情報にアクセスしたかの記録。
監査ログは、不正アクセスや漏えいの検知・抑止に役立ちます。たとえば他業界では、設定を任せた結果、患者情報が外部から見られる状態になった事例もあります。
RFPには、暗号化、バックアップ、不正アクセス対策も記します。さらに、クラウド型ではデータの保管場所や、提供事業者のセキュリティ認証の有無も確認します。
介護・福祉は地域の信頼を基盤とする事業で、一度の情報漏えいは事業継続に致命的な打撃を与えます。そのため、セキュリティは事業を守る投資と捉え、発注側が要件を定義します。
可用性とシステム停止時のBCP要件
介護・福祉のケアは止められません。そのため、可用性（稼働の安定性）は重要な非機能要件です。要件定義では、目標稼働率と、障害発生時の復旧目標時間を明記します。
- 停止中の記録：紙の記録フォーマットの用意。
- 代替運用：手作業の流れと、紙運用への切り替え手順。
可用性を高めても、障害やサイバー攻撃で情報を見られない事態は起こり得ます。そこで、停止を前提にした業務継続計画（BCP）も必要になります。
停電やネットワーク障害が起きたときの切り替え手順を明文化し、定期的に訓練しておきます。BCPまで要件に含めると、停止中も利用者の安全を守れます。
可用性と停止への備えを合わせて定めると、現実的で堅牢な要件定義になります。
データ移行と過渡期連携の要件
既存システムからのデータ移行は、トラブルが起きやすい工程です。移行の中心は利用者の基本情報とケア記録で、ケアプランや請求履歴も、正確かつ安全に移す必要があります。
移行要件が曖昧なままだと、移行後にデータの欠落や誤表示が起きます。そこで、要件定義の段階で対象範囲、方法、検証手順を具体化しておきます。
データクレンジングと移行範囲の明確化
既存システムには、重複した利用者情報や古い形式の記録が混在することがあります。そのため、移行前にはデータクレンジング（整理・洗浄）が必要です。
- 移行するデータ：移行の対象となる情報の範囲。
- 保管するデータ：移行せず、アーカイブとして残す情報。
未整理のデータを移すと、誤表示や請求ミスの原因になります。たとえば他業界では、クレンジング不足で未納データが誤表示された事例もあります。
過去データをすべて移すと、コストと工数が膨らみます。そこで、法令上の保存義務がある期間と、参照頻度の低い古いデータを分けて扱います。
移行範囲は現実的に定め、コストと品質のバランスを取ります。さらに、移行後のサンプルデータを突合する検証手順も要件に含めます。
新旧並行稼働と過渡期連携の要件
一斉切り替えはリスクが高いため、新旧システムの並行稼働期間を想定しておきます。さらに、その間のデータ連携は、どの方法で行うかを決めておきます。
- 記録データ：新旧システム間で整合を取る方法。
- 請求データ：並行期間中の扱いと運用ルール。
連携設計が甘いと、現場に二重入力が生じます。他業界では、電子カルテの一斉移行初日に操作中心の研修を行い、外来待ち時間が平均3倍に膨らみました。
介護・福祉でも、移行計画や現場研修が不十分なまま一斉に切り替えると、混乱を招きかねません。そこで、段階的な切り替えと並行期間の運用を要件に含めます。
riplaは、フルスクラッチ受託と国内開発の立場から、過渡期連携の設計を含む要件整理を支援しています。
加算・補助金・責任分界（SLA）の要件記載
要件定義には、介護・福祉業界に固有の制度的な論点も織り込みます。加算、ICT導入支援などの補助金、複数ベンダーの責任分界（SLA）は、一般的な業務システムにはない要件です。そのため、RFPにこれらを明記しておくと、提案の質と導入後の安心感が変わります。
報酬改定・LIFE・補助金への対応要件
介護報酬は3年ごとに改定され、加算も新設・変更されます。そのため、制度改定への対応方法と、保守契約に含める範囲を要件に記載しておきます。
- 制度への対応：LIFEや報酬改定後の変更を、要件に含めます。
- 補助金との整合：対象機器・ソフトの仕様を、申請日程に合わせること。
令和8年度改定の電子的診療情報連携体制整備加算は、加算1が15点、加算2が9点、加算3が4点です。制度対応を要件に含めておけば、未対応を避けられます。
介護分野のICT導入支援事業には、職員数に応じ最低100万円相当の補助枠があります。電子処方箋関連は最大194,000円、自治体の上乗せを含めると最大29.1万円です。
補助金の対象要件に沿って仕様を設計し、申請日程とも合わせれば、初期負担を抑えられます。そのうえで、RFPでは補助金を活用する意図を示し、要件に沿った提案を求めます。
複数ベンダー環境の責任分界とSLA
記録ソフトや見守りセンサー、ナースコールなど、複数の機器やベンダーが連携する場合があります。通信回線も加わると、障害時に原因の切り分けが難しくなります。
- 責任範囲：各ベンダーの担当範囲と、その境界。
- 障害対応：一次窓口と、切り分けを主導する担当。
責任が曖昧だと、各社が対応を押し付け合い、復旧が遅れる恐れがあります。また、他業界でも、接続エラーの原因特定を発注側が担う実態が報告されています。
責任分界点は、要件定義書とSLA（サービス品質保証）に明記します。そのうえで、一次窓口は一本に絞り、切り分けの主導役を契約で定めます。
連携を軽く見た結果、接続できず、二重入力の後にシステムを入れ替えた他業界の例があります。移行の負担も二重にかかりました。
そのため、連携要件と責任分界をRFPに含め、既存機器との接続を確かめます。
保守・伴走・教育の契約範囲
導入後の保守・伴走・教育は、見落とされがちです。特に、ICTに不慣れな職員が多い介護現場では、納品時に支援が終わると使いこなせず、利用率が下がる悪循環に陥ります。
- 伴走支援：操作研修、問い合わせ対応、利用状況の点検。
- 教育の継続：新人教育と、マニュアルの整備・更新。
各支援の範囲と頻度を要件に記し、契約に含めれば、「導入して終わり」を防げます。職員の入れ替わりが多い現場では、教育の仕組みも欠かせません。
教育がなければ、定着したシステムも数年で形骸化しかねません。riplaは、フルスクラッチ受託と国内開発の立場から、導入後の定着を見据えます。
検収基準とテスト・受け入れ要件
完成したシステムをどう検収するかの基準を、あらかじめ定めておきます。基準がないと、要件を満たしたかを客観的に判断できず、「言った・言わない」になりかねません。さらに、各機能が期待どおり動くかを確かめる受け入れテストの観点も、要件として明文化しておきます。
- 業務機能：請求データや加算要件の確認機能。
- 機器連携：既存機器との接続が、想定どおりに動くかの確認。
- 操作と誤入力：現場の代表者が実データを使う検証。
中でも、請求データの生成や加算要件の確認、既存機器との連携は、業務に直結するテストです。
正常な操作だけでなく、入力ミスや想定外の操作への反応も試します。そのため、誤操作を防ぎ、操作を誤ってもデータが壊れない設計が求められます。
観点と合格基準は、発注側とベンダーで合意しておき、検収の客観性を保ちます。「作る要件」と「確かめる要件」の両方が必要です。
テスト設計が甘いと、稼働後に不具合が続き、現場が混乱します。要件を一つずつ積み上げておくと、トラブルを最小限に抑えられます。
まとめ
要件定義は、現場業務の可視化から始めます。必須と任意を分けて機能の優先度を決め、制度やリスクに備える要件も整理します。
権限・監査ログや可用性・BCPの要件に加え、データクレンジングと過渡期連携も含めます。報酬改定・補助金への対応や、マルチベンダーの責任分界（SLA）も要件に入れます。
介護・福祉固有の論点を漏れなく織り込めば、現場に使われ続けるシステムに近づけます。
電子カルテの一斉移行では外来待ち時間が平均3倍に膨らみ、クレームが殺到しました。連携不足の例では、二重入力の後に入れ替えたうえ、移行の負担も二重にかかりました。
機能の網羅性に加えて、現場業務を起点に制度やリスクを言葉にする視点が大切です。他業界の電子カルテ一斉移行や連携不足の例は、要件定義の甘さが混乱につながることを示しています。
riplaは、フルスクラッチ受託と国内開発を組み合わせ、要件整理を一貫して支援しています。現場ヒアリングからToBe設計、データ移行、SLA設計まで、一連の流れで扱います。要件整理の前に全体像をつかみたい方は、完全ガイドをご活用ください。
▼全体ガイドの記事
・介護・福祉業界のシステムの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。