こんにちは。Lamb です。 手順どおりに進まないときほど、教える側が何を聞くかで差が出ます。
若手へ作業を教えるとき、最初に必要なのは手順です。ただ、期日が早まる、要件の範囲が変わる、顧客側の体制が変わる。こうした前提変更が起きると、決められた手順だけでは判断できない場面が出てきます。
そのときに必要なのが、正解集ではなく判断の型です。
私が若手に使ってもらったのは、「現状・インパクト・対策」を1セットで整理する型でした。5W1Hで抜けを点検し、分からないことは相談してもらう。リーダーは成果物をレビューし、足りない観点を補い、最後の判断を持ちます。
前回の記事では、実行・報告・判断を分け、最初から判断まで渡さない考え方を整理しました。今回は、その次の段階として、判断するための材料をどう組み立ててもらうかを扱います。
☑️ 手順が正しくても、前提が変われば判断は変わる
手順書は、想定した条件の中で作業を再現するために役立ちます。一方で、手順を作ったときの前提まで変わらないわけではありません。
- 期日が前倒しになった
- 要件の範囲が変わった
- 顧客側の体制や窓口が変わった
前提が変われば、同じ作業でも優先順位、影響範囲、役割分担を見直す必要があります。手順に書かれた操作ができることと、今も同じ条件で進めてよいことは別です。
だから、手順を覚えてもらった次には、「前提が変わったときに何を確認するか」を渡します。
☑️ 判断の型は「現状・インパクト・対策」
前提変更が起きたとき、私は若手からの報告を3点で整理してもらいました。
3つを1セットにするのがポイントです。
現状だけでは次の行動を決められません。対策だけでは、なぜその案を選んだのかが分かりません。インパクトが抜けると、緊急度や優先順位を判断しにくくなります。
提出前には5W1Hでも点検してもらいました。誰が、何を、いつ、どこで、なぜ、どのように行うのか。5W1Hは原因分析の代わりではありませんが、報告の主語、期限、対象範囲、実行方法の抜けを見つける助けになります。
☑️ 現状は、事実・推測・未確認に分ける
現状欄に「要件が変わりました」と書くだけでは、判断材料として足りません。まず、なぜ変更が起きたのかを確認し、表面の出来事だけでなく、仕組み上の欠陥や潜在的なリスクがないかを見ます。
ここで注意したいのが、事実と推測を混ぜないことです。
- 事実：関係者から期日の前倒しを依頼された
- 推測：先方はこの作業を重視していないと思う
- 未確認：前倒しの背景と、変更できない期限の条件
経験が少ない段階では、「こう思う」という推測が事実のように報告されることがあります。そこで感情的に否定するのではなく、「それは確認できた事実か」「何を見てそう考えたか」「他の誰に意見を聞いたか」と質問します。
推測を持つこと自体が悪いわけではありません。3つに分ければ、追加で確認すべきことが見えるようになります。
☑️ インパクトは、数字と数字にしにくい影響を見る
影響は、数字で表せるものだけではありません。
定量的な影響には、遅延日数、対象件数、追加工数、停止時間などがあります。ただし、確認できていない数字を埋める必要はありません。分からない場合は「未確認」とし、確認方法を決めます。
定性的な影響には、関係者との調整難易度、品質への懸念、説明責任、信用への影響などがあります。
さらに、直接影響だけでなく、間接影響も確認します。
- 後続タスクの開始条件が崩れないか
- 別チームや顧客部門の予定に影響しないか
- 担当変更で承認・連絡経路が切れないか
- 急いで進めることでレビューやテストが薄くならないか
経験が少ない段階では、間接的に影響を受ける箇所やステークホルダーまで見渡すのが難しい場合があります。ここはリーダーが知見を使って補う範囲です。
☑️ 対策は、二次災害と仕組み化まで見る
対策欄には、目の前の問題を収める方法だけでなく、その対応から生まれる新しいリスクと回避策も書いてもらいます。
例えば、期日に間に合わせるためレビュー時間を短くするなら、見落としが増える可能性があります。その場合は、重要箇所を別の担当者も確認する、変更範囲を限定する、といった回避策が必要です。
もう一つ注意したいのが、「確認不足だったので、今後は意識して確認する」で終わることです。
意識は必要です。ただ、意識だけに依存すると、忙しいときや担当者が変わったときに同じことが起こり得ます。
監視アラートやメールの見逃し対策では、私は確認時間をチームの予定に入れ、SlackやTeamsなどから担当者へメンション付き通知を出す仕組みにしました。
大切なのは、反省の言葉を強くすることではありません。人が忘れる可能性を前提に、確認が発生し、必要な人へ届く仕組みに変えることです。
☑️ まず本人が整理し、最後はリーダーが判断する
判断基準を教えることは、若手にすべての責任を渡すことではありません。
私は、まず本人に一通り整理してもらいました。そのアウトプットをレビューし、必要な補足と最終判断を行います。途中で分からないことや迷いがあれば、その都度相談してもらいました。
レビューでは、答えを先に言うのではなく、次のような質問をします。
- 変更が起きた真因は何か
- それは確認した事実か、推測か
- 影響を受ける人や後続作業は何か
- 数字で確認できる影響と、数字にしにくい影響は何か
- その対策で新しい問題は起きないか
- 個人の注意ではなく、仕組みとして変えられないか
ただし、重大な影響が迫っているときや、安全に関わる判断は待ちません。前回の記事で整理したとおり、考えてもらう場面とリーダーが止める場面は分けます。
☑️ 繰り返すと、相談の中身が変わる
この型を繰り返してもらう中で、本人のアウトプットは、品質や内容の面で他のメンバーと遜色ない水準へ近づきました。中難易度の課題にも対応できるようになったと感じています。
報告や相談も、状況を整理してから判断が必要な点を絞る形へ変わりました。相談の回数が減ること自体を成果にするのではなく、必要なときに、判断材料を添えて相談できる状態を目指します。
これは私が観測した変化であり、この型を使えば同じ成果を保証できるという話ではありません。チームや作業の状況に合わせて、リーダーが補う範囲を調整する必要があります。
☑️ 前提変更時のチェックリスト
➕️ 現状
- 何が変わったかを一文で説明できる
- 変更が起きた理由を確認した
- 事実、推測、未確認を分けた
- 仕組み上の欠陥や潜在リスクを確認した
➕️ インパクト
- 定量的な影響を確認した。不明な数字は未確認とした
- 定性的な影響を確認した
- 直接影響と間接影響を確認した
- 後続作業とステークホルダーへの影響を確認した
➕️ 対策
- 対策の実行者、期限、方法を明確にした
- 対策から生じる二次災害を確認した
- 二次災害を抑える回避策を用意した
- 意識だけでなく、仕組みとして変えられることを確認した
- 自分で判断できない点と相談先を明確にした
➕️ 5W1H
- Who：誰が行うか、誰に影響するか
- What：何が変わり、何をするか
- When：いつまでか、いつ確認するか
- Where：どの環境・工程・範囲か
- Why：なぜ変わり、なぜその対策か
- How：どのように実行・確認するか
☑️ まとめ
手順は、想定した条件の中で作業を再現するために必要です。ただし、期日、要件、体制などの前提が変われば、同じ手順のまま進めてよいとは限りません。
そのときに若手へ渡したいのが、「現状・インパクト・対策」で考える型です。
現状では、事実・推測・未確認を分ける。インパクトは定量・定性、直接・間接で見る。対策は二次災害と回避策、仕組み化まで考える。そして、5W1Hで抜けを点検します。
最初から正しい判断を求めるのではなく、まず本人に整理してもらい、迷いは相談してもらう。リーダーは質問で不足を見つけ、必要な観点を補い、最後の判断を持ちます。
正解だけを渡すと、次に前提が変わったときにまた止まります。判断するための問いと型を渡すことが、手順の次に必要な育成だと思います。