コラム
デジタルビジネスのサービス品質改善のための問題管理のポイント（後編）
2016年10月25日
著者： 河村 拓
小学生時代をアメリカ合衆国カルフォルニア州で過ごす。慶應義塾大学総合政策学部を卒業し、2009年4月に株式会社ビーエスピーに入社。提案から要件定義、設計、実装までを、プロジェクトマネージャーまたはPMOとしてワンストップで担当。複数サービス・部門・企業を横断したプロセス標準化やシステム共通化のプロジェクトを、手戻りなくスケジュール通り遂行する業務改革ノウハウに強みを持つ。
前回に続き、問題管理プロセスを実施する際のポイントについて書きます。
前編はこちら
根本原因を深く掘り下げ、開発フェーズの対策にまでつなげる：
問題管理では、インシデントおよび問題の事業に対するインパクトを最小限に抑え、インシデントの再発をプロアクティブに防止することを目指します。その際に特に重要なのが、根本原因の特定です。
例えばプログラムの不具合に起因するインシデントを例にとると、プログラムを修正すれば、そのシステムにおいて同様のインシデントが発生することを防ぐことはできます。ここでもう一歩掘り下げて、不具合を発生させたそもそもの原因が、開発工程やプロジェクトマネジメントになかったかどうかを分析すると、より効果的です。システムアーキテクチャへの対応だけでなく、システムの開発から運用に至るプロセス、ルール、ツール、各種基準や文書に修正すべき点がないかまでを分析することで、本質的な根本原因への対策が可能となります。このような活動が定着すると、運用から開発へのフィードバックサイクルが回り、トラブルを未然に防ぐ仕事の仕方に変わっていきます。
サービス横断で対策を行い、対岸の家事を防ぐ：
根本原因を特定したら、変更要求を起票して恒久対応を行います。その際に重要なのが、直接の影響を受けたサービスやシステムだけでなく、似たような根本原因がほかのサービスやシステムにも内在していないかを洗い出し、横断的に対策を行うことです。
特にデジタルビジネスでは、サービスやシステムごとに担当者が縦割りな事例をよく見ます。その場合、担当者間での情報共有が行われず、以前あるサービスで発生したトラブルと似たようなケースがあちこちで再発しがちです。こうした「対岸の火事」を防ぎ、組織としての品質向上に取り組むためには、問題管理を特定のサービスや担当者でクローズさせず、組織横断・サービス横断で取り組む必要があります。
ワークアラウンドを発見し、既知のエラーとして登録・活用する：
ワークアラウンドとは、問題によって発生したインシデントの困難を克服する、一時的な方法のことです。問題の中には恒久対応が困難なものがあります、そのような防止できないインシデントについては、発生時の事業へのインパクトを最小化できるよう、ワークアラウンドを見つけ、ナレッジとして残しておくと効果的です。ITIL®では、根本原因とワークアラウンドを文書化したものを、既知のエラーと定義しています。
KPIでパフォーマンスチェック：
定義したプロセスフローや基準が有効的・効率的に機能しているかどうかを評価し、改善を推進することが、継続的なプロセスの強化につながります。例えば以下のKPIを設定し、ツールから実績データをとれるようにするとよいでしょう。
ITサービスごとの未処理の問題の数（品質改善の指標）
ITサービスごとの再発インシデント数（多いようなら、根本原因の特定および対策が不十分）
登録された既知のエラーの数（防止できないインシデントの事業インパクトを最小化する）
