サービスマネジメントと監査

IT システムは「作って終わり」ではなく、安定して使い続けられるように日々の運用管理が必要です。たとえば病院では、受付で患者を案内し、急患が来たら優先対応し、機器の点検も欠かしません。IT の世界でも同じように、利用者からの問い合わせ対応、障害の復旧、計画的な変更作業など、日常的な管理活動が不可欠です。

このセクションでは、IT サービスの運用管理を体系化した ITIL （アイティル）のフレームワークを中心に、 SLA によるサービス品質の約束、 サービスデスク の役割、そして インシデント管理 ・ 問題管理 ・ 変更管理 ・ リリース管理 などの主要プロセスを学びます。

ITIL（Information Technology Infrastructure Library）

ITIL は、IT サービスマネジメントの ベストプラクティス （成功事例）を体系化したガイドラインです。もともとイギリス政府が策定したもので、世界中の企業や組織で IT サービスの品質向上に活用されています。

身近な例で考えると、チェーンレストランの「マニュアル」のようなものです。どの店舗でも同じ品質のサービスを提供できるように、接客手順・調理手順・クレーム対応などを標準化しています。ITIL は IT サービスにおけるこの「マニュアル集」にあたります。

ITIL の主要な構成

ITIL では、IT サービスのライフサイクル全体をカバーする形でプロセスが整理されています。FE 試験では特に サービスオペレーション （日常運用）の各プロセスが頻出です。

カテゴリ	主な活動	対応するプロセス例
サービスストラテジ	IT サービスの戦略策定	需要管理、財務管理
サービスデザイン	サービスの設計	SLA 管理、可用性管理、キャパシティ管理
サービストランジション	サービスの移行	変更管理、リリース管理、構成管理
サービスオペレーション	日常の運用管理	インシデント管理、問題管理
継続的サービス改善	サービスの改善活動	PDCA サイクルによる改善

SLA（Service Level Agreement: サービスレベル合意書）

SLA は、IT サービスの提供者と利用者の間で サービスの品質レベルを数値で合意する文書 です。「このサービスはどれくらいの品質で提供しますか？」を明文化したものです。

身近な例では、宅配便の「翌日配達保証」に似ています。「翌日の午前中に届けます」という約束があるからこそ、届かなかったときに問い合わせできますし、配送業者も品質を維持する努力をします。

SLA に含まれる主な項目

項目	内容	具体例
可用性	サービスが利用可能な時間の割合	稼働率 99.9% 以上
応答時間	リクエストに対する応答の速さ	画面応答 3 秒以内
障害復旧時間	障害発生から復旧までの時間	4 時間以内に復旧
サポート対応時間	問い合わせに対応する時間帯	平日 9:00〜18:00
ペナルティ	SLA 未達時の措置	利用料の減額

サービスレベル管理

SLA を策定して終わりではなく、実際のサービス品質を 継続的に測定・評価 し、SLA の達成状況を確認するプロセスです。未達の場合は原因を分析し、改善策を実施します。

サービスデスク

サービスデスクは、利用者と IT サービス提供者の間の 単一の窓口（SPOC: Single Point of Contact） です。利用者からの問い合わせ、障害報告、サービス要求などを一手に受け付けます。

家電量販店の「総合案内カウンター」をイメージしてください。修理の相談も、商品の問い合わせも、返品の手続きも、まず総合案内で受け付けてから適切な担当に振り分けます。IT の世界では、この役割をサービスデスクが担います。

サービスデスクの組織構造

種類	特徴	メリット	デメリット
ローカルサービスデスク	利用者の近く（拠点ごと）に設置	対面対応が可能、利用者に親近感	コストが高い、品質にばらつき
中央サービスデスク	1か所に集約して設置	コスト削減、品質の均一化	利用者との距離が遠い
バーチャルサービスデスク	複数拠点をネットワークで接続し仮想的に1つに見せる	分散しつつ統一的な管理	ネットワーク依存
フォロー・ザ・サン	世界各地の拠点が時差を利用して24時間対応	24時間365日サポート	拠点間の情報共有が重要

インシデント管理と問題管理

インシデント管理

インシデント とは、IT サービスの中断や品質低下を引き起こす（または引き起こす可能性がある）事象のことです。インシデント管理の目的は、 サービスをできるだけ早く復旧させる ことです。根本原因の究明は目的ではありません。

身近な例では、水道管が破裂したとき、まず応急処置で水を止めるのがインシデント管理です。「なぜ破裂したのか」を調べるのは後の話です。

問題管理

問題 とは、インシデントの 根本原因 のことです。問題管理の目的は、インシデントの根本原因を特定し、 再発を防止する ことです。

先ほどの例で言えば、「配管の老朽化が原因だった」と突き止め、他の古い配管も交換するのが問題管理です。

比較項目	インシデント管理	問題管理
目的	サービスの迅速な復旧	根本原因の特定と再発防止
対応の緊急度	高い（すぐに対処）	低い（じっくり分析）
解決方法	応急処置（ワークアラウンド）でもよい	恒久的な解決策を策定
時間軸	短期的	長期的

変更管理とリリース管理

変更管理

IT サービスに対する変更を 計画的かつ安全に実施する ためのプロセスです。変更には、ソフトウェアの更新、ハードウェアの交換、設定の変更などが含まれます。

病院で新しい治療法を導入するとき、いきなり患者に適用するのではなく、まず安全性を検討し、承認を得て、手順を整えてから実施します。IT の変更管理も同様に、 変更の影響を事前に評価し、承認を経てから実施 します。

変更管理の主要な要素

• RFC（Request for Change）: 変更要求書。変更の内容・理由・リスク・スケジュールを記載
• CAB（Change Advisory Board）: 変更諮問委員会。変更の可否を審議する組織横断的なメンバーで構成
• 影響度分析: 変更がサービスに与える影響を事前に評価

リリース管理

変更管理で承認された変更を、 本番環境に確実に展開する プロセスです。テスト環境での検証、展開手順の策定、切り戻し（ロールバック）計画の準備などを行います。

プロセス	目的	主な活動
変更管理	変更を安全に管理	RFC 受付、影響分析、CAB での承認
リリース管理	変更を確実に展開	テスト、展開計画、ロールバック準備
構成管理	IT 資産の情報を正確に把握	CMDB（構成管理データベース）の維持

可用性管理とキャパシティ管理

可用性管理

IT サービスが 合意されたレベルの可用性を満たす ようにするプロセスです。SLA で約束した稼働率を達成するために、障害の予防策、冗長化、監視体制の整備などを行います。

可用性管理で扱う主な指標:

• MTBF（平均故障間隔）: 故障と故障の間の平均時間。長いほど信頼性が高い
• MTTR（平均修復時間）: 故障から復旧までの平均時間。短いほど保守性が高い
• 稼働率: MTBF / (MTBF + MTTR)

キャパシティ管理

現在および将来の 需要に見合った IT リソースの容量（キャパシティ）を確保 するプロセスです。容量が不足するとサービスが遅くなり、過剰だとコストの無駄になります。

レストランで考えると、席数が少なすぎると行列ができ（容量不足）、席数が多すぎると空席ばかりでコストがかかります（容量過剰）。キャパシティ管理は「ちょうどよい席数」を維持する活動です。

管理プロセス	目的	主な活動
可用性管理	サービスの安定稼働	障害予防、冗長化、稼働率の監視
キャパシティ管理	適切なリソース配分	需要予測、性能監視、リソース計画
ITサービス継続性管理	災害時の復旧	BCP（事業継続計画）、DRP（災害復旧計画）

ITIL の主要プロセスの全体像

以下の図は、主要なプロセスがどのように連携するかを示しています。

IT システムは企業の経営を支える重要な基盤ですが、システムが正しく安全に運用されているかを客観的に確認する仕組みがなければ、リスクを見落とす可能性があります。

学校で考えると、先生が自分の授業を自分で評価するだけでなく、第三者による授業参観や外部評価を受けることで、客観的な改善点が見つかります。IT の世界でも同様に、 システム監査 という第三者によるチェックの仕組みがあります。

このセクションでは、 システム監査の目的と手順 、監査人に求められる 独立性 、組織の不正を防ぐ 内部統制 と IT 統制 、そして経営層が IT を適切に管理する IT ガバナンス を学びます。

システム監査の目的

システム監査とは、情報システムに関わるリスクに対して、コントロール（統制）が適切に整備・運用されているかを 独立かつ客観的な立場 から検証・評価し、改善を助言・勧告する活動です。

システム監査の主な目的は以下の3点です。

評価の観点	内容
信頼性	システムが正確に、安定して稼働しているか
安全性	不正アクセスやデータ漏洩から保護されているか
効率性	経営資源（ヒト・モノ・カネ）を有効に活用しているか

これに加えて、法令や社内規程への 準拠性 も重要な評価項目です。

システム監査の手順

システム監査は、以下の手順で実施されます。

各手順の詳細

手順	内容	ポイント
監査計画	監査の目的・範囲・スケジュール・体制を決定	リスクの高い領域を優先（リスクアプローチ）
予備調査	監査対象の概要を把握（資料の収集・ヒアリング）	本調査の重点ポイントを絞り込む
本調査	監査証拠を収集・分析して、統制の有効性を評価	十分かつ適切な 監査証拠 が必要
監査報告	監査結果をまとめ、経営者（被監査部門の長ではない）に報告	指摘事項と改善勧告を含む
フォローアップ	改善勧告の実施状況を確認	改善が実行されたか追跡する

監査証拠の種類

• 物理的証拠: 現地視察で確認した事実（サーバ室の施錠状況など）
• 文書的証拠: 規程、マニュアル、ログなどの記録
• 口頭的証拠: 担当者へのインタビューで得た情報
• 分析的証拠: データ分析や比較検証で得た結論

監査人の独立性

システム監査の信頼性を担保するために、監査人には 独立性 と 客観性 が強く求められます。これは監査の最も重要な原則です。

裁判の裁判官が、原告や被告と利害関係があってはならないのと同じです。もし自分の部署を自分で監査したら、問題を見つけても隠してしまう恐れがあります。

独立性の3要素

種類	内容	具体例
外観上の独立性	第三者から見て独立しているように見えること	被監査部門から人事・予算の影響を受けない
精神上の独立性	監査人自身が公正な判断を行う姿勢を持つこと	個人的な利害関係に左右されない
職業倫理	専門家としての倫理基準を守ること	守秘義務の遵守、正当な注意義務

監査人に関する重要なルール

• 監査人は被監査部門から 独立した立場 でなければならない（同じ部署の人が監査しない）
• 監査報告書は 経営者（組織の長） に提出する（被監査部門の長ではない）
• 助言・勧告 はするが、改善の 実施 は被監査部門が行う（監査人が直接改善しない）
• 外部の専門家（ システム監査人 ）に依頼する場合でも、 監査の責任は依頼元の組織 にある

内部統制

内部統制とは、組織の目的を達成するために、業務の適正を確保する仕組み（ルール・プロセス・体制）を組織内部に設けることです。不正の防止、法令遵守、財務報告の信頼性確保などが目的です。

会社を「家庭」に例えると、「お小遣い帳をつける」「大きな買い物は家族会議で決める」「レシートを保管する」といった家庭内のルールが内部統制にあたります。

内部統制の4つの目的

目的	内容
業務の有効性と効率性	経営資源を有効に活用し、業務を効率的に遂行する
財務報告の信頼性	財務諸表が正確で信頼できることを確保する
法令等の遵守（コンプライアンス）	法律や規則、社内規程を守る
資産の保全	組織の資産（情報資産を含む）を適切に管理・保護する

内部統制の6つの基本的要素

要素	内容
統制環境	組織の文化・風土。経営者の姿勢が基盤
リスクの評価と対応	目的達成を阻むリスクの識別・分析・対応
統制活動	リスクに対する具体的なルール・手続き（承認、照合、職務分掌など）
情報と伝達	必要な情報を適時・適切に伝達する仕組み
モニタリング	内部統制の有効性を継続的に監視・評価
ITへの対応	IT を適切に利用・管理して内部統制を支援

IT 統制

IT 統制は、内部統制の中で特に 情報技術に関する統制 を指します。IT が適切に管理されていないと、内部統制全体が機能しません。

IT 統制の分類

統制の種類	対象	具体例
IT 全般統制	IT 基盤全体に対する統制	アクセス権限管理、バックアップ、変更管理手順、開発・テスト手順
IT 業務処理統制	個別の業務アプリケーションに組み込まれた統制	入力データのバリデーション、計算の正確性チェック、出力の照合

IT 全般統制が有効でなければ、その上に乗る IT 業務処理統制も信頼できなくなります。たとえば、アクセス管理（全般統制）がずさんだと、アプリケーションの入力チェック（業務処理統制）をいくら厳しくしても、不正な操作を防げません。

職務分掌（しょくむぶんしょう）

IT 統制で特に重要な概念が 職務分掌 です。これは、1人の担当者に権限が集中しないように業務を分離する仕組みです。

• 開発担当者と運用担当者を分ける
• データの入力者と承認者を分ける
• プログラムの作成者とテスト者を分ける

これにより、不正やミスの発生を抑制し、発見しやすくします。

IT ガバナンス

IT ガバナンスとは、経営陣が IT の利活用に関する 方針を決定し、組織全体で適切に管理・統制する 仕組みです。「IT 投資は経営戦略に沿っているか？」「IT リスクは適切に管理されているか？」といった経営レベルの意思決定に関わります。

IT ガバナンスと IT マネジメントの違いを整理すると:

比較項目	IT ガバナンス	IT マネジメント
担い手	経営層（取締役会等）	IT 部門の管理者
視点	方向づけ・監督・評価	計画・構築・運用・監視
対象	IT 投資の戦略的判断	IT システムの日常運用
関係	方針を決める	方針に従って実行する

経営者がレストランのオーナーだとすると、「どんな料理を出す店にするか」「立地はどこにするか」を決めるのがガバナンス、実際に料理を作り店を運営するのがマネジメントです。

コーポレートガバナンスとの関係

IT ガバナンスは コーポレートガバナンス （企業統治）の一部です。企業全体の統治の中で、IT に関する部分を IT ガバナンスが担当します。近年は IT が経営に与える影響が大きくなり、IT ガバナンスの重要性も高まっています。