第14話「まず元に戻せ！」
マネジメント系 ／ サービスマネジメント・監査 ── テーマ：SLA・インシデント管理と問題管理・ITIL
▶ マンガで読む（無料・登録なし）この話で覚える用語（7語）
- ITILあいてぃる
- ITサービスを運用・管理するための成功例（ベストプラクティス）をまとめたガイドブック。英国で生まれ、世界中で使われている。
- SLAえすえるえー
- サービスレベル合意書。ITサービスの提供者と利用者が、サービスの内容と水準（稼働率、受付時間、復旧時間など）を合意して文書にしたもの。
- サービスデスクさーびすですく
- 利用者からの問い合わせや障害の連絡を受け付ける窓口。窓口を1つにまとめた単一窓口（SPOC：Single Point Of Contact）にするのが基本。
- インシデント管理いんしでんとかんり
- サービスの中断や品質の低下（インシデント）が起きたとき、原因の追究よりも、できるだけ早くサービスを元の状態に戻すことを目的とする活動。
- 問題管理もんだいかんり
- インシデントの根本原因を突き止め、恒久的な対策をとって再発を防ぐことを目的とする活動。
- 変更管理へんこうかんり
- システムへの変更を、影響やリスクを評価し、承認してから計画的に実施するよう管理する活動。勝手な変更による新たな障害を防ぐ。
- ファシリティマネジメントふぁしりてぃまねじめんと
- 建物・電源・空調などの設備（ファシリティ）を、最適な状態で使えるように管理すること。UPS、自家発電装置、免震構造などで災害や停電に備える。
試験に出るポイント
- サービスの稼働率：99.9％以上
- 問い合わせの受付時間：平日9時〜18時
- 障害が起きたら：30分以内に第一報
- 「どこまで約束するか」を両者で合意して文書にする
- レストランなら「ラストオーダー21時、料理は20分以内に出す」
- ついでに：インシデント管理＝応急手当、問題管理＝精密検査
- できるだけ早くサービスを復旧させる → インシデント管理
- 根本原因を突き止めて再発防止 → 問題管理
- 提供者と利用者でサービスの水準を合意 → SLA
- 問い合わせ窓口を1つにまとめる → サービスデスク（SPOC）
- 変更を評価・承認して実施 → 変更管理／機器やソフトの版を記録 → 構成管理
- 停電時に短時間電気を送り、安全に停止 → UPS
確認クイズ（ITパスポート試験の形式）
- インシデントの根本原因を突き止め、再発を防止する
- サービスをできるだけ早く通常の状態に戻す
- システムへの変更を評価・承認して計画的に実施する
- ハードウェアやソフトウェアの構成情報を正確に記録する
答えと解説を見る
正解：イ サービスをできるだけ早く通常の状態に戻す
インシデント管理は「早く戻す」。根本原因と再発防止は問題管理、変更の承認は変更管理、構成情報の記録は構成管理です。
- ITIL
- SLA
- NDA
- RFP
答えと解説を見る
正解：イ SLA
サービスの水準の合意はSLA。ITILは運用のお手本集、NDAは秘密保持契約、RFPは提案依頼書です。
- 自家発電装置
- UPS
- RAID
- ルータ
答えと解説を見る
正解：イ UPS
短い時間だけ電気を送り続けるのがUPS（無停電電源装置）。長い停電で発電し続けるのは自家発電装置です。
マンガのセリフ（文字版）
月曜の朝――
ミライ「電話が鳴りやまない！「家計簿アプリにログインできない」って…！」
ミライ「原因がわかるまで、お客さまには何も答えられないし…」
ツカサ先輩「原因探しはあとだ！まずお客さまが使える状態に戻せ！」
ツカサ先輩「これがインシデント管理。目的はとにかく早く元に戻すことだ」
ミライ「原因がわからなくてもいいんですか？」
ツカサ先輩「ああ。昨日の版に戻すなど、とりあえずの策でいい」
ツカサ先輩「家が水もれしたら、まず元栓を閉めるだろ？」
昼すぎ、ログインは復旧した――
ツカサ先輩「ここからが問題管理。根本原因を突き止めて再発を防ぐ」
ミライ「水もれなら、配管のどこが傷んだか調べて取り替える！」
ミライ「今朝は部署ごとに電話番号がバラバラで、お客さまが迷ってました…」
ツカサ先輩「窓口はサービスデスクにまとめる。単一窓口（SPOC）だ」
部長「そもそも、お客さまとはどこまで約束しとるんだ？」
ツカサ先輩「それを決めるのがSLA。提供者と利用者の合意です」
- サービスの稼働率：99.9％以上
- 問い合わせの受付時間：平日9時〜18時
- 障害が起きたら：30分以内に第一報
- 「どこまで約束するか」を両者で合意して文書にする
- レストランなら「ラストオーダー21時、料理は20分以内に出す」
- ついでに：インシデント管理＝応急手当、問題管理＝精密検査
ツカサ先輩「原因の修正も勝手に本番に入れない。変更管理で影響を確かめ承認してからだ」
ツカサ先輩「どの機器にどの版のソフトがあるか記録するのは構成管理」
ツカサ先輩「こうした運用のやり方のお手本集がITILだ」
ミライ「アイティル…「愛してる」の業界用語ですか？」
ツカサ先輩「違う！IT運用の成功例集だ！」
その夜、雷が――
部長「停電したら、わしが自転車をこいで発電する！」
ツカサ先輩「部長、無理です。建物や電源の備えはファシリティマネジメントの仕事です」
ミライ「まず元に戻す、それから原因を突き止める。順番が大事なんですね！」
ツカサ先輩「そこがいちばんのひっかけだ」
- できるだけ早くサービスを復旧させる → インシデント管理
- 根本原因を突き止めて再発防止 → 問題管理
- 提供者と利用者でサービスの水準を合意 → SLA
- 問い合わせ窓口を1つにまとめる → サービスデスク（SPOC）
- 変更を評価・承認して実施 → 変更管理／機器やソフトの版を記録 → 構成管理
- 停電時に短時間電気を送り、安全に停止 → UPS
翌朝――
部長「インシデントだ！コーヒーをこぼした！まず根本原因の分析を…」
ミライ「部長、まず拭いてください！それがインシデント管理です！」