１．サービスデスク
サービスデスクは，ユーザからの問合せ窓口である。ヘルプデスクやカスタマーサポート，コールセンタという言葉のほうが馴染み深いかもしれない。
また，試験センターからのシラバスでは次のような説明がある。
サービスデスクには次の3つの形態があります。
①ローカルサービスデスク
拠点ごとにサービスデスクを設置する形態です。過去問（H27秋FE問55）では「サービスデスクを利用者の近くに配置することによって，言語や文化が異なる利用者への対応，専用要員によるVIP対応などができる」と述べられています。
②中央（セントラル）サービスデスク
複数拠点を統括し、1拠点で集中的に問い合わせを受け付ける形態です。過去問（H27秋FE問55不正解選択肢）では「サービスデスクを1拠点又は少数の場所に集中することによって，サービス要員を効率的に配置したり，大量のコールに対応したりすることができる」と述べられています。
③バーチャルサービスデスク
物理的に分散していても、ユーザから見ると仮想的（バーチャル）に1カ所でサポートしているかのように思わせる形態です。過去問（H27秋FE問55不正解選択肢）では「サービス要員は複数の地域や部門に分散しているが，通信技術を利用することによって，単一のサービスデスクであるかのようにサービスが提供できる。」と述べられています。
２．インシデント管理
インシデント管理は障害管理と置き換えると分かりやすい。ただ，厳密には“インシデント”という概念が“障害”とは多少異なるので注意する。
また，試験センターからのシラバスでは次のような説明がある。
過去問（H22春FE午前）をみてみましょう。
【解説】
インシデントには問合せを含む場合もあります。しかし、基本的には、障害などのサービス品質の低下を引き起こすものがインシデントです。単なる「使い方に対する問合せ」などはインシデントにはなりません。
正解はウです。アプリケーションの応答の大幅な遅延は、サービス品質の大幅な低下を引き起こしていますから、インシデント管理で対応すべき事象です。
３．問題管理
インシデント管理でも述べたが，問題管理は「根本原因の究明と解決」を行うプロセスである。
また，試験センターからのシラバスでは次のような説明がある。
問題管理では、大きく「問題コントロール」と「エラー・コントロール」の2つの活動があります。「未知の問題」、「既知のエラー」という言葉と合わせて理解しましょう。
①問題コントロール
問題とは「インシデントの未知の根本原因」であり、「未知」の問題という点がポイントです。この問題を対処しようにも、「未知」の問題なので対処の方法が分からないのです。そこで、「未知」の根本原因を「既知」の根本原因にし、対処可能にする活動が問題コントロールです。
②エラー・コントロール
問題コントロールによって把握できた「既知」の根本原因を解決するのがエラー・コントロールです。
なので、未知の根本原因が「問題」で、既知の根本原因が「エラー」と考えることもできます。過去問（H26年春午前問56）では、「ITサービスマネジメントにおける“既知の誤り（既知のエラー）”の説明」として、「根本原因が特定されている又は回避策が存在している問題」と述べられています。
過去問(H20春SW午前）を見てみましょう。
【解説】
アは、インシデント管理プロセスの説明です。
イは、ITサービス継続性管理プロセスの説明です。
ウは正解です。問題管理プロセスは，インシデントの根本原因を究明します。インシデント管理が、早期復旧を目的とするのに対し、問題管理では、抜本的な対策を検討する点を理解しましょう。
エはインシデント管理プロセスの説明です。
【解答】
ウ
別の過去問(H29春AP午後問10）では、問題と「既知の誤り」を次のように整理しています。
４．変更管理
変更管理とは変更要求（RFC：Request For Change） を管理し，優先度などを基にからどの変更を実施するかを判断するプロセスである。
また，試験センターからのシラバスでは次のような説明がある。
５．リリース管理
リリース管理では，変更管理で承認された変更を実際に適用する。
また，試験センターからのシラバスでは次のような説明がある。
サービスデスクは，ユーザからの問合せ窓口である。ヘルプデスクやカスタマーサポート，コールセンタという言葉のほうが馴染み深いかもしれない。
また，試験センターからのシラバスでは次のような説明がある。
| サービスデスク（ヘルプデスク） サービスデスクは，サービスの利用者からの問合せに対して単一の窓口機能を提供し，適切な部署への引継ぎ，対応結果の記録，記録の管理などを行う一連の活動であることを理解する。 （※応用情報技術者シラバス 中分類15：サービスマネジメント より引用） |
サービスデスクには次の3つの形態があります。
①ローカルサービスデスク
拠点ごとにサービスデスクを設置する形態です。過去問（H27秋FE問55）では「サービスデスクを利用者の近くに配置することによって，言語や文化が異なる利用者への対応，専用要員によるVIP対応などができる」と述べられています。
②中央（セントラル）サービスデスク
複数拠点を統括し、1拠点で集中的に問い合わせを受け付ける形態です。過去問（H27秋FE問55不正解選択肢）では「サービスデスクを1拠点又は少数の場所に集中することによって，サービス要員を効率的に配置したり，大量のコールに対応したりすることができる」と述べられています。
③バーチャルサービスデスク
物理的に分散していても、ユーザから見ると仮想的（バーチャル）に1カ所でサポートしているかのように思わせる形態です。過去問（H27秋FE問55不正解選択肢）では「サービス要員は複数の地域や部門に分散しているが，通信技術を利用することによって，単一のサービスデスクであるかのようにサービスが提供できる。」と述べられています。
２．インシデント管理
インシデント管理は障害管理と置き換えると分かりやすい。ただ，厳密には“インシデント”という概念が“障害”とは多少異なるので注意する。
また，試験センターからのシラバスでは次のような説明がある。
| インシデント管理（障害管理） インシデント管理は，インシデントの検知から解決までの一連のプロセスであり，迅速にサービスを復旧させ，業務への影響を最小限に抑えることを目的とする一連の活動であることを理解する。 （※応用情報技術者シラバス 中分類15：サービスマネジメント より引用） |
過去問（H22春FE午前）をみてみましょう。
| 問54 ITサービスマネジメントにおいて,インシデント管理の対象となるものはどれか。 ア ITサービスの新人への教育依頼 イ ITサービスやシステムの機能,使い方に対する問合せ ウ アプリケーションの応答の大幅な遅延 エ 新設営業所へのITサービス提供要求 |
インシデントには問合せを含む場合もあります。しかし、基本的には、障害などのサービス品質の低下を引き起こすものがインシデントです。単なる「使い方に対する問合せ」などはインシデントにはなりません。
正解はウです。アプリケーションの応答の大幅な遅延は、サービス品質の大幅な低下を引き起こしていますから、インシデント管理で対応すべき事象です。
３．問題管理
インシデント管理でも述べたが，問題管理は「根本原因の究明と解決」を行うプロセスである。
また，試験センターからのシラバスでは次のような説明がある。
| 問題管理 問題管理は，問題の根本原因を突き止め，インシデントの再発防止のための解決策を提示する一連の活動であることを理解する。 （※応用情報技術者シラバス 中分類15：サービスマネジメント より引用） |
問題管理では、大きく「問題コントロール」と「エラー・コントロール」の2つの活動があります。「未知の問題」、「既知のエラー」という言葉と合わせて理解しましょう。
①問題コントロール
問題とは「インシデントの未知の根本原因」であり、「未知」の問題という点がポイントです。この問題を対処しようにも、「未知」の問題なので対処の方法が分からないのです。そこで、「未知」の根本原因を「既知」の根本原因にし、対処可能にする活動が問題コントロールです。
②エラー・コントロール
問題コントロールによって把握できた「既知」の根本原因を解決するのがエラー・コントロールです。
なので、未知の根本原因が「問題」で、既知の根本原因が「エラー」と考えることもできます。過去問（H26年春午前問56）では、「ITサービスマネジメントにおける“既知の誤り（既知のエラー）”の説明」として、「根本原因が特定されている又は回避策が存在している問題」と述べられています。
過去問(H20春SW午前）を見てみましょう。
| 問49 ITILにおける問題管理プロセスとして実施するものはどれか。 ア システムダウンから暫定的に復旧させ，業務を継続できるようにする。 イ システムダウンに備えて，復旧のための設計をする。 ウ システムダウンの根本原因を究明し，抜本的な対応策を策定する。 エ システムダウンの発生を記録し，関係する部署に状況を連絡する。 |
アは、インシデント管理プロセスの説明です。
イは、ITサービス継続性管理プロセスの説明です。
ウは正解です。問題管理プロセスは，インシデントの根本原因を究明します。インシデント管理が、早期復旧を目的とするのに対し、問題管理では、抜本的な対策を検討する点を理解しましょう。
エはインシデント管理プロセスの説明です。
【解答】
ウ
別の過去問(H29春AP午後問10）では、問題と「既知の誤り」を次のように整理しています。
| ITサービスに対する計画外の中断やITサービスの品質の低下をインシデントと定義している。一つ以上のインシデントの根本原因を[ a：問題 ]と呼び，“根本原因が特定されているか，若しくは回避策によってサービスへの影響を低減又は除去する方法がある[ a：問題 ]”を[ b：既知の誤り ]と呼んでいる。 |
４．変更管理
変更管理とは変更要求（RFC：Request For Change） を管理し，優先度などを基にからどの変更を実施するかを判断するプロセスである。
また，試験センターからのシラバスでは次のような説明がある。
| 変更管理 変更管理は，すべての変更を制御された方法で，アセスメント，承認，実装，レビューを確実に実施し，リスクの回避，効率的な変更処理の実施などを行う一連の活動であること，また，変更によるシステムへの影響を最小限に抑えることを理解する。 （※応用情報技術者シラバス 中分類15：サービスマネジメント より引用） |
５．リリース管理
リリース管理では，変更管理で承認された変更を実際に適用する。
また，試験センターからのシラバスでは次のような説明がある。
| リリース管理 リリース管理は，変更管理で承認された変更を稼働環境に配送し，配布し，追跡するプロセスであることを理解する。また，新たな版の導入の計画から実際の導入，サービスの利用者とのコミュニケーション，万一導入に失敗した場合に元に戻す作業などを行う一連の活動であり，構成管理及び変更管理との連携が必要であることを理解する。 （※応用情報技術者シラバス 中分類15：サービスマネジメント より引用） |
コメント