チームで取り組む！Web運用業務の品質改善方法（後編）

みなさんこんにちは！
前編ではWeb運用業務の品質改善方法に関する体制づくりやツールをご紹介しました。
後編では品質改善に関する具体的な実践方法をご紹介いたします。

事故発生時の対応とヒヤリハットの改善方法

トラブル発生時の流れをご紹介します！

1、事故発生時の対応

公開事故などが発覚した瞬間、誰しも血の気が引き胃液が逆流し、パニックに陥りがちです。しかし起こってしまったことは元に戻せません。次にやるべきことを冷静に考え、チーム全員で対処することが重要です。

★Point

• 犯人捜しは行わず、リカバリ対応を最優先。
• リカバリ対応と並行して、責任者は現状把握と社外/社内への第一報を行う。
• 1次対応が完了後、事故に関連した作業者は日を置かずに「ミス・トラブル表」へ記載する。

報告、確認

当事者および確認者がミス・トラブル表に記載、QCチームへ報告します。
この表は品質改善において非常に重要なデータとなります。事故対応が終了後、速やかに記載することで内容の詳細を書くことができます。

当事者を責めたりミス・トラブル表を埋めることが目的ではありません。
今後誰が対応しても同様のことが起こらないよう、事実のみに従い起きた事象を時系列で第三者が理解できるように書いていくことが改善アクションにとって重要なポイントです。

ミス・トラブル表の記載方法

ミス・トラブル表に記載する項目は最低でも以下の内容が必要になります。
ひとつずつ見ていきましょう。

①事故レベル

事故の影響範囲がどの程度なのかを記載することで、対策のスピード感や重みづけが変わってきますので必ず記載します。
例）Lv1=社内周知と改善のみ、Lv2=クライアント担当者への報告のみ、Lv3=クライアントへの経緯報告書が必要なレベルなど、事前のLvの定義付けが必要です。

②事故概要

どのタスクで何が起き、どういった経緯で発覚、リカバリ対応まで完了したかを簡潔にまとめたものです。箇条書きで事故のポイントのみを記載します。

③事故詳細

概要をさらに詳細化した報告です。時系列で第三者が見ても経緯が分かる書き方が望ましいです。5W1Hに従い記載することで第三者にも読みやすくなります。

④事故要因（真因）

なぜその事故が起きたのか、事故の真因を記載していきます。

「うっかり見落としました」は真因ではありません。
なぜ見落としたのか、が重要です。なぜ見落としたのかを明らかにすることがマニュアルを整備する必要があるのか、作業フローを変える必要があるのかなど正しい改善アクションを起こすための必要な項目です。

⑤事故影響度合い

「事故レベル」項目の詳細内容を記載します。

事故により発生した影響を「〇%のエンドユーザーに××の影響があった」など具体的かつ定量的に記載します。影響が図れない場合は定性的な予測値でも問題ありません。

⑥改善策

すぐに完全な改善策は生まれません。ある程度現実的な案を書き出したうえで、関係者と煮詰めていきます。

実効性があるか否かが良い改善策かどうかの分かれ道です。コスト、リソース、汎用性の3点で検討しましょう！具体的には、「事故発生時の影響と改善コストが見合っているか」「改善内容を構築できる人材は居るか」「だれでも同じ改善結果を出せる汎用性はあるか」
※コスト面については一時的、例外的にコストをかけてでも行う必要があるケースがありますので責任者が判断します。

⑦改善完了目標日

何事もゴール日程を設定しないと進捗しないのはご承知のとおり。仮でもいいので必ず完了目標日は設定した方がスムーズに進みます。
必ず出てくるのが、期限日を守れない問題です。ここはQC担当者と責任者が進捗を確認し、チーム全体で改善策が進められるよう促していきましょう。

⑧改善完了日

改善が完了したら効果測定を行い、継続して実行可能か、改善結果が保たれるかの確認を行い、完了日とします。

完了したら終了ではありません。定期的に過去の改善を見直し前回完了日から日数が経っていたら、現状のフローに沿っているかをタスクチームとQCチームが共同で見直すことでより高い品質を維持できます。

2、ヒヤリハットの改善方法

ヒヤリハットには、既に発生したヒヤリハットと発生するかもしれない隠れヒヤリハットの2種類が存在します。
発生したヒヤリハットの改善は容易ですが、難しいのはまだ発生していない隠れヒヤリハット（潜在リスク）を事前に見抜くことです。

発生したヒヤリハットは下記のようなリスクから派生します。

【顕在リスク】

• 属人化している箇所がある
• 口伝で対応している箇所がある
• 暗黙知で対応している

対して隠れヒヤリハットには以下のような潜在的リスクが考えられます。

【潜在リスク】

• 見直されていないルールがある
• 誰が作成したか不明なマニュアルを使用している
• マンパワーでのみ対応している業務がある

上記のような状況があれば少なからず事故が発生する余地が存在しているので早急に何らかの対応が必要となります。

ヒヤリハット改善の流れ

チームメンバーは自分の業務に【顕在リスク】【潜在リスク】に該当する箇所があれば品質相談窓口フォームからQCチームに相談します。

フォームの入力項目が多いと相談自体が億劫になってしまうので、項目をタスクと懸念点、改善したいゴールのみに絞ることで相談しやすくなります。
QCチームはなるべく早い日程を組み、チームメンバーとヒアリングを行いどのような改善が可能か合同で検討を進めます。ここはブレストテクニックと事故発生時の改善策の立て方が有効です。
改善施策は基本的にチームメンバーが実行します。QCチームも当然自分の業務を抱えていますので基本的には改善施策を推進させる役割となります。

ヒヤリハット改善の優先順位付け

改善項目は施策に係る時間（難度）と改善効果の高低で4象限に分け、第1象限から取り組むと効果的です。