Article

【新米インフラリーダー #3】若手に答えを教える前に確認したいこと

若手へ正解を渡す前に、空・雨・傘で本人の事実・解釈・行動を確認する方法と、リーダーが判断を引き取る境界を整理します。

若手育成インフラエンジニアリーダー問題解決
空・雨・傘のカードを使い、若手の考え方を確認するLamb
答えの前に、事実・解釈・行動のつながりを確認する。

こんにちは。Lamb です。 答えが分かる質問ほど、すぐ答えたくなるので少し厩介です。

若手から、こんな質問を受けることがあります。

「この手順でエラーが出ました。次に何をすればよいですか?」

「この設定値は、何にするのがよいですか?」

こちらに経験があれば、正解を伝えること自体は難しくありません。急いでいるときほど、答えだけを渡した方が早く進みます。

ただ、それだけだと、次に少し違うエラーや設定項目が出たとき、また同じところで止まりやすくなります。

私が意識しているのは、答えを渡す前に、本人がどう考えたかを聞くことです。最後は私が、そのロジックに問題がないか、その考え方から導かれる答えが妥当かをレビューします。

前回の記事では、手順だけでなく判断基準を渡す考え方を書きました。今回は、実際に質問を受けたとき、答えの前に何を聞くかを整理します。

☑️ すぐ答えれば、その場は早く進む

「次に何をすればよいですか」と聞かれたとき、リーダーが答えを知っていれば、そのまま指示するのが最短です。

特に、本番影響がある、セキュリティに関わる、期限が迫っているといった場面では、考える時間より安全と復旧を優先する必要があります。

一方で、毎回すぐ答えると、こちらが何を見て判断したのかが本人に残りにくくなります。質問の形が少し変わっただけで、また答えを待つ状態にもなりやすいです。

そこで、時間と安全に余裕があるときは、答えを教える前に本人なりの考えを聞きます。

☑️ 「自分ではどう思う?」だけでは足りない

本人の考えを聞くといっても、「自分ではどう思う?」とだけ返すと、何を整理すればよいか分からない場合があります。

そこで、私は「空・雨・傘」の考え方に沿って聞きます。

  • 空:確認できた事実は何か
  • 雨:その事実から、何が起きていると考えたか
  • 傘:次に何を確認し、どう対応したいか

空・雨・傘は、事実、解釈、行動を分けて考えるシンプルな型です。

答えを当ててもらうのではありません。事実から解釈を作り、解釈から行動を選ぶロジックを見せてもらいます。

空を事実、雨を解釈、傘を行動として整理し、最後にリーダーがロジックと導かれる答えをレビューする図
事実から解釈、解釈から行動へのつながりを見る。図を拡大する

☑️ エラーが出た質問では、事実から聞く

「この手順でエラーが出ました。次に何をすればよいですか」と聞かれたときは、まず空に当たる事実を確認します。

  • どの手順まで完了したか
  • どの操作で止まったか
  • 実際に表示されたエラーは何か
  • 直前の操作や入力は何か
  • 手順書の想定と違う点はあるか

次に、雨に当たる本人の解釈を聞きます。

  • どこが原因候補だと考えたか
  • そう考えた根拠は何か
  • 別の可能性はないか
  • まだ確認できていないことは何か

最後に、傘に当たる次の行動を聞きます。

  • 次に何を確認したいか
  • その確認で何が分かるか
  • 実行しても安全か
  • 元へ戻せるか

この順序にすると、単に答えを待っているのか、判断材料は揃っていて最後の確認だけ必要なのかが見えやすくなります。

若手が抽象化したエラーを示し、Lambが3つのトレーで事実、解釈、次の行動のロジックを確認するレビュー場面
答えではなく、事実・解釈・次の行動のつながりを一緒に確認する。図を拡大する

☑️ 設定値の質問でも、考え方は同じ

「設定値を何にすればよいですか」という質問も、値だけを答える前に前提を確認します。

設定値には、目的、通常時の状態、許容できる影響、運用方法などが関係します。一般的な推奨値が、そのまま目の前の環境に合うとは限りません。

本人には、何を根拠にその値を選ぼうとしているのかを聞きます。

  • その設定で何を実現したいか
  • 現在値と通常時の状態はどうか
  • 値を上げ下げすると、どこへ影響するか
  • 候補値をどう比較したか
  • 適用後に何を確認するか

ここでも、空は確認済みの状態、雨は状態の解釈、傘は提案する設定値と確認方法です。

値そのものより、「なぜその値なのか」「適用後に何を見るのか」を確認します。

☑️ 最後はロジックと答えをレビューする

本人なりの答えを聞いた後は、リーダーがレビューします。

私が見るのは、答えが合っているかだけではありません。

  • 事実と推測が混ざっていないか
  • 必要な事実が抜けていないか
  • 事実から解釈へ飛躍していないか
  • 解釈と次の行動がつながっているか
  • 選んだ行動に安全上の問題がないか
  • そのロジックから導かれる答えが妥当か

ロジックに問題があれば、足りない観点を伝えます。

ロジックが妥当でも、権限や影響範囲のために本人だけで決められないこともあります。その場合は、最後の判断をリーダーが引き取ります。

☑️ 答えを教えないことと、放置は違う

本人に考えてもらうことは、何でも自分で調べさせることではありません。

本番影響がある、セキュリティに関わる、期限が迫っている、本人に判断権限がない。このような場面では、リーダーが早めに介入します。

状況によって、渡すものを変えます。

  • 考える材料が揃っている:本人の案を聞く
  • 観点が不足している:確認する観点をヒントとして渡す
  • 選択肢を比較できていない:候補と違いを一緒に整理する
  • 緊急・高リスク・権限外:答えや判断をリーダーが引き取る

目的は、若手に正解当てをさせることではありません。安全を守りながら、判断の過程を一緒に確認することです。

☑️ まとめ

若手から「次に何をすればよいですか」「設定値は何がよいですか」と聞かれたとき、すぐ答えを渡す方がよい場面もあります。

ただ、時間に余裕があり、安全上の問題がないなら、空・雨・傘の順で本人の考えを聞きます。

  1. 空:確認できた事実
  2. 雨:事実から考えたこと
  3. 傘:次に取りたい行動や答え
  4. リーダー:ロジックと、そこから導かれる答えをレビューする

答えだけでなく、答えに至る考え方を見る。必要な観点を補い、最後の判断はリーダーが持つ。この使い分けが、答えを教えることと、考えてもらうことの間にあると思います。