介護・福祉業界のシステム開発のPoC・プロトタイプ・モックアップ開発について

介護・福祉業界の基幹システム開発では、モックアップ、プロトタイプ、PoCの順に試作を重ね、確かめる深さを上げていきます。実データでPoCを行い、KPIで判断すると、現場との適合度を契約前に見極められます。

本記事で扱うのは、施設運営と現場を横断する総合基幹業務システムです。各テーマの詳細は、関連記事もご覧ください。

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

介護・福祉業界の基幹システムにおけるモックアップ・プロトタイプ・PoCの違い

モックアップ、プロトタイプ、PoCの3段階と、それぞれで確かめる画面、操作、実業務の範囲を並べた図。
試作が進むにつれて、確認対象は画面から実業務へ広がります。

この基幹システムは、介護記録やケアプランから、介護報酬請求(レセプト・国保連伝送)、シフト・勤怠管理、家族との情報共有までを扱います。利用者の記録から実績を集計し、レセプト請求や勤務管理、家族への連絡につなげます。業務範囲が広い基幹システムでは、部門間で業務データが連動するため、どこまで事前検証するかが導入の成否を左右します。

本開発の前には、モックアップ、プロトタイプ、PoCという試作段階がよく話題になります。その違いを曖昧にして試作を依頼すると、画面だけで安心して契約し、職員が使えないと後で分かる恐れがあります。

モックアップ・プロトタイプ・PoCという3段階の位置づけ

3段階はいずれも本番前に試作して確かめますが、対象やデータ、現場環境の深さが異なります。

  • モックアップ:画面の見た目と配置
  • プロトタイプ:操作や入力後の動き
  • PoC:実データと現場環境で見る業務全体

モックアップでは、介護記録入力、ケアプラン照会、シフト表などの主要画面を、紙芝居のように並べます。画面遷移で業務が回るかを確かめられますが、データは裏側で処理されません。

介護職員の約74%が「ICTという言葉を知らない」と回答した調査もあります。そのため、ボタンの大きさや文字の読みやすさ、画面の簡潔さを、職員の立場で確かめることが大切です。

プロトタイプでは、一部をカスタマイズした試作品にデータを入れて操作します。音声入力やICタグを使うことで、現場の動きやUI/UXの使い勝手を確かめられます。

プロトタイプの検証は、ベンダー提供のダミーデータによる動作確認にとどまることが多く、自社の利用者数や算定パターンの複雑さまで試せないケースが大半です。

介護現場でPoC(実地検証)まで踏み込む理由

PoC(Proof of Concept=概念実証)は、実業務への適合性を確かめる段階です。

  • 実データ:利用者記録やケアプランを使った検証
  • 現場環境:実際の職員やシフト状況での検証
  • 業務連携:記録から請求、家族共有までを通した検証

PoCでは、実在するケアプランや、日々変わる職員のシフト状況も使います。記録、実績集計、レセプト請求、家族への情報共有が滞りなく流れるかを、実業務に近い条件で確かめます。

加算算定のルールや業務手順は施設ごとに異なり、汎用パッケージの標準機能が、そのまま自社に合うとは限りません。そのため、画面やデモだけで決めず、特定部署やフロアで一定期間運用します。

総合基幹システムの導入を成功させるには、実地検証まで進めることが強く推奨されます。

ポイント

試作の段階は、確かめたいことの深さで選びます。画面の確認で足りるのか、実データと現場での業務適合まで必要なのかを、発注前に目的から決めておくことが判断の目安です。

PoCが重要視される理由と期間・費用の目安

介護記録から請求、シフト、家族共有までを横断するシステムは、数百万円規模の投資になります。稼働後は介護提供や請求業務がそこに乗るため、後戻りが難しくなります。

PoCは、投資判断の一部として行うものです。契約前に適合度を確かめておけば、その後の大きな損失を防ぐ助けになります。

PoCで確かめる現場受容性と制度対応の見極め

PoCが重要な理由は、現場受容性と制度対応の2点を契約前に確かめられることです。導入判断の最後の関門にもなります。

  • 現場受容性:職員が入力を続けられるか
  • 制度対応:国の情報基盤へ連携できるか

営業デモや標準機能の資料だけで契約すると、本開発の後になって現場との不一致が見つかります。たとえば、ITに不慣れな職員が入力を続けられず、マニュアルやエラー画面を理解できないことがあります。

介護職員への調査では74%が「ICTという言葉を知らない」と回答しました。入力が続かなければデータが蓄積されず、形だけのシステムに終わる恐れがあります。特に、この現場受容性の検証はPoCの最重要目的の一つです。

国が推進するLIFE(科学的介護情報システム)やケアプランデータ連携への対応も、契約前に確かめておきます。連携が不十分だと、稼働後にCSV出力や接続方式の追加開発が必要になり、想定外の追加費用が発生することもあります。

PoCの期間・費用の目安

PoCの期間と費用は、施設規模や検証範囲によって変わります。

  • 期間:医療・介護の試験導入は最低3ヶ月が一般的な目安
  • 定着支援:導入後の伴走支援を含め3〜6ヶ月程度が標準
  • 費用:小規模は10万円から、規模により数十万〜数百万円

行政と民間の実証例として、神戸市がスタートアップと協働した事例があります。同事例は、課題公募から実証、成果報告ピッチまでを4ヶ月で完了しました。

外部のDX支援企業には、10万円から試せる小規模検証プランもあります。福井県の協働事例では、最大300万円の補助金で実証を支援しています。

PoC費用は検証規模により、数十万円から数百万円まで幅があります。また、本開発はクラウド型で数ヶ月、フルスクラッチで半年〜1年以上かかります。その前に数ヶ月PoCを行うことは、本投資を守る合理的な保険です。

ポイント

PoCは、数百万円規模の投資を契約前に見極める機会です。期間と費用は施設規模と検証範囲で変わるため、検証範囲を先に決めてから見積もりを比べるのが判断の目安です。

PoCで検証すべき技術・現場要素

PoCを中心に、現場職員の使いやすさ、既存機器のデータ連携、LIFEの刷新、自社の算定条件に沿った請求額を確認する図。
現場での操作から制度出力や請求計算までを一続きで確認します。

「動いたから大丈夫」という感触だけで終えると、PoCの意味が薄れます。そこで、検証項目を先に決め、自社の生の業務データと実際の現場を使って、一つずつ厳しく評価します。

介護記録から請求、制度対応までを横断して確認します。これは、追加開発や現場の混乱を防ぐための確認項目です。

現場受容性(デジタル格差)・既存システム/IoT機器連携の検証

最初に現場受容性を確かめ、職員の使いやすさと周辺機器とのデータ連携を検証します。

  • 受容性:ITに不慣れな職員も操作できるか
  • 機器連携:既存機器のデータを集約できるか
  • 二重入力:システム間の連携で入力を減らせるか

現場職員に実際に触ってもらい、ITリテラシーの低い人が困らないかを見ます。事前アンケートでリテラシーの分布を把握し、代替手段や教育体制も試します。

マニュアルやエラー画面が分かりにくい場合にも、支援が機能するかを確かめます。

ナースコール、バイタル測定器、見守りセンサーなどとの連携も検証します。価格だけで選ぶと、連携できずに手入力が増える事態も起こり得るため、PoCで見極めます。

LIFE・ケアプランデータ連携システムへの対応力の検証

国が推進する制度基盤への出力と、レセプト請求の計算ロジックの再現度を検証します。

  • 制度連携:LIFEやケアプラン連携用データを出力できるか
  • 請求計算:自社の算定条件で請求額が合うか

令和8年度(2026年度)に、LIFEはクラウド型へ刷新されます。そのため、LIFEやケアプランデータ連携システムへのCSV出力などを確かめます。

LIFEの刷新時は、利用者基本情報が自動では移行されず、再入力の手間が課題になります。また、システム側で再入力をどこまで省けるかも、実務上の確認点です。

要介護度や加算条件の組み合わせなど、自社でよくある利用者像を入力します。そのうえで、手作業や既存ソフトの請求額と一致するかを見て、レセプト計算を確かめます。

ずれが出れば、単価表や算定ロジックの再構築が必要になる場合があります。その場合は、本開発の見積もりも見直す必要があります。

ポイント

実データを使い、現場職員が使えるかと、制度連携や請求計算が自社の算定条件でそのまま成り立つかを、一つずつ確かめられるかが判断の目安です。

Go/No-Go判断基準となるKPI

本開発への移行判断に使う、記録時間、請求、継続入力、障害時の紙運用の4つのKPIを並べた図。
効率と請求だけでなく、継続利用や障害時の運用も判断材料になります。

PoC後は、本開発へ進むGoか、見送るか別案を検討するNo-Goかを決めます。「良さそう」という主観で判断すると、検証結果を投資判断に生かせません。

総合基幹システムでは、定量KPIを先に設定し、その達成度をもとに冷静に判断する方法が望まれます。

記録業務の時間削減率とレセプト請求精度による効果の定量化

Go/No-Go判断の中心は記録業務の時間削減率です。

  • 時間削減率:記録入力にかかる時間の短縮度
  • 請求精度:算定ミスによる返戻件数の変化

PoC前に介護記録の入力時間を計測し、導入後の短縮見込みを確かめます。削減率が分かれば、職員の負担軽減を具体的な数値で示せます。

複雑な加算算定を正しく自動化できるかは、システムの価値に直結します。そこで、返戻件数がPoC前より減る見込みかを、投資対効果の指標にします。

時間削減率と請求精度の目標を導入前後で比較すれば、Go/No-Goを根拠を持って判断できます。

現場定着率とアナログ切替対応力による運用適合の測定

時間削減率や請求精度に加えて、日々の運用に根づくか、障害時にも業務を続けられるかも測ります。

  • 現場定着率:対象職員のうち継続入力した割合
  • アナログ切替:紙の運用へ移るときの対応状況

定着率の数値が高いほど、稼働後にデータが蓄積し、導入の価値が出る可能性があります。

アナログ切替対応力は、障害やネットワーク不通時に紙へ移る速さを示します。安全に直結する記録を止められない介護現場では、切替の速さが業務継続を左右します。

PoC中に意図的な停止を想定した訓練を行い、切替速度を測れば、運用適合の面からもGo/No-Goを判断できます。

ポイント

Go/No-Goは、事前に決めた数値目標との比較で判断します。記録時間の短縮率、返戻件数の変化、現場定着率を導入前の数字と並べて目標を立てておくと、感覚に頼らず決められます。

陥りやすい失敗パターンと対策

PoCやプロトタイプは本投資を守る役に立ちますが、進め方を誤ると、時間や費用をかけても判断材料が得られません。

総合基幹システムのPoCで起きやすい失敗は、対策とあわせて事前に把握しておけば避けられます。

横展開されない属人化の罠・現場無視のトップダウン選定

成功を横展開できるよう、現場職員の初期参加もPoCの段階から設計します。

  • 属人化対策:横展開マニュアルと効果測定の型を作る
  • 現場参加:実際に使う職種を初期から加える

パイロット施設で成功しても、他施設が「状況が違う」と抵抗することがあります。成功を担った担当者の異動で、ノウハウが失われる場合もあります。

PoCの成果を「記録時間が〇分から〇分へ短縮」など、明確な数値評価として整えておくと、他施設への展開が進みやすくなります。

もう一つの失敗は、管理職やベンダー主導で、現場を無視して設計してしまうことです。介護の流れから外れると、導入初日に混乱する恐れがあります。

対策として、介護士、看護師、ケアマネジャーなど実際に使う職員を、プロジェクト初期から参加させます。

システム障害時の想定漏れ(パニックの発生)

通常稼働だけでなく、障害時に紙へ切り替える手順も試します。

  • 小規模運用:特定部署での最低3ヶ月の試験運用
  • バックアップ:紙の運用マニュアルを整備する
  • 切替訓練:年1回以上、定期的に実施する

ネットワーク障害や停電でシステムが止まる場合の検証が漏れがちです。安全に関わる記録や情報共有は止められず、システム停止時に現場が混乱する事態は避けなければなりません。

ある病院の電子カルテ一斉導入では、操作説明に偏った研修で、スタッフが不慣れでした。その結果、対応に時間がかかり、クレームが殺到したと報告されています。

介護現場でも全体へ一斉に展開せず、まず小さく試すのが有効です。課題を洗い出してから、横展開します。

試験の間に、紙のバックアップ手順が現場で動くかを確かめておきます。

ポイント

PoCの失敗は、現場を外した設計と障害時の想定漏れから起きやすいものです。現場職員を初期から加え、特定部署での試験運用と紙への切替訓練を計画に入れているかが、判断の目安になります。

まとめ

モックアップは画面を、プロトタイプは操作感を、PoCは実データで現場との適合を確かめます。検証対象は、機器連携、制度基盤、請求計算に加えて、現場の使いやすさです。

介護職員の74%が「ICTを知らない」と回答した現場特性も考慮します。そのうえで、PoCでは現場受容性と制度対応を確認し、契約後の形骸化や追加費用を防ぎます。

期間は試験導入で最低3ヶ月、定着支援を含め3〜6ヶ月が目安です。費用は10万円から数百万円まで幅があり、行政の補助金を使える場合もあります。

Go/No-Goは、時間削減と請求精度、定着率とアナログ切替力を基準に判断します。横展開の仕組みや現場参加、障害訓練を用意すれば、失敗を避けやすくなります。

代表的な利用者パターンで小さなPoCを始め、複数社に実地検証を相談します。その結果を根拠として、本開発へ進むかを判断します。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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