Digital of eXperience |体験の見える化から、組織は変わる。

属人化とも言えるSPOFとしての「できる人」から、中核ノードとしてのチームへ。「DX・AX論」第5章

Care Network Design for Ambient Care 第5章

多くの現場で、こんな言葉を耳にします。

  • 「あの人がいないと、現場が回らない」
  • 「○○さんが全部分かっている」
  • 「とりあえず困ったら、△△さんに聞けばいい」

一見、とても心強い言葉です。
しかしネットワークの視点で見ると、これはそのまま──

**SPOF(Single Point of Failure:単一障害点)**が存在している状態

だとも言えます。

第5章では、

  • なぜ「できる人」がSPOFになりやすいのか
  • それが続くと、どんなリスクがあるのか
  • どうすれば「個人」から「チームの設計」へと移行していけるのか

を、Care Network 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つに分けてみます。

  1. ルール化できるもの
    • すでに基準があり、文書に落とせそうなもの
  2. トレーニングすれば他の人もできるもの
    • 少し時間をかけて学べば、他の職員も担えそうなもの
  3. その人の経験・感性が大きく関わるもの
    • 難しいケースの判断
    • 関係性の調整 など

SPOFを解消したいからといって、
3番をすべてなくす必要はありません。

むしろ、

①と②を組織に広げていくことで、
③=「本当にその人ならではの仕事」に集中してもらう

というのが現実的な方向です。

4-3. ルール・チェックリスト・テンプレートに落とす

①に分類されたものについては、

  • 手順書
  • チェックリスト
  • テンプレート(文書・フォーム・マニュアル)

にしていきます。

ここで大事なのは、

完璧なものを一度で作ろうとしないこと。

最初は粗くても構いません。

  • 最初の版をつくり
  • 実際に使いながら修正し
  • 現場の声を反映して、少しずつ精度を上げていく

という“育て方”が、現実的です。

4-4. ペアリングと「影の担当」をつくる

②と③に関しては、
いきなり担当者を変えるのではなく、

  • メイン担当(今のSPOF的な人)
  • サブ担当(将来そこを担う可能性のある人)

という 「ペア構造」 をつくるのが有効です。

  • 会議や重要なやり取りには、できるだけ2人で参加する
  • 重要なメールや書類は、2人の名前で出す
  • 休みのときにサブ担当が対応し、あとでメインと振り返る

こうしたペアリングは、

「できる人」の頭の中にある暗黙知を、
チームの共有財産に変えていくプロセス

でもあります。

4-5. 「最悪のときにどうするか」を先に決めておく

完全にSPOFをなくすのは難しくても、

  • その人が長期不在になったとき
  • 急に対応できない状況になったとき

に備えて、

「最低限、ここまでならこのルートで対応する」というフェイルオーバー(切り替え)

を、あらかじめ決めておくことはできます。

  • どの情報をどこに残しておくか
  • 誰が一次対応をするか
  • 困ったときに相談できる外部の窓口(社労士・専門職など)

を整理しておくだけでも、
組織の「揺れ方」は大きく変わります。


5. 「できる人」を神格化から、アーキテクトへ

SPOFの話をするとき、
もうひとつ大事にしたい視点があります。

「できる人」を、
“神様”ではなく“アーキテクト(設計者)”として位置づけ直す。

ということです。

  • すべてをその人に頼るのではなく
  • その人の持つ知識や感覚を、
    組織の「設計」に生かしていく役割へと、
    少しずつ移行していきます。

たとえば、

  • ルールやチェックリストの初版を、その人と一緒につくる
  • ペアリングの仕組みを、一緒に考えてもらう
  • 後輩や他職種への「教え方」そのものを設計してもらう

といった形です。

これは、

本人の負担を減らしつつ、
組織全体の知恵を底上げする役割を担ってもらう

ことでもあります。

「できる人」がいなくなるのではなく、
役割の重心が「現場の一人」から「チームの設計者」に移るイメージです。


6. AIは「その人の頭の中」を外に出す手伝いができる

SPOFをほどいていくうえで、
AIはこんな部分を支援できます。

  • その人の説明をもとに、手順書の叩き台を作る
  • チェックリストやテンプレート案をいくつか生成してもらう
  • ケースごとの判断基準を言語化する手伝いをする

つまり、

「その人の頭の中にあるもの」を、文章や図として外に出す

ところをAIに手伝ってもらうイメージです。

ただし、

  • 最終的な判断
  • 関係調整
  • 微妙なニュアンスの読み取り

といった部分は、やはり人の役割として残ります。

AIは「万能ルーター」ではなく、
設計を支える“道具”としての賢いノードであることを、
最終章であらためて整理していきます。


7. まとめ:SPOFを責めず、設計として引き受ける

第5章のメッセージを、一文にまとめるとこうなります。

「あの人がいないと回らない」という状況を、
個人の問題ではなく、“ネットワーク設計の課題”として扱ってみる。

  • その人に集まっている業務と判断を棚卸しする
  • ルール化できるもの・共有できるもの・その人ならではのものに分ける
  • ペアリングやフェイルオーバーを通じて、少しずつ分散させていく
  • 「できる人」を神格化するのではなく、設計者=アーキテクトとして位置づけ直す

こうした一つひとつの試みが、

ケアのネットワーク全体を“しなやかに強く”していく

ことにつながっていくのだと思います。