Care Network Design for Ambient Care 第2章

第1章では、DXやAXを考える前に、

仕事を一件ごとの トランザクション として見ること
それらがどれくらい流れているかという トラフィック を見ること

が大切だ、という話をしました。

今度は、その一歩先の視点として、

「業務フロー」を、ひとつの「ルーティングテーブル」として捉え直す

というテーマを扱います。

誰に、どの順番で、どの経路で仕事が渡っていくのか。
ここが歪んだまま「人を増やす」「ツールを増やす」と、
現場の忙しさは、形を変えながら残り続けてしまいます。

1. 業務フローは「社内ルーティングテーブル」

ネットワークの世界では、
パケットの行き先を決めているのが ルーティングテーブル です。

どの宛先に向かうパケットを
どの経路から出すのか

が、あらかじめルールとして整理されています。

職場の仕事も、よく見ると同じ構造を持っています。

「この内容は、まず誰に伝えるのか」
「誰の確認や承認を経て、どこに落ち着くのか」
「例外の場合は、最終的に誰に相談が集まるのか」

これらは、暗黙のうちに
社内ルーティングテーブル として動いています。

ただ多くの現場では、このテーブルは

文書化されていない
歴代の慣習と「なんとなくの空気」でできあがっている

ことが少なくありません。

その結果として、
こんな言葉があちこちで聞こえてきます。

「とりあえず、あの人に回しておいて」
「迷ったら、まず○○さんに相談して」

これは、ネットワークの用語でいえば
“なんでも流す default route（デフォルトルート）” が
人に紐づいてしまっている状態です。

2. 「default route」が生む静かな渋滞

default route は、本来とても便利な仕組みです。

行き先がはっきり分からないパケットを、
最後に受け止める場所。

しかし、ここに何でもかんでも流し込んでしまうと、
特定の場所に仕事が集中し、「静かな渋滞」が生まれます。

現場では、こんな形で現れます。

相談・決裁・トラブルが、いつも同じ人に集まる
その人のメールボックスだけが常に満杯
デスクの上に紙の山ができ、チャットの通知も止まらない

周囲から見ると、

「頼りになる人」であり
「仕事の早い人」に見える一方で

その人だけが、
社内ネットワークのボトルネック になっている可能性があります。

そして、こうした「人に紐づいたdefault route」は、
DXやAXを導入してもそのまま残りがちです。

メールの代わりにチャットになっても
紙の代わりにワークフローシステムになっても

「とりあえず、あの人へ」 というルートが変わらない限り、
渋滞ポイントは移動しません。

3. 忙しさの前に「経路」を問い直す

現場が忙しく見えるとき、
最初に浮かびやすいのは「人を増やす」という選択肢です。

もちろん、本当に帯域（人手・時間）が足りないケースもあります。
ただ、その前に一度だけ立ち止まって、

「今のルート設計は、合理的だろうか？」

と問い直してみる価値は大きいと感じています。

ネットワークの世界では、
回線を増やす前に必ず、

経路の見直し
負荷の偏りのチェック

が行われます。

業務も同じように、

すべてを同じ人・同じ部署に通す必要が本当にあるのか
もっと手前で判断・対応できるポイントはないのか
内容や重要度によって、ルートを分けられないか

といった視点で眺めてみると、
「増員」の前にできることがいくつも見えてきます。

4. 現場でできる「ルーティングテーブルの見直し」3ステップ

ここからは、特別なツールを使わずに、
紙とペン、あるいは1枚のシートでできる見直しの方法を
3つのステップで整理してみます。

ステップ1：今のルートを「線で描いてみる」

まず、対象とする業務を1つ決めます。

利用者からの相談
職員の休暇申請
設備の不具合報告
苦情・ヒヤリハットの報告

など、日々繰り返し発生しているものがおすすめです。

そして、

最初に誰が受け取り
次に誰へ渡し
どの書類・システムを経由し
最終的に誰が判断しているのか

を、シンプルな矢印でつないでみます。

このとき、

いつも同じ人のところで止まりやすい
そこで「待ち」が発生しやすい

と感じるポイントに、印やメモをつけておきます。

きれいな図にする必要はありません。
大切なのは、

「実際には、こういう経路で流れているよね」

と、関係者同士でイメージを共有できることです。

ステップ2：default route を減らす

描いてみた業務フローの中から、

「迷ったら、すべてここへ」
「最終的には、必ずここへ」

というノード（人・部署）を探します。

次に、その人が普段行っている判断や作業を、

ルールとして整理できないか
チェックリストやフォーマットに落とせないか
一部を現場や別の役割に委ねられないか

という視点で細かく見ていきます。

目指したいのは、

「その人しかできない判断」ではなく、
「組織として共有できるルール」に置き換えられる部分を少しずつ増やすこと

です。

default route をゼロにする必要はありません。
ただ、「すべてがそこに流れ込まなくてもよい状態」をつくることはできます。

ステップ3：ルートを「分ける」「近づける」

最後に、ルートそのものを調整します。

具体的には、たとえばこんな工夫が考えられます。

内容ごとにルートを分ける
- 利用者支援に関すること
- 人事・労務に関すること
- 設備・環境に関すること
  など、テーマごとに「最初の窓口」を変える。
優先度ごとにルートを変える
- 命や安全に関わるもの
- 法令・制度に関わるもの
- 改善・提案に関わるもの
  など、重さに応じて経路や扱い方を変える。
「現場で完結できる範囲」を少し広げる
- 一定の条件を満たしていれば、現場判断で対応してよい
- その代わり、「あとから共有」のルールだけを徹底する

ネットワーク設計と同じように、

「すべてのパケットが、同じ一点に集中しなくてもよい」

という状態を目指すことで、
結果的に「忙しさの質」は大きく変わっていきます。

5. DX/AXと「ルート設計」の関係

新しいツールやシステムを導入するDX/AXの場面でも、
このルート設計の視点は欠かせません。

ワークフローを導入したのに、承認が遅くなるケース

よくあるのは、

紙のときの承認経路を、そのままシステムに載せただけ
内容に関係なく、すべての申請が同じルートを通る

というパターンです。

この場合、

「見える化はされたけれど、詰まる場所は変わっていない」

という現象が起きます。

DXによって、

承認待ちの件数や
ボトルネックとなっている場所

は「見える」ようになりますが、
ルーティングテーブルを変える勇気 がなければ、
現場の体感はあまり変わりません。

チャットやタスク管理ツールで「情報の渋滞」が起きるケース

チャットツールやタスク管理を導入した現場で、

すべての情報が「全員宛て」で流れてくる
どのチャンネル・どのボードを見ればよいか分からない
通知が多すぎて、本当に重要なものを見逃してしまう

という悩みを聞くこともあります。

これもまた、

「どこに、どんな情報を流すか」というルート設計がないまま、
送信手段だけ高速化してしまった状態

だと言えます。

DX/AXを検討するときこそ、

誰に向けた情報なのか
どのくらいのスピードで届いていればよいのか
どこに残っていれば、あとから見返しやすいのか

といった「ルーティングの設計」を、一度立ち止まって考える必要があります。

6. 現場を守るための「経路のデザイン」

ケアの現場は、本来、

利用者とゆっくり向き合う時間
ご家族の話を丁寧に聴く時間
職員同士で振り返り、学び合う時間

にこそ、最大の価値があります。

だからこそ、

誰に回せばいいか分からず、仕事がたらい回しになること
default route に選ばれた人だけが、静かに疲弊していくこと
経路の悪さのせいで、ケアに向けるはずだった時間が削られてしまうこと

は、できるだけ少なくしたいところです。

業務フローを「ルーティングテーブル」として捉え直すことは、

現場の時間と注意を、
本当に向けたいところへ戻していくための、静かな設計作業

なのだと思います。

7. まとめ：人を増やす前に、流れを整える

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

忙しさに押されて「人を増やす」「ツールを増やす」と考える前に、
今の業務フローを「社内ルーティングテーブル」として見直してみる。

どこに default route ができているのか
どこでパケット（仕事）が滞りがちなのか
どの部分なら、ルール化や分散ができそうか

を、落ち着いて見てみること。

それは、
Ambient Care Design が目指す「ケアの再人間化」に向けて、
ケアのネットワークそのものを少しずつ整えていく営みでもあります。

業務フローは「ルーティングテーブル」だ！人を増やす前に経路を見直す。「DX・AX論」第2章