引き継ぎ資料を、丁寧に作り込む。
構成も、背景も、想定される疑問への答えも、網羅する。
渡す側としては、それが親切だと思っている。

ところが、資料を精緻にするほど、受け取った側は自立しない。
「次は何をやればいいですか」「このやり方でいいですか」と、判断を外に投げ続ける。
おかしなことに、こちらが渡したものが完璧なほど、相手は育たない。
渡せているものと、渡せていないものが、どこかで食い違っている。

足りないのはスキルではなく判断基準

何が食い違っているのか。
ジュニアチームに足りないスキルを挙げると、いくらでも出てくる。
プログラミング、問題定義、目的志向、タスク管理、コミュニケーション、言語化、リーダー経験。

だが、技術を伝えるだけでは、引き継ぎとして足りない気がする。
それらのスキル不足を、一本貫いている共通点があるからだ。
自分の行動の意味を、自分で説明できない。
これが、核心にある。

判断基準は経験で育てるしかない

その核心を、うまく言い当てた言葉がある。
「計算問題を解くように一つ一つこなすのではなく、感覚的にいろんな物事が把握できる状態」。
これが暗黙知であり、言語化して渡せるものではない。

チームに足りないのは、個別のスキルではなく、判断基準そのものだ。
判断基準が自分の中にないと、「次に何をやればいいですか」「このアプローチでいいですか」を、外に投げるしかなくなる。
そして、その判断基準は、渡せるものではない。
本人が、経験の中で育てるしかない。
ここを取り違えると、引き継ぎは「自立を妨げる作業」に変わってしまう。

渡せるものと、渡せないもの

だとすれば、引き継ぎで渡せるものと渡せないものを、はっきり分けておく必要がある。

渡せるもの

渡せるのは、次のようなものだ。

• 技術的な構成の情報
• 個別の疑問への回答
• タスクの目的や背景

これらは、言語化して文書にできる、形式知の領域だ。
網羅的にまとめるほど、価値が出る。

渡せないもの

一方、渡せないものもある。

• 判断基準
• 有機的な結合（個別の知識が一つに繋がっている状態）
• 暗黙知全般

これらを言葉や手順で渡そうとすると、形ばかり整って実体の伴わないものができる。
だから、整えすぎないことが、逆に最大の貢献になりうる。
彼らが「わからない中でもがく」経験を、奪わないことだ。

ここに、居心地の悪いトレードオフがある。
引き継ぎ資料の精度を上げ続けるほど、受け取る側の判断機会は減っていく。
情報の網羅性と本人の成長は、ある点から先で、互いに食い合う。
冒頭の「完璧なほど育たない」は、気のせいではなかった。

質問への応答を設計する

線引きが分かっても、実務では質問が飛んでくる。
そして、すべての質問に同じように答えると、判断を外注する習慣が固定化してしまう。
だから、質問の種類で応答を分ける。

• 純粋な技術質問。事実関係や仕様の確認。これはそのまま答えていい
• 判断を含む質問。「次に何をやればいいですか」「AとBどっちがいいですか」。これには、答える前に一つ挟むものがある

判断を含む質問には、まず「今いちばん分かっていないことって、何だと思う？」を返す。
これは、判断を本人に戻すための問いだ。
思考のステップを、飛ばさせないための装置でもある。
慣れるまでは、突き放されたように感じるかもしれない。
だが、判断基準を育てるルートは、たぶんここしかない。

苦しむ余地を残す

とはいえ、この設計にも、解けない問いが残る。
仕組みやフォーマットを残しても、それを運用する意志がなければ、定着しない。
そして、意志をどう育てるかは、仕組みでは解けない領域だ。

もう一つ、境界が曖昧なものがある。
「苦しむ余地を残す」ことと、「放置」の境目だ。
ここに正解はない。
相手の状態を見ながら、その都度、引き受けるしかない。

だから、引き継ぎのゴールを、少しずらしておく。
すべてを渡し切ることではなく、渡せないものを、渡せないものとして尊重すること。
資料を一行足すか、あえて空けておくか。
その判断そのものが、実は渡せないはずの判断基準を、こちらが使ってみせる場面になっている。