ー止まる前に設計する 第２弾ー 優秀な問題解決者ほど「面談」でフリーズする――悩みの因数分解と「未然防止型 状態遷移設計」の原点
前回の記事で、私はこう書いた。
「私がやりたいのは、“伴走”だけではなく、“設計”なのかもしれない」
この違和感の正体に気づいたのは、キャリアコンサルタント養成講座を修了し、国家試験のロープレ（ロールプレイ面談）練習を始めてからだった。
今回は、その過程で私が経験した「完全停止（フリーズ）」と、そこから見えてきた、
「なぜ面談は身につかないのか」
という構造的な問題について書きたい。
■ 問題解決のプロが、完全に止まった
私はシート設計の世界で約20年、問題解決を仕事にしてきた。
大量の変数が絡み合う開発現場で、どこが崩れるか、どこで手戻りが起きるか、どの条件が性能に影響するかを観測しながら、再現性高くプロジェクトを推進する。
マネージャーとしても様々なPJを動かしてきたし、
「主体的に問題解決する側」の人間としての自信も自覚もあった。
キャリアコンサルタント養成講座の内容も、驚くほど腑に落ちた。
傾聴
受容
共感
自己理解
価値観
キャリア理論
これまで現場経験や本から断片的に感じていたことが、理論として接続されていく感覚があった。
正直に言えば、「かなり理解できている」と思っていた。
だからこそ、初めてのロープレで完全に止まったことは衝撃だった。
相談者役が話し始めた瞬間、頭が真っ白になった。
自分が経験したことのない悩み。知らない業界。知らない感情。知らない人生。
聴けない。アドバイスもできない。何を話せばいいか分からない。
「問題解決」が最強の武器だったはずなのに、その武器が急に機能しなくなった。何度やっても上手くいかないまま、養成講座は終わった。
■ これは私だけの問題ではない
実は、「練習しても面談ができるようにならない」という現象は、国家試験において構造的な問題になっている。
国家試験のデータを見ても、養成講座受講者が受験者の約9割を占めるにもかかわらず、学科・実技の同時合格率は約54%（第24回～第30回の過去7回の試験結果平均より算出）で推移している。2人に1人は一発合格できていない。
これは講師の質でも、受講生の努力不足でもない。
構造の問題だ。
そして同じ構造は、職場の管理職にも起きている。
「1on1をやっている。部下の話も聴いている。しかし、部下は動けるようにならない」
これも、本質的に同じエラーだ。後で詳しく触れる。
■ 脳内が「迷宮」になっていた
なぜ、知識があるのに面談ができないのか。
設計者として唯一知っている方法を使った。
因数分解だ。
見えてきた答えはこれだった。
「完成図を見ずに、膨大なジグソーパズルを組み立てようとしていた」
養成講座で学ぶ知識は素晴らしい。しかし、それらをどう組み立てるかの「設計図＝全体像」がないまま面談に臨むため、相談者の言葉を前に脳内が「迷宮」状態に陥る。
全体像がないと、脳はすべての情報を「等しく重要」として処理しようとする。感情・状況・不安・希望・現実条件・価値観——それらが整理されないまま一気に流れ込んでくる。
結果として脳の「メモリ（作業スペース）」がパンクし、フリーズする。
だから、こうなる。
質問が飛ぶ
沈黙が怖くなる
アドバイスしたくなる
正解を探し始める
相談者の話を「聴いているようで、自分の脳内会議に夢中」になっている
状態だ。
私が初ロープレで止まったのは、センスがなかったからではない。全体像という構造の地図がなかったからだと気づいた。
■ 「悩み」を設計者の目で分解する
そこで私は「悩みとは何か」を因数分解し始めた。
辿り着いたのがこの定義だ。
悩み＝問題＋葛藤
さらに、
悩み＝行動できていない状態＝選択できていない状態
「Aしたい、しかしBだからできない」という葛藤がボトルネックになり、システムが停止している。
これはシート設計の「状態遷移」と同じ構造だった。部品が動かないのは壊れているのではなく、動ける条件が揃っていないだけだ。
人が動けないのも、本人の問題ではなく、選択できる状態になっていないだけかもしれない。
前提
葛藤
感情
条件
役割
時期
関係性
これらは「動けない理由の変数」だ。しかし当時の私は、何を観測すればいいかの整理がまだできていなかった。
ここで気づいた。
私がやるべきことは「解決」ではなく、「状態の観測」だと。
しかし、もう一つの壁があった。
■ 転換点は「主語の入れ替え」だった
フレームワークを持っても、私はまだ面談で苦しんでいた。
相談者が話している間、私の頭では
「これは何の問題か」
「どう整理するか」
「次に何を聴くか」
という脳内処理が走り続けていた。
「聴いているようで、自分が解こうとしていた。」
ここで決定的な気づきが起きた。
「悩みはCC（支援者）が解決するのではなく、CL（相談者）が自分で整理し、自分で動き出す」
主語の入れ替えだ。
私はずっと「問題解決者」として面談に入っていた。しかし本来、整理し、選び、動いていくのはクライアント本人だ。
CCの役割は「代わりに解決すること」ではなく、「動ける条件を設計すること」だった。
これは設計者の自分に、完全に腑に落ちた言語だった。
無理やり部品を動かすのではない。動ける条件を整えれば、部品は自然に動き始める。人間系システムも同じ構造だ。
この転換以降、私はLABプロファイル（言語パターンから思考傾向を観測する手法）等で相談者の言葉のパターンを観察し、内省を促す問いを使い、整理もクライアント自身にやってもらう面談へと変わった。
その結果、国家試験に合格した。
■ 観測に必要なのは「複数のレイヤー」だった
試験合格後、次の受験生のロープレサポートを始めた。そこで改めて見えてきたことがある。
面談で「状態を観測する」と言っても、何を観測すればいいのかが整理されていないと、また迷宮に入る。
私が気づいたのは、人間の「動けない状態」には、複数のレイヤーが同時に絡んでいるということだ。
たとえば、部下が動けない場面を観察すると、こういう複数の要因が重なっている。
構造の問題（役割や境界線がどう未定義か）
前提の問題（本人が無意識に信じているルールは何か）
因果の問題（行動と結果の繋がりがどう見えていないか）
時間の問題（過去の失敗や未来への不安がどう影響しているか）
性能の問題（その時の感情やコンディションはどうなっているか）
固定制約の問題（動かせない事実やリソースは何か）
これらを一つずつ順番に見るのではなく、同時に保持しながら観測する必要がある。
この視点が、後に私が整理していく「面談OS」の核心になった。
詳細は後日書くが、この「複数レイヤーの同時観測」という視点を、ここで一旦頭に置いておいてほしい。
■ これが「未然防止型 状態遷移設計」の原点
今振り返ると、私が辿り着いたのはこういう視点だ。
面談とは、相手の感情に寄り添うことだけではない。
「人間が動けなくなる構造を事前に観測し、動ける状態へ遷移させる設計」
だ。私はこれを「未然防止型 状態遷移設計」と呼んでいる。
「未然防止」というのは、問題が起きてから対処するのではなく、どこで状態が崩れるかを事前に観測し、崩れる前に設計するという意味だ。シート設計で20年やってきたことと、構造が同じだ。
この視点は、キャリアコンサルタントのロープレだけに使えるものではない。
■ 管理職の1on1も、同じ構造で崩れている
職場の管理職が1on1で直面する問題は、根が同じだ。
「なぜ部下は、1on1をやっても動けるようにならないのか」
多くの1on1は「雑談」か「詰問」で終わる。
なぜか。
部下の「状態」を観測せずに、「どうしたいの？」「何が問題なの？」という問いを投げているからだ。
何が未定義で、どこで葛藤が起きていて、どの前提が崩れているかを観測しないまま「解決しよう」とするから、1on1は機能不全になる。。
これはまさに、私が初ロープレで経験した「問題解決者としてのフリーズ」と全く同じエラーである。
■ 次回
次回は、この「未然防止型 状態遷移設計」という視点を、管理職の1on1に持ち込む。
なぜ1on1は「雑談」か「詰問」になるのか。「寄り添っているのに機能しない」のはなぜか。
そして、部下の「動けない状態」を観測するとはどういうことか。
工学的な視点から、1on1の構造的エラーを分解する。
