Care Network Design for Ambient Care 第4章
前の章では
- 「人手が足りない」と感じる状況の中にも、
実は特定の場所での輻輳（ふくそう）が潜んでいること - 帯域不足と輻輳を切り分けて考える大切さ
を整理しました。
今章のテーマは、もうひとつの重要な視点──
「何を、どこまで優先するか」という設計＝QoS（Quality of Service）
です。
ネットワークの世界では、QoSは
- 音声通話やビデオ会議のように、遅れが許されない通信
- 多少遅れても構わないデータの通信
を区別し、
「大事なものが、そうでないものに邪魔されないようにする」ための仕組みです。
一方、多くの職場では、
- 「急ぎでお願いします」
- 「できるだけ早めで」
- 「至急対応をお願いします」
といった言葉が飛び交い、
結果としてすべてが“最優先”のように扱われてしまうことがあります。
そのとき、一番守りたかったはずのケアは、
かえって後ろに追いやられてしまうかもしれません。
1. なぜ現場は「全部が急ぎ」になってしまうのか
現場での“急ぎ”が増えていく背景には、いくつかの要因が重なっています。
1-1. 「早く動いてくれる人」に依存しやすい構造
- すぐに返信してくれる人
- いつも対応が早い人
がいると、ついそこに仕事を集めてしまいます。
その結果、
「急ぎではないけれど、あの人ならすぐ動いてくれそうだから」
という理由で、“なんとなく急ぎ扱い”の仕事が増えていきます。
1-2. 「期限」と「優先度」が区別されていない
- 「今週中」が、「できれば今日中」になり
- 「今日中」が、いつの間にか「いますぐ」に近づいていく
理由のひとつは、
「期限（いつまで）」と「優先度（どれくらい大事か）」が、分けて語られていない
ことです。
- 「今日中にやってほしいが、他の急ぎ案件の合間で良いもの」
- 「期限は先だが、準備に時間がかかる重要なもの」
これらがすべて「急ぎ」や「早めで」といった、
似たようなラベルで扱われると、現場は判断に迷います。
1-3. 声の大きさが「優先度」を決めてしまう
QoSの設計がないと、
実質的に優先度を決めてしまうのは、
- 声の大きさ
- 感情の強さ
- 職位の高さ
になってしまいがちです。
- 強く依頼をしてくる人の案件が通りやすく
- 物静かな人や、直接は声を上げられない利用者のことは後回しになりがち
という構図は、
ケアの現場が本来大切にしたい価値観と、少しズレてしまいます。
2. ネットワークにおけるQoSと、ケア現場でのQoS
ネットワークのQoSは、
「限られた帯域の中で、
何を優先して通すかを決めるルール」
とも言えます。
これをケア現場に移し替えると、
「限られた時間と人手の中で、
何にどれだけ時間と注意を割くかを決めるルール」
となります。
ここで、ケア現場で考えられるQoSのレイヤーを、あえてシンプルに分けてみます。
レイヤーA：リアルタイム層（今この瞬間〜今日中）
- 生命や安全に関わること
- 信頼関係が大きく揺らぐようなトラブル対応
- 即座に対応しないと、取り返しのつかない事態につながること
これらは、ネットワークで言えば
「遅延が許されない通信」にあたります。
レイヤーB：近日中層（数日〜1週間）
- 法令や制度上の期限が決まっている手続き
- 他部署・外部機関の仕事の“起点”となる情報提供
- 期日を守ることで、信頼を積み重ねていく類の仕事
ネットワークでは、
「ある程度は遅延に耐えられるが、締め切りを超えると意味が変わる通信」
に近いイメージです。
レイヤーC：計画・育成層（1週間〜数か月）
- 業務改善やDXの検討
- 教育・研修・振り返りの時間
- チームづくりや関係調整に関する活動
これらは、目の前の“今日の忙しさ”とは別の軸で、
未来のケアを支える基盤になります。
ネットワークでいえば、
インフラの増強や、設計そのものの見直しに近い存在です。
3. QoSがないと起きること
QoSが明確でない職場では、
次のようなことが起きやすくなります。
3-1. レイヤーA〜Cがすべて「A扱い」になる
- 命や安全に関わる案件と、
- 中長期の改善のための案内やアンケートが、
同じ「急ぎで」「お忙しいところ恐縮ですが」といった枕詞で扱われます。
その結果、
「本当にAであるべきもの」と
「BやCでもよいもの」が、混ざってしまう
という状態になります。
3-2. レイヤーC（計画・育成層）が、常に後ろに追いやられる
草の根的な改善案や、
ゆっくりと話す時間、
学びの場は、多くの場合「Cの仕事」です。
QoSが決まっていないと、
AとBに押される形で、
気づけば常に「時間があればやりたいこと」になってしまいます。
しかし、ケアの質をじわじわと変えていくのは、
多くの場合この「Cの層」の積み重ねでもあります。
3-3. 「忙しさ」の手触りが、ずっと変わらない
QoSがないままツールや人手だけを足すと、一見、
- 仕事のスピードは速くなったように見え
- 処理できている案件の数も増えているように見えます。
それでもなお、
「忙しさそのものの質が、あまり変わらない」
「ケアに向き合う余白が増えた実感がない」
と感じるのは、
優先度の設計が変わっていないからかもしれません。
そして、DXと称して、暗にデジタライゼーションしてるだけ（アナログ作業をデジタルに代替）になっているのが、原因です。
4. 現場でできる「QoS設計」の小さなステップ
QoSという言葉を使わなくても、
現場で静かにできる工夫はいくつかあります。
4-1. すべての依頼・タスクに「いつまで」と「どれくらい大事か」をセットで書く
メールやチャット、メモ書きでも構いません。
- 「◯日までに必要なものです（制度上の期限）」
- 「今日中が理想ですが、明日午前中でも大丈夫です」
- 「優先度は高くありませんが、時間があるときに検討いただけると助かります」
といった形で、
期限（when）と重要度（how important）を分けて伝える
ことを、まず送る側から意識してみる。
それだけでも、受け取る側の“心のキュー”（タスクの並べ替え方）は変わっていきます。
4-2. 「A層だけは、必ずここで扱う」という原則をつくる
たとえば、
- 利用者の安全に関すること
- 命や重大な健康リスクに関すること
については、
- どの時間帯でも、まずこの窓口へ
- このチャネルに投稿されたものは、最優先で見る
といった**「A層の専用レーン」**を決めてしまう。
逆にいえば、
- A層ではないものは、そこに流さない
- A層ではないものは、別のレーンを通す
という整理にもつながります。
4-3. C層（計画・育成）に「時間を予約する」
C層の仕事は、「時間が空いたらやる」方式だと、
ほとんど実行されないまま終わってしまいます。
- 週に1時間だけ、改善や振り返りのための枠をカレンダーに確保する
- 月に一度だけ、「立ち止まって話すための時間」をチームで共有する
といった形で、
「Cのための帯域を、あらかじめ確保しておく」
という発想も、QoS設計の一部です。
5. DX/AXにQoSの視点を埋め込む
DXツールやシステムを導入するときも、
QoSの考え方は静かに効いてきます。
5-1. 通知の「強さ」を変える
- A層：ポップアップ通知・メール・アラートなど、気づきやすい形で
- B層：通常の通知にとどめる
- C層：ダイジェストや定期的なまとめとして提示する
といったように、
**「すべての情報を同じ強さで通知しない」**こと自体が、QoSです。
5-2. ダッシュボードの上位に何を置くかを決める
- 期限が近いA/B層のタスクを最上位に表示する
- C層に関わるものは、別タブや別ビューに整理する
といった形で、
「画面のどこを“特等席”にするか」 を設計に反映させます。
5-3. AIの活用も「層」を意識する
AIに任せたいのは、
- C層のアイデア出しや草案作成
- B層の定型処理の一部
- A層では、人が判断するための補助的な整理
といった役割分担です。
すべての層をAIに任せてしまうのではなく、
どの層で、どの程度まで支援してもらうかを決める
ことも、QoSに似た設計といえます。
6. ケアを守るための「優先順位のエlegance」
ケアの現場は、
- 「全部大事」
- 「全部大切」
と言いたくなる場面が多い場所です。
だからこそあえて、
「それでも、今この瞬間は何を一番守りたいのか」
を静かに選び取る必要があります。
- 今日どうしても守りたいもの
- 今週じっくり向き合いたいこと
- 半年かけて少しずつ育てたいこと
それぞれに時間と注意を分けていくことは、
切り捨てではなく、
むしろケアの価値を守るための選択と言えるかもしれません。
7. まとめ：すべてを「最優先」にしない勇気
第4章のメッセージを、一文にまとめるならこうなります。
「全部急ぎ」と言いたくなるときこそ、
何を・いつまで・どれくらいの強さで扱うのかという
“現場のQoS”を設計してみる。
- 期限と重要度を分けて言葉にすること
- A層（本当に遅延できないこと）の専用レーンを決めること
- C層（未来のケアを支えること）の時間を、あらかじめ予約しておくこと
これらはどれも、大げさな仕組みではなく、
日々の小さな設計の積み重ねです。
それでも、その積み重ねが、
「忙しさの質」を静かに変え、
ケアの現場に少しずつ余白を取り戻す
ことにつながっていくのだと思います。
◆社内のDXやAXについてのご相談承っております（初回無料）