【真面目版】基本情報技術者試験対策:サービスマネジメントとシステム移行をわかりやすく解説!

情報セキュリティのポスター #1

情報セキュリティのポスター #2

目次

はじめに

幽灯子/基本情報技術者副専門官

「基本情報技術者試験(FE)」は、ITエンジニアを目指す人にとって登竜門ともいえる国家資格です。その試験範囲の中に「サービスマネジメント」と「システム移行」という分野があります。名前を聞いただけで難しそう…と感じるかもしれませんが、実は私たちの日常生活でもよく見られる考え方が土台になっています。

この記事では、一般の方にもわかりやすいように、具体的な例を交えながら解説します。


第1章:サービスマネジメントとは?

サービスマネジメントの基本的な考え方

「サービスマネジメント」とは、一言でいうと 「ITサービスをきちんと管理・運営していくための仕組み」 のことです。

たとえば、会社で使っている「メールシステム」や「勤怠管理システム」などを想像してください。これらのシステムが止まってしまったら、業務が大きく滞ってしまいます。そうならないように、日々の管理・監視・対応を行うのがサービスマネジメントの役割です。

試験では、「ITIL(アイティル)」という国際的なベストプラクティス集がよく登場します。ITILはITサービスを安定して提供するための「ガイドブック」のようなもので、世界中の企業で活用されています。


インシデント管理:障害が起きたらどうする?

インシデント管理とは、ITシステムに何らかの問題が発生したとき(=インシデント)に、できるだけ早くサービスを元の状態に戻すための管理プロセスです。

【具体例】
会社のメールが突然届かなくなった!という状況を考えましょう。

  1. ユーザーがヘルプデスクに問い合わせる
  2. 担当者が状況を把握・記録する
  3. 原因を調査し、暫定対応(とりあえずの解決策)を実施
  4. サービスを復旧させる
  5. 復旧後も経緯を記録して管理する

ポイントは「根本的な原因を直すことよりも、まずサービスを早く復旧させることを優先する」という点です。根本原因は後で「問題管理」として別途対応します。


問題管理:再発防止のために

問題管理は、インシデントの根本原因を調査・分析し、再発を防ぐための管理プロセスです。

インシデント管理が「消火活動」だとすれば、問題管理は「なぜ火が出たのか原因を調べて、二度と火事が起きないようにする活動」といえます。

試験でよく問われる用語として「既知のエラー(Known Error)」があります。これは「原因はわかっているが、まだ解決していない問題」のことで、次にインシデントが起きた際の暫定対応手順として活用されます。


変更管理:システムの変更を安全に行う

ITシステムはずっと同じ状態ではなく、機能追加や修正を繰り返して進化していきます。この「変更」を計画的・安全に行うための仕組みが変更管理です。

変更管理で重要なのは「RFC(Request For Change:変更要求)」というドキュメントです。変更を行う前に、「何を・なぜ・どのように変更するのか」「リスクはないか」「問題が起きたときにどうやって元に戻すか(ロールバック計画)」などを事前に確認・承認します。


サービスレベル管理:サービス品質の約束

**サービスレベル管理(SLM)**では、ITサービスの品質について、提供者と利用者の間で事前に合意を結びます。この合意書を「SLA(Service Level Agreement:サービスレベル合意書)」と呼びます。

SLAの例:

  • システムの稼働率を99.9%以上維持する
  • 障害発生時は1時間以内に対応を開始する
  • ヘルプデスクへの問い合わせは24時間以内に回答する

SLAがあることで、利用者は「どの程度のサービスが受けられるか」を把握でき、提供者も「何を守れば良いか」が明確になります。


キャパシティ管理とパフォーマンス管理

キャパシティ管理とは、今後のIT需要の増加に備えて、システムリソース(CPU・メモリ・ストレージなど)の容量を適切に計画・管理することです。

たとえば「来年度は社員が100人増える予定なので、サーバーの容量を増やしておこう」というような活動がこれに当たります。需要を先読みしてリソースを確保することで、突然のシステム過負荷を防ぎます。


第2章:システム移行とは?

システム移行の基本的な考え方

システム移行とは、現在使っているシステムを新しいシステムへ切り替えることです。古くなったシステムをリニューアルしたり、オンプレミス(自社サーバー)からクラウドへ移行したりする際に発生します。

システム移行は会社にとって一大イベントです。失敗すると業務が止まるリスクがあるため、入念な計画と段階的な実施が求められます。


移行方式の種類

試験によく出るのが、移行の「やり方(方式)」です。代表的なものを4つ紹介します。

① 一斉移行(コールドターキー移行)
旧システムを完全に止めてから、一度に新システムへ切り替える方法です。

  • メリット:移行が一度で終わり、管理がシンプル
  • デメリット:移行中はサービスが使えない。失敗したときのリスクが高い

② 段階的移行(フェーズ移行)
システムの機能や部門を少しずつ移行していく方法です。

  • メリット:問題が起きても影響範囲が小さい
  • デメリット:移行期間が長くなり、旧・新両方のシステムを並行して管理する必要がある

③ 並行運用(パラレル移行)
新旧システムを一定期間同時に動かしながら、動作確認が取れたら旧システムを止める方法です。

  • メリット:新システムで問題が起きても旧システムで業務を続けられる。安全性が最も高い
  • デメリット:コストと運用の手間が二重にかかる

④ パイロット移行
まず一部の拠点や部門だけで新システムを試験的に導入し、問題がなければ全社展開する方法です。

  • メリット:小さな範囲でリスクを検証できる
  • デメリット:展開に時間がかかる

データ移行の重要性

システムを新しくするときは、今まで蓄積してきたデータも移し替える必要があります。これをデータ移行と呼びます。

データ移行で注意すべきポイントは以下のとおりです。

  • データ変換:旧システムと新システムでデータの形式が異なる場合、変換処理が必要
  • データクレンジング:移行前に、不要・重複・不正なデータを整理・削除する
  • 移行テスト:本番移行前に、テスト環境で移行のリハーサルを行う
  • 移行後の検証:移行後、データが正しく移っているか確認する

移行計画と切り戻し(ロールバック)

どんなに準備を万全にしても、移行後に想定外のトラブルが起きることがあります。そのため、切り戻し(ロールバック)計画を事前に用意しておくことが重要です。

切り戻し計画とは「何か問題が起きたとき、旧システムに素早く戻せるようにしておく手順書」のことです。試験でも「移行計画には切り戻し手順を含めるべきか」という問いがよく出ます。答えはもちろん「含めるべき」です。


第3章:試験で押さえるべきキーワードまとめ

用語意味
インシデントサービスの中断・品質低下などの問題事象
問題(Problem)インシデントの根本原因
RFC変更要求書(Request For Change)
SLAサービスレベル合意書(提供者と利用者の品質契約)
キャパシティ管理リソース容量の計画・管理
一斉移行旧システムを止めて一度に新システムへ切替
並行運用旧・新システムを同時稼働させながら移行
ロールバック問題発生時に旧システムへ戻すこと
データクレンジング移行前のデータ整理・クリーニング

おわりに

サービスマネジメントとシステム移行は、「どうやってITサービスを安定して提供し続けるか」という非常に現実的なテーマを扱っています。試験勉強として覚えるだけでなく、「もし自分が担当者だったらどう対応するか?」と考えながら学ぶと、理解がぐっと深まります。

基本情報技術者試験は、暗記だけでなく考える力も問われます。この記事で解説したサービスマネジメントとシステム移行の考え方をしっかり理解して、試験合格を目指しましょう!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

ITTIのアバター ITTI 運営長

ITTI運営長
調べものと学ぶことが止められなくなり、現在は以下の4ブログを運営中:
・DXブログ(今ここ!)
・CODEブログ
・INFRAブログ
・XRブログ

保有資格:ITパスポート
目標資格:情報処理安全確保支援士(学ぶこと多すぎて道のりは遠いですが、毎日コツコツ進めています…泣)

ブログでは、実務経験と最新技術を掛け合わせて、読者の「わかりにくい」を「わかる!」に変える記事を発信中!
最終目標は、これらの知識を活かして「ドラえもんのような万能AI」を開発すること(AIを副運営長任命が待ち遠しい!)。
DX・CODE・INFRA・XRに興味ある方、気軽にX(@llEqmDGOYZ4258)でDMください。一緒に学びましょう!

IT企業のAIイラスト #1

IT企業のAIイラスト #2

IT企業のAIイラスト #3

コメント

コメントする

CAPTCHA


目次