目の前で困っている人を助ける。
これは一般に良い行動である。
しかし、助け方には種類がある。
依存を残す支援
- 完成した答えを渡す
- 毎回代わりに処理する
- 問題が起きるたびに先輩が考える
- 本人は手順と理由を学ばない
- 次回も同じ人へ持ってくる
自立を助ける支援
- 最初は一緒に進める
- 考え方を言語化する
- 判断基準を渡す
- 手順書や例を用意する
- 本人に案を出してもらう
- 次回は本人が処理する
- 例外時の相談先を決める
短期的には、前者の方が速い。
長期的には、後者の方が人も組織も強くなる。
自律志向の支援と依存志向の支援
支援研究では、援助を大きく二つに分ける考え方がある。[7][8][9]
- 依存志向の支援：問題の完全な解決を相手へ渡す
- 自律志向の支援：相手が自分で解決できる資源、知識、方法を渡す
依存志向の支援は、緊急時や初心者の最初の一歩では必要になる。
しかし、恒常化すると、受け手が自分で解決する機会を失う。
自律志向の支援は、すぐに答えを与えないため、短期的には冷たく見えることがある。
それでも、
- 問い返す
- 手順を見せる
- 小さな範囲を任せる
- 結果を一緒に確認する
- 次回の判断基準を残す
という方法は、将来の自走を目的にしている。
職場研究では、自律的に解決できる形の援助が、受け手の学習や課題遂行へ異なる影響を与えることが確認されている。[10]
先輩が全部考えると、後輩は考えなくなる
問題が起きたときに、
先輩なのだから、改善策まで考えてあげなさい
と毎回処理すると、後輩は次のルールを学ぶ。
問題が起きる
→ 先輩へ渡す
→ 先輩が原因を考える
→ 先輩が対策を作る
→ 自分は指示どおり実行する
その結果、後輩に不足するのは知識だけではない。
- 問題を定義する力
- 原因を切り分ける力
- 仮説を出す力
- 優先順位を付ける力
- 失敗から修正する力
- 他者へ説明する力
つまり、考える工程そのものが奪われる。
親切に見える代行が、育成機会を消す。
自立支援は放置ではない
「自分で考えて」とだけ言うのは、自立支援ではない。
情報も権限も経験もない人へ丸投げすれば、擬似的な自律になる。
自立支援には足場が必要である。
初心者へ渡すもの
- 目的
- 完了条件
- 使用する資料
- 基本手順
- 典型例
- よくある失敗
- 判断してよい範囲
- 必ず相談する条件
- レビューの時点
本人へ残す工程
- 最初の案を作る
- 事実を集める
- 仮説を出す
- 選択肢を比較する
- 自分の言葉で説明する
- 結果を振り返る
支援者は、思考を代行しない。
思考できる環境を設計する。
標準書は「考えなくてよい紙」ではない
標準化というと、マニュアルどおりに動く人を作るように聞こえる。
しかし、良い標準書の役割は違う。
- 毎回考える必要がない部分を固定する
- 正常と異常の境界を示す
- 初心者が最低限の品質へ到達できる
- 熟練者の暗黙知を共有可能にする
- 改善前後を比較できる基準を作る
- 例外を発見しやすくする
ISO 9000では、作業指示書を、作業をどのように実行するかの詳細な記述として扱い、文章、図、テンプレート、画像、動画、チェックリストなど複数の形を例示している。[11]
標準書は文字だけである必要もない。
重要なのは、
誰がやっても全く同じ動きをさせる
ことではなく、
必要な品質と判断境界を共有し、違いが出たときに改善できる基準を持つ
ことである。
属人化は、できる人がいる間は見えにくい
属人化した職場では、熟練者が問題を吸収する。
- 難しい案件はあの人へ
- 例外はあの人が知っている
- 新人の失敗はあの人が直す
- 外部との関係はあの人にしか分からない
- システムの不具合はあの人が迂回する
在籍中は速く見える。
しかし、その人が休む、異動する、退職すると止まる。
さらに、できる人へ支援が集中するため、中堅ほど疲弊する。
できる人が拾う
→ できる人に知識が集まる
→ 他の人が考えなくなる
→ さらにできる人へ集まる
→ 中堅が消耗する
→ 中堅が抜ける
→ 若手比率が上がる
→ 残った中堅の教育負荷が増える
これは個人の性格ではなく、組織の学習構造である。
多拠点・多言語ほど「説明できる仕組み」が重要になる
一つの職場だけなら、熟練者の暗黙知と対面支援で回ることがある。
しかし、複数拠点や多言語のチームへ展開すると、その方法は拡張しにくい。
- 同じ背景知識を共有していない
- 言語のニュアンスが異なる
- 設備や部材が完全には同じでない
- 現地の法規、文化、役割分担が違う
- 熟練者を常駐させられない
- 時差がある
拠点間の技術移転研究では、送る側と受ける側の意思、明示知と暗黙知の移転、検証が重要になると整理されている。[12][13]
つまり、手順書だけ送れば終わりではない。
標準書
＋ 実演
＋ 質問
＋ 現地での試行
＋ 理解確認
＋ ローカル条件への調整
＋ 改訂
が必要になる。
標準化と現地適応は対立しない
過剰な標準化には危険がある。
- 現場条件を無視する
- 例外を報告しにくくする
- 手順の目的が分からなくなる
- 改善を禁止する
- 中央の都合を現地へ押し付ける
そのため、標準化の対象を分ける。
共通化するもの
- 品質基準
- 安全条件
- 法令遵守
- 異常判定
- エスカレーション
- 必須記録
- 変更管理
現地で調整するもの
- 伝え方
- 教育方法
- 配置
- 補助具
- 作業順序の細部
- 現地設備に合わせた操作
- 文化や言語に合う表現
良い標準化は、現地の判断を消さない。
共通の目的と境界を固定し、その中で改善できる余地を残す。
本当に相手のために「ここまで」で止める
支援を止めることは、見捨てることではない。
次の状態になったら、本人へ返す。
- 基本手順を説明した
- 判断基準を渡した
- 質問に答えた
- 一度は一緒に実施した
- 必要な権限がある
- 失敗しても修正可能
- 相談条件が明確
そこで再び全部代行すると、本人は成功体験を得られない。
助ける。
ただし、相手のためにも、できるところまで奪わない。
これが自立支援の境界である。
反証：直接解決した方がよい場合もある
自立支援が常に最優先ではない。
- 緊急性が高い
- 失敗が重大事故につながる
- 初心者が前提知識を持たない
- 一度だけの作業で学習投資が回収できない
- 相手が極度に疲弊している
- まず安全を確保する必要がある
この場合は、支援者が直接解決し、その後に説明する方がよい。
重要なのは、直接支援を恒久的な関係へしないことである。
結論：優しさは、相手が次回一人でできるかで測る
短期的な親切は、目の前の負担を消す。
長期的な支援は、次回の処理能力を残す。
- 答えではなく判断基準を渡す
- 代行ではなく練習機会を作る
- 人へ集めず、手順と記録へ戻す
- 標準化しつつ、現地の知識で更新する
- 支援者がいなくても回る状態を作る
本当に相手を助ける人は、永遠に必要とされる人ではない。
自分がいなくても相手が進める状態を作る人である。
