はじめに
エンジニアとして働いていると、技術だけで解決できない場面が増えてくる。
メンバーに業務を教える、1on1で悩みを聞く、レビューで改善点を伝える、チーム内の認識のズレを解消することが必要となることがあります。
こうした場面では、正しい答えを知っているだけでは足りません。
『エンジニアのためのマネジメント入門』では、エンジニアリングとマネジメントでは求められるスキルや仕事の進め方が異なると説明されています。
本書を読んで、特に使いたいと感じたのが、次の6つだった。
| フレームワーク | 主に使う場面 |
|---|---|
| ADDIEモデル | 育成施策の全体を組み立てる |
| ガニェの9教授事象 | 一回の研修や説明を設計する |
| チャンキング | 情報を理解しやすい単位に分ける |
| GROWモデル | 相手の考えと行動を引き出す |
| ジョハリの窓 | 自分と他者の認識のズレを捉える |
| SBI | 行動に対して具体的にフィードバックする |
どれか一つですべてを解決するものではない。それぞれが異なる場面を支える道具だと捉えると、取り入れやすくなると考えます。
本記事では、「障害対応を自走できるメンバーを育てる」という例を使いながら、それぞれをどう実践するか考えていきます。
ADDIEモデルで育成全体を組み立てる
誰かに業務を教えるとき、いきなり資料を作り始めてしまうことがある。
しかし、資料を作ること自体が目的ではない。
相手がどのような状態になれば育成が完了したと言えるのかを、先に決める必要がある。
ADDIEモデルは、学習や研修を次の流れで設計する考え方。
- Analyze：現状や課題を分析する
- Design：学習目標や進め方を設計する
- Develop：教材や演習を作る
- Implement：実際に実施する
- Evaluate：成果を評価する
ADDIEは、Analyze、Design、Develop、Implement、Evaluateの5段階から成る教育設計の枠組みとして整理されている。
障害対応の育成であれば、最初に「障害対応が苦手」という曖昧な状態を分解する。
ログの確認方法が分からないのか、影響範囲を判断できないのか、関係者への連絡に迷うのかによって、必要な育成内容は変わる。
そのうえで、完了状態を「障害対応を理解した」ではなく、次のように行動で定義する。
発生した事象を整理し、必要なログを確認し、影響範囲と暫定対応をチームに共有できる。
目標が決まったら、確認手順、過去事例、演習用の障害シナリオを準備する。
実施後は、説明を聞いたかではなく、実際のシナリオに対して適切に動けたかを確認する。
ADDIEモデルを使うことで、「何を教えるか」から考えるのではなく、「何ができるようになってほしいか」から育成を組み立てられる。
ガニェの9教授事象で一回の学習を設計する
ADDIEモデルが育成全体を設計するための枠組みだとすれば、ガニェの9教授事象は、一回の研修や説明を組み立てるときに使いやすい。
ガニェの9教授事象は、学習が進む流れを次の9段階で捉える。
| 段階 | 障害対応研修での実践例 |
|---|---|
| 注意を引く | 実際に起きた障害事例を紹介する |
| 目標を伝える | 研修後にできるようになることを示す |
| 前提知識を思い出してもらう | ログの場所やシステム構成を確認する |
| 新しい内容を提示する | 障害対応の流れを説明する |
| 学習の手がかりを与える | 判断基準や確認用チェックシートを示す |
| 実際にやってもらう | 障害シナリオを使って調査してもらう |
| フィードバックする | 調査方法や共有内容について伝える |
| 習得度を確認する | 別のシナリオを一人で対応してもらう |
| 定着と応用を促す | 実案件で使える手順書に反映してもらう |
これまでの自分の説明を振り返ると、「新しい内容を提示する」ことに偏りがちだった。
説明したあとに、理解できたかを質問するだけでは、実際にできるようになったかは分からない。
相手に手を動かしてもらい、その結果にフィードバックし、別の状況でも使えるかを確認するところまでが育成になる。
教えたことと、相手ができるようになったことは別だと意識したい。
チャンキングで情報を理解しやすい単位に分ける
障害対応について一度に説明しようとすると、監視、ログ調査、データ確認、影響範囲、暫定対応、関係者連絡、恒久対応、振り返りなど、多くの情報が登場する。
教える側には関連性が見えていても、初めて学ぶ側には、それぞれが独立した情報に見える。
チャンキングは、複数の情報を意味のあるまとまりとして扱う考え方。
情報をまとめることで、ワーキングメモリにかかる負荷を減らせることが研究されている。
障害対応であれば、すべての手順を並べるのではなく、次のようなまとまりで捉えられる。
- 事象を受け付ける
- 影響と原因を調べる
- サービスを復旧させる
- 原因を振り返り、再発を防ぐ
まず全体を4つのまとまりとして伝え、その後に各まとまりの詳細を説明する。
これは研修だけでなく、設計書、プルリクエスト、会議資料にも使える。
情報を減らすことだけが分かりやすさではない。
情報同士の関係を示し、理解できる単位にまとめることも必要になる。
ただし、チャンキングは単に項目をグループ分けすることではない。
学ぶ側が「なぜ同じまとまりなのか」を理解できなければ、見出しが増えただけになる。
チャンキングもっと詳しく
チャンキングは、簡単に言うと、バラバラの情報を、意味のあるまとまりにして覚えやすくすること。
エンジニアの業務でも同じで、障害対応の手順をいきなり細かく並べると、学ぶ側は一つひとつを別々に覚えなければならない。
- 問い合わせ内容を確認する
- 発生時刻を確認する
- 対象ユーザーを確認する
- 再現する
- ログを確認する
- DBを確認する
- 影響範囲を調べる
- 暫定対応を考える
- 関係者に共有する
これをそのまま覚えるのは大変だが、次のようにまとめると理解しやすくなる。
- 事象を整理する
- 原因と影響を調べる
- 対応方針を決める
- 関係者に共有する
「事象を整理する」というまとまりの中に、発生時刻や対象ユーザー、再現条件の確認が含まれる。
「原因と影響を調べる」というまとまりの中に、ログやDBの確認が含まれる。
つまり、チャンキングは単に情報を短くしたり、適当な数で区切ったりすることではない。
細かい情報に共通する意味や目的を見つけ、上位の概念としてまとめることが重要になる。
イメージとしては、受け手の頭の中に「情報を入れる棚」を先に作るようなもの。
「ログを確認してください」「DBを確認してください」と個別に説明する前に、「ここからは原因を調べる段階」と伝える。
すると、学ぶ側は新しい情報を「原因調査」という棚に入れられる。
逆に、次のような分け方は、見た目は整理されていてもチャンキングとしては弱い。
- 手順1〜3
- 手順4〜6
- 手順7〜9
なぜ同じまとまりなのか分からないためである。
「受付」「調査」「復旧」「振り返り」のように、それぞれのまとまりに意味を持たせる必要がある。
次の順番で考えると使いやすい。
- まず細かい情報をすべて出す
- 同じ目的を持つ情報を集める
- そのまとまりに「何をする段階なのか」が分かる名前を付ける
チャンキングとは、情報を減らす技術というより、情報同士の関係を示し、全体像をつかみやすくする技術だと考えると分かりやすい。
GROWモデルで答えを渡す前に考えを引き出す
メンバーから「この障害はどう対応すればいいか」と相談されたとき、すぐに答えを伝えたほうが早い。
緊急度が高い状況では、指示が必要なこともある。
一方で、毎回答えを渡していると、メンバーはマネージャーの判断を待つようになる。
GROWモデルは、Goal、Reality、Options、Willの流れで対話を進めるコーチングの枠組みである。
目標を明確にし、現状を捉え、選択肢を広げ、次の行動を決めるために使われる。
障害対応後の1on1であれば、次のように問いかける。
今回、どこまで一人で対応できる状態を目指していた？
実際には、どの場面で判断に迷った？
同じ状況が起きたら、どのような選択肢がありそう？
次回に向けて、まず何を準備する？
重要なのは、GROWの順番どおりに質問することではない。
相手が自分で状況を捉え、次の行動を決めることに意味がある。
質問しながら、マネージャーが期待する答えへ誘導してしまうこともある。
「どうしたらいいと思う？」と聞きながら、実際には正解を当てさせようとしていないか注意したい。
また、知識や経験が不足している相手に、質問だけを続けても答えは出ない。
その場合は、必要な情報や選択肢を渡すティーチングと組み合わせる必要がある。
GROWモデルをもう少し解説
GROWモデルは、相手にすぐ答えを教えるのではなく、「どうなりたいか」「今どうなっているか」「何ができそうか」「実際に何をするか」を順番に整理し、相手自身が次の行動を決められるようにする対話の進め方。
たとえば、メンバーから「障害対応を一人でできるようになりたい」と相談された場合を考える。
最初のGoalでは、目指す状態を確認する。
どこまで一人で対応できるようになりたい？
今回の振り返りで、何を決めたい？
次のRealityでは、現在の状況や困っていることを整理する。
今回はどこまで自分で進められた？
どの場面で判断に迷った？
何が分かっていれば進められそうだった？
その後のOptionsでは、解決方法を一つに決めつけず、取り得る選択肢を考える。
次回に備えて、どんな準備ができそう？
過去の障害対応を確認する以外に、何ができそう？
チェックリストを作る方法は使えそう？
最後のWillでは、考えた選択肢の中から、実際に行うことを決める。
まず何から始める？
いつまでにやる？
次回の障害対応で、どこまで自分で担当する？
つまり、流れを簡単にすると、
目標を決める → 現状との差を知る → 解決方法を考える → 次の行動を決める
となる。
特に分かりにくいのがWillで、「やる気」だけを確認する段階ではない。
考えた選択肢を、いつ、何を、どこまで実行するかという具体的な行動に変える段階である。
GROWモデルの目的は、マネージャーが正解へ誘導することではなく、相手の頭の中にある目標や課題、選択肢を整理し、本人が納得して行動を選べるようにすること。
したがって、質問を順番どおりに読み上げることよりも、相手が「自分は次に何をするのか」まで整理できたかが重要になる。
ジョハリの窓で認識のズレを捉える
本人は「関係者に十分共有した」と考えているが、周囲は「状況が分からなかった」と感じていることがある。
このようなズレを考えるときに、ジョハリの窓が使える。
ジョハリの窓では、自分に見えているか、他者に見えているかによって、自己認識を4つの領域に分ける。
| 領域 | 状態 |
|---|---|
| 開放の窓 | 自分も他者も知っている |
| 盲点の窓 | 他者は知っているが、自分は知らない |
| 秘密の窓 | 自分は知っているが、他者は知らない |
| 未知の窓 | 自分も他者も知らない |
自己開示とフィードバックを通じて、自分と他者の双方が認識している領域を広げる考え方である。
障害対応を振り返るとき、最初から評価を伝えるのではなく、本人の認識を確認する。
自分では、今回の共有はどの程度できていたと思う？
本人が十分できていたと考えているにもかかわらず、周囲は情報不足だと感じているなら、そこには盲点がある。
一方で、「状況が整理できていなかったが、混乱していると思われたくなくて相談できなかった」という事情は、本人だけが知っている秘密の領域にあたる。
行動だけを見て「共有する意識が足りない」と決めつけると、この背景を見落とす。
ただし、ジョハリの窓を理由に、個人的な事情や感情の開示を強制してはいけない。
仕事上必要な範囲で認識を共有し、相互理解を深めるために使うものだと考えている。
SBIで行動に対してフィードバックする
フィードバックでは、「もっと主体的に動いてほしい」「共有が遅い」「説明が分かりにくい」といった表現を使ってしまうことがある。
しかし、これらは評価する側の解釈であり、相手が次に何を変えればいいのか分かりにくい。
SBIは、Situation、Behavior、Impactの順にフィードバックを組み立てる方法である。
Situationでは具体的な場面を示し、Behaviorでは観察できた行動を伝え、Impactではその行動が周囲や業務に与えた影響を説明する。
たとえば、次のように伝える。
昨日の決済機能の障害対応で、最初の調査結果を共有した場面で、確認したログと発生条件を整理して投稿していた。
ほかのメンバーが重複して調査せずに済み、原因の特定を早められた。
改善点を伝える場合も同じである。
昨日の障害対応で、影響範囲を確認する前に「一部のユーザーだけの問題」と共有していた。
その情報を前提に対応方針を決めかけたため、判断をやり直す必要が生じた。
「判断が雑だった」と人格や能力を評価するのではなく、何が起き、どの行動が、どのような影響を与えたのかを伝える。
SBIを使ったあとに、GROWモデルの問いかけを加える方法も使いやすい。
このときは、どのような意図で判断した？
次回、影響範囲を判断するために何を確認する？
SBIで事実と影響を共有し、GROWで背景と次の行動を一緒に考える。フィードバックを一方的な指摘で終わらせず、次の成長につなげられる。
6つのフレームワークを一連の流れで使う
今回取り上げた6つは、独立した知識ではなく、一連の育成の中で組み合わせられる。
まずADDIEモデルを使い、現在の課題と育成後の目標を整理する。
次に、ガニェの9教授事象を使って研修や演習の流れを作り、チャンキングによって伝える情報を理解しやすい単位に分ける。
実践後の1on1では、GROWモデルを使って本人の振り返りと次の行動を引き出す。
自分と周囲の認識にズレがある場合は、ジョハリの窓を使って盲点や共有されていない事情を捉える。
具体的な行動を伝えるときはSBIを使い、事実と影響を分けてフィードバックする。
このように整理すると、それぞれの役割が見えてくる。
- ADDIEは育成全体を設計する
- ガニェの9教授事象は学習体験を設計する
- チャンキングは情報の伝え方を整える
- GROWは本人の思考を支援する
- ジョハリの窓は認識のズレを捉える
- SBIは行動と影響を具体的に伝える
フレームワークを使うこと自体を目的にしない
フレームワークを学ぶと、すべての場面に当てはめたくなる。
しかし、緊急対応中にGROWモデルの質問を繰り返せば、対応が遅れる。
知識がないメンバーに考えさせ続ければ、単に困らせてしまう。
SBIの形式を守ることに集中しすぎると、機械的な会話になる。
フレームワークは、相手を型にはめるものではない。
自分の考え方や伝え方に抜け漏れがないか確認するための補助線となるものである。
状況によって、指示する、教える、一緒に考える、任せるという関わり方を変える必要がある。
「このフレームワークを使ったか」ではなく、「相手が理解し、考え、次の行動を選べたか」で振り返りたい。
まとめ
これまで自分は、相手に伝えたことで「教えた」と考えたり、早く解決するために答えを渡しすぎたりすることがありました。
今後は、説明することではなく、相手ができるようになることを育成の完了条件にして、すぐに答えを伝える前に、相手がどこまで考え、何に迷っているのかを確認するようにします。
フレームワークを知識として覚えるだけで終わらせず、日々の1on1、業務説明、レビュー、フィードバックの中で使いながら、自分なりのマネジメントの形を作っていきます。