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

IT サービスマネジメント（ITSM） とは、利用者に対して IT サービスを安定的に提供するための管理活動の総称です。ITSM の国際的なベストプラクティス集が ITIL（Information Technology Infrastructure Library） です。

ITIL では、IT サービスのライフサイクルを以下の5つのフェーズで管理します。

フェーズ	内容
サービス戦略	IT サービスの方針・目標を策定し、投資対効果を評価
サービス設計	サービスの要件を定義し、SLA やプロセスを設計
サービス移行	新サービスや変更をテスト環境から本番環境へ移行
サービス運用	日常的なサービスの提供、インシデント対応、問題解決
継続的サービス改善	サービスの品質を測定し、継続的に改善

ITIL は特定の製品やベンダーに依存しない汎用的なフレームワークであり、企業規模を問わず適用できます。

サービスデスク

サービスデスク（ヘルプデスク） は、利用者からの問い合わせや障害報告を受け付ける 単一の窓口（SPOC: Single Point of Contact） です。

サービスデスクの種類	特徴
ローカルサービスデスク	利用者の近くに設置。直接対応が可能
中央サービスデスク	1か所に集約。コスト効率が高い
バーチャルサービスデスク	地理的に分散した拠点をネットワークで統合。利用者からは1つに見える
フォロー・ザ・サン	時差を利用して24時間対応。各地域のデスクが引き継ぐ

サービスデスクが SPOC（単一窓口） である理由は、利用者が「どこに連絡すべきか」迷わないようにするためです。問い合わせ履歴を一元管理でき、対応漏れや重複対応を防げます。サービスデスクは利用者にとって IT 部門の「顔」であり、第一印象を左右する重要な機能です。

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

インシデント と 問題 は ITIL では明確に区別されます。分離する理由は、インシデント管理は まず復旧を最優先 し、問題管理は 根本原因を調査して再発防止 に注力するためです。両方を同時にやろうとすると、復旧が遅れるか根本対策がおろそかになります。

用語	定義	目的
インシデント	サービスの中断や品質低下を引き起こす事象	できるだけ早くサービスを復旧する（応急処置）
問題	インシデントの根本原因	根本原因を究明し、再発を防止する（根本対策）

インシデント管理のプロセス

1. 検知・記録 — インシデントを検知し、チケットとして記録
2. 分類・優先度付け — 影響範囲と緊急度から優先度を判定
3. 調査・診断 — 原因を調査し、解決策を検討
4. 解決・復旧 — ワークアラウンド（暫定対応）または恒久対応でサービスを復旧
5. クローズ — 利用者に解決を確認し、チケットを閉じる

エスカレーション は、対応を上位者や専門チームに引き継ぐことです。

• 機能的エスカレーション — より専門性の高いチームに引き継ぐ（水平方向）
• 階層的エスカレーション — 管理職に報告・判断を仰ぐ（垂直方向）

変更管理と構成管理

変更管理 は、IT サービスへの変更を計画的・体系的に実施するプロセスです。無秩序な変更はインシデントの原因になるため、CAB（Change Advisory Board / 変更諮問委員会） で変更の承認を行います。

変更の種類	説明
通常変更	CAB の承認を経て実施する変更
標準変更	リスクが低く、事前に承認された手順で実施できる変更
緊急変更	重大インシデントへの対応として緊急に実施する変更

構成管理 は、IT サービスを構成する要素（ハードウェア、ソフトウェア、文書など）を CI（構成アイテム / Configuration Item） として識別・記録・管理するプロセスです。すべての CI は CMDB（構成管理データベース） で一元管理されます。

用語	説明
CI	構成管理の対象となるアイテム（サーバー、OS、アプリケーション等）
CMDB	CI の情報と相互関係を記録するデータベース
ベースライン	ある時点の構成の基準状態。変更前の状態に戻すための基準

SLA（Service Level Agreement）

SLA（サービスレベル合意書） は、IT サービスの提供者と利用者の間で、サービスの品質・範囲・責任を合意した文書です。SLA に記載される代表的な項目は以下のとおりです。

項目	内容	例
サービス提供時間	サービスが利用できる時間帯	24時間365日、平日9:00〜18:00
可用性	サービスが利用可能な時間の割合	99.9%以上（= 年間ダウンタイム約8.76時間。365日 × 24時間 × 0.001 = 8.76時間）
応答時間	問い合わせから初回応答までの時間	30分以内
復旧時間	障害発生から復旧までの目標時間	4時間以内
ペナルティ	SLA 未達時の対応（料金減額など）	可用性99.9%未達で月額10%減額

SLA を達成するための管理活動を SLM（Service Level Management / サービスレベル管理） と呼びます。SLM では定期的にサービスレベルを測定・報告し、改善に取り組みます。

可用性・信頼性・保守性

サービスレベルを測定する上で重要な3つの指標があります。

指標	意味	高いほど
可用性（Availability）	システムが利用可能な状態にある割合	「止まらない」
信頼性（Reliability）	システムが故障せずに稼働し続ける能力	「壊れにくい」
保守性（Serviceability）	故障時に迅速に復旧できる能力	「直しやすい」

これら3つの指標は RAS と総称され、さらに 完全性（Integrity） と 機密性（Security） を加えた RASIS として評価されることもあります。

MTBF・MTTR・稼働率

システムの可用性を定量的に測定する指標として MTBF と MTTR があります。

指標	正式名称	意味
MTBF	Mean Time Between Failures（平均故障間隔）	故障と故障の間の平均稼働時間。大きいほど信頼性が高い
MTTR	Mean Time To Repair（平均修復時間）	故障してから復旧するまでの平均時間。小さいほど保守性が高い

稼働率 は以下の式で計算します。

稼働率 = MTBF / （MTBF + MTTR）

稼働率の計算例

単体システムの稼働率

あるシステムの MTBF = 950時間、MTTR = 50時間の場合:

稼働率 = 950 / （950 + 50） = 950 / 1000 = 0.95（95%）

直列システムの稼働率

2つのシステム A（稼働率0.95）と B（稼働率0.90）が 直列（両方稼働で全体が稼働） の場合:

全体の稼働率 = 0.95 × 0.90 = 0.855（85.5%）

並列システムの稼働率

2つのシステム A（稼働率0.95）と B（稼働率0.90）が 並列（どちらか一方でも稼働すれば全体が稼働） の場合:

全体の稼働率 = 1 -（1 - 0.95）×（1 - 0.90） = 1 - 0.05 × 0.10 = 1 - 0.005 = 0.995（99.5%）

構成	計算式	特徴
直列	A × B	個々より低くなる
並列	1 -（1-A）×（1-B）	個々より高くなる（冗長化）

システム監査の目的

システム監査 とは、情報システムの 信頼性・安全性・効率性 を独立した第三者の立場で客観的に点検・評価する活動です。経済産業省の「システム監査基準」に基づいて実施されます。

監査の観点	確認内容
信頼性	システムが障害なく安定して稼働しているか
安全性	不正アクセスやデータ漏洩への対策が適切か
効率性	IT 投資に見合った効果が得られているか
有効性	経営目標の達成に IT が貢献しているか
準拠性	法令や社内規程に準拠しているか

システム監査の最も重要な原則は 監査人の独立性 です。監査対象のシステムの開発や運用に関わっている人が自ら監査することはできません。利害関係がある人が監査すると、問題を隠蔽するインセンティブが生まれるため、客観的な評価には独立性が不可欠です。

監査の流れ

システム監査は以下のプロセスで実施されます。

ステップ	内容
監査計画	監査の目的・範囲・スケジュール・体制を決定
予備調査	監査対象の概要を把握し、重点的に調査する領域を特定
本調査	監査証拠の収集。ドキュメントレビュー、インタビュー、実地調査など
監査報告	発見事項と改善勧告を監査報告書にまとめ、経営者に報告
フォローアップ	改善勧告の実施状況を確認

監査報告書 には、監査の結論だけでなく 改善勧告（指摘事項と改善の方向性） を記載します。ただし、監査人は改善勧告は行いますが、具体的な改善策の実施には関与しません 。改善の実施は被監査部門の責任です。

監査証拠と監査手続

監査証拠 とは、監査の結論を裏付ける根拠となる資料・データです。十分かつ適切な監査証拠を入手することが、信頼性の高い監査の前提条件です。

監査手続	内容	例
ドキュメントレビュー	文書・記録を閲覧し内容を確認	運用手順書、アクセスログ
インタビュー	関係者に質問して情報を収集	システム管理者へのヒアリング
ウォークスルー	業務プロセスを最初から最後まで追跡	受注から出荷までの流れを確認
実査	実物を直接確認	サーバールームの入退室管理を確認
再実施	被監査部門が行った処理を監査人が再度実施	データ集計を再計算して検証

監査証跡（監査トレイル） とは、処理の過程を追跡可能にするための一連の記録です。操作ログやアクセスログが代表的で、不正の検知やインシデント発生時の原因究明に不可欠です。

IT 統制

IT 統制 は、IT に関わるリスクを適切に管理するための仕組みです。内部統制の一環として位置づけられます。

統制の種類	対象	例
IT 全般統制（ITGC）	IT 基盤全体に対する統制	アクセス管理、変更管理、システム開発管理、運用管理
IT 業務処理統制（ITAC）	個々の業務処理の正確性・完全性を確保する統制	入力チェック、計算ロジックの検証、出力結果の照合

IT 全般統制が適切に機能していないと、IT 業務処理統制の信頼性も担保できません。例えば、アクセス管理（ITGC）が甘ければ、不正なユーザーがデータを改ざんできるため、入力チェック（ITAC）の結果も信頼できなくなります。両方の統制が揃って初めて IT 統制が有効に機能します。

IT 全般統制の領域	主な統制活動
アクセス管理	権限の付与・変更・削除の適切な運用
変更管理	プログラム変更の承認プロセスと記録
開発管理	システム開発の標準手順の遵守
運用管理	バックアップ、ジョブスケジュールの管理

内部統制の基本的枠組み

内部統制 とは、企業の業務が適正に行われるよう、組織内に構築される仕組みです。金融庁の「財務報告に係る内部統制の評価及び監査の基準」では、内部統制の目的と構成要素を以下のように定義しています。

内部統制の4つの目的

目的	内容
業務の有効性と効率性	業務を効果的かつ効率的に遂行する
財務報告の信頼性	財務諸表が正確に作成されることを確保する
事業活動に関わる法令等の遵守	法令やルールを守る（コンプライアンス）
資産の保全	企業の資産（情報資産含む）を適切に管理・保護する

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

要素	内容
統制環境	組織の気風や文化。内部統制の基盤となる最重要要素。経営トップの姿勢が組織全体のコンプライアンス意識を左右する（「上が守らなければ下も守らない」）
リスクの評価と対応	業務目的の達成を阻害するリスクの識別・分析・対応
統制活動	リスクを低減するための方針と手続（承認、照合、職務分掌など）
情報と伝達	必要な情報を適時に識別・把握し、関係者に伝達する
モニタリング	内部統制が有効に機能しているかを継続的に監視
IT への対応	IT を適切に利用し、内部統制の有効性を高める

J-SOX 法（金融商品取引法）

J-SOX 法 は、上場企業に対して 内部統制報告書の提出 と 内部統制監査 を義務づける制度です。米国の SOX 法（サーベンス・オクスリー法）を参考に日本版として整備されました。

項目	内容
対象	上場企業（金融商品取引法の適用対象）
義務	経営者が内部統制の有効性を評価し報告書を作成
監査	内部統制報告書について外部の監査法人が監査
目的	財務報告の信頼性確保と投資家保護

J-SOX では トップダウン型のリスクアプローチ を採用しています。全業務プロセスを対象にするのではなく、財務報告に重要な影響を与えるプロセスを重点的に評価します。

内部統制の評価プロセス

1. 全社的な内部統制の評価 — 組織全体の統制環境を評価
2. 業務プロセスに係る内部統制の評価 — 重要な業務プロセスの統制を評価
3. IT 統制の評価 — IT 全般統制と IT 業務処理統制を評価
4. 内部統制報告書の作成 — 評価結果をまとめて提出

IT ガバナンス

IT ガバナンス とは、企業の経営戦略に沿って IT を活用し、組織の目標達成に貢献するよう IT を統制・管理する仕組みです。IT 投資の意思決定やリスク管理を 経営者の責任 として位置づけます。

比較項目	IT ガバナンス	IT マネジメント
責任者	経営者・取締役会	IT 部門の管理者
視点	経営戦略との整合性	日常的な IT 運用
活動	方針策定・監督・評価	計画・実行・管理
フレームワーク	COBIT	ITIL

COBIT（Control Objectives for Information and Related Technologies） は、IT ガバナンスと IT マネジメントの国際的なフレームワークです。IT が経営目標の達成にどう貢献するかを体系的に管理します。

コンプライアンスと職務分掌

コンプライアンス（法令遵守） は内部統制の重要な目的の一つです。IT に関連するコンプライアンスには以下が含まれます。

法令・規程	内容
個人情報保護法	個人情報の適切な取得・利用・管理
不正アクセス禁止法	他人のIDでの不正ログインの禁止
著作権法	ソフトウェアの不正コピーの禁止
マイナンバー法	特定個人情報の安全管理措置

職務分掌（Segregation of Duties / SoD） は、不正を防止するための重要な統制活動です。1人に権限を集中させず、複数の担当者で業務を分担します。

分掌の例	理由
承認者と実行者を分ける	不正な支出を防ぐ
開発者と運用者を分ける	不正なプログラム改変を防ぐ
入力者と承認者を分ける	データの不正入力を防ぐ

内部統制における IT への対応は、IT 環境への対応（IT リスクの理解と IT の利用方針の策定）と IT の利用及び統制（ITGC・ITAC の整備と運用）の2つの側面で捉えます。