LASSIC Media らしくメディア

システムの障害が起きたとき、まず求められるのは一刻も早い復旧です。ところが、復旧だけを繰り返していると、同じような障害が何度もぶり返すことがあります。原因を突き止めないまま、その場しのぎの対応でしのいでいると、根っこが残り続けるためです。同じ火消しに追われ、担当者が疲弊していく——そんな悪循環に心当たりのある組織は少なくありません。

そこで欠かせないのが、障害の根本原因を掘り下げ、再発を断つための「問題管理」です。ただ、この取り組みは「インシデント対応」や「ポストモーテム」としばしば混同されがちで、担う役割は別物です。本記事では、自社のシステムを預かる情報システム部門や運用担当者に向けて、問題管理とは何か、近い取り組みとどう違うのか、そして進め方と外注の勘所を整理します。

問題管理とは——インシデント対応・ポストモーテムとの違い

問題管理とは、ITサービスマネジメントの考え方の一つで、繰り返す障害や潜在的な弱点を「問題」として登録し、根本原因を分析して、再発を断つための恒久的な対策までを管理する取り組みを指します。その場の復旧ではなく、原因そのものをなくすことに軸足を置く点が特徴です。似た文脈で語られる2つの取り組みと並べると、役割の違いがはっきりします。

インシデント対応・オンコール運用は、障害が起きたときに、まずサービスを復旧させることを最優先にする取り組みです。原因究明より、目の前の業務を止めないことを急ぎます。またポストモーテムは、起きた障害を一件ずつ振り返り、責めずに学びを引き出す取り組みです。これらに対して問題管理は、それらの振り返りやインシデントの傾向を束ねて、背後にある問題を継続して追いかけ、根本原因を断つところまでを受け持ちます。

まず復旧させる取り組みでも、一件を振り返る取り組みでもなく、根本原因を管理して再発を断つ——ここに違いがあります。復旧の速さと、再発を防ぐ根治は、目的が異なる別の活動です。どちらか一方ではなく、両輪で回すことに意味があります。自社に足りていないのが、素早い復旧なのか、振り返りの文化なのか、それとも再発を断つ仕組みなのかを見極めておくと、取り組みの範囲を絞りやすくなります。

なぜ「復旧」だけでは足りないのか

障害が起きたら、まず復旧させる。これはもちろん正しい対応です。利用者や業務への影響を止めることが最優先だからです。ところが、復旧の裏で本当の原因が手つかずのまま残っていると、同じ障害が形を変えて何度も戻ってきます。そのたびに担当者が呼び出され、対応に追われ、本来やるべき仕事が進まなくなっていきます。

やっかいなのは、その場しのぎの対応が積み重なると、システムの中に説明のつかない回避策や設定が増えていくことです。なぜそうなっているのかが分からないまま運用が続き、いざ調べようとしても手がかりが散らばっていて追いにくくなります。こうした悪循環を断つには、復旧とは別に、腰を据えて原因を掘り下げる場が要ります。それが問題管理です。繰り返す障害や、大きな影響を及ぼしかねない弱点を「問題」として拾い上げ、根本原因を突き止めて、二度と起きない状態を目指す。目の前の火消しと、火種そのものを消す取り組みを分けて考えることで、じわじわ膨らむ負担を減らせます。

問題管理でやること

問題管理は、思いついたときに原因を調べるだけでは、抜け漏れが生じます。おおまかには次のような工程を、継続した仕組みとして回します。自社でどこまで回せているかと照らし合わせてみてください。

まず、問題を起票します。繰り返し起きている障害や、影響が大きくなりそうな弱点を「問題」として登録し、見える形にする工程です。次に、根本原因を分析します。「なぜ起きたのか」を掘り下げ、その場の症状ではなく、真の原因を突き止める工程です。原因が分かったら、既知のエラーとして管理します。原因と、当面しのぐための回避策を記録し、関係者で共有する段階です。そのうえで、再発を断つための恒久対策を計画します。設定や仕組みの見直しが必要なら、変更管理と連携して進めるのが基本です。最後に、対策を実施したあと、本当に再発が止まったかを確認し、問題をクローズします。この一連の流れを図にすると次のとおりです。

つまずきやすい難所

問題管理を根づかせるうえで、あらかじめ想定しておきたい難所がいくつかあります。着手前に押さえておくと、形だけの取り組みで終わりにくくなります。

一つ目は、インシデント対応との切り分けです。復旧を担うチームがそのまま原因分析まで抱えると、日々の火消しに追われて手が回りません。誰が問題を追うのかを、あらかじめ決めておく必要があります。二つ目は、時間の確保です。根本原因の分析は、腰を据えて向き合う時間が要ります。通常業務の合間では進まないため、意識して時間を割く仕組みが欠かせません。三つ目は、原因の見極めです。表面的な症状で満足すると、真の原因を取り逃がします。「なぜ」を重ねて掘り下げ、思い込みで決めつけない姿勢が求められます。四つ目は、恒久対策の実施までやり切ることです。原因が分かっても、対策が後回しになれば再発は止まりません。変更管理とつなぎ、実施と効果の確認まで追う流れを作ることが大切です。

インシデント管理・変更管理との連携

問題管理は、単独では成り立ちません。障害の入り口であるインシデント管理と、対策の出口である変更管理と、手をつないで初めて回る仕組みです。3つの取り組みの役割を整理しました。

流れとしては、インシデント管理でしのいだ障害のうち、繰り返すものや重いものを問題管理が引き取り、根本原因を突き止めて恒久対策を立てます。その対策を実際のシステムへ反映するのが変更管理です。3つが分断されていると、原因が分かっても対策が実行されなかったり、対策が別の障害を招いたりします。つなげて回すことで、火消しと根治のバランスが取れるようになります。

外注時に確認しておきたい点

問題管理の仕組みづくりや運用を外部に委託する場合は、次の点を事前にすり合わせておくと、認識のずれを防ぎやすくなります。まず、いま抱えている繰り返しの障害と、その影響です。どの障害に困っているかによって、最初に取り組む問題が変わります。次に、どこまでを任せるか。根本原因の分析だけなのか、恒久対策の計画や、インシデント管理・変更管理との連携づくりまで含めるのかで、進め方が変わります。

さらに、問題や既知のエラーをどこで管理し、どう共有するか、そして対策の効果をどう確認するかも、あらかじめ決めておきたいところです。問題管理は続いていく取り組みなので、いずれ自社で回せるように、分析の進め方や記録の残し方を引き継いでもらえるかどうかは、後々の助けになります。分析の支援だけを頼むのか、仕組みの定着まで含めて依頼するのかを明確にしておくと、任せたあとのつまずきを抑えやすくなります。

まとめ：問題管理で押さえる3つの視点

問題管理は、まず復旧させるインシデント対応や、一件を振り返るポストモーテムとは役割の異なる、「根本原因を管理して再発を断つ」取り組みです。検討するうえで押さえたい視点は3つに整理できます。第一に、インシデント対応・ポストモーテム・問題管理を切り分け、自社に足りないのがどれなのかを見極めること。第二に、その場しのぎの復旧を繰り返すと根っこが残ると踏まえ、繰り返す障害を「問題」として拾い上げ、根本原因まで掘り下げること。第三に、問題管理を単独で終わらせず、入り口のインシデント管理と出口の変更管理とつなぎ、恒久対策の実施と効果の確認までやり切ることです。この3点を踏まえておけば、「同じ障害の火消しに追われ続ける」という悪循環を抜け出しやすくなります。自社だけで仕組みを回しきるのが難しいと感じたら、根本原因の分析や仕組みづくりから外部の手を借りるのも一つの選択肢です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：情報処理推進機構（IPA）「情報セキュリティ」（https://www.ipa.go.jp/security/）

Tweet