Kotone Systemsでは現在、個別支援計画、日々の支援、
ケース記録、振り返りをつなぐ
「Kotone Local Application」の開発を進めています。
この開発記事では、完成した機能だけではなく、
なぜこのApplicationを作ろうと考え、
どのように設計しているのかという過程も記録していきます。
今回は、その出発点について紹介します。
記録はある。それでも、次の支援につながらない
発達支援では、たくさんの情報が記録されます。
個別支援計画があります。
日々の支援があります。
その日の様子を残したケース記録があります。
一定期間が経てば、モニタリングが行われ、
その結果をもとに次の支援が検討されます。
一つひとつを見ると、必要なものはすでに存在しています。
それでも、実際にこれらの資料を並べて見ていると、
一つの疑問が生まれました。
これらの情報は、本当に一本につながっているのだろうか。
これが、Kotone Local Applicationを考え始めた出発点です。
支援の流れと情報のつながり
個別支援計画
本人の目標や
支援方針を設定する
日々の支援
日々の活動の中で
支援を行う
ケース記録
その日に起きたことを
具体的に記録する
振り返り
記録をもとに
変化や傾向を確認する
次の支援へ
振り返りをもとに
支援を検討する
個別支援計画と、毎日の支援の間にある距離
個別支援計画には、本人の目標や支援方針が書かれています。
一方、日々のケース記録には、
その日に実際に起きたことが残されています。
例えば、
- どのような活動だったのか
- 本人がどのような反応をしたのか
- どのような声かけをしたのか
- 見本を示したのか
- 選択肢を提示したのか
- 途中で難しくなったのか
- どのような支援で活動へ戻れたのか
といった情報です。
どちらも重要です。
ところが、一定期間後に振り返ろうとすると、
-
この支援目標について、
実際にはどのような場面があったのか -
その場面では、
どのような条件でうまくいったのか - 一度だけなのか、何度か確認されているのか
- 場所や人が変わっても同じだったのか
といったことを、
複数の記録から一つずつ確認していく必要があります。
計画と記録は存在していても、
その間にある関係までは自動的には見えてきません。
個別支援計画 → 日々の支援 → 記録 → 振り返り → 次の支援
この流れを、もう少しつながった形で扱えないだろうかと
考えるようになりました。
作りたいのは「記録をたくさん残すSoftware」ではない
最初は、ケース記録を整理しやすくする仕組みを
作ればよいのではないかとも考えました。
しかし、資料を整理し続けるうちに、
問題は記録の量だけではないことが分かってきました。
記録された出来事を、そのときの条件と一緒に
次の支援へつなげること。
これが大切なのではないかと考えるようになりました。
例えば、ある活動が一度うまくいったとします。
それだけを見ると、「できた」と書くことができます。
しかし実際には、
- 見本があった
- 短い声かけがあった
- 支援者が近くにいた
- 選択肢が提示されていた
- 活動の終わりが分かりやすかった
といった条件があったかもしれません。
その条件を消して「できた」だけを残してしまうと、
次に同じことを支援するときに、
本当に必要だった情報が失われてしまいます。
逆に、一度うまくいかなかったからといって、
「できない」と決めてしまうのも適切とは限りません。
その日の環境や活動、支援方法が
違っていた可能性があるからです。
「できた／できなかった」だけではなく、
どのような条件で成立したのかを見る。
この考え方が、
Kotone Local Applicationの土台になっています。
同じ本人でも、場所が変われば見える姿が変わる
家庭ではできる。
療育ではできる。
園では難しい。
逆に、集団では自然にできるのに、
一対一になると難しくなる。
こうした違いは珍しくありません。
本人自身が突然別人になるわけではありません。
周囲の、
- 人
- 場所
- 活動内容
- 指示の出し方
- 見本
- 集団の人数
- 見通し
- 身体的な負荷
などが変わります。
これまで本人理解の資料を作る中でも、
家庭・療育・園などの情報を最初から一つにまとめるのではなく、
それぞれの場面を分けて見た上で、
共通点や違いを確認してきました。
そうすると、
「この人はこういう人です」という固定した評価よりも、
どの場面で、何があり、
どのような条件なら力を発揮しやすかったのかを残す。
その方が、
次の支援につながりやすいことが見えてきます。
「分からない」ことも、支援に必要な情報
記録を整理していると、
もう一つ大切なことがあります。
記録に書かれていないことを、
「できなかった」と判断してよいとは限らないことです。
その行動を見る機会がなかったのかもしれません。
実際には起きていたけれど、
記録されなかったのかもしれません。
条件が違っていて比較できないのかもしれません。
判断するための情報が、
まだ十分ではないのかもしれません。
確認できなかったことと、
できなかったことは同じではありません。
「まだ分からない」という状態も、
そのまま次へ引き継ぐ必要があります。
この違いは小さく見えますが、
積み重なると、記録から作られる本人像そのものに影響します。
振り返りの根拠を、後から確認できるようにしたい
一定期間が経過すると、
- 以前よりできるようになってきた
- この支援があると安定している
- この場面ではまだ難しい
といった振り返りが行われます。
こうした判断には、
支援者の経験や日々の観察が欠かせません。
その上で、
なぜそう判断したのかを、
過去の記録から確認できる。
そのような仕組みがあれば、
より具体的に次の支援を検討できます。
例えば、
- この条件では何度か成立していた
- 別の場所ではまだ確認できていない
- この支援をしたときに参加しやすくなっていた
といったことを、
必要に応じて元の記録まで戻って確認できる。
そうした仕組みを作りたいと考えました。
目指しているのは、
もっともらしい振り返りの文章を
自動で作ることではありません。
その振り返りが、
何をもとにしているのかを確認できること。
AIに支援を決めてもらうことが目的ではない
Kotone Local Applicationの開発には、
AIを活用しています。
設計の整理や検討にも使っていますし、
今後の実装でも活用していく予定です。
しかし、このApplicationの目的は、
AIに本人を評価してもらうことでも、
AIに支援方針を決めてもらうことでもありません。
支援について最終的に考え、
確認し、判断するのは人です。
ApplicationやAIには、
情報を整理し、考えるための材料をつなぎ、
人の判断を支える役割を持たせる。
このApplicationで目指していること
Kotone Local Applicationで目指しているのは、
単に記録をデジタル化することではありません。
個別支援計画を作ることだけでもありません。
AIに文章を書かせることでもありません。
日々の支援の中で起きたことを、
そのときの条件や支援内容と一緒に残し、
支援目標や振り返りへつなぎ、
必要なときには元の記録まで戻れるようにすること。
その結果として、
- この条件ではこうだった
- この支援があるとこう変わった
- 別の場面でも確認された
- ここについては、まだ分からない
という情報を、
次の支援へ引き継げる仕組みにしたいと考えています。
そして、コードを書く前の設計が始まった
ここまで考えると、
最初に必要だったのは画面を作ることではありませんでした。
Databaseを作ることでもありませんでした。
まず必要だったのは、
- このApplicationでは、何を事実として扱うのか
- どこから先を、人が考え判断するのか
-
記録に含まれる条件や意味を、
どうすれば失わずに残せるのか
を決めることでした。
Kotone Local Applicationの開発は、
コードを書くことより先に、
情報の意味を整理することから始まりました。
現在地
現在、Kotone Local Applicationは基本的な設計を進め、
本格的な実装へ移る段階にあります。
まだApplicationが完成したわけではありません。
これから実際に実装し、
まずは個人を特定しない架空の検証用データを使いながら、
設計した考え方をSoftwareの中でも本当に守れるのか
を確認していきます。
この開発記事では、
完成した結果だけではなく、
その途中で何を考え、何を変更し、
なぜその設計にしたのかも記録していく予定です。