【介護・福祉】スマホ記録にハードルを感じているヘルパーに寄り添う導入前シミュレーション

障害福祉サービスの特定事業所加算（加算Ⅰ〜Ⅲなど）の要件を維持しつつ、数ヶ月間の試行運用を行うためのシステム構築案ですね。

特に「サービス提供責任者（責）による指示」と「ヘルパーからの報告」の一対一の対応、および「前回記録の確認」という実務上のクリティカルな要件を、低コストかつ迅速に実現する方法をご提案します。

1. 推奨されるシステム構成案

結論から申し上げますと、開発スピードと「前回の記録を確認する」という動線作りを考慮すると、「Google スプレッドシート + GAS（Google Apps Script）によるWebアプリ化」が最もおすすめです。

なぜ Google Sheets + GAS なのか？

• 「前回の記録」の参照が容易： FirebaseやPHP/MySQLよりも、スプレッドシートをデータベースに使うことで、過去ログの検索や表示のロジックをGASで簡潔に記述できます。
• 印刷（保存）との相性： 暫定期間後の保存用印刷も、スプレッドシートの標準機能や、GASによるPDF出力機能で容易に実装できます。
• コストと管理： 5名のヘルパーであれば無料枠内で十分運用可能です。

2. 実装案の比較

3. 具体的なシステム設計（GAS Webアプリ案）

特定事業所加算の要件を満たすためのデータ構造とフローを整理します。

① データベース構造（スプレッドシート）

• マスタ： ヘルパー名、利用者名、サービス種別
• シフト/指示シート： 日時、利用者名、ヘルパー名、【指示内容】、ステータス（未・済）
• 実績記録シート： 日時、対応シフトID、【報告内容（指示に対して）】、特記事項、入力時刻（タイムスタンプ）

② ヘルパー用アプリの画面遷移

1. ログイン： 専用パスワードで照合。
2. 当日シフト一覧： ログインしたヘルパーに割り当てられた今日の訪問先が表示される。
3. 詳細・報告画面：
   • サ責からの「指示」が大きく表示されている。
   • 「前回の記録を確認する」ボタン： クリックすると、その利用者さんの直近の報告内容がポップアップで表示される。
   • 報告入力欄： 指示に対する返答と、特記事項を入力。
4. 送信： スプレッドシートに書き込まれ、ステータスが「完了」になる。

4. 特定事業所加算の要件クリアのポイント

実地指導でも指摘されやすいポイントを以下の通りカバーします。

• 指示と報告の整合性： 画面設計上、指示を読まないと報告が書けないレイアウトにします。
• タイムスタンプの保持： GASの new Date() で送信時刻を自動記録します。これにより「サービス提供後の速やかな報告」を証明できます。
• 情報の共有（申し送り）： 「前回の記録を確認」ボタンを必須動線に入れることで、要件にある「伝達」を担保します。
• 電子署名の代替： ログインIDによる本人確認をもって署名に代える運用が一般的ですが、必要であればHTML5のCanvas機能で簡易的な手書き署名欄を付けることも可能です。

5. 運用のメリット・デメリット

メリット

• 現場の負担軽減： スマホで完結するため、ヘルパーが事務所に戻って紙に書く手間が省けます。
• リアルタイム管理： サ責は事務所のPCからスプレッドシートを見るだけで、全員の訪問状況がリアルタイムで把握できます。
• 市販ソフトへの移行準備： どのデータ項目が必要か、数ヶ月でブラッシュアップされるため、本導入時の失敗が防げます。

デメリット

• オフラインに弱い： 地下や電波の悪い利用者宅では入力できない（Webアプリの特性）。
• 保守： Google側の仕様変更（稀ですが）に対応する必要があります。

6. まとめと次のステップ

まずは、「Google スプレッドシート + GAS（Webアプリケーション）」でプロトタイプを作るのが、最も目的（検証と要件合致）に即していると考えます。

今後の流れとしての提案：

1. スプレッドシートで「シフト/指示」と「実績」の列項目を確定させる。
2. ヘルパーさんに「これなら打てそうか」の画面イメージ（手書きでもOK）を見せて意見をもらう。
3. GASで最小限の入力フォームを作成してみる。

もしよろしければ、「スプレッドシートに用意する列項目（指示内容、特記事項以外に必要な項目など）」のリスト作成をお手伝いしましょうか？あるいは、GASの具体的なコードの雛形を作成することも可能です。