前編で問いの渡し方を整理しました。後編では、部下が答えを返してきた後のフィードバックと、「問いの設計そのもの」を段階的に任せていく判断基準を整理します。

この記事でわかること

• 部下の答えに対するフィードバックの仕方
• 「問いの設計」を委譲するタイミングの見極め方
• 委譲した後のフォロー

前編では、答えではなく問いを渡す方法を整理しました。問い・コンテキスト・期待する出力の3つを揃えて渡す。部下のレベルに応じて問いのサイズを調整する。

でも、問いを渡しただけでは終わりません。部下が答えを返してきたときのフィードバックが、問う力を育てる最大のチャンスです。

答えの「内容」ではなく「考えたプロセス」にフィードバックする

部下が「A社への提案は、コスト削減を最優先にすべきです。理由は、先方の資料でコスト関連の言及が最も多かったからです」と返してきた。

多くの上司は、答えの「内容」にフィードバックします。「コスト削減は合ってるけど、納期の話も入れた方がいい」。これは有効ですが、実行力へのフィードバックです。

問う力を育てるには、「考えたプロセス」にフィードバックする。

「資料をちゃんと読んで根拠を出したのはいい。ただ、言及の『量』だけで判断してるよね。社長が最後に一言だけ言った『納期が心配だ』と、資料に10回出てくる『コスト』、どっちが重いと思う？『誰が言ったか』も見てみるといいよ」。

この返しは、部下の「観察の仕方」にフィードバックしている。次に同じ場面が来たとき、部下は「量」と「発言者の重み」の両方を見るようになる。

プロセスへのフィードバックは3つの場面に分けて使います。

良い着眼点があったとき。 「今回、競合の動きを先に調べてから提案を組み立てたのが良かった。自社の都合だけじゃなくて、市場の中での位置づけを先に押さえた。Vol.9の『主語を変える』をちゃんと使ってる」。何が良かったかを具体的に言語化する。型を共有しているチームなら、シリーズの用語で褒められる。

視点に穴があったとき。 答えを否定するのではなく、見落としている視点を問いの形で示す。「解約率の分析は的確だった。ちなみに、これは今四半期だけの傾向？過去3四半期も同じ傾向か確認した？」。Vol.11の「時間軸」を問いで追加している。部下は自分で「あ、時間軸を見ていなかった」と気づく。

根拠が弱かったとき。 「結論は分かった。でも『なんとなくそう感じた』になってない？何のデータを見てそう判断したか、一度整理してみて」。仮説思考のミニシリーズVol.4で「結論と根拠をセットで言い切れる」をゴールにしました。根拠の出し方にフィードバックする。

「問いの設計」を委譲するタイミング

前編でレベル1〜4を整理しました。最終的にはレベル4「自分で問いを立てられる段階」まで育てたい。では、いつ委譲すればいいか。

見るべきサインは3つあります。

① 同じ種類の問いに、繰り返しうまく答えられている。 顧客の優先順位を読む問いに何度もうまく答えているなら、その種類の問いは自力で立てられる可能性が高い。次からは「この案件、まず何を論点にすべきだと思う？」と問い自体を任せてみる。

② 追加の問いやヒントなしで、そのまま使える答えが返ってくる。 問いを渡した後、軌道修正なしで最後までたどり着いている。毎回フィードバックで軌道修正が必要なら、まだ早い。

③ 部下自身が「こういう問いを立てました」と報告してくる。 「A社の案件、先方の優先順位を確認しようと思います。コスト削減と納期短縮のどちらが重いか、先方の資料と前回の議事録から読み取ります」。こういう報告が自発的に来たら、もう問いの設計ができている。

3つ全部が揃う必要はありません。②か③が見えたら、まず小さい案件で試してみる。 うまくいけば範囲を広げる。うまくいかなければ、また問いを渡す段階に戻す。委譲は一方通行ではなく、行ったり来たりするものです。

委譲した後のフォロー

問いの設計を委譲したら、放置しない。着手前に「問いの設計」を共有してもらうステップを入れます。

「今回の案件、どこから手をつける予定？」。部下が「まず先方の優先順位を確認しようと思います」と返してくる。方向が合っていれば「いいね、それで進めよう」。ずれていそうなら「なるほど。ちなみに先方の社長が前回言っていた○○も関係しそうだけど、どう思う？」と問いで返す。

これは「検査」ではなく「壁打ち」です。Vol.24でAIを壁打ち相手にする方法を整理しましたが、上司も同じ役割を果たせます。部下が立てた問いに対して、「別の角度」や「見落としている前提」を問いの形で返す。答えを渡すのではなく、問いで返す。

Vol.14で「論点がないと何も決まらない」と整理しました。部下の仕事のレビューも同じです。成果物の細部をチェックするより、問いの設計を一緒に確認する方が、少ない時間で大きなずれを防げます。

委譲後にうまくいかなかったとき

問いの設計を任せたのに、論点がずれていて成果物が使えなかった。このとき「やっぱりまだ早かった」と答えを渡す側に戻ってしまうと、部下は「自分では無理だ」と学習する。

ここでやるべきは、Vol.23の「振り返り3つの基準」を一緒にやることです。「今回の問い、動いた？ 使えた？ つながった？」。部下と一緒に振り返り、「どこで問いがずれたか」を特定する。問いの設計を一緒にやり直す。

失敗は委譲を撤回する理由ではなく、一緒に学ぶ機会です。 失敗から学べる環境を作れるかどうかが、問う力を育てられるチームとそうでないチームの分かれ目です。

まとめ

この記事のポイントを3つにまとめます。

• フィードバックは答えの「内容」だけでなく「考えたプロセス」に出す。良い着眼点は具体的に言語化して褒め、穴があれば問いの形で示し、根拠が弱ければ根拠の出し方を教える
• 委譲のサインは、繰り返し成功している、軌道修正なしでたどり着く、自発的に問いの設計を報告してくる。まず小さい案件で試し、行ったり来たりしながら広げる
• 委譲後は「問いの設計」を一緒に確認する。うまくいかなかったら振り返りの3基準を一緒にやる。失敗は委譲を撤回する理由ではなく、一緒に学ぶ機会

次回は「上司の問いが、チームの思考の天井になる」。ここまで部下の育成を扱いました。でも、チームの問いの質を決めているのは、実は上司の問いです。上司の問いが狭ければ、部下の思考も狭くなる。