本文へ移動
組織学習

他事業所の成功例を移す前の確認手順

ある事業所でうまくいった取り組みを、自分の職場に持ち込んでも同じようには動きません。移せるのは「やり方」だけで、それを支えていた人員配置、利用者の状態像、記録の様式、情報システムの契約条件といった条件は移らないからです。成功例を使うなら、結果ではなく条件を先に突き合わせる。この記事では、その突き合わせを漏らさず行うための確認項目と、小さく試して判断するまでの手順を整理します。

なぜ他所の成功例はそのまま動かないのか?

研修や事業者団体の勉強会、あるいは業界メディアで紹介される取り組みは、たいてい「何をやったか」と「どう良くなったか」の二点に圧縮されています。発表する側も、持ち時間の都合で前提条件まで語りきれません。聞く側は結果の鮮やかさに引かれ、手順だけを持ち帰ります。

しかし現場の取り組みは、単独では成立していません。たとえば「音声入力で記録時間が短くなった」という報告があったとして、その背景には、記録様式が自由記述中心だった、夜勤帯の人員に余裕があって練習時間が取れた、法人内に情報システムの担当者がいて端末設定を一括で行えた、といった条件が重なっていることがあります。条件のどれか一つが欠けると、同じ手順を踏んでも結果が再現しません。

さらに厄介なのは、失敗したときに「うちの職員は意欲が低い」「現場が変化を嫌う」という人の問題に読み替えられやすいことです。条件の違いを確認しないまま導入すると、本来は設計の問題だったものが、人の評価の話にすり替わってしまいます。

確かめるべき「条件」とは何を指すのか

条件は漠然と「環境が違う」と言っても比較できません。層に分けて、それぞれ具体的な問いの形にしておくと、短時間でも突き合わせができます。

層 確認する問い 確認先の例
制度・報酬 サービス種別、算定している加算、人員基準や設備基準は同じか。指定権者(都道府県・市町村)は同じか 運営規程、指定申請書類、加算の届出控え
人員・体制 常勤換算の人数、夜勤帯の配置、兼務の有無、職種構成は近いか。取り組みを回す担当者を置けるか 勤務表、職務分掌、シフト作成の担当者
利用者・患者の状態像 要介護度や医療的ケアの分布、在院日数、滞在時間帯は近いか 利用者台帳、アセスメント記録の集計
情報基盤 使っている記録システム、端末の台数と持ち出し可否、通信環境、外部サービスとの接続可否 システムの契約書、情報システム担当、ベンダー窓口
規程・手続き 個人情報の取扱規程、委託先の選定手続き、利用者への説明と同意の取り方 個人情報保護規程、重要事項説明書、同意書の様式
文化・経緯 過去に似た取り組みをして頓挫した経験があるか。誰が旗を振ったか 議事録、前任者、現場のベテラン職員

この表は、相手に質問する順番としても使えます。発表者に声をかけられる場面があるなら、「結果」ではなく「導入前に何を変えたか」「うまくいかなかった時期はあったか」を聞くと、語られていない条件が出てきやすくなります。

条件の違いはどう突き合わせる? — 4つの手順

確認は、次の順で進めると手戻りが少なくなります。

  1. 何が良くなったのかを言い換える。「記録が楽になった」では比較できません。「夜勤者が記録に充てる時間」「申し送りのやり直し回数」のように、自分の職場でも観察できる言葉に置き換えます。置き換えられないなら、その成功例は自分の課題と対応していない可能性があります。
  2. 前提条件を列挙する。上の表の層ごとに、相手の条件を分かる範囲で書き出します。分からない欄は「不明」と明記します。空欄のままにすると、後で「分かっていたつもり」になります。
  3. 自分の職場の条件を同じ欄に書く。ここで差が出た欄が、そのまま導入時のリスク箇所です。特に制度・報酬と情報基盤の欄で差があると、手順の修正では済まず、設計からやり直しになることがあります。
  4. 差を埋める費用と期間を見積もる。端末を増やす、規程を改定する、委員会に諮る、といった作業にどれだけかかるかを出します。ここまで出して初めて、やるかどうかの判断材料が揃います。

この整理は、現場の業務を一度書き出す作業と相性が良いものです。どの工程に手を入れるのかが曖昧なまま道具だけ入れると、結局は使われません。業務の棚卸しの進め方はAIの入れどころは業務の書き出しで決まるで扱っています。

AIツールの事例で特に注意したい点は?

AIを使った業務支援の事例は、ほかの改善活動より条件依存が強くなりがちです。理由は、取り扱う情報と契約形態が職場ごとに違うためです。

確認しておきたい点を挙げます。

  • 入力する情報に個人情報が含まれるか。氏名や生年月日を消しても、状態像と地域を組み合わせれば特定につながる場合があります。個人情報の保護に関する法律、および厚生労働省などが示す「医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンス」の考え方に沿って、自分の職場の規程で判断します。
  • 外部サービスの利用が委託に当たるか。委託に当たる場合、委託先の監督が必要になります。相手の事業所が法人内の閉じた環境で動かしていて、自分の職場は一般向けのサービスを使う、という違いは決定的です。
  • 入力内容が学習に使われない設定になっているか。同じサービス名でも、契約プランによって扱いが異なることがあります。サービス名だけを真似ると前提がずれます。
  • 医療情報を扱うシステムに接続するか。接続する場合は「医療情報システムの安全管理に関するガイドライン」の要求事項を確認する必要があり、院内・法人内の情報システム担当者や委員会との調整が前提になります。
  • 出力をそのまま記録や説明文書に使っていないか。事例紹介では省略されがちですが、確認者と確認手順が設けられているかどうかで、安全性はまったく変わります。

ここは「相手の事業所でできているから大丈夫」とは言えない領域です。指定権者や所属法人の規程が異なれば、同じ行為の可否も変わります。

どこまで試して、どこでやめるかを先に決める

条件を突き合わせても、やってみないと分からない部分は残ります。そこで、本格導入の前に範囲を区切った試行を置きます。試行の設計で決めておきたいのは次の点です。

  • 対象:どの部署の、どの業務の、どの時間帯か
  • 期間:いつ始め、いつ振り返るか(都度または定例会議のどちらで扱うかも決める)
  • 見る指標:手順2で言い換えた観察可能な言葉を使う
  • 撤退条件:どうなったらやめるか、誰が決めるか
  • 記録担当:やってみた感想ではなく、起きた事実を残す人

撤退条件を先に決めておくと、「言い出した人の顔を立てる」という理由で続いてしまう状況を避けられます。続けるか見直すかの判断軸についてはAI試行の続行判断を分ける3つの物差しも参考になります。

たとえば次のような場面を想定してみます。訪問系の事業所が、他法人の報告を聞いて移動中の音声入力を導入しようとしたところ、突き合わせの段階で「相手は社用端末を全員に配布しているが、自分の職場は私物端末の併用」という差が見つかった、という場面です。これは仮の例ですが、この差が見つかれば、導入判断の前に端末の扱いと個人情報の取扱規程を先に整理する、という順序に変えられます。あくまで架空の設定であり、実際の判断は各事業所の契約と規程に基づいて行う必要があります。

持ち込む側が負いやすい三つの負担

成功例を紹介した側に悪意はありません。問題が起きるのは、持ち込む側の進め方に偏りがあるときです。よくある負担を挙げておきます。

一つ目は、管理者が外で見てきた話を、現場の確認なしに決定として下ろすことです。現場からは「また増える」としか見えません。二つ目は、条件の差を現場の努力で埋めようとすることです。端末が足りない、時間が取れないという差は、気合いでは埋まりません。三つ目は、うまくいかなかったときに振り返りをしないことです。条件の突き合わせ表が残っていれば、どの欄の見積もりが甘かったかが分かり、次の判断の材料になります。

逆に言えば、突き合わせ表を一枚残しておくだけで、取り組みの失敗が組織の学習に変わります。

まとめ

他事業所の成功例は、手順のヒントとしては有用ですが、そのまま持ち込む対象ではありません。移せるのはやり方だけで、それを支えていた条件は移らないためです。

  • 結果の表現を、自分の職場でも観察できる言葉に言い換える
  • 制度、人員、利用者像、情報基盤、規程、文化の層ごとに条件を書き出し、不明な欄は不明と書く
  • 差が出た欄を埋める費用と期間を見積もってから、やるかどうかを判断する
  • AI関連では、個人情報の取扱い、委託の該当性、契約プラン、システム接続の可否を必ず自分の職場の基準で確認する
  • 試行は、対象・期間・指標・撤退条件・記録担当を先に決める

条件を確かめる作業は地味で、導入そのものより時間がかかることもあります。ただ、この一手間が、現場に無理を押し付けない導入と、失敗しても次に生きる記録を生みます。法令や制度の適用については、所属法人の規程および指定権者への確認を前提にしてください。

この記事は、AI で下書きを作り、益山康秀(運営者)が内容を確認して公開しています

運営者を応援する

Amazonのアソシエイトとして、メディカルリテラシーラボは適格販売により収入を得ています。