サービスマネジメントとシステム監査かんさ β版

この章しょうで学まなぶこと

マネジメント系けい 20 問もんのうち、この章しょうは **4〜6 問もん**ほどの出題しゅつだいがあります。「システムが止とまったらどう直なおす？」「止とまらないようにどう管理かんりする？」「サービス品質ひんしつの契約けいやくってどう作つくる？」「社内しゃないの不正ふせいをどう防ふせぐ？」といった、**システムを作つくった後のちの運用うんよう・管理かんり・監査かんさ**にまつわる章しょうです。

前章ぜんしょう（プロジェクトマネジメント）がシステムを**作つくる**話ばなしなら、この章しょうは**作つくった後のちに安定あんてい稼働かどうさせ、健全けんぜんに管理かんりする**話ばなし。地味じみだけど IT 部門ぶもんで最もっとも人手ひとでと時間じかんがかかる領域りょういきで、実務じつむと直結ちょっけつする論点ろんてんが多おおいです。

学習がくしゅうゴール

この章しょうを読よみ終おえた時点じてんで、以下いかができるようになっていることを目指めざします。

• ITIL の主要しゅようプロセス（インシデント・問題もんだい・変更管理へんこうかんり等）をシナリオから**判別はんべつ**できる
• SLA・SLM・SLO・OLA の違ちがいを使つかいこなせる
• サービスデスクの機能きのうと役割やくわり、エスカレーションの種類しゅるいを判別はんべつできる
• ファシリティマネジメント（UPS・無停電電源装置むていでんでんげんそうち・PUE 等ひとし）の要素ようそを使つかいこなせる
• システム監査かんさの目的もくてき・手順てじゅん・独立どくりつ性せいを説明せつめいできる
• 内部ないぶ統制とうせい（J-SOX・COSO・職務しょくむ分掌ぶんしょう）を判別はんべつできる

試験しけんでは: 「このシナリオは何なに管理かんり？」の判別はんべつ問題もんだいが中心ちゅうしん。たとえば「障害しょうがいでサーバが落おちた → 待機たいき系けいに切きり替かえた」=インシデント管理かんり、「なぜ落おちたか根本こんぽん原因げんいんを調しらべた」=問題もんだい管理かんり、のように**目的もくてきで区別くべつ**する訓練くんれんをする。

1. サービスマネジメントの基礎きそと ITIL

サービスマネジメントとは、「IT サービスを止とめずに提供ていきょうし続つづける」ための一連いちれんの活動かつどう。システムを作つくるのは一時いちじ的てきな仕事しごと（プロジェクト）ですが、運用うんようはシステムが使つかわれている**数すう年ねん〜数すう十じゅう年ねんにわたって続つづく**長期ちょうき活動かつどうです。「24 時間じかん止とまらない銀行ぎんこう ATM」「月つきに 1 回かいしか落おちない EC サイト」のような**品質ひんしつの高たかいサービス**を維持いじするには、体系たいけい的てきな管理かんりが必要ひつよう。その世界せかい的てきベストプラクティスが ITIL です。

1.1 サービスマネジメントとは

IT サービスを**安定あんてい的てきに提供ていきょうし続つづけるための管理かんり活動かつどう全般ぜんぱん。作つくったシステムを「動うごかし続つづける」**運用うんよう・保守ほしゅフェーズの根幹こんかんで、**インシデント対応たいおう・構成こうせい管理かんり・変更へんこう管理かんり・キャパシティ管理かんり**などを含ふくみます。

具体ぐたい例れい: オンラインバンキングを 365 日にち 24 時間じかん止とめずに動うごかすには、**監視かんし（異常いじょう検知けんち）・バックアップ・冗長じょうちょう化か・障害しょうがい対応たいおう手順てじゅん・定期ていきメンテナンス計画けいかくが欠かかせません。これらシステムを使つかい続つづけるための裏方うらかた仕事しごと**がサービスマネジメント。日本にっぽんでは「運用うんよう保守ほしゅ」とも呼よばれますが、体系たいけい化かされた枠組わくぐみとして ITIL が使つかわれます。

1.2 ITIL（Information Technology Infrastructure Library）

ITIL（アイティル）は、IT サービスマネジメントのベストプラクティス集しゅう。1980 年代ねんだいに英国えいこく政府せいふが策定さくていし、現在げんざいは世界せかい標準ひょうじゅんとして採用さいようされています。SLA・インシデント管理かんり・問題もんだい管理かんり・変更へんこう管理かんりなど、本章ほんしょうで学まなぶ用語ようごの**多おおくが ITIL 由来ゆらい**です。最新さいしん版ばんは ITIL 4（2019〜）。

ITIL の特徴とくちょうは「こうすべき」と断定だんていするのではなく、「こうした方ほうがうまくいきやすい」という**推奨すいしょう事項じこうのライブラリである点てん。各かく組織そしきが自社じしゃのサイズ・業種ぎょうしゅに合あわせて取捨選択しゅしゃせんたく**するのが基本きほんです。

ポイント: ITIL は**枠組わくぐみ・用語ようごの標準ひょうじゅんであって、絶対ぜったい守まもるべき法律ほうりつではない**。実務じつむでは自社じしゃの規模きぼ・業種ぎょうしゅに合あわせてカスタマイズするのが普通ふつう。

1.3 SLA と SLM

**サービス品質ひんしつを数値すうち化かして取とり決きめるのが SLA（Service Level Agreement）、それを継続けいぞく的てきに守まもる活動かつどうが SLM（Service Level Management）。SLA を結むすんだだけでは意味いみがなく、毎月まいつきの実績じっせきを測はかって改善かいぜんする SLM の運用うんよう**とセットで初はじめて機能きのうします。

• SLA（Service Level Agreement） — サービス品質ひんしつの**合意ごうい書しょ。稼働率かどうりつ・応答おうとう時間じかん等とうを数値すうち化かした契約けいやく文書ぶんしょ**
• SLM（Service Level Management） — SLA を達成たっせいするための**継続けいぞく的てき管理かんり活動かつどう**（PDCA）
• SLO（Service Level Objective） — SLA に書かかれるサービス目標もくひょう値ち（例れい: 稼働かどう率りつ 99.9% 以上いじょう）
• OLA（Operational Level Agreement） — 社内しゃない部門ぶもん間かんでの合意ごうい（SLA は社外しゃがい契約けいやく、OLA は社内しゃない合意ごうい）

具体ぐたい例れい: AWS の SLA では「月間げっかん稼働かどう率りつ 99.99% 未満みまんなら返金へんきん」のような条項じょうこうがあります。もし 99.99% を割わった場合ばあい、ユーザーは使用しよう料りょうの一部いちぶ返金へんきんを受うけられます。単たんなる約束やくそくではなく、違反いはん時じのペナルティまで決きめてあるのが SLA の契約けいやく文書ぶんしょとしての特徴とくちょう。

頻出ひんしゅつ引ひっかけ: SLA は文書ぶんしょ、SLM は管理かんりプロセス。SLA「Agreement」の A が「合意ごうい・契約けいやく」、SLM「Management」の M が「継続けいぞく管理かんり」。SLA を作つくっただけでは意味いみがなく、SLM で守まもり続つづける活動かつどうとセットで初はじめて機能きのうする。

2. サービスマネジメントの主要しゅようプロセス

ITIL のプロセス群ぐんは大おおきく「日常にちじょう運用うんよう系けい」と「ユーザ窓口まどぐち系けい」に分わかれます。日常にちじょう運用うんようではインシデント・問題もんだい・変更へんこう・構成こうせい・リリースの 5 大だいプロセスが中心ちゅうしん。それぞれ「何なにを目的もくてきとした活動かつどうか」で区別くべつされ、試験しけんでは**シナリオからプロセス名めいを当あてる問題もんだい**が頻出ひんしゅつです。

2.1 日常にちじょう運用うんよう系けいプロセス

日常にちじょう運用うんようは、「トラブル対応たいおう」と「変更へんこう時じの安全あんぜん確保かくほ」が二に本ほん柱ばしら。5 つのプロセスはそれぞれ異ことなる役割やくわりを持もち、互たがいに連携れんけいして動うごきます。特とくにインシデント管理かんり（早期そうき復旧ふっきゅう）と問題もんだい管理かんり（根本こんぽん対策たいさく）の違ちがいは、毎年まいとし必かならず出題しゅつだいされる鉄板てっぱん論点ろんてんです。

プロセス	内容ないよう	目的もくてき
**[[インシデント管理	インシデントかんり]]**	障害しょうがいやトラブルの**早期そうき復旧ふっきゅう**
**[[問題管理	もんだいかんり]]**	インシデントの**根本こんぽん原因げんいん**分析ぶんせきと恒久こうきゅう対策たいさく
**[[変更管理	へんこうかんり]]**	システム変更へんこうのリスクを抑おさえて実施じっし
**[[構成管理	こうせいかんり]]**（CMDB）	構成こうせい要素ようそ（機器きき、ソフト、ドキュメント）の管理かんり
**[[リリース管理	リリースかんり]]**	本番ほんばん環境かんきょうへの展開てんかい管理かんり

1. ⚠ 障害しょうがい発生はっせい
2. ① インシデント管理かんり（短期たんき）
   　目的もくてき: できるだけ早はやくサービス復旧ふっきゅう
   　手段しゅだん: 暫定ざんてい対応たいおう・回避かいひ策さく（再さい起動きどう・代替だいたい系けい切替きりかえ）
3. ② 問題もんだい管理かんり（中長期ちゅうちょうき）
   　目的もくてき: 根本ねもと原因げんいんを突つき止とめて恒久こうきゅう対策たいさく
   　手段しゅだん: 根本ねもと原因げんいん分析ぶんせき・既知きちのエラー登録とうろく

「とりあえず動うごかす（インシデント）」と「再発さいはつ防止ぼうしする（問題もんだい）」を分わけて運用うんようする。

頻出ひんしゅつ引ひっかけ: 「サーバーがダウン → とりあえず再さい起動きどうして復旧ふっきゅうさせた」は インシデント管理かんり（暫定ざんてい対応たいおう）。「ダウンの根本こんぽん原因げんいんを調しらべてメモリリークを修正しゅうせい、再発さいはつを防ふせいだ」は 問題もんだい管理かんり（恒久こうきゅう対策たいさく）。同おなじ事象じしょうでも段階だんかいで呼よび方かたが違ちがう。

2.2 サービスデスク

サービスデスクは利用りよう者しゃ（社員しゃいん・顧客こきゃく）からの問とい合あわせ・障害しょうがい連絡れんらくの**窓口まどぐち。電話でんわ・メール・チャットで受うけ付つけ、簡単かんたんな案件あんけんは自分じぶんで解決かいけつし、難むずかしい案件あんけんは専門せんもん部門ぶもんにエスカレーション（引ひき継つぎ）します。企業きぎょうにおける IT の顔かお**であり、ここの質しつがユーザ満足まんぞく度どを大おおきく左右さゆうします。

型かた	特徴とくちょう	利点りてん・欠点けってん
ローカルサービスデスク	拠点きょてんごとに設置せっち	地元じもと密着みっちゃくで文化ぶんか的てきにも近ちかい / 重複じゅうふくコスト
中央ちゅうおうサービスデスク	1 箇所かしょに集約しゅうやく	コスト効率こうりつ / 時差じさ・言語げんごの問題もんだい
バーチャルサービスデスク	仮想かそう的てきに統合とうごう（分散ぶんさん配置はいちだが統一とういつ的てきに運用うんよう）	柔軟じゅうなん性せい / 管理かんり複雑ふくざつ
フォロー・ザ・サン	時差じさを活用かつようして 24 時間じかん対応たいおう（東京とうきょう→ロンドン→NY の 3 拠点きょてんリレー）	24 時間じかん対応たいおう / 拠点きょてん管理かんりコスト

2.3 エスカレーション

エスカレーションは、サービスデスクで対応たいおうしきれない案件あんけんを**上位じょういや専門せんもん部門ぶもんに引ひき継つぐ**仕組しくみ。2 つのタイプがあり、「誰だれに」「なぜ」引ひき継つぐかが違ちがいます。試験しけんでは **機能きのう的てき vs 階層かいそう的てき**の区別くべつが問とわれます。

• 機能きのう的てきエスカレーション — **専門せんもん知識ちしきを持もつ担当たんとう者しゃ**へ引ひき継つぎ（例れい: ネットワーク障害しょうがいなら NW エンジニアへ）
• 階層かいそう的てきエスカレーション — **上位じょうい管理かんり者しゃ**へ報告ほうこく・権限けんげん委譲いじょう依頼いらい（例れい: 大だい規模きぼ障害しょうがいなら IT 部長ぶちょうへ）

引ひっかけ: 機能きのう的てき = 専門せんもん（横よこ方向ほうこう）、階層かいそう的てき = 上司じょうし（縦たて方向ほうこう）。技術ぎじゅつ的てきに難むずかしい案件あんけんは機能きのう的てき、組織そしき的てき判断はんだんが必要ひつような案件あんけんは階層かいそう的てき。

3. ファシリティマネジメント

ファシリティマネジメントは「IT 設備せつびや物理ぶつり環境かんきょうを適切てきせつに管理かんりする」活動かつどう。サーバルームの空調くうちょう・電源でんげん・防火ぼうか、災害さいがい対策たいさく、データセンタの省しょうえねエネなどが対象たいしょうです。システムが動うごく**物理ぶつり的てきな基盤きばんを守まもらないと、どんなに優秀ゆうしゅうなソフトウェアも意味いみを成なしません。大だい規模きぼ災害さいがい（停電ていでん・地震じしん・水害すいがい）で業務ぎょうむが止とまらないよう、二重化にじゅうか・代替だいたい系けい・省しょうえねエネ**の設計せっけいが求もとめられます。

3.1 物理ぶつり環境かんきょうの管理かんり

サーバルーム・データセンタの**物理ぶつりセキュリティと設備せつび管理かんりは、IT サービス継続けいぞくの土台どだい。とくに電源でんげん管理かんりは最さい重要じゅうようで、瞬まどか停とま（一瞬いっしゅんの停電ていでん）でも機器ききが壊こわれたりデータが飛とぶリスクがあります。そのため多段ただん階かいの電源でんげんバックアップ**が標準ひょうじゅん設計せっけいになっています。

• サーバルーム — **空調くうちょう・電源でんげん・消火しょうか・入にゅう退室たいしつ管理かんり**を統合とうごうした専用せんよう設備せつび
• UPS（無む停電ていでん電源でんげん装置そうち） — 瞬まどか停とま（数すう分ふん〜10 分ぶん）対策たいさく。バッテリで一時いちじ的てきに給電きゅうでん、安全あんぜんにシャットダウンできる
• 自家じか発電はつでん装置そうち — 長時間ちょうじかん停電ていでん対策たいさく（数すう時間じかん〜数すう日にち）。ディーゼル発電はつでん機きなど
• 冗長じょうちょう化か電源でんげん（二に系統けいとう受電じゅでん） — 電力でんりょく会社かいしゃ系統けいとうを**二重化にじゅうか**（A 社しゃ + B 社しゃから受電じゅでん）
• ホットスタンバイ — 予備よび機きを常時じょうじ稼働かどうさせ、障害しょうがい時じに瞬時しゅんじ切替きりかえ

頻出ひんしゅつ: 電源でんげん対策たいさくの段階だんかい — 瞬まどか停とま対策たいさく = UPS、長時間ちょうじかん停電ていでん対策たいさく = 自家じか発電はつでん。この 2 つは**対応たいおう時間じかんスケールが違ちがう**ので役割やくわり分担ぶんたん。UPS は自家じか発電はつでんが起動きどうするまでの「つなぎ」としても機能きのうする。

3.2 環境かんきょうへの配慮はいりょ

IT 機器ききは**大量たいりょうの電力でんりょくを消費しょうひします。世界せかいのデータセンタの電力でんりょく消費しょうひ量りょうは、世界せかいの電力でんりょく消費しょうひの2% に達たっすると言いわれており、環境かんきょう配慮はいりょが経営けいえい課題かだいになっています。これを背景はいけいにグリーン IT・PUE 指標しひょう・省しょうえねエネ法ほう**などの概念がいねんが重視じゅうしされるようになりました。

• グリーン IT — 環境かんきょう負荷ふかを減へらす IT 活用かつよう（**省しょう電力でんりょく CPU・仮想かそう化かによる集約しゅうやく・クラウド移行いこう**など）
• PUE（Power Usage Effectiveness） — データセンタの**電力でんりょく効率こうりつ指標しひょう**（1.0 に近ちかいほど効率こうりつ的てき）
• 省しょうえねエネ法ほう — 一定いってい規模きぼ以上いじょうの事業じぎょう者しゃに**エネルギー使用しよう合理ごうり化か**を義務付ぎむづけ

PUE の計算けいさん: PUE = データセンタ全体ぜんたいの消費しょうひ電力でんりょく ÷ IT 機器ききの消費しょうひ電力でんりょく。1.0 なら IT 機器きき以外いがい（空調くうちょう・照明しょうめい）の電力でんりょくがゼロの理想りそう状態じょうたい。日本にっぽんの平均へいきんは約やく 1.7、先進せんしん的てきな施設しせつは 1.2 未満みまん。

4. システム監査かんさ

システム監査かんさは「情報じょうほうシステムが適切てきせつに運用うんようされているか、独立どくりつした第三者だいさんしゃが検証けんしょうする」活動かつどうです。会社かいしゃが IT に依存いぞんする時代じだいになり、システムが止とまる・情報じょうほうが漏もれる・不正ふせいが起おきるなどのリスクが経営けいえいを揺ゆるがすようになりました。これを**客観きゃっかん的てきにチェックする仕組しくみがシステム監査かんさで、上場じょうじょう企業きぎょうには金融きんゆう商品しょうひん取引とりひき法ほうで監査かんさが義務ぎむ化か**されています。

4.1 システム監査かんさの目的もくてき

情報じょうほうシステムが**安全あんぜん（セキュリティ）・効率こうりつ的てき（コスト適正てきせい）・効果こうか的てき（業務ぎょうむに役立やくだつ）に運用うんようされているか、独立どくりつした第三者だいさんしゃが検証けんしょうする活動かつどう。単たんなる技術ぎじゅつチェックではなく、経営けいえい目標もくひょうと IT の整合せいごう性せいを見みます。監査かんさ結果けっかは改善かいぜん指導しどうに活いかされ、健全けんぜんな IT 運営うんえい**に貢献こうけんします。

具体ぐたい例れい: ある企業きぎょうのシステム監査かんさで「バックアップは取とられているが、復元ふくげんテストが 3 年間ねんかんされていない」と指摘してきされたら、それは重大じゅうだいリスク。本当ほんとうに復元ふくげんできるか未み検証けんしょうのバックアップは、災害さいがい時じに使つかえない可能かのう性せいがあります。こうした運用うんよう上じょうの見落みおとしを発見はっけんするのが監査かんさの役割やくわり。

4.2 監査かんさ人じんの独立どくりつ性せい

監査かんさ人じん（Auditor）は、被ひ監査かんさ部門ぶもんと独立どくりつした立場たちばで検証けんしょうする必要ひつようがあります。同おなじ部署ぶしょの人ひとが監査かんさすると身内みうちの不正ふせいを見逃みのがしやすいため、客観きゃっかん性せいを担保たんぽする仕組しくみとして「独立どくりつ性せい」が 3 つの観点かんてんで求もとめられます。

• 外観がいかん上じょうの独立性どくりつせい — 被ひ監査かんさ部門ぶもんと組織そしき的てきに独立どくりつ（別べつ部署ぶしょ、あるいは社外しゃがいの第三者だいさんしゃ機関きかん）
• 精神せいしん上じょうの独立どくりつ性せい — 公正こうせい不偏ふへんな姿勢しせい（身内みうち贔屓ひいきせず、事実じじつのみで判断はんだん）
• 適格てきかく性せい — 専門せんもん知識ちしきと経験けいけん（IT と監査かんさの両方りょうほうに精通せいつう）

引ひっかけ: 監査かんさ人じんは被ひ監査かんさ部門ぶもんの業務ぎょうむを自みずから改善かいぜんしてはならない。改善かいぜんは被ひ監査かんさ部門ぶもんの責任せきにん、監査かんさ人じんは**指摘してきと助言じょげんのみ**。監査かんさ人じんが改善かいぜんまで関与かんよすると**独立どくりつ性せいが損そこなわれる**（「自分じぶんが作つくった仕組しくみを自分じぶんで監査かんさ」する状態じょうたいになる）。

4.3 監査かんさのプロセス

監査かんさは6 段階だんかいのプロセスで進すすみます。計画けいかくから実行じっこう、報告ほうこく、フォローアップまで体系たいけい化かされており、単発たんぱつではなく**継続けいぞく的てきな PDCA** として運用うんようされます。試験しけんでは**各かく段階だんかいで何なにをするか**が問とわれます。

1. 監査計画かんさけいかくの策定さくてい — 監査かんさ範囲はんい・スケジュール・手続てつづきを計画けいかく
2. 予備よび調査ちょうさ — 事前じぜん情報じょうほう収集しゅうしゅう（組織そしき図ず・業務ぎょうむフロー・システム構成こうせい）
3. 本ほん調査ちょうさ — 証拠しょうこ収集しゅうしゅう（インタビュー・文書ぶんしょ確認かくにん・実地じっちテスト・データ分析ぶんせき）
4. 評価ひょうか・結論けつろん — 収集しゅうしゅうした証拠しょうこに基もとづく判定はんてい
5. 報告ほうこく書しょ作成さくせいと提出ていしゅつ — 監査かんさ結果けっか・指摘してき事項じこう・改善かいぜん提案ていあんを文書ぶんしょ化か
6. 改善かいぜん指導しどう・フォローアップ — 指摘してき事項じこうの**改善かいぜん状況じょうきょうを後日ごじつ確認かくにん**

4.4 システム監査かんさ基準きじゅん・管理かんり基準きじゅん

経済けいざい産業さんぎょう省しょうが策定さくていした**監査かんさの拠より所どころとなる公的こうてき基準きじゅんが 2 つあります。「監査かんさする側がわの行動こうどう規範きはん」と「監査かんさされる側がわの管理かんり項目こうもく」という監査かんさ人じん / 被ひ監査かんさ者しゃの両面りょうめん**から基準きじゅんが作つくられています。

• システム監査かんさ基準きじゅん — 監査かんさ人じんの行為こうい規範きはん（経済けいざい産業さんぎょう省しょう策定さくてい）
• システム管理かんり基準きじゅん — 情報じょうほうシステムの管理かんり項目こうもくのチェックリスト（経済けいざい産業さんぎょう省しょう策定さくてい、被ひ監査かんさ者しゃ向むけ）

5. 内部ないぶ統制とうせいと IT ガバナンス

内部ないぶ統制とうせいは「会社かいしゃ自身じしんが不正ふせいや誤あやまりを防ふせぐ仕組しくみ」。上場じょうじょう企業きぎょうには法律ほうりつで義務付ぎむづけられており、監査かんさとは別べつに**組織そしき内部ないぶでの継続けいぞく的てきな統制とうせい活動かつどうが求もとめられます。特とくに財務ざいむ報告ほうこくの信頼しんらい性せい**を担保たんぽする J-SOX 制度せいど（内部ないぶ統制とうせい報告ほうこく制度せいど）は、日本にっぽんの上場じょうじょう企業きぎょう全社ぜんしゃに適用てきようされています。

5.1 内部ないぶ統制とうせいの 4 つの目的もくてき

内部ないぶ統制とうせいは**4 つの目的もくてき**を達成たっせいするための仕組しくみ。金融きんゆう庁ちょうの「財務ざいむ報告ほうこくに係かかる内部ないぶ統制とうせいの評価ひょうか及および監査かんさの基準きじゅん」で定義ていぎされています。経営けいえい層そうが主導しゅどうし、全ぜん社員しゃいんが役割やくわりを持もって取とり組くみます。

1. 業務ぎょうむの有効ゆうこう性せい・効率こうりつ性せい — 業務ぎょうむが目的もくてきに沿そって効率こうりつ的てきに行おこなわれているか
2. 財務ざいむ報告ほうこくの信頼性しんらいせい — 決算けっさん書しょに嘘うそがないか（最さい重要じゅうよう、J-SOX の中核ちゅうかく）
3. 関連かんれん法規ほうきの遵守じゅんしゅ — コンプライアンス
4. 資産しさんの保全ほぜん — 会社かいしゃ資産しさん（現金げんきん・在庫ざいこ・情報じょうほう）が守まもられているか

5.2 内部ないぶ統制とうせいの基本きほん要素ようそ（COSO フレームワーク）

COSO フレームワークは、国際こくさい的てきな内部ないぶ統制とうせいの教科書きょうかしょ。米国べいこくで策定さくていされ世界せかい的てきに採用さいようされています。日本にっぽんの J-SOX もこれに準拠じゅんきょしつつ、**「IT への対応たいおう」を 6 番ばん目めに独自どくじ追加ついか**しているのが特徴とくちょうです。

1. 統制とうせい環境かんきょう — 組織そしき文化ぶんか・倫理りんり観かんの土台どだい
2. リスク評価リスクひょうか — リスクを特定とくてい・分析ぶんせき・評価ひょうか
3. 統制とうせい活動かつどう — 不正ふせい防止ぼうしのための手続てつづき（承認しょうにん・分掌ぶんしょう等とう）
4. 情報じょうほうと伝達でんたつ — 必要ひつような情報じょうほうを関係かんけい者しゃに伝達でんたつ
5. モニタリング — 内部ないぶ統制とうせいの有効ゆうこう性せいを継続けいぞく監視かんし
6. IT への対応たいおう — 日本にっぽん独自どくじの追加ついか項目こうもく（IT 依存いぞんの時代じだいへの対応たいおう）

頻出ひんしゅつ: 「IT への対応たいおう」は COSO にない日本にっぽん版ばん独自どくじの 6 つ目め要素ようそ。金融きんゆう商品しょうひん取引とりひき法ほうに基もとづく日本にっぽん版ばん SOX（J-SOX）で追加ついかされた。国際こくさいフレームワークに日本にっぽん流りゅうアレンジを加くわえた形かたち。

5.3 主おもな内部ないぶ統制とうせい関連かんれん制度せいど

内部ないぶ統制とうせいに関連かんれんする制度せいど・フレームワークは複数ふくすうあり、それぞれ**役割やくわりが違ちがいます**。COSO は国際こくさい的てきな内部ないぶ統制とうせいの枠組わくぐみ、J-SOX は日本にっぽんの法律ほうりつ、COBIT は IT ガバナンスの枠組わくぐみ、のように整理せいりすると混乱こんらんしません。

制度せいど	内容ないよう	主体しゅたい
J-SOX（内部ないぶ統制とうせい報告ほうこく制度せいど）	金融きんゆう商品しょうひん取引とりひき法ほうに基もとづく、上場じょうじょう企業きぎょうの内部ないぶ統制とうせい評価ひょうか	日本にっぽん（法律ほうりつ）
COSO	国際こくさい的てきな内部ないぶ統制とうせいフレームワーク	米国べいこく（自主じしゅ基準きじゅん）
COBIT	IT ガバナンスのフレームワーク	ISACA（自主じしゅ基準きじゅん）

頻出ひんしゅつ: J-SOX は日本にっぽんの法律ほうりつ・義務ぎむ、COSO は国際こくさい標準ひょうじゅんのフレームワーク、COBIT は IT ガバナンス専用せんよう。3 つを混同こんどうしないように。日本にっぽんの上場じょうじょう企業きぎょうに強制きょうせいされるのは J-SOX。

5.4 IT ガバナンス

IT ガバナンスは「経営けいえい戦略せんりゃくと IT を整合せいごうさせ、IT 投資とうしの効果こうかを最大さいだい化かする統制とうせい活動かつどう」。IT は経営けいえいの根幹こんかんを支ささえる時代じだいになりましたが、現場げんばの IT 部門ぶもんが勝手かってに投資とうしするのではなく、経営けいえい層そうが主導しゅどうして方向ほうこう性せいを決きめるのが IT ガバナンスの要点ようてんです。

• IT 戦略せんりゃく委員いいん会かい — 経営けいえいと IT を結むすぶ意思いし決定けってい機関きかん（経営けいえい陣じん + IT 部門ぶもんの合同ごうどう委員いいん会かい）
• CIO（Chief Information Officer） — 最高さいこう情報じょうほう責任せきにん者しゃ。IT ガバナンスの責任せきにん者しゃ
• CISO（Chief Information Security Officer） — 最高さいこう情報じょうほうセキュリティ責任せきにん者しゃ（セキュリティ専門せんもん）

具体ぐたい例れい: 企業きぎょうのデジタル変革へんかく（DX）推進すいしんで「基幹きかんシステムをクラウド化かするか、オンプレで残のこすか」のような大おおきな判断はんだんは、IT 部門ぶもんだけでは決きめられません。経営けいえい戦略せんりゃく・投資とうし規模きぼ・リスク許容きょよう度どを総合そうごう判断はんだんする **IT 戦略せんりゃく委員いいん会かいで決定けってい**し、CIO が遂行すいこう責任せきにんを持もちます。

5.5 職務しょくむ分掌ぶんしょう

開発かいはつと運用うんようを分離ぶんり、申請しんせいと承認しょうにんを分離ぶんりなど、権限けんげんの集中しゅうちゅうを防ふせぐ仕組しくみ。内部ないぶ統制とうせいの基本きほん。1 人ひとが「何なにでもできる」状態じょうたいは不正ふせいの温床おんしょうになるので、業務ぎょうむを複数ふくすうの役割やくわりに分わけ、相互そうごチェックを効きかせる。

⚠ NG（職務しょくむ集中しゅうちゅう）	✓ OK（職務しょくむ分掌ぶんしょう）
1 人ひとが全部ぜんぶできる ・開発かいはつ・本番ほんばんリリース ・申請しんせい・承認しょうにん ・記録きろく改かいざんも可能かのう → 不正ふせいの温床おんしょう	役割やくわりを分離ぶんりして相互そうごチェック ・開発かいはつ ↔ 運用うんよう ・申請しんせい ↔ 承認しょうにん ・記帳きちょう ↔ 出納すいとう ・注文ちゅうもん ↔ 検収けんしゅう

「権限けんげんを分離ぶんり → 相互そうごチェック」が原則げんそく。

頻出ひんしゅつ引ひっかけ: **「開発かいはつ担当たんとう者しゃが本番ほんばんシステムにそのまま変更へんこうを反映はんえいできる」**は職務しょくむ分掌ぶんしょう違反いはんの代表だいひょう例れい。本番ほんばん反映はんえいには別べつの運用うんよう担当たんとう者しゃの承認しょうにん・実施じっしを要ようするのが内部ないぶ統制とうせいの基本きほん。

📋 章しょう末まつまとめ

最さい重要じゅうようポイント 10 連発れんぱつ

1. SLA と SLM の違ちがい — 合意ごうい書しょと継続けいぞく的てき管理かんり
2. インシデント vs 問題もんだい管理かんり — 早期そうき復旧ふっきゅう vs 根本ねもと原因げんいん
3. CMDB — 構成こうせい情報じょうほうの一元いちげん管理かんりデータベース
4. サービスデスクの型かた — ローカル・中央ちゅうおう・バーチャル・フォロー・ザ・サン
5. UPS の役割やくわり — 瞬まどか停とま対策たいさく（長時間ちょうじかんは自家じか発電はつでん）
6. PUE の意味いみ — 1.0 に近ちかいほど効率こうりつ的てき
7. システム監査かんさの独立どくりつ性せい — 外観がいかん上じょう・精神せいしん上じょう
8. J-SOX の目的もくてき — 財務ざいむ報告ほうこくの信頼しんらい性せい確保かくほ
9. COSO の 5（+1）要素ようそ — 日本にっぽんでは IT 対応たいおうが追加ついか
10. 職務しょくむ分掌ぶんしょう — 開発かいはつと運用うんようを分離ぶんり

出題しゅつだい傾向けいこうのコツ

• インシデント管理かんりと問題もんだい管理かんりの違ちがいは頻出ひんしゅつ
• SLA は「サービス品質ひんしつを数値すうちで約束やくそくする文書ぶんしょ」と覚おぼえる
• 監査かんさは「第三者だいさんしゃの視点してん」がキーワード