“実践”システム障害対応：4週目：結果の見える化・振り返り

12週にわたり「”実践”システム障害対応」と題して、システム障害対応の改善のプロセスを約3か月で実行できるように、各週ごとに何を実践すればよいか？を考えていきたいと思います。

3週目では、「事前に何を目指すか？」を明確にすることで、テスト運用で想定の効果が出そうか、改善するためには「どこを目指せばよいか？」がわかりやすくなるため、「結果目標」と「アクション目標」を持てると一番良いと、お話させていただきました。

4週目は、結果目標・アクション目標の「結果の見えるか・振り返り」について考えていきましょう。

テスト運用結果「見える化、振り返り」プロセスイメージ

3週目をもとに、結果目標・アクション目標を定めたと思います。
今週お話する「結果の見える化・振り返り」について、プロセスイメージは以下のよう形です。
「見える化」→「振り返り」→「アクション検討/実施」という流れで記載していきます。

「見える化（測定）」

結果目標・アクション目標はどうだったか？

結果目標やアクション目標が実際にどうだったかを純粋に見てみましょう。
「目標を超えた or 超えない」も、もちろん重要ですが是非詳細を確認していきましょう。
もう少し具体的に言うと、いくつかの切り口で層別に見てどうだったかを見ていきましょう。

確認観点：

• 人によって目標上回り、下回りがないかのばらつきがないか？
• チームによって目標上回り、下回りがないかのばらつきがないか？
• 日によってばらつきがないか？
• 時間帯によってばらつきがないか？

などなど…

結果目標、アクション目標それぞれを見て事実の把握に努めましょう。
事実として悪い部分が明確に見えてしまうかもしれません。ですがそれでもいいんです。
事実が見えないと改善はできません。
見える化する事で振り返りに活かせるようにしましょう。

「振り返り」（課題出し）

最初に約束するべきこと

まずはじめに大事な事として、批判しない・責めない事を約束しましょう。
「心理的安全性 （組織の中で自分の考えや気持ちを誰に対してでも安心して発言できる状態）」 が流行ってきております。
人は基本、自分の事が可愛く守りたいという心理が働くため、悪かったとしても「成果が出ました！」という形にもっていきがちな所もあると思います。
ですが目的はチームとしての成功（チームとしての目標を達成することであり）、チームとして悪いことは悪いと認めましょう。
次のステージに進むかを判断するために振り返りの参加者は「批判しない・責めない」逆に言うと「批判されない、責められない」というルールや文化、環境作りはとても大事だと思います。

振り返りのやり方

振り返りのフレームワークとして世の中で以下のようなものありますが、関係したメンバーが参加しやすく理解しやすい手法で、実施いただければと思います。
どんなフレームワークにせよ、うまくいった事はチームとして喜び、継続し続ける事を意識し、悪かった事は課題として、今後改善すべき内容として認識できるかと思います。

課題・リスクは何か？

実際にやってみると今まで気づけなかったものが気づけるかと思います。
例えば、以下のような事がわかってきます。

• アクションは進んだけど、結果が出なかった。
• 稼働が多くかかってしまった。
• 忙しくてできなかった。
• 説明したつもりが進まなかった。

などなど…

是非、関係者全員にアウトプットしていただき、関係者でディスカッション、その後、体系的にまとめていきましょう。
各メンバーが普段実施している主な業務以外の片手間として、このテスト運用をやっているのであれば、「忙しかった」「稼働がかかった」などあった場合でも、責める事はしないでください。

「振り返り」（分析）

結果目標・アクション目標は正しかったか？

人によって目標設定の仕方は性格も出る事もあり、難しいものです。
積極的な人であれば高めに設定する、保守的な方だと低めに設定するかと思います。
目標どおりできた事実、成功体験の積み重ねで目標値を少しずつ上げていくやり方もあれば、しっかり頑張らないと達成できない高めの目標を設定して行動を促すやり方など様々です。

経験としては、目標達成ができないと「なんでできなかったの？」と批判・責められる環境だと、「達成できる目標」に修正しがちです。
結果目標、アクション目標の値が「高すぎたよ…」というのはよくありますが、正しさを見直す必要はあります。「高すぎたから下げよう」となりがちですが、これは要注意です。
本来この目標や課題は「どんな意義があるのか？目的はなんだったのか」を思い出しましょう。

システム障害発生時に、お客様の業務影響を与えないようにするためには？と考えると
xx分以内に調査/連絡しなければならないから、それならばこの結果目標にしよう。
この限られた人員でやりきるためには、この結果目標にしようなどです。

観点としての例を記載します。

• この課題解決する目的は何か？
• アクション目標値を実行するための期間や期限は現実的だったのか？
• アクション目標の実行優先度は、他業務と比べてどのくらい高いのか？
  （優先度が高いなら、他業務をどの程度、捨てるのか？）

スケジュールがあると、予実ギャップを見る事で「予定通り進めている」という判断になるのと同じで、事前に結果目標やアクション目標を決めておけばギャップが見えてより良い判断ができるはずです。

結果目標・アクション目標と実績の関係性はどうか？

もう１つ忘れがちなのが、結果目標を達成するためのアクション目標が妥当だったか？という関係性の観点です。
アクション目標を達成していても、結果目標が達成できない事があるかもしれません。
実は、結果目標とアクション目標の関係性が薄かったという事実がわかるかもしれません。その場合シンプルにアクション目標を変えればよいのです。

観点としての例を記載します。

• 結果目標を達成すれば、課題解決ができる事につながっているか？（関係性の再確認）
• アクション目標を達成すれば、結果目標が本当に向上するか？（関係性の再確認）
• 結果目標に到達するためのアクション目標数値は足りているか？多すぎないか？（アクション目標値の妥当性）
• 他により良いアクション目標は無いか？

「アクション検討/実施」

課題・リスクで出たものをどう対処をするか？

最後に課題・リスクで出たものをどのようにアクションを取るかを是非考えましょう。
全部を対処する必要はありません。

• サービスとして、お客様にとって、チームとして価値があるものはどれか？
• お客様や利用者に影響を与えてしまうようなクリティカルに危険なものがないか？
• 他により良いアクション目標は無いか？出たアクション内容に変更して試すべきか？

目的を忘れず、優先度を検討し、「本当に進めてよいか？」は慎重に決めましょう。

ここまで、ご覧いただきありがとうございました。