“実践”システム障害対応:3週目:テスト運用の準備・実施

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

2週目では、「アラート・故障申告」の分類は目的を明確にすることが大事だと、お話させていただきました。

  • 緊急度・インパクト(影響度)
    (目的)アラート・故障申告が発生した際に、対処内容や体制/担当者を決めるため
  • 「「アラート・故障申告が無い状態」に向けた段階」
    (目的)改善アクションを決めるため

特に分類の「「アラート・故障申告が無い状態」に向けた段階」は「アラートも鳴らず、故障申告も来ない」が一番良い状態」という事を忘れず意識するために必要だと、ご説明させていただきました。

3週目は、改善アクションの「テスト運用の準備・実施」について考えていきましょう。

何を目標としてテストをするか?

Panasonic  松下幸之助さんの言葉で「やってみなはれ」や、サントリー創業者  鳥井 信治郎さんの言葉で「やってみなはれ。やらなわからしまへんで」という言葉が有名ですが、
私も「まずはやってみたい」「小さく始めてみよう」という事をやりたいと思っています。

ただ、今回は1点だけどうしても事前にやってほしいことがあります。
それは「何を指標(KPI)とするか」です。

KPIは戦略でもあり、人の動かし方につながります。
そして現場の方は、見た目に引っ張られます。

一例として、皆さんが住宅販売営業の業務をしていたとします。
会社が目指すKPIは「販売戸数」となった場合、価格や利益率を気にせず、高い、安い、利益率に関係なく、とにかく数を売るスタンスで働く方向へ引っ張られると思います。
会社が目指すKPIは「利益」となった場合、販売戸数は気にせずとにかく利益率の高い住宅を探して売るスタンスを取りがちになるかと思います。
このように「何を目標とするのか?」「どこに向かっていくのか?」を決めるかが大事で、現場もその方向に引っ張られるものだと思っています。

結果目標とアクション目標

ご存知の方も多いかと思いますが、KPIも種類があります。
テスト運用をする前に、以下2つの「結果目標」と「アクション目標」をもてると一番良いと考えます。
一般的な事例としては以下のようなものになります。

「事前に何を目指すか?」を明確にすることで、テスト運用で想定の効果が出そうか、改善するためには「どこを目指せばよいか?」がわかりやすくなります。

アクション目標を決めることが重要なポイントだと思っています。
理由は、現場の若いメンバーがモチベーション高く取り組んで行く事がありますが、何を目的としているかわからず空回ってしまうことが多いと思います。
1つの原因として「結果目標しか与えられておらず、何をすれば結果が出るかがわからない」ためです。

結果につながりそうで、今日からでも若手ができるアクション目標をマネージャーが設定してあげることで行動を移しやすくなります。
結果が出なかった場合もアクションを頑張ったことをほめてあげられて、結果とアクションのつながりが無かったのは、また次で改善すればよいのです。

では実際にテスト運用をするための具体的なKPI事例を挙げて行きたいと思います。

具体的なKPI事例①「大量のアラームで不要なものが多いのを減らしたい」

「大量のアラームで不要なものが多いのを減らしたい」のであれば、以下になります。

※宣伝的な内容で恐縮ではございますが、私が企画/製造しているインシデント管理ツールで登録できるようになっており、ユーザーの方にはまず対処不要なものから自動判定させる事をお勧めしております。

またKPIはストーリーが大事だと言われてもおります。
とても簡易的ですが、上記課題を解決した先まで考えると以下のようなストーリーなどあるかなと想像してみました。
(KAI)「対処不要の自動判定の条件追加」を増やす。
  →(KRI)「対処不要と自動判断できた割合」が増える
      →「夜や休日に発生したアラートで起こさなくなる/休日に仕事をしなくて済む」または
   「業務時間中に他の課題解決に時間を使える」(対処不要アラートの稼働時間を減らし、チームとしての生産性を向上させる)
   →新機能開発への稼働投入率をあげる
    →新機能での顧客満足度や新規販売数を増やし、チームとしての成果を上げる(KFI 重要財務指標につなげる)

具体的なKPI事例②「対処を若手でもできるようにしたい」(アラーム検知時の対処は、限られた有識者しかできず、属人化しているため)

「対処を若手でもできるようにしたい」のであれば、以下になります。

1点注意があり「準備を頑張りすぎない」ことです。
私の経験上、準備をしっかりして欲しいと伝えた場合に、モチベーション高く応えてくれるメンバーもいる一方、準備が長引くとモチベーションが下がってくるメンバーもいます。
結果目標・アクション目標は定めたほうがよいですが、最低限は実施メンバーがあつまってディスカッションが1,2度できれば十分かなと思います。

他にも以下のような解決したい課題があればと思い、参考までに一例を記載しておきます。

具体的なKPI事例③「アラート検知時の情報が足りず、すぐに事象を把握したい。」(アラート検知時の情報を充実させたい)

具体的なKPI事例④「調査時間を短くしたい」(1アラートあたり15分以内に復旧対処の有無、又は顧客連絡の必要有無を見極めたい)

テスト運用の実施

実際に上記の目標をもとに他業務に影響しないように始めます。
やはり重要なのは「結果の振り返り(ポストモーテム)」です。
ここで目標を定めた効果が出てきて、目標とした成果ができてなくても全然問題ないと思っています。
それよりも、目標に向けて「何が想定外だったか?」「何が予想通りだったか?」「次はどうすればよいか?」「目標は見直すべきか?」を関係者でしっかり話し合って次につなげることが重要だと思っています。
メンバーも徐々に結果が出てくるとワクワクしてモチベーション高く続けてくれるはずです。

参考:KPIの設定方法については以下に詳しく記載されておりますので、参考書籍のリンクを記載しておきます。

①「最高の結果を出すKPIマネジメント

②「人と組織を効果的に動かす KPIマネジメント

ここまで、ご覧いただきありがとうございました!
次回は「4週間目:テスト運用の見える化・振り返り」をもう少し詳しく書きます!
私のチームはこんな課題があるから、こんなKRIやKAIにしようと思う!など、感想、コメントいただけますと、幸いでございます。

野村 浩司

金融系システムを中心に開発・保守・運用を6年実施、その後、事業部・社内改善を5年しており、大規模障害時は300人ほどの障害対応の統括を実施、事業部の故障数を30%削減などに取り組んだ。 他にも、原価削減はBPRで8000万/年、システム監視改善で3600万/年、申込運用改善で2500万/年など実績あり。

The following two tabs change content below.

野村 浩司

金融系システムを中心に開発・保守・運用を6年実施、その後、事業部・社内改善を5年しており、大規模障害時は300人ほどの障害対応の統括を実施、事業部の故障数を30%削減などに取り組んだ。 他にも、原価削減はBPRで8000万/年、システム監視改善で3600万/年、申込運用改善で2500万/年など実績あり。
是非フォローお願いしますm(_ _)m
NO IMAGE