🎯 対象読者
- チームの問題や課題に対して、効果的に対処したいマネージャー
- 突発的なトラブルにも冷静に対応できるスキルを身につけたいリーダー
🛑 よくある課題
- 「問題が発生するたびに場当たり的な対応をしてしまう」
- 「原因を特定しないまま対処し、同じ問題が繰り返される」
- 「トラブル発生時に、チームが混乱してしまう」
マネージャーにとって、問題解決とトラブルシューティングは避けて通れないスキルです。トラブルが発生したとき、場当たり的な対応では同じ問題が繰り返されます。本記事では、トラブル対応の初動から根本原因の分析、再発防止策の実行まで、マネージャーが押さえるべきポイントを体系的に解説します。
📖 ケーススタディ：本番障害で3時間を無駄にした夜
金曜日の夜21時、監視アラートが一斉に鳴りました。ECサイトの決済処理が全面停止したのです。私はマネージャーとして即座にチームを召集しました。しかし、この時点で大きな失敗をしていました。「とにかくサーバーを再起動しろ」と指示を出してしまったのです。
再起動で一時的に復旧しましたが、15分後に同じ障害が再発しました。原因を特定しないまま対処した結果です。結局、データベースのコネクションプール枯渇が根本原因だと判明するまでに3時間かかりました。冷静にログを確認していれば、30分で特定できた内容です。
この経験から、場当たり的な復旧指示がいかに現場を混乱させるかを痛感しました。以降、障害対応の手順書を整備し、「まず状況を把握してから動く」ことをチームの原則にしました。ここからは、その過程で学んだトラブル対応の具体的な方法を説明します。
📌 1. トラブル対応の初動で重要な3つのポイント
以下のフローチャートは、トラブル発生時の初動対応の流れを示したものです。
トラブルが発生した際、マネージャーの役割は混乱を最小限に抑えつつ、迅速かつ適切な対応を指示することです。初動対応が遅れると被害が拡大し、解決までの時間も長くなります。初動では「状況把握と情報収集」「影響範囲の特定」「適切な判断と優先順位付け」の3点を意識します。
🔹 ① 状況把握と情報収集
トラブル発生時にまずやるべきことは、現状を正しく把握し、事実ベースの情報を収集することです。間違った情報をもとに行動すると、誤った判断を下すリスクが高まります。
事象の正確な把握として、次の情報を早く正確に集めます。
- 何が起こっているのか（トラブルの具体的な内容）
- いつ発生したのか（発生時刻と経過時間）
- どこで発生したのか（影響範囲）
- どのように発覚したのか（最初に気づいた人）
この段階では、憶測や感情に左右されず、客観的な事実のみを整理します。たとえば、システム障害の場合、「サーバーが落ちた」ではなく「サーバーAで◯時◯分にCPU使用率が100%に達し、応答がなくなった」という具体的な記録が必要です。
情報の収集は、主に以下の手段で行います。
- 直接観察：現場で何が起きているかを目視・確認する
- ログやデータの確認：システム障害であればログファイルや監視ツールをチェックする
- 関係者からのヒアリング：問題を発見した人、影響を受けている人、技術担当者から聞き取りを行う
- ドキュメントの確認：マニュアルや過去の類似事例を参照する
情報を偏りなく収集することが重要です。技術チームだけでなく、営業やカスタマーサポートなど他部門にもヒアリングし、顧客への影響も考慮します。
事実と推測を分けることも欠かせません。「〜だと思う」「〜だったはず」という曖昧な情報を防ぐため、次のように整理します。
- 事実（Fact）：「本日10:15にAサーバーのCPUが100%になり、10:20にシステムがダウンした」
- 推測（Assumption）：「Aサーバーに負荷の高いバッチ処理が走った可能性がある」
初動対応では「確認された事実のみ」をもとに判断し、推測に基づく行動は慎重に進めます。
🔹 ② 影響範囲の特定
次に重要なのが、トラブルがどこまで影響を及ぼしているのかを把握することです。影響範囲の特定が曖昧だと、必要な対応が遅れたり、関係者への連絡が適切に行われません。
直接的な影響として、以下を整理します。
- 影響を受ける顧客：どの顧客が影響を受けているか。クレームや契約違反の可能性はあるか
- 影響を受ける社内部門：どの部署が業務に支障をきたしているか
- 影響を受けるシステムやプロセス：他のシステムへの連鎖的な影響はあるか
たとえば、ECサイトの決済システムがダウンした場合、「決済ができない顧客」「カスタマーサポートへの問い合わせ増加」「財務部門の処理停止」など、多方面への影響が発生します。
潜在的な影響も考慮する必要があります。
- トラブルが長引くと、どのような二次被害が発生するか
- 信用問題につながる可能性はあるか
- この問題が別のトラブルを引き起こすことはないか
障害発生により顧客からの注文が滞った場合、後日一斉に処理が走り、別のシステムに負荷が集中する可能性もあります。今後のリスクも見越した対応が求められます。
🔹 ③ 適切な判断と優先順位付け
状況把握と影響範囲の特定ができたら、「何を最優先で対応するか」を決定します。感情的な判断は効果的な対処を妨げ、問題が長引く原因になります。
対応の優先順位を決める基準は以下のとおりです。
- 生命や安全に関わる問題か：人命に関わる問題は最優先で対処する
- 事業への影響度：顧客対応、売上、業務継続性に大きく関わる問題は優先度が高い
- 時間的な制約：今すぐ対応しないと悪化する問題は迅速に対応する
- リカバリーの難易度：簡単に修正できる問題はすぐに対応し、大規模な修正は段階的に進める
たとえば、システム障害の場合、「一時的な迂回策で業務を継続できるならそれを優先」「完全復旧に時間がかかるなら根本対応は後回し」という戦略が求められます。
緊急対応チームの編成も重要です。問題の規模が大きい場合、適切なメンバーを選定し、役割を明確にします。
- リーダー（意思決定者）
- 技術担当（問題分析・復旧対応）
- 関係者対応（顧客・社内調整）
初動でチーム編成を素早く行い、それぞれの役割を明確にすると混乱を防げます。
これら3つのポイントを実行することで、トラブル対応の精度が向上し、組織全体の対応力も強化されます。
📌 2. 再発防止につなげる問題解決の3ステップ
初動対応が完了し、一時的な問題を解決した後に重要なのは、同じ問題が二度と発生しないようにすることです。多くの組織では問題が解決した時点で安心してしまい、根本的な原因の追及や再発防止策がおろそかになりがちです。再発防止を怠ると同じ問題が繰り返し発生し、組織全体の生産性が低下します。
再発防止には「問題の正しい定義」「根本原因の特定」「再発防止策の実行」の3つのステップが必要です。
🔹 ① 問題を正しく定義する
問題を正しく定義できなければ、適切な再発防止策は講じられません。表面的な症状を「問題」と捉えるのではなく、根底にある「本当の課題」を明らかにすることが重要です。
「問題」と「症状」を区別する必要があります。多くの人は目の前のトラブルの症状を問題として捉えてしまいますが、症状は問題の結果であり、真の課題ではありません。
- 症状（目に見える問題）：「システムの応答速度が遅くなり、ユーザーからのクレームが増えている」
- 真の問題：「データベースの設計が最適化されておらず、ピーク時の負荷に耐えられない」
表面的な事象に惑わされず、問題の本質を見極めることが重要です。
SMARTな問題定義も有効です。SMARTの原則を活用すると、具体的かつ実行可能な形に落とし込めます。
- Specific（具体的）：どのシステムのどの機能で問題が発生しているか
- Measurable（測定可能）：パフォーマンスの低下率は何％か。影響を受けたユーザー数は
- Achievable（実現可能）：改善のための技術的な手段はあるか
- Relevant（適切）：この問題は本当に業務に影響を与えているか
- Time-bound（期限明確）：いつまでに問題を解決する必要があるか
たとえば「システムの応答速度が遅い」をSMARTに定義すると、「ピーク時のデータベース処理時間が5秒を超えることで、月間100件以上のユーザークレームが発生している。来月末までに応答速度を2秒以内に改善する」となります。具体的な数値や期限を設定することで、解決策を立案しやすくなります。
🔹 ② 根本原因を分析する
問題を定義したら、次は「なぜこの問題が発生したのか」を分析します。原因の特定を個人のミスや単発の出来事で終わらせず、組織やシステムの構造的な問題を洗い出すことが重要です。
なぜなぜ分析（5 Whys）は、問題の真因を探るために有効な手法です。「なぜ？」を5回繰り返して根本的な課題を明らかにします。
たとえば「システムの応答速度が遅い」場合は以下のとおりです。
- なぜ？ → クエリの処理時間が長いため
- なぜ？ → データベースのインデックスが適切に設定されていないため
- なぜ？ → 過去のシステム拡張時にインデックス最適化が実施されなかったため
- なぜ？ → 拡張時の設計プロセスにパフォーマンス評価が含まれていなかったため
- なぜ？ → システム開発時のガイドラインが不十分だったため
原因を掘り下げることで、「インデックスの設定ミス」だけでなく「開発プロセスの問題」「ガイドラインの不足」など、根本的な対策を検討する視点を得られます。
ロジックツリーも有効です。問題が複雑な場合、原因を構造的に整理できます。
- 「技術的な要因」「人的要因」「プロセス上の問題」などの軸で分類する
- 原因を可視化することで対応策の抜け漏れを防ぐ
🔹 ③ 再発防止策を実行する
根本原因を特定したら、具体的な再発防止策を講じます。単なる対処療法ではなく、組織としての仕組みを改善することが重要です。
再発防止策は、大きく3つのカテゴリに分けて考えます。
- 技術的対策：システムの改修、自動化ツールの導入、監視・アラートの強化
- 人的対策：マニュアルの改訂、トレーニング・教育の実施、責任分担の明確化
- プロセス改善：業務フローの見直し、レビュー・チェックプロセスの強化、定期的な検証とフィードバックの仕組みづくり
たとえば、システム障害が発生した場合、「担当者の確認ミス」で終わらせず、「チェック体制を強化し二重チェックを義務化する」「監視機能を強化する」などの具体的な対策を講じます。
効果検証を行い、改善を続けることも欠かせません。
- 施策実施後にKPIを設定し、効果測定を行う
- 定期的にトラブルレビューを実施し、新たな問題を洗い出す
- 継続的な改善の仕組みをつくる
問題解決を単発のイベントではなく、組織の改善活動として継続することが重要です。
📌 3. 根本原因を見極める分析手法
トラブル対応で最も難しいのが「根本原因の特定」です。多くのマネージャーは問題が表面化した際に、目に見える症状だけを解決して終わりにしがちですが、それでは同じ問題が繰り返されるリスクがあります。
効果的な問題解決には、再現性のある論理的なアプローチが必要です。ここでは「なぜなぜ分析（5 Whys）」「ロジックツリー」「MECE」の3つの手法を説明します。
🔹 ① なぜなぜ分析（5 Whys）
「なぜなぜ分析」は、問題の真の原因を特定するために「なぜ？」を繰り返して問う手法です。シンプルで実践しやすく、トラブル発生時の初動でも活用できます。
手順は以下のとおりです。
- 現象を明確に定義する（例：「顧客からのクレームが増加している」）
- 最初の「なぜ？」を問う：なぜクレームが増えているのか → 製品の動作が不安定になっているから
- 次の「なぜ？」を問う：なぜ動作が不安定か → ソフトウェアのアップデート後に不具合が発生したから
- さらに「なぜ？」を続ける：なぜ不具合が発生したか → テストが不十分だったから
- 真因にたどり着く：なぜテストが不十分か → 納期が厳しく十分なテストが実施できなかったから（開発プロセスの問題が根本原因）
活用ポイントは次のとおりです。
- 「なぜ？」の回数は5回が目安だが、3回や7回でもよい
- 表面的な原因で止めず、組織的な問題や業務プロセスの問題に行き着くまで掘り下げる
- 「個人のミス」に原因を帰結させない。仕組みの問題を特定する
🔹 ② ロジックツリー
ロジックツリーは、問題の全体像を俯瞰し、体系的に原因を分析する手法です。なぜなぜ分析と異なり、一つの問題に対して複数の可能性を同時に検討できる点が特徴です。複雑な問題の原因を明確に整理でき、チームで共通認識を持つ際にも役立ちます。
手順は以下のとおりです。
- 問題を定義する（例：「売上が低迷している」）
- 主要な要因を大枠で分類する（「外部要因」と「内部要因」に分ける）
- 各要因をさらに細分化する（「内部要因」→「商品力の低下」「マーケティング不足」「営業力の低下」）
- 具体的な問題点を特定する（「マーケティング不足」→「広告投資が減った」「SNS戦略が不十分」）
活用ポイントは次のとおりです。
- 要因を細かく分解し、どこに問題があるのか可視化する
- MECEの原則を意識し、分類が重複しないようにする
- チームで議論しながら作成すると、多面的な視点を取り入れられる
🔹 ③ MECE（モレなくダブりなく）
MECE（Mutually Exclusive, Collectively Exhaustive）は、「モレなくダブりなく」問題を整理するための原則です。ロジックツリーを作成する際にも活用でき、分析の抜け漏れを防ぎます。
たとえば「業務改善の課題」を考える場合、MECEの原則を適用すると以下のようになります。
NG例（MECEになっていない）：「業務の効率化」「ミス削減」「チームワーク強化」→「業務の効率化」と「ミス削減」が重複する可能性があり、「チームワーク強化」は曖昧です。
OK例（MECEになっている）：「プロセス改善」「ITツール導入」「組織の最適化」→ 明確な切り口で分類され、重複がありません。
活用ポイントは次のとおりです。
- MECEを意識すると、問題の抜け漏れが防げる
- 「どの視点で分類するか」を明確にする
- ロジックツリーと組み合わせると効果的
📌 4. マネージャーがやりがちな間違い
トラブル対応でマネージャーの判断はチームの方向性を大きく左右します。適切な対応ができればスムーズに解決へ導けますが、誤った対応は問題を長引かせる原因になりかねません。ここでは、マネージャーが陥りがちな4つの間違いを説明します。
🔹 ①「場当たり的に対応する」
応急処置ばかりで根本的な解決にならないパターンです。
ありがちな状況として、トラブルが発生すると「とにかく止血しよう」と考え、目先の対応に追われます。「とりあえず○○をやって！」と即断即決し、顧客や上司に早急に対応策を示そうとして根本原因の追及を後回しにします。
再発防止策を考える時間が確保されず、同じ問題が繰り返し発生します。「その場しのぎの対策」が常態化すると、チームが長期的な視点で問題解決する力を失います。
失敗例：サーバーがダウンし「急いで再起動しろ！」と指示。しかし実際にはリソース不足が原因で、再起動してもすぐに落ちます。根本的な原因分析をしないまま場当たり的な対応を繰り返し、業務停止時間が長引きました。
🔹 ②「原因を個人のせいにする」
本質的な問題を見落とし、組織としての改善が進まないパターンです。
ありがちな状況として、「誰のミスか？」を最初に特定しようとします。「○○さんが仕様を間違えたからだ」と個人の責任追及が優先され、チーム全体の振り返りより「犯人探し」が先行します。
個人のミスに帰結させると根本的な改善につながりません。チーム内に責任転嫁の文化が生まれ、心理的安全性が損なわれます。プロセスや仕組みの改善が進まないため、同じ問題が繰り返されます。
失敗例：システム障害が発生し「○○くんがコードをミスしたからだ」と指摘。しかし実際にはコードレビューのプロセスが不十分だったことが真の原因でした。個人を責めるだけで改善が進まず、別のエンジニアが同じミスをしました。
🔹 ③「対策を実行しっぱなしで検証しない」
実際に効果があったかを確認せず、同じミスを繰り返すパターンです。
ありがちな状況として、とりあえず改善策を決めて実行します。「今回はこうやって対応したから、次は問題ないはず」と楽観し、改善策が有効だったか検証せず形だけの対策に終わります。
効果を確認しないと根本的な解決になりません。間違った対策を続けても同じ問題が発生し続けます。「対策を決めたことで安心してしまう」という心理的な落とし穴があります。
失敗例：情報漏洩が発生し「今後は二重チェックを義務化しよう」と決定。しかし実際にはチェックフローが形骸化し、担当者が形だけの確認を行うようになり、別の情報漏洩が発生しました。
🔹 ④「すぐに新しいツールやシステムに頼る」
問題の本質を考えず、ツール導入で解決しようとするパターンです。
ありがちな状況として、「このツールを導入すれば解決するはず」と考えがちです。問題が発生するたびに「ツールを変えればいい」と判断し、既存プロセスの見直しを後回しにします。本当の問題を分析せず、ツール導入を「解決策」として扱ってしまうのです。
ツールやシステムは「手段」であり「目的」ではありません。根本的な業務の問題や人的な課題が解決しない限り、新しいツールを入れても同じ問題が繰り返されます。チームが新しいツールに適応するコストだけが増えます。
失敗例：「業務の抜け漏れを防ぐために新しいタスク管理ツールを導入しよう」と決めたが、結局誰も使いこなせずタスク管理の課題は解決しませんでした。
これらの間違いを避け、本質的な問題解決に取り組む姿勢が、優れたマネージャーの条件です。
📌 5. トラブル時にチームを動かすマネージャーの役割
トラブル発生時、マネージャーの役割はチームを迅速かつ適切に動かし、混乱を最小限に抑えながら解決へ導くことです。マネージャーの振る舞いによってチームの士気や対応速度が大きく左右されるため、適切なリーダーシップが求められます。
トラブル対応時に果たすべき役割は以下の5つです。
- 指示をシンプルにする
- メンバーに役割を与える
- 冷静に状況を整理する
- 情報共有と意思決定を適切に行う
- チームの士気を維持し、心理的安全性を確保する
🔹 ① 指示をシンプルにする
トラブル発生時、チームメンバーは動揺し、何をすべきか判断できなくなりがちです。マネージャーはシンプルで明確な指示を出し、迷いを排除することが求められます。
適切な指示には以下の3要素が必要です。
- 「何を」（対応内容）：「ログを確認して、エラーメッセージを収集してほしい」
- 「誰が」（担当者）：「Aさんはシステムログの分析、Bさんは影響範囲の確認を担当」
- 「いつまでに」（期限）：「30分以内に初期分析を終えて報告してください」
曖昧な表現を避け、具体的なアクションを指示します。
- NG例：「誰か、ログを調べてくれ」
- OK例：「Aさん、過去1時間のエラーログを取得し、10分後に報告してください」
指示が抽象的だとメンバーが迷い、対応の遅れにつながります。短時間で実行可能な具体的なタスクとして伝えます。
🔹 ② メンバーに役割を与える
トラブル対応では複数のタスクを同時並行で進めるため、メンバーに適切な役割を与え、責任の所在を明確にすることが欠かせません。
以下のような役割を設定するとスムーズです。
| 役割 | 主な担当 |
|---|---|
| 指揮官（マネージャー） | 全体の指揮、意思決定、対外報告 |
| 技術担当（エンジニア） | 原因調査、復旧対応 |
| 影響評価担当 | 影響範囲の特定、ビジネス影響の評価 |
| 関係者対応担当 | 顧客・上層部・他部門への報告 |
| ドキュメント担当 | トラブル対応の記録、振り返り用のレポート作成 |
各メンバーに明確な役割を与えることで、「誰が何をやるべきか分からない」という混乱を防げます。
「全員で対応しよう」という指示は、かえって情報が錯綜し効率が悪化します。役割を明確にした上で適材適所に配置します。
- NG例：「みんなでとにかく情報を集めよう」
- OK例：「Aさんはサーバーの状態を調べて、Bさんは影響範囲を確認してください」
🔹 ③ 冷静に状況を整理する
マネージャーが動揺するとチーム全体がパニックになり、適切な対応ができなくなります。どんな状況でも冷静に事実に基づいて判断することが重要です。
トラブル発生時には以下の3点を整理します。
- 何が起きているか（事実の確認）：「システムAが14:30からダウンしている」
- 影響はどこまで広がっているか（影響範囲）：「ユーザーBとCの決済処理に影響」
- 今すぐにできることは何か（初動対応）：「関連するサーバーの負荷を下げる」
事実を整理することで、感情に流されず的確な対応を指示できます。
🔹 ④ 情報共有と意思決定を適切に行う
トラブル時には関係者への情報共有と適切な意思決定が欠かせません。情報が共有されないと、対応が遅れたり二重対応が発生します。
- 報告は定期的に行う（例：30分ごとに状況アップデート）
- 「誰に」「何を」伝えるかを明確にする（社内と顧客で報告内容を分ける）
- 事実と推測を分けて伝える（誤情報を流さない）
🔹 ⑤ チームの士気を維持し、心理的安全性を確保する
トラブル対応ではチームメンバーがストレスを感じやすくなります。マネージャーが適切にサポートしないと、士気が低下し対応ミスが増える可能性があります。
以下のような声かけが有効です。
- 「今できることに集中しよう」
- 「焦らず、落ち着いて対応しよう」
- 「この経験を次に活かそう」
安心感を与える声かけにより、チームの心理的安全性を保てます。
トラブル時のマネージャーの行動は、問題解決だけでなくチームの成長にも影響を与えます。適切な役割を果たすことで、組織全体の対応力を高められます。
📌 6. トラブル対応の際の心理的マネジメント
トラブル対応では、技術的な解決策と同じくらい心理的なマネジメントが重要です。トラブル時にはチームメンバーが強いストレスやプレッシャーを感じ、冷静な判断ができなくなることがあります。「焦り」「恐怖」「責任の重圧」が精神的負担となり、適切な対応が難しくなるためです。
優れたマネージャーは心理的な側面にも配慮し、チームのパニックを防ぎ、適切な精神状態を維持させる役割を果たします。
🔹 ① フレーミングを活用する
フレーミングとは、出来事の見方を意図的に変えることで心理的な負担を軽減するテクニックです。「大変なことが起きた」とネガティブに捉えるとストレスが増大しパフォーマンスが低下します。同じ状況でも「この経験は学びになる」「問題解決の力を試される機会だ」と捉え直すことで、ポジティブな姿勢を保てます。
- NG：「またトラブルが発生した、もうダメだ」
- OK：「この問題を解決すれば、今後の業務がより強固になる」
マネージャーがフレーミングを意識的に行うことで、チーム全体の心理状態を安定させられます。
🔹 ② 呼吸法で冷静さを保つ
トラブル発生時にパニックになるのは、自律神経が興奮状態に入り冷静な思考ができなくなるためです。「呼吸法」を活用した冷静さのコントロールが有効です。
- 4-7-8呼吸法：4秒吸って、7秒止めて、8秒吐く
- ボックスブリージング：4秒吸って、4秒止めて、4秒吐いて、4秒止める
マネージャーが「まず深呼吸しよう」と促すだけでも、チームの焦りを軽減できます。
🔹 ③ パニックを防ぐ言葉を使う
言葉の選び方ひとつでチームの心理状態は大きく変わります。冷静さを保つ言葉を意識的に使います。
- 「大丈夫、解決できる」（チームの不安を軽減）
- 「まずはできることからやろう」（行動を明確化）
- 「焦らず、落ち着いて」（精神的な安定を与える）
避けるべき言葉は以下のとおりです。
- 「急げ！」「やばい、終わったかもしれない」（焦りを助長する）
- 「誰のせいだ？」（責任追及が優先され、心理的安全性が低下する）
マネージャーが意識的に冷静な言葉を使うことで、チーム全体の落ち着きを取り戻せます。
🔹 ④ 責任のプレッシャーを軽減する
トラブル対応時に特定の個人に責任が集中すると、心理的負担が大きくなりミスが増える可能性があります。「チームで解決する」という意識を持たせることが大切です。
- チーム対応の体制を整える（「一緒に解決しよう」というメッセージを伝える）
- 役割分担を明確にする（「〇〇さんはこれを担当」と伝えて安心感を与える）
🔹 ⑤ 適度なユーモアを交える
マネージャーが意図的にユーモアを交えると、チームの緊張感が和らぎ冷静な対応がしやすくなります。ただし、不謹慎なジョークや無理な笑いは逆効果です。状況を見極めて適切に活用します。
🔹 ⑥ トラブル対応後のメンタルケアを行う
トラブルが解決した後、「解決したから終わり」ではなくメンバーの心理的負担を軽減するフォローアップが重要です。大きな問題が発生した場合、メンバーが疲弊している可能性が高いため、適切なケアが求められます。
- 対応したメンバーに「お疲れ様」と声をかける
- 全体で振り返りを行い、「次につながる学び」を共有する
- 心理的負担が大きかったメンバーには1on1でフォローする
「トラブル対応がチームの成長につながる」という意識が生まれれば、今後の対応の質も向上します。
トラブル対応は技術的なスキルだけでなく、心理的なマネジメントによっても大きな差が生まれます。冷静な対応を心がけ、チーム全体が適切に動ける環境を整えます。
✅ 今日の実践ワーク
- 最近のトラブルを振り返り、「なぜなぜ分析」を使って根本原因を洗い出す
- 自チームのトラブル対応手順を整理し、マニュアル化する
📝 チェックリスト
- 問題の本質を正しく定義できているか
- 応急処置だけでなく、再発防止策まで考えたか
- チームメンバー全員が対応方針を理解しているか
次回は、「「また変わるの？」を味方に変える組織変革リーダーシップ」です。
📖 関連記事
- 「「また変わるの？」を味方に変える組織変革リーダーシップ」 → 問題解決力を高めるためのマネジメント視点
- 「経営層と現場の板挟みを抜け出すステークホルダー管理術」 → トラブル時の社内調整スキル
