サ責の裏技から事業所の公式ツールへ？！アプリを個人用から作り直した理由

自己紹介

はじめまして。Lily∞シリーズを１人で企画・設計・運営している「えーちゃん」です。

私はコードは1行も書けません。でも、「何を作るか」「なぜ作るか」を決めるのが自分の仕事だと思っています。１人の構想とAIという実行力で、現場の声を拾い「こうあるべき姿」を設計する。余計な工程を省き、思考と実装を直結させながら、目の前の課題を一つずつ過去のものにしていく──そんなスタイルで、介護業界向けの記録AI支援アプリを作っています。

当初の甘い目論見「サ責個人のための裏技ツール」

もともとこのアプリは、「サービス提供責任者（サ責）さんを助けたい！」という思いからスタートしました。 書類仕事に追われるサ責さんが、その日だけサクッと使える個人の便利ツールみたいなものを想定していたんです。

私の頭の中にあったのは、いわゆる「ボトムアップ」のストーリー。 現場のサ責さんが個人的にこのアプリを使ってみて、「めちゃくちゃ便利！これがないと生きていけない！」となって、そこから経営者に「これ、事業所全体で導入しませんか？」と直訴していく……そんな展開を想像していました。

致命的な気づき「これ、個人情報だよね？」

しかし、開発を進めていく途中でハッとしました。 介護の計画書を作るためにこのツールで扱う情報って、利用者の「要介護度」や「保険番号」といった、めちゃくちゃセンシティブな内容なんですよね。

冷静に考えてみてください。 一人の従業員にすぎないサ責さんが、経営者の許可も得ずに、外部のアプリケーションにそんな超重要データを勝手に入力する。……これ、明らかに間違っています。コンプライアンス的にもモラル的にも完全にアウトな事態です。

気づいた瞬間、「あ、これボトムアップじゃダメだ。トップダウンじゃないと無理だ」と悟りました。現場が勝手に使い始めるのではなく、経営者がしっかり判断し、事業所として契約・管理する形にしなければ、安全に運用できません。

データベースの大手術を決行

そこで、アプリの根本的な仕組みを作り直すことにしました。 これまではユーザー個人にデータを紐付ける形（users/{uid}/clients）で作っていたものを、すべて事業所・組織単位（organizations/{orgId}/clients）のデータ構造へ全面移行させたのです。

組織の概念を入れ、誰がどの権限を持つか（管理者、サ責、ヘルパーなど）を明確に制御する仕組みを実装しました。 正直、個人アプリからマルチテナント（複数組織対応）の構造に変えるのは大がかりな手術になりました。でも、これで事業所単位で安全にデータを共有できる基盤が整ったわけです。結果的に、サ責さんが退職しても引き継ぎが楽になりますし、本来あるべきベストな形に収まったなと感じています。

メニューが多いだけで「拒絶反応」が出る

事業所単位で導入するということは、ITリテラシーが高い人だけでなく、パソコンやスマートフォンが苦手なスタッフさんも同じシステムを使うことになります。

端末操作に自信がない人って、画面の横（サイドバー）にメニューがいくつもズラッと並んでいるだけで、「うわっ……」と拒絶反応が出てしまうんですよね。

そこで、新しく導入したロール（権限）制御を活かして、画面の表示も徹底的に分けました。 例えばヘルパーさんの画面には、自分に関係のある「報告書」と「その他（指示書）」のふた項目くらいしか表示されません。

これなら、端末操作に慣れていない人でも「変なところを触ってしまうかも……」という不安を感じずに、安心して使うことができます。 また、管理者（サ責や経営者）の目線からしても、ヘルパーさんに不必要な機能が見えないことで、「間違って勝手にいじられない」という安心感につながります。システム側で操作をブロックするだけでなく、そもそも「表示されない」ということが、双方にとっての大きな安心を生むんです。

思考と実装を直結させる

「個人ツールでいいや」という思い込みから始まり、データの取り扱いの重さに気づき、事業所向けのシステムへと大転換する。 業界の外から入ってきた私だからこそ、最初は見えていないこともたくさんありました。

でも、間違いに気づいたら即座に構造を変え、現場の「こうあるべき姿」に合わせていくのが私のやり方です。 これからも、現場のリアルな声とAIの実行力を武器に、目の前の課題を一つずつ過去のものにしていきます。