SGでは、機器の一覧から構成の関係へ視点を広げる
情報資産の管理と構成管理は関連しますが、同じ見出しの一覧を作れば両方が完了するわけではありません。まず何を持ち、誰が管理しているかを整理し、その上で、サービスを成り立たせる要素の版・設定・関係を追えるようにします。資産を財務上の物品だけに限定したり、構成管理を機器の台数確認だけに限定したりしないことが出発点です。
現行SGシラバスVer.4.1のサービスマネジメントには、資産管理、構成管理、構成品目などの用語が挙がっています。この記事は情報資産台帳の作り方を繰り返すのではなく、構成品目の単位、要素間の関係、基準と実態の不一致を読む学習に絞ります。公式問題の再現や、特定の構成管理製品の操作手順ではありません。
業務で合意する水準の学習はSGのSLAとサービスレベル管理へ。依存する構成と、利用者への約束を区別して整理できます。 購入した利用権と実際の割当を照合する学習はSGのソフトウェアライセンス管理で、人数・台数・契約の単位を分けて確認できます。 容量不足を調べる学習はSGの容量・能力管理と性能の測り方で、要求・処理・応答と時間帯を対応付けます。 データベースで更新を一緒に確定する仕組みと競合の扱いはSGのトランザクションと排他制御で、構成を記録するCMDBとは別の観点として学べます。
構成品目（CI）は、管理する目的に合わせて単位を決める
CIはConfiguration Itemの略で、構成管理の対象として指定し、一つの単位として扱う要素やそのまとまりです。NISTの用語集でも、単一の小さな要素からシステム全体まで、定義の文脈に応じた粒度が示されています。「必ずサーバ1台が1件」「物理的に触れるものだけ」と覚えると、サービスやソフトウェアの関係を読めなくなります。
例えば「経費精算サービス」を上位の管理対象とし、認証連携、申請アプリ、保存先などを関連する対象として識別する考え方があります。何でも細分化すればよいのではなく、変更の影響や責任の所在を追うために必要な粒度を決めます。まとめた単位と内訳を混同せず、識別子、属性、他の対象との関係を対応付けて読みます。
架空ケース：ログインと通知では、業務への影響が違う
会社Yでは、経費精算サービスに社内の認証基盤でログインし、申請アプリから添付書類を保存します。承認待ちの案件は画面の一覧に表示され、同時にメール通知も送ります。このケースでは、メールが届かなくても一覧から承認できますが、新たなログインには認証基盤が必要という条件にします。
「つながっている」とだけ記録すると、全てが止まるのか、一部の利便性が落ちるのかを区別できません。関係の種類、影響する機能、確認した条件を残します。認証停止の影響も、既存のログイン状態がどう扱われるかは別途確認が必要です。図から全利用者が直ちに使えなくなるとまでは結論にしません。
経費精算サービス
新規ログイン・申請・承認を提供
認証基盤
新規ログインで利用。既存セッションへの影響は未確認。
申請アプリ
申請内容を処理し、承認待ちを画面に表示。
添付書類の保存先
書類の保存・閲覧で利用。必要な権限も確認。
メール通知
補助的な通知。届かなくても一覧で承認できる。
依存先の名前だけでなく、どの機能がどんな条件で影響を受けるかを読む。
当サイト独自の架空ケース。中央との関係を簡略表示した図で、通信経路・処理順序・冗長化や全ての相互依存を表すものではありません。
ベースライン・構成記録・実態を、同じものとして扱わない
ベースライン構成は、ある時点で正式にレビュー・合意された仕様を基準として扱い、変更管理の手続きを経て変更するものです。単に直近に取得した設定のコピーとは限りません。どの対象の、どの版の基準かを押さえ、プロジェクトの範囲や日程のベースラインとも対象を区別します。
会社Yの認証連携について、承認済みの仕様はB、台帳の記録はA、現在の設定を確認した記録はBだったとします。これだけで「無断変更があった」とは言い切れません。承認と適用の時点、確認方法、記録の更新経緯を照合すると、台帳への反映が遅れている可能性もあります。逆に台帳にBと書かれていても、実際の適用を確認した証拠にはなりません。
承認された基準
- 仕様B
- 対象・版・承認時点を確認
- 変更の根拠と適用条件を追う
構成記録
- 台帳にはAと記載
- 記録の確認日と更新履歴を確認
- 記載だけで現物を確定しない
確認した実態
- 観測記録ではB
- 対象・時点・確認方法を確認
- 観測だけで承認済みとしない
不一致は調査の入口。古い記録・適用待ち・未承認の変更などを、証拠で切り分ける。
架空のA・Bは設定の版を表す記号で、安全性の優劣ではありません。この図だけでは不一致の原因や対応方法は確定しません。
CMDBは記録を関連付ける仕組みで、正しさの保証ではない
CMDBはConfiguration Management Databaseの略で、構成管理の情報を扱うデータベースを指します。製品の実装例として、MicrosoftのService ManagerはCIとインシデント・変更要求等を関連付けて管理します。同社のサービス構成の説明でも、依存関係が影響分析の材料になることを確認できます。ただし、特定製品の機能や登録対象を、そのまま全組織共通の必須仕様とはしません。
自動収集した値にも、取得できる範囲、最終同期時点、識別の重複、手入力の関係が残ります。会社Yで通知サービスだけが一覧から漏れていたなら、登録件数が合っているかより、通知機能との関係が確認できるかを調べます。ツールを導入した事実と、情報の信頼性を維持する運用は別の確認対象です。
同じ「Bを承認した」という情報でも、適用予定日が翌日なら、今日の実態がAであることだけで異常とは判断できません。反対に、適用完了の報告があり、対象環境と時点をそろえた観測でもAのままなら、適用結果を確認する必要があります。承認、作業報告、観測の三つは、それぞれ裏付ける事実が違います。
また、認証基盤そのものは同じでも、接続先の環境や認証方式が変われば、利用関係の記録を見直す必要があります。識別子が一致したという理由だけで影響なしと決めないようにします。図で「認証基盤につながる」と読めたら、次はどの環境のどの連携を指すのか、今回の変更がその関係へ届くのかを確認します。これらは会社Yの架空例に条件を追加した学習であり、実システムの不具合を示す情報ではありません。
不一致のケースを、根拠を残す確認シートへ変える
会社Yの例を読むときは、「AとBが違う」という発見に、どの対象か、いつの値か、どの承認と比べたかを添えます。新しい値を古い記録へ無言で転記すると、相違の原因を追う材料がなくなります。調査中の状態と、確認後に確定した状態を分けて残す考え方が重要です。
実際に差異を見つけた場合の適用・停止・復元は、組織の権限と手順に従います。この記事は本番設定を直ちに変更する指示ではありません。受験の復習では、下のシートにケースの事実を埋め、資料だけでは分からない欄を「未確認」として残す練習に使ってください。
| 観点 | 残す情報 | 早合点を避ける点 |
|---|---|---|
| 対象 | CIの識別子・対象サービス・環境 | 別の環境や同名の対象と比較しない |
| 基準 | 承認した仕様・版・日時・条件 | 最新版という名前だけで承認を判断しない |
| 記録 | 台帳の値・確認日・更新経緯 | 台帳と実態を同一視しない |
| 観測 | 確認した値・時点・確認方法 | 観測値だけで無断変更と決めない |
| 影響 | 関係する機能・利用者・確認範囲 | 関係図だけで全停止や原因を断定しない |
SGの復習では、構成・変更・サービス水準をつなぐ
構成管理の情報は、何がどうつながり、どの状態を基準にしているかを考える材料です。変更管理の確認手順では影響・承認・確認の進め方へ、SLAとサービスレベル管理では利用者と合意した水準へつなげてください。サービスの構成と、提供を約束した水準は同じ記録ではありません。
学習範囲はSGシラバスの学習案内で確認できます。理解した言葉を別の状況でも使えるか、SGの登録不要の無料6問で確かめてください。SG対策の教材・料金は学習サービスの案内で、公式試験の申込みや、企業システムの運用代行ではありません。