この章で学ぶこと

情報セキュリティ担当者は、対策を「導入して終わり」にはできません。プロジェクトとして計画的に進め（プロジェクトマネジメント）、日々のサービスとして安定運用し（サービスマネジメント）、その運用が正しく回っているかを第三者の目でチェックする（システム監査）——この3つが揃って初めて、対策が形骸化せずに機能し続けます。

プロジェクトマネジメント

新しいセキュリティ対策の導入や規程の改定は、多くの場合1つのプロジェクトとして進みます。まず、プロジェクトが誰のために・何を目指すのかという方向性を示すプロジェクトガバナンス、立ち上げから終結までの一連の流れであるプロジェクトライフサイクルを押さえます。関係者を把握するステークホルダの特定とその調整、やるべき作業の範囲を決めるスコープの定義、それを階層的に分解して洗い出すWBS（作業分解構造）という順序で計画を具体化していきます。

スケジュールは、作業の順序や依存関係を踏まえて所要時間を見積もるPERTで組み立て、コストは予算の基準線となるコストベースラインで管理します。プロジェクト全体に共通するリスクと個別作業のリスク（プロジェクトの全体リスクと個別リスク）を洗い出し、リスクへの対応を検討する点は、第2章で学んだリスクマネジメントの考え方がそのまま応用できます。外部のベンダーを使う場合は調達の計画と供給者の選定、関係者への報告・共有を行うコミュニケーションのマネジメントも欠かせません。

扱う用語（精選・16語）

• プロジェクト／プロジェクトガバナンス／プロジェクトライフサイクル
• ステークホルダの特定／ステークホルダのマネジメント
• スコープの定義／WBS（作業分解構造）
• PERT／コストベースライン
• プロジェクトの全体リスクと個別リスク／リスクへの対応
• 調達の計画／供給者の選定
• コミュニケーションのマネジメント／得た教訓の収集／プロジェクト憲章の作成

深掘り: WBS・見積り・ガントチャート・クリティカルパスまで一気に整理

サービスマネジメント

対策を導入した後は、日々のサービスとして安定的に運用し続ける必要があります。サービス提供者と利用者の間で品質水準を合意するSLA（サービスレベル合意書）と、その中で定める具体的な数値目標であるサービスレベル目標はセットで理解します。提供するサービスの一覧であるサービスカタログ、構成品目（CI）を管理する構成管理、需要の変動に備える需要管理と容量・能力管理も運用の基本です。

システムに変更を加える際は、影響を事前に評価する変更管理を経てからリリース及び展開管理に進みます。障害対応の中心となるのがインシデント管理と問題管理で、この2つの違いは次のコラムで詳しく扱います。サービスが止まらないようにする備えとしては、目標復旧時間であるRTOと目標復旧時点であるRPO、常時稼働の予備系であるホットスタンバイと障害時に起動するコールドスタンバイを対比で押さえます。評価と改善はパフォーマンス評価と継続的改善という、第2章のISMSと同じPDCA発想で回します。利用者からの問い合わせ窓口であるサービスデスク、電源や空調などの設備を管理するファシリティマネジメントも押さえておきます。

扱う用語（精選・21語）

• SLA（サービスレベル合意書）／サービスレベル目標／サービスカタログ
• 構成管理（CI）／需要管理／容量・能力（キャパシティ）管理
• 変更管理／リリース及び展開管理
• インシデント管理／問題管理（既知の誤り，根本原因，予防処置）
• サービス可用性管理／サービス継続管理／RTO／RPO
• ホットスタンバイ／コールドスタンバイ
• パフォーマンス評価／継続的改善
• サービスデスク／ファシリティマネジメント

深掘り: SLA・SLO・SLIとプロジェクト管理5用語まとめ

現場のワンシーン: なぜ「インシデント管理」と「問題管理」は別物なのか

ある朝、社内システムにログインできないという問い合わせが複数の部署から相次いだとします。担当者はまず、利用者がすぐに業務を続けられるよう、パスワードの再発行や別環境への切り替えといった応急対応を行い、システムを復旧させます。これがインシデント管理の役割で、目的は「とにかく早く元に戻す」ことです。

しかし、応急対応をしただけでは、同じ問題が翌週また起きるかもしれません。そこで「そもそもなぜログインできなくなったのか」という根本原因を調査し、恒久的な対策を講じるのが問題管理の役割です。原因が判明するまでの暫定的な対処法は回避策として、根本原因が特定できた状態は既知の誤りとして記録・管理します。

「インシデント管理は火を消す仕事、問題管理は火の原因を絶つ仕事」と分けて覚えると、なぜ同じような場面で2つの管理プロセスが必要なのかが理解できます。

システム監査と内部統制

システムが適切に運用されているかを、運用者自身ではなく独立した立場から評価するのがシステム監査です。監査を担う人には、対象部門から独立していることを示す監査の独立性と客観性の保持、公正に判断する監査人の倫理が求められ、結論の根拠となる監査証拠の入手と評価を経て報告に至ります。監査には目的別の種類があり、次の3つを区別しておくと出題対応がしやすくなります。

監査とあわせて理解しておきたいのが内部統制です。権限を1人に集中させず複数人で分担する職務分掌は、不正や誤りを一人では実行・隠蔽できない仕組みを作る代表的な統制活動です。日々の業務の中でルールが守られているかを継続的に見張るモニタリング、組織自身が自分の統制状況を点検するCSA（統制自己評価）もあわせて押さえておきます。

扱う用語（精選・11語）

• システム監査の目的と手順／監査の独立性と客観性の保持／監査人の倫理／監査証拠の入手と評価
• 情報セキュリティ監査基準／コンプライアンス監査
• 内部統制／職務分掌／統制活動／モニタリング
• CSA（統制自己評価）

AIで学ぶ

ここまでの用語は、ChatGPTやClaudeなどの生成AIに以下のプロンプトを投げかけると、比較表つきでさらに深く掘り下げて学習できます。コピーして使ってみましょう。

あなたは情報セキュリティマネジメント試験の講師です。「マネジメント（プロジェクト・サービス・監査）」の範囲について、以下の用語を初学者向けに**関連づけながら**説明してください（単体の丸暗記より、用語同士のつながりを理解したほうが記憶に定着しやすく、試験本番で紛らわしい選択肢を見分ける力もつくためです）。用語同士の違いが分かる**比較表**を最後に付けてください。

【プロジェクトマネジメント】プロジェクトガバナンス、ステークホルダ、スコープの定義、WBS、PERT、コストベースライン、プロジェクトリスク、調達の計画
【サービスマネジメント】SLA、サービスレベル目標、構成管理、需要管理、変更管理、リリース及び展開管理、インシデント管理、問題管理、RTO、RPO、ホットスタンバイ、コールドスタンバイ
【システム監査と内部統制】システム監査、監査の独立性、監査人の倫理、情報セキュリティ監査、コンプライアンス監査、内部統制、職務分掌、CSA

このプロンプトが「役割」「関連づけ」「出力形式」の3点を指定しているのは、AIに丸投げで質問すると単語の説明が羅列されるだけになりやすいからです。慣れてきたら、この3点（誰の立場で答えさせるか・どう説明させるか・どう受け取るか）を自分で組み立てられるようにしておくと、他の章や他の資格でも応用できます。

章末チェック

最後に、この章で学んだ知識をアウトプットして定着させましょう。全問に答えたら「答え合わせ」を押してください。

この章のまとめ

この章では、プロジェクトとして対策を計画・実行する視点、日々のサービスとして安定運用する視点、そして独立した立場からチェックする監査・内部統制の視点を学びました。WBS・ガントチャート・クリティカルパス・SLA/SLOを「計画→スケジュール化→遅延回避→品質保証」という一連の流れとして整理し直したい場合は、プロジェクト計画からサービス運用まで｜5用語のつながりを整理するも参考にしてください。

次章では、経営層の視点に立ち返り、経営・システム戦略という、組織全体の方向性を決める知識を学びます。→ 第7章 経営・システム戦略