Care Network Design for Ambient Care 第5章
多くの現場で、こんな言葉を耳にします。
- 「あの人がいないと、現場が回らない」
- 「○○さんが全部分かっている」
- 「とりあえず困ったら、△△さんに聞けばいい」
一見、とても心強い言葉です。
しかしネットワークの視点で見ると、これはそのまま──
SPOF（Single Point of Failure：単一障害点）が存在している状態
だとも言えます。
第5章では、
- なぜ「できる人」がSPOFになりやすいのか
- それが続くと、どんなリスクがあるのか
- どうすれば「個人」から「チームの設計」へと移行していけるのか
を、Ambient Care Design の言葉で整理していきます。
1. 「できる人」がSPOFになってしまう構造
ネットワークの世界でSPOFとは、
そこが止まると、全体が止まってしまうポイント
のことです。
ケア現場での「あの人がいないと回らない」は、まさにこれに相当します。
たとえば、その人だけが：
- 利用者・家族・多職種との関係を一手に担っている
- 制度や加算、請求の細かいルールを一番よく知っている
- トラブル・クレーム対応の“最終窓口”になっている
という場合、その人の不在は、
- 現場の迷い・不安を増やし
- 手続きや判断を止め
- ケアの質にも影響を及ぼします。
ここで重要なのは、
その人が「悪い」のではない
という点です。
多くの場合、
- 真面目さ
- 責任感
- 現場への思い
が強い人ほど、
結果的にSPOFの役割を背負ってしまいやすいのです。
2. なぜSPOFが生まれやすいのか
組織にSPOFが生まれる背景には、いくつかの要因が重なります。
2-1. default route の集中（第2章とのつながり）
第2章で触れたように、
「よく分からないことは、とりあえずあの人へ」
という default route が、暗黙のうちに形成されます。
- 新しい制度・新しいツール
- 他部署とのやり取り
- 雑多な問い合わせや調整
が、すべて同じ人に向かうことで、
その人はいつの間にか情報と判断のハブになります。
2-2. 善意と遠慮のミックス
- できる人が「自分でやったほうが早い」と引き取ってしまう
- 周囲が「忙しそうだから、あまり負担をかけたくない」と遠慮する
この善意の循環が続くと、
「その人しか分からない／できない」仕事が増えていく
という結果につながります。
2-3. 評価と責任が「個人」に寄りすぎる
- トラブルが起きたときも
- 何かを乗り切れたときも
「○○さんが頑張ってくれたから」と、
個人名ベースで語られ続けると、
- 設計ではなく「努力」で乗り切る文化
- 仕組みではなく「根性」で何とかする空気
が強くなり、ますますSPOFが固定化されていきます。
3. SPOFがもたらす4つのリスク
SPOFを放置すると、次のようなリスクが少しずつ積み上がります。
3-1. 本人の燃え尽きと孤立
一番分かりやすいのは、
SPOFとなっている本人の疲弊です。
- 休みが取りづらい
- 休んでも、復帰したときに業務が山積み
- 困ったことが、すべてその人に集まる
という状態は、
燃え尽きや体調不良につながりやすくなります。
また、
「みんな頼ってくれるけれど、代わりはいない」
という感覚は、
静かな孤立感を生むこともあります。
3-2. 組織全体の「揺らぎ」
SPOFとなる人が不在になると、
- 現場での判断が止まる
- 小さなミスや行き違いが増える
- やり方や解釈にバラつきが出る
といった揺らぎが生じます。
結果として、
属人化による“品質のムラ”が見え始める
ことになります。
3-3. 次世代が育ちにくい
SPOFが強固なままだと、
- その人に「聞けば済んでしまう」
- その人が「判断してしまう」
ため、
若手や新しい人が育つ機会が減っていきます。
- 「自分で考える前に、聞いたほうが早い」
- 「自分の判断で動くのが怖い」
という空気は、
学びと成長のチャンスを少しずつ削っていきます。
3-4. 変化に弱い組織になる
制度改正、加算の変更、DXの推進など、
環境が変わるタイミングでこそ、
組織としての柔軟さが問われます。
SPOF前提のままだと、
その人のキャパシティ＝組織の変化耐性
になってしまいます。
SPOFの余力が尽きたとき、
組織全体の動きも鈍くなってしまう危険があります。
4. 「できる人」を責めずに、SPOFをほどくために
SPOFを解消しようとするとき、
大切にしたい前提があります。
「できる人」個人を責めるのではなく、
そこに負荷を集めてしまった“設計”を問い直す。
そのうえで、現場でできるステップを
いくつかに分けてみます。
4-1. その人が担っている「業務」と「判断」を棚卸しする
まずは、
- どんな仕事がその人に集まっているのか
- どんな種類の判断を、その人が日々行っているのか
を、一度書き出してみます。
ポイントは、
- 単なる作業だけでなく
- 「このケースはOK／これはNG」といった判断のパターン
- どんなときに、どの人に連絡しているか
まで含めて整理することです。
これは、
その人の頭の中にある「暗黙のルーティングテーブル」を
外に出していく作業だと言えます。
4-2. 内容を3つに分ける
棚卸しした内容を、ざっくりと3つに分けてみます。
- ルール化できるもの
- すでに基準があり、文書に落とせそうなもの
- トレーニングすれば他の人もできるもの
- 少し時間をかけて学べば、他の職員も担えそうなもの
- その人の経験・感性が大きく関わるもの
- 難しいケースの判断
- 関係性の調整 など
SPOFを解消したいからといって、
3番をすべてなくす必要はありません。
むしろ、
①と②を組織に広げていくことで、
③＝「本当にその人ならではの仕事」に集中してもらう
というのが現実的な方向です。
4-3. ルール・チェックリスト・テンプレートに落とす
①に分類されたものについては、
- 手順書
- チェックリスト
- テンプレート（文書・フォーム・マニュアル）
にしていきます。
ここで大事なのは、
完璧なものを一度で作ろうとしないこと。
最初は粗くても構いません。
- 最初の版をつくり
- 実際に使いながら修正し
- 現場の声を反映して、少しずつ精度を上げていく
という“育て方”が、現実的です。
4-4. ペアリングと「影の担当」をつくる
②と③に関しては、
いきなり担当者を変えるのではなく、
- メイン担当（今のSPOF的な人）
- サブ担当（将来そこを担う可能性のある人）
という 「ペア構造」 をつくるのが有効です。
- 会議や重要なやり取りには、できるだけ2人で参加する
- 重要なメールや書類は、2人の名前で出す
- 休みのときにサブ担当が対応し、あとでメインと振り返る
こうしたペアリングは、
「できる人」の頭の中にある暗黙知を、
チームの共有財産に変えていくプロセス
でもあります。
4-5. 「最悪のときにどうするか」を先に決めておく
完全にSPOFをなくすのは難しくても、
- その人が長期不在になったとき
- 急に対応できない状況になったとき
に備えて、
「最低限、ここまでならこのルートで対応する」というフェイルオーバー（切り替え）
を、あらかじめ決めておくことはできます。
- どの情報をどこに残しておくか
- 誰が一次対応をするか
- 困ったときに相談できる外部の窓口（社労士・専門職など）
を整理しておくだけでも、
組織の「揺れ方」は大きく変わります。
5. 「できる人」を神格化から、アーキテクトへ
SPOFの話をするとき、
もうひとつ大事にしたい視点があります。
「できる人」を、
“神様”ではなく“アーキテクト（設計者）”として位置づけ直す。
ということです。
- すべてをその人に頼るのではなく
- その人の持つ知識や感覚を、
組織の「設計」に生かしていく役割へと、
少しずつ移行していきます。
たとえば、
- ルールやチェックリストの初版を、その人と一緒につくる
- ペアリングの仕組みを、一緒に考えてもらう
- 後輩や他職種への「教え方」そのものを設計してもらう
といった形です。
これは、
本人の負担を減らしつつ、
組織全体の知恵を底上げする役割を担ってもらう
ことでもあります。
「できる人」がいなくなるのではなく、
役割の重心が「現場の一人」から「チームの設計者」に移るイメージです。
6. AIは「その人の頭の中」を外に出す手伝いができる
SPOFをほどいていくうえで、
AIはこんな部分を支援できます。
- その人の説明をもとに、手順書の叩き台を作る
- チェックリストやテンプレート案をいくつか生成してもらう
- ケースごとの判断基準を言語化する手伝いをする
つまり、
「その人の頭の中にあるもの」を、文章や図として外に出す
ところをAIに手伝ってもらうイメージです。
ただし、
- 最終的な判断
- 関係調整
- 微妙なニュアンスの読み取り
といった部分は、やはり人の役割として残ります。
AIは「万能ルーター」ではなく、
設計を支える“道具”としての賢いノードであることを、
最終章であらためて整理していきます。
7. まとめ：SPOFを責めず、設計として引き受ける
第5章のメッセージを、一文にまとめるとこうなります。
「あの人がいないと回らない」という状況を、
個人の問題ではなく、“ネットワーク設計の課題”として扱ってみる。
- その人に集まっている業務と判断を棚卸しする
- ルール化できるもの・共有できるもの・その人ならではのものに分ける
- ペアリングやフェイルオーバーを通じて、少しずつ分散させていく
- 「できる人」を神格化するのではなく、設計者＝アーキテクトとして位置づけ直す
こうした一つひとつの試みが、
ケアのネットワーク全体を“しなやかに強く”していく
ことにつながっていくのだと思います。