--- title: "部下の「問う力」を育てる（後編）——フィードバックと段階的な委譲" description: "部下の答えに「考えたプロセス」へフィードバックし、Vol.9やVol.11の指標で判断基準を見極めると、問いの設計を段階的に委譲でき、育成が加速します。" canonical: "https://novajournal.net/question-design/grow-questioning/vol-26/" publishedAt: "2026-07-27" author: "NOVA JOURNAL編集部" category: "問いのデザイン" subCategory: "問いの力を伸ばす" tags: ["マネジメント・育成", "問いの技法"] --- # 部下の「問う力」を育てる（後編）——フィードバックと段階的な委譲 部下の答えに「考えたプロセス」へフィードバックし、Vol.9やVol.11の指標で判断基準を見極めると、問いの設計を段階的に委譲でき、育成が加速します。 **前編で問いの渡し方を整理しました。後編では、部下が答えを返してきた後のフィードバックと、「問いの設計そのもの」を段階的に任せていく判断基準を整理します。** ### この記事でわかること - 部下の答えに対するフィードバックの仕方 - 「問いの設計」を委譲するタイミングの見極め方 - 委譲した後のフォロー --- 前編では、答えではなく問いを渡す方法を整理しました。問い・コンテキスト・期待する出力の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つの基準」を一緒にやることです。「今回の問い、動いた？ 使えた？ つながった？」。部下と一緒に振り返り、「どこで問いがずれたか」を特定する。問いの設計を一緒にやり直す。 **失敗は委譲を撤回する理由ではなく、一緒に学ぶ機会です。** 失敗から学べる環境を作れるかどうかが、問う力を育てられるチームとそうでないチームの分かれ目です。 ### まとめ ![](/images/articles/34ab0067d96980159793d4dc8674307b.png) この記事のポイントを3つにまとめます。 - フィードバックは答えの「内容」だけでなく「考えたプロセス」に出す。良い着眼点は具体的に言語化して褒め、穴があれば問いの形で示し、根拠が弱ければ根拠の出し方を教える - 委譲のサインは、繰り返し成功している、軌道修正なしでたどり着く、自発的に問いの設計を報告してくる。まず小さい案件で試し、行ったり来たりしながら広げる - 委譲後は「問いの設計」を一緒に確認する。うまくいかなかったら振り返りの3基準を一緒にやる。失敗は委譲を撤回する理由ではなく、一緒に学ぶ機会 --- 次回は「上司の問いが、チームの思考の天井になる」。ここまで部下の育成を扱いました。でも、チームの問いの質を決めているのは、実は上司の問いです。上司の問いが狭ければ、部下の思考も狭くなる。