Skip to content

「介護」にしない支援の設計論

   
「介護」にしない支援の設計論のGPT生成本文インフォグラフィック

支援する立場に立つと、つい何でも引き受けたくなる。
相手が詰まっていれば手を出し、要件が曖昧なら整理してやり、問題が起きれば先回りして消す。
どれも善意だし、実際にプロジェクトは進む。

けれど、しばらくして妙なことに気づく。
支援したはずの相手が、いつまでも自分たちで決められるようにならない。
手を貸すほど、当事者が育たない。
このねじれは、どこから来るのか。

手を貸すほど、当事者が育たない

まず、このねじれに名前をつけておく。
手を貸すほど育たない支援は、支援というより「介護」に近い。
善意でやっていても、構造としては相手から機会を奪っている。

介護に傾くのは、たいていこんな場面だ。

  • 技術で何でも解決してあげる
  • 要件定義を肩代わりする
  • 意思決定の場に、支援者ばかりが出ていく
  • 問題が起きると、先回りして消火する

どれも、その場では感謝される。
だが結果として、支援される側は「自分たちで決めた」という感覚を持てなくなる。

理由は、課題の種類にある。
技術的に答えが決まっている問題なら、肩代わりしても害は小さい。
だが適応課題やソフトスキルの問題は、当事者が自分で向き合わないと解けない。
支援者がそれを引き受けた瞬間、向き合う機会そのものが消える。

だから短期と長期で符号が逆になる。
短期的には、巻き取ったぶんプロジェクトは進む。
長期的には、組織の自走能力が育たない。
これが、介護としての支援が最後に払う代償だ。

何を引き受け、何を残すか

介護に落ちないためには、支援に入る前に自分の原則を言葉にしておくといい。
判断が、現場でぶれなくなる。

  • 技術選定は支援側で行うが、支援される側も触れる構成にする。力不足を感じる経験が、学びの原動力になるからだ
  • 要件定義は協働で進める。対話を通したほうが、よりよい答えに辿り着けるからだ
  • チーム活動はスクラムマスターのように支える。プロセスを整え、判断は当事者に残す

大事なのは、「何をやるか」だけでなく「何をやらないか」まで決めておくことだ。
支援の範囲を絞ることが、そのまま相手に残すべき領域を確保することになる。
やらないことを決めていない支援は、放っておくと際限なく広がり、いつのまにか介護に届く。

クリティカルパスを一人で決めない

それでも、最後まで悩ましいものが一つ残る。
クリティカルパスの扱いだ。

自分が巻き取ったほうが、確実に進む。
ボトルネックのリスクも減らせる。
だが、クリティカルパスに関わることは、責任感や当事者意識が育つ数少ない機会でもある。
巻き取ることは、確実さと引き換えに、成長の芽を摘みかねない。

ありがちな落とし所は、経験で線を引くやり方だ。

  • エントリーレベルには、重要なタスクは任せない
  • ジュニアクラスには任せて、必要に応じて支える

わかりやすい。
だが、誰にどのレベルを任せるかを支援者が一方的に決めていること自体に、矛盾が潜んでいる。

「どうしたいか」を当事者に問う

配分は、当事者に問えばいい。

  • このタスクに挑戦してみたいか
  • 自信がないなら、不安はどこにあるか
  • どこまでなら引き受けたいか
  • どんな支えがあれば踏み出せるか

問うこと自体が、すでに成長支援になっている。
自分で選んだという感覚があるだけで、同じタスクの意味が変わる。
押し付けられた責任が、自分で引き受けた挑戦に変わる。

相手が「今は自信がない」と答えたなら、それも一つの答えだ。
無理に背負わせることは、成長ではない。
適切なタイミングで適切な負荷を、相手と一緒に見極めればいい。
この対話そのものが、相手の自己認識と判断力を育てていく。

ここまで来ると、冒頭のねじれの正体が見える。
「配分は自分一人で決めなければならない」と思い込んでいたこと、それ自体が協働の信念と食い違っていた。
協働を大切にすると言いながら、いちばん重要な配分だけは支援者が握る。
これでは設計の入り口で、支援される側がもう締め出されている。

支援の設計は、支援される側と一緒に組むものだ。
何を引き受けて何を残すかという線引きこそ、最初に対話すべきテーマになる。
その線を相手と引けたかどうか。
支援が介護に変わらずに済むかは、たぶんこの一点に集約されている。

関連記事

  1. 「技術支援の要請」の裏にある本質的課題
  2. 「欠乏の言語」と「可能性の言語」