システム障害対応における課題発見チャート

皆様ご無沙汰しております。
今回は最近よく相談される「システム障害対応の改善をすることはわかったけど、どこに手を打てばよいかわからない」のに対して、課題の仮説を発見するためのチャートを共有しようと思います。

問題と課題の定義

よくこの2つが混同することが多いので、最初に意識合わせをします。
こちらの東洋経済様の記事がわかりやすかったため、引用させていただきました。

｢問題｣と｢課題｣を区別できない人がしがちな失敗より
https://toyokeizai.net/articles/-/474094?page=3

「問題」とは、目標である未来の「理想的な状態」との間にギャップが発生している、現在の「問題を抱えている状態」です。「問題」の所在はあくまでも現状の中にあります。ネガティブな影響を及ぼすため、解決するべき事柄です。
「課題」とは、目標である「理想的な状態」と問題を抱える状態のギャップを埋めるためにやるべきこと・やると決めたことです。「What to do」と理解してください。

｢問題｣と｢課題｣を区別できない人がしがちな失敗より
https://toyokeizai.net/articles/-/474094?page=3

この章の使い方

システム障害対応において本書を手にとっていただいた読者の皆様も多くの問題を抱えていると思います。
後述の「問題の候補」から、読者の皆様自身に当てはまるものをチェックしてください。

次に選択した”問題”と”課題”のマッピング表を見ながら、どの章で解決するか？を見て、読むべき章を選択してください。

4ブロック、13週に分けて書いており、当てはまった”課題”の章のみを読んでも問題・課題の解決ができるようになっています。

問題の候補

過去1000を超える事例を分類した結果、システム障害対応時に発生する”問題”はQCDに分かれます。
※ここはのちに3日籠りでアップデート、備忘：初期Xonの課題集める、KPI、リードを1つ1つ再度整理

Q:クオリティ：主に作業品質
┗ヒト
　・人によって対応レベルがばらける（属人化含む）
　・調査・連絡・復旧の方法を間違える
┗モノ（情報含む）※
　・情報収集や連絡内容が想定と異なる
┗コト（プロセス含む）
　・対応方法が暫定的な悪い方法を続けている

C：コスト：主に人件費（労務費・委託費）
┗ヒト
　・無駄・意味がない作業をしている
　・作業と単金でレベルがあっていない（単純作業をエンジニアが実施等）
　・一時的なピークに合わせた要員配置
┗モノ（情報含む）※
　・非効率な環境での作業（隔離部屋・不自由な作業環境等）
┗コト（プロセス含む）
　・過去のオペミスからの不要なダブルorトリプルチェック

D：デリバリー：主に対応時間
┗ヒト
　・プレッシャーが高い状態での対応になる
┗モノ（情報含む）※
　・必要な情報が集まらない
　・必要な情報が何かわからない
┗コト（プロセス含む）
　・関係者へ多い
　・関係者へ依頼するのに何人か挟む
　・関係者への依頼がうまくできない

※モノの中で、そもそものアプリの作り、運用設計が悪いという点はあります。往々にしてあり得るものですが、大規模改修などが必要になるため、対象外としています。

課題の候補

同様に課題の候補と後述の隔週との対応を記載します。

1～4週
　・大量な不要メッセージを削除
　・対処のノウハウの蓄積
　・オペレーションの手順化・引継ぎ・自動化
5週～8週 アクションの仮説を作る
　・判断情報・判断基準の仮説を作る
　・アクションの手順化・引継ぎ・自動化
　・情報収集の手順化・引継ぎ・自動化
　・故障対応訓練
9週～12週
　・関係者との合意
　・関係者との訓練
13週以降
　・役割分担の適正化

問題と課題のマッピング

問題・課題のマッピング表

よくある声

このような問題・課題を見た際に「うちは特殊だから改善はなかなか進まない」という声をよく聞きます。
ここではよくある声とその対策を書いていきます。

・忙しくて出来ない

一番の多い声はこちらです。通常業務で手一杯でなかなかできない・・・というのはどの現場でも起こっていることです。
忙しいのは事実だと思いますが、改善活動できないのは必ず別の問題も存在しています。
例えば、「変化をする勇気が出ない」「やりづらいので優先順位を下げている」「モチベーションが落ちていて変える気持ちがわいていない」など、どちらかというと「忙しい」のではなく「何となく一歩踏み出せない」が本当の原因ではないでしょうか？
ただ、本書を手に取っていただいた読者の皆様であれば、これを乗り越えらるはずですし、筆者へ相談いただければ相談に乗ります。是非一緒に一歩踏み出してみましょう！

・関係者（顧客・委託先等）が許してくれない

二番目に多い声はこちらです。システム会社であれば「顧客が許してくれない」、事業会社では「システム会社がなかなか動いてくれない」などです。
この時に私がご案内するのは「顧客・システム会社の課題をともに解決する体制になってないのでは？」です。
システム会社は「業務量が減ると売上が下がる」、顧客は「変化を望んでいない」というのは誤解であることがほとんどです。勇気をもって顧客・システム会社と会話をしてみてください。実は一緒に改善をしたいと思っているのではないでしょうか？

・セキュリティ上、実施することができない

金融分野・官公庁・個人情報を多く持つ方はこの声が大きいです。
「クレジットカードを扱っているから、ルール上できない」とか「顧客のルール上できないことになっている」などと言われます。
私の経験上70%以上は「ルールを誤解している」or「ルールが変えられないものだと思っている」ため、実施ができないだけです。
「決まっているルールでできない」と”思い込んでいる”だけの場合がほとんどで、ルールが複雑で読み直すことはほぼ無いので、記憶の中のルールにしばられてどんどんやりづらい方向へ向かっていることがほとんどです。問題・課題・概算の効果を準備した上で、ルールを司るチームへ相談することをお勧めしています。その際に「私たちの会社の今後のためには是非これが必要なんだ、どのようにしたらできるか？」と一緒に進め方を相談してみてください。ほとんどの場合道が開けます。

・改善活動をするコストの捻出ができない

最後にコストの問題です。保守運用の組織は「コストセンター」と呼ばれて、原価削減を毎年実施する傾向にあり、コストの余裕があることは少ないです。
本書はまさにこのような方が使いやすい構造になっていて、今いるメンバーの空き稼働で小さく改善を繰り返すことに重点を置いていす。
課題によりますが、最短1か月、30時間程度作業をすれば1回目の効果を実感でき、空いた稼働で次の改善へと進めるように設計しています。
是非、私たちともに一歩を踏み出しましょう。
（これはいいメッセージなので「はじめに」に持って行ったほうがよいかも。