丁寧な指示は邪魔？！介護記録フォームを「引き算」で再設計した話

わたしについて

こんにちは、えーちゃんです。

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

私自身は介護業界は未経験です。だからこそ、業界の当たり前に縛られず、「外から見てどう感じるか」「本当にユーザーにとって使いやすい形は何か」をフラットに考えられると思っています。

今回は、ヘルパーさんが日々入力するサービス記録（報告書）フォームを、「操作に疎い人でもマニュアル不要で使える」ことを目指して全面再設計したときのお話をしたいと思います。

丁寧な説明は、時に邪魔になる

アプリの入力画面を設計するとき、どうしても「あれもこれも」と情報を載せたくなります。ミスがないように、詳しく説明書きを添えたくなるものです。

しかし、現場の方（ここではCommanderと呼びます）から話を聞くと、意外な事実が見えてきました。

自分がヘルパーだった場合、同じ利用者さんを何度も扱うからそうそう指示内容は変わらない。つまり頭に指示内容は入っている。なのに報告をするときにくどくど同じような説明文を見せられるのは絶対にストレスだし、無駄なスクロールが生まれるのでユーザー体験も損なわれる。

たしかに、初めて行く訪問先なら詳細な指示が必要かもしれません。しかし、日常的に同じ利用者さんを訪問するヘルパーさんにとって、毎回画面いっぱいに表示される「指示内容の全文」は、ただスクロールの手間を増やすだけの邪魔な存在になっていたのです。

そこで思い切って、指示内容の全文リストを非表示にしました。

代わりに、サービス提供責任者（サ責）が報告書に盛り込んでほしい内容（観察ポイントや気づきのメモ欄）だけをシンプルに提示する構成に変更。これにより、入力時の迷いがなくなり、他の書類との整合性も図りやすくなりました。

「全部見せたらダメ？！介護アプリで「見せない工夫」にこだわった理由」という記事でも触れましたが、フォーム設計では「何を表示するか」よりも「何を表示しないか」という引き算の思考が重要になる場面が多々あります。慣れたユーザーにとって、既知の過剰な情報は心理的負荷でしかないのです。

入力順序は「直感」から「具体」へ

もう一つ、フォームの構成で大きく変えたのが入力の順番です。 これまでは具体的なサービス内容を先に入力する流れになっていましたが、今回は「利用者の状態（気分や食欲など）」をサービス内容より前に配置しました。

これにも、現場のリアルな意見が反映されています。

細かいところまで見だすと「あれは良かったけどこれはダメだった」とか判断基準がいろいろ出てくる。そうした時に迷うんじゃなくて、サービス提供終わった後の全体のイメージで気軽にポンポンポンと決めてもらいたかった。

まずその人の直感、サービスを提供した後のイメージでパッと入れてほしい。雰囲気イメージみたいなものをまずは入力してほしかった。

人間は、細かい事実を先に羅列すると「木を見て森を見ず」の状態になり、全体像の評価に迷ってしまいます。だからこそ、まずはサービス直後の「残り香」のような直感で、気分や食欲をタップ選択でポンポンポンと選んでもらう。そのあとに具体的な内容を書くという「直感→具体」の流れにすることで、ユーザーの認知負荷をグッと下げることができました。

また、入室・退室ボタンもスティッキーバー（画面上下に固定表示されるバー）にし、退室ボタンを押したら自動で報告フォームへ遷移するようにしました。ITに不慣れな方でも、自然な流れで次のアクションに移れるように工夫しています。 「完全ペーパーレス化は正解？！あえて「紙で印刷できる」機能を実装した理由」でも書いたように、ITに疎い現場の方々に寄り添う設計こそが、本当に使われるシステムへの第一歩だと信じています。

「あり／なし」の二択では現場が困る

今回の再設計で、もう一つこだわったのが「口腔状態」の記録方法です。 以前は、口腔ケアを行ったかどうかを「あり/なし（boolean）」の二択で記録していました。しかし、現場からはこんな声が上がりました。

ありなしオンオフみたいなチェックボックスだけじゃ情報として絶対足りない。どういう状態なのか、それがどう変化しているのかっていう過程が見えないと今後打つ手がない。ケアマネさんに報告するときもそんなぼやっとした情報だけじゃ困る。かといってヘルパーに毎回テキストで書かせるのは負担が大きい。

ケアマネジャーへの報告や今後のプラン作成を考えると、詳細な情報が必要です。しかし、それを忙しいヘルパーさんに毎回テキストで打たせるのは酷です。

そこで、口腔状態を「あり/なし」から**「5段階の横並びボタン」**に変更しました。 これにより、ワンタップで「前回より良くなっているか、悪くなっているか」の変化を追えるようになり、入力の負担を抑えつつ、質の高いデータを残せるようになりました。特記すべき事項がある場合だけ、テキストエリアで補完すればよいのです。

開発の裏側：地味にハマった罠

ここまでUIやUXの設計について偉そうに語ってきましたが、実装ではしっかりと壁にぶち当たっています。

例えば、バイタル入力の部分。元々作っていたVitalsInputコンポーネントが自前でアコーディオン機能を持っていたのをすっかり忘れ、報告フォーム側でさらにアコーディオンで包んでしまい、画面上でバイタル入力欄がマトリョーシカのように二重表示されるというダサいミスをしました。

さらに冷や汗をかいたのは、先ほど触れた「口腔状態」のデータ型変更です。 データベース上の値をboolean（あり/なし）からinteger（5段階の数値）に変更したのですが、アプリ側で入室ボタンを押した瞬間、データベース（Supabase）から「oral_notesなんてカラム見つからないよ！」と怒られエラーに。原因は、新しい仕様に合わせてデータを送信しようとしたものの、データベース側の準備（マイグレーション）が追いついていなかったことでした。

また、すでに保存されている過去の「true / false」のデータを、新しい「数値」として読み出すための後方互換変換（trueなら3にする、など）も必要でした。

この件での学びは、「データベースの型変更は、アプリ側で古いデータも新しいデータも受け止められる変換関数を先に作ってから、データベース自体の変更を実行する」という順番が絶対に安全だということです。逆をやると、見事にアプリがクラッシュします（しました）。

おわりに

業界未経験の私が、こうして介護アプリを作れているのは、現場のリアルな声と、それを形にしてくれるAIのおかげです。

「操作に疎い人でもマニュアル不要」なフォームを作るには、ただ機能を減らせばいいわけではありません。現場の動線を理解し、「何を隠し、何を直感で選ばせ、何を詳細に残すか」をデザインすることが大切だと、今回の再設計を通して強く感じました。

これからも、コードは書けなくても、思考と実装を直結させながら、現場の課題を一つずつ過去のものにしていきたいと思います。