1 |
セルフヘルプの例ではないものはどれか |
インシデントの登録やFAQ参照など、ユーザー自らがサービスデスクを利用できる仕組みのこと |
|
2 |
サービス資産・構成管理が支援できるものはどれか(複数) |
変更管理
インシデント管理と問題管理
可用性管理
ITサービス継続性管理
財務管理 |
管理と計画立案
構成識別
構成コントロール
ステータスの説明と報告
検証と監督 |
3 |
アプリケーション管理が支援できる意思決定はどれか |
アプリケーションの設計
機能の可用性の保証
アプリケーションの保守(サポート)
障害発生時のサポート |
|
4 |
コア書籍で「サービスカタログ」「可用性管理」「情報セキュリティ管理」の詳細記述があるものはどれか |
サービス・デザイン |
|
5 |
効果的にITサービスマネジメントを行うために考慮すべきものは何か |
People
Products
Partner
Processes |
|
6 |
情報セキュリティレベルを決定するのはだれだ |
情報セキュリティ方針 |
|
7 |
デミングサイクルの要素ではないものはどれか |
|
品質改善用で用いられる4つの段階(計画、実施、点検、処置)を持つサイクルのこと |
8 |
変更管理の目的ではないものはどれか(複数) |
RFCの作成、記録
RFCのレビュー
変更のアセスメント、評価
変更の許可
変更の実施の調整
変更のレビュー、クローズ |
許可、計画、サポートされているサービスやサービスの構成要素(サービス・コンポーネント)とその関連文書を追加、修正、削除とのこと。 |
9 |
ECABの役割はなにか |
Emergency
Change Advisory Board |
緊急の変更が必要となった場合(CAB全体を招集する時間の余裕がない場合)に招集され、緊急の意思決定を下す権限を持つCABより小規模なグループ。 |
10 |
サービスデスクの役割ではないものはどれか |
|
様々なインシデントやイベントの処理に責任を負う専任のスタッフで構成される組織のこと。
ITサービス・プロバイダとユーザ間における日常の単一窓口である。
事業へのマイナスのインパクトの低減。
ITサポート側のリソースの有効利用と事業側の生産性向上。 |
11 |
継続的サービス改善のアプローチとして適切なものはどれか |
計画(Plan)
実施(Do)
点検(Check)
処置(Action) |
ビジョンは何か
我々はどこにいるか
我々はどこを目指すのか
どのように目標を達成するのか
我々は達成したのか
どのようにして推進力を維持するか |
12 |
技術的測定の対象となるものはどれか |
可用性とパフォーマンスなどといった、ITサービスを構成するコンポーネントやアプリケーションの測定基準のこと。 |
CPU使用率
メモリ使用量
自動稼働性能情報収集など |
13 |
イベントの3カテゴリを適切に示したものはどれか |
情報
警告
例外 |
情報:処置を必要としない運用上の監視上必要とされる通知。
警告:利用率や負荷を設定した閾値に達したという通知
例外:サービスまたはコンポーネントが正常に運用させていない時の通知 |
14 |
事業活動パータンの収集が支援できるプロセスはどれか(複数) |
需要管理
キャパシティ
サービスストラテジ |
|
15 |
プロアクティブな対応とみなされるものはどれか |
将来発生する可能性のある問題を予防する活動。通常、「サービスオペレーション」で開始されるが、「継続的サービス改善」の一部として推進する。 |
|
16 |
すべてのプロセスが持つ要素はどれ |
プロセス・オーナー?? |
|
17 |
プロセスの特性ではないものはどれか |
|
プロセスは測定可能である
具体的な結果を伴う
主な結果は顧客または利益関係者に提供される
特定のイベントに対応する |
18 |
外部委託先のパフォーマンスを測定、管理するプロセスはどれか。(複数) |
サプライヤ管理
契約
サプライヤ契約データベース(SCD) |
|
19 |
インシデントを報告する役割を持つ人について正しい記述はどれか |
サービスデスク?? |
イベント管理プロセスからのエスカレーション
サービスデスクへの電話
Webなどのセルフヘルプ
技術スタッフからのメール |
20 |
オペレーションレベル合意は何か |
OLA:Operation
Level Agreement |
SLAを実現するために、ITサービス・プロバイダと同じ組織でサービスの提供を支援する他部署と結ぶ合意。 |
21 |
マルチレベルSLAの3層に含まれないものは何か |
企業レベル
顧客レベル
サービスレベル |
|
22 |
単独のリリースユニット、あるいはリリースユニットの集合をまとめたものは何か |
リリースパッケージ |
|
23 |
問題管理の役割ではないものはどれか |
一時的なワーク?? |
問題管理は、イベントおよびインシデントの根本原因を特定し解決するプロセス。問題管理プロセスは、将来発生する可能性があるインシデント及び問題を防止し、インシデントが発生した場合に迅速な診断と解決を可能にするため、既知のエラーの作成、ワークアラウンドの提供を行う。 |
24 |
外部委託先との契約書に書かれるべきものはどれか(複数) |
法的な条項
セキュリティ要件
事業継続性要件
情報開示お合意 |
|
25 |
既知のエラーコードに登録する時期の説明として適切なものはどれか(複数) |
|
サービスの回復や問題の解決のために実施したワークアラウンド、解決策の詳細情報
障害内容、障害の兆候の詳細情報 |
26 |
特定の事業分野、(忘れた)でのIT戦略立案の際に参照すべき書籍はどれか。(複数) |
サービス・ストラテジ
サービス・デザイン ??? |
|
27 |
アクセス管理の目的ではないものはどれか |
ユーザーにサービスを使用できる権力を与えるプロセス。
データや知的の所有権の機密性、可用性、完全性の確保に繋がる。 |
|
28 |
サービスベースのSLAの説明として適切なものはどれか(複数) |
|
ひとつのSLAがひとつのサービスを利用する全ての顧客を対象とする場合のSLA |
29 |
サービスストラテジで考慮すべきものはどれか(複数) |
財務管理プロセス
需要管理プロセス
サービス・ポートフォリオ管理プロセス |
有用性
保証:顧客がITサービスを使用するのに、十分なキャパシティ、可要請、継続性、セキュリティが提供されること。
リソースと能力
サービス資産
サービスポートフォリオ(サービスパイプライン、サービスカタログ、廃止されるサービス) |
30 |
イベントの説明として正しいものはどれか |
構成アイテムやITサービスの管理に取って重要性のある状態の変更のこと。通常、ITサービス、構成アイテム、イベント管理ツールにより生成される。 |
情報
警告
例外 |
31 |
顧客がその製品またはサービスによってニーズが満たせるかどうかを知ることができるものはどれか |
有用性 |
特定のニーズを満たすために、製品またはITサービスによって提供される機能性のこと。 |
32 |
重大なインシデントとは何か |
事業に深刻な中断を与える原因となるインシデントのこと |
|
33 |
プロセスの特性には「トリガの存在」があるか |
|
プロセスを開始させるイベントをトリガーと言います。 |
34 |
PDCAサイクルの具体的例をPDCA順に並べる |
|
|
35 |
財務管理とは |
ITサービス・プロバイダの予算業務、会計業務、課金に対する要件の管理を責務とする機能及びプロセス。 |
ビジネス・ケース:主要な支出項目の正当性を説明するもので、コスト、利点、代案、課題、リスク、起こりうる問題に関する情報を含む。 |
36 |
サービス・ポートフォリオ管理の目的 |
ITサービス・プロバイダによって管理されている全てのITサービスのこと。ITサービスのライフサイクルの管理に使用される。 |
|
37 |
有用性と保証の具体例で正しい組み合わせ |
|
|
38 |
サービスカタログ管理は |
サービス・カタログ管理は、サービス・カタログを管理し、その情報が常に正確で最新であることを保証する |
サービスオペレーション段階で顧客やユーザーに提供されているITサービスと、顧客やユーザーに提供することが承認済みで導入準備中のITサービスについての詳細をリストにまとめたもの、サービスポートフォリオの一部。
ビジネス・サービス・カタログ
技術サービス・カタログ |
39 |
サプライヤ管理での定期的なレビューで関係するプロセスとは |
サービスレベル管理?? |
|
40 |
4Pの組み合わせ |
People
Products
Partner
Processes |
スタッフの能力またはスキル
サービス、使用するツール、技術
メーカ、ベンダ、サプライヤ
サービス設計時の役割、活動が含まれます |
41 |
OLAの説明 |
No.20参考 |
|
42 |
アラウンドが見つかった時か、原因と恒久的な対策が判明した時か |
問題管理 |
既知のエラー |
43 |
インシデント管理とは |
ITサービスの計画外の停止や品質低下のこと。 |
サービスデスク経由でユーザから直接伝達され事象
イベント管理からのエスカレーション
技術スタッフによる記録 |
44 |
サービスデザインのプロセスではないものは |
サービスカタログ管理
サービスレベル管理
キャパシティ管理
ITサービス継続性管理
可用性管理
情報セキュリティ管理
サプライヤ管理 |
可用性管理:バックアップと復旧、サービス可用性とコンポーネント可用性、可用性、信頼性、保守性、サービス性、重要ビジネス機能(VBF)、拡張版インシデント・ライフサイクル
サプライヤ管理:①戦略的サプライヤ、②戦術的サプライヤ、③運用上のサプライヤ、④コモディティ・サプライヤ。 |
45 |
|
|
46 |
標準的な変更の適切な説明は |
|
ビジネスへの影響度、リスク、コストが少なく、変更管理によって手順が確立された(手順が承認済みの)変更のことです。かならずしもRFCは必要ではありません。サービスデスクに権限を与えて置き、サービスデスクで処理することもあります。 |
47 |
コンポーネント間の関係を保存するところは |
|
|
48 |
リリースユニットとは |
通常、同時にリリースされるサービス、ITインフラストラクチャの一部分。構成ユニットをまとめたリリースする単位。 |
|
49 |
リリースパケージとは |
同時にりリースするためにパッケージ化されたリリース・ユニット全体のこと。単一のリリース・ユニットの場合や複数のりr-ス・ユニットのセットで構成される場合がある。 |
|
50 |
要求実現で扱うものの具体例はどれか |
PCの設置
OSユーザーの追加
プリンタのトナーの入れ替え
パスワードリセット
新規ユーザーの登録
アプリケーションのインストール |
予期しないサービスの遅延や中断に起因するインシデントを除いた、顧客やユーザからの要求を処理するプロセス。要求実現プロセスによって、顧客やユーザの生産性を向上でき、サービスの品質を改善できる。 |
51 |
アクセス管理とは |
|
ユーザーにサービスを使用できる権利を与えるプロセス。データや知的所有権の機密性、可用性、完全性の確保に繋がる。 |
52 |
イベント管理とは |
構成アイテムやITサービスの管理に取って重要性のある状態の変更のこと。通常、ITサービス、構成アイテム、イベント管理ツールにより生成される。 |
ITインフラストラクチャ全体で発生する全てのイベントをモニタリングするプロセス。イベント管理によって通常どおり運用されていることを監視でき、障害などの例外状況を検出した場合にはエスカレーションを行う。また、イベント管理によって、他のプロセス、特にインシデント管理の活動を迅速に着手できる。さらに、イベント管理の活動を自動化することによってコストを削減できる。 |
53 |
問題とは |
|
ひとつまだは複数のインシデントを引き起こす未知の原因。 |
54 |
継続的サービス改善の「我々は達したか」の次は? |
どのようにして推進力を維持するか |
ビジョンは何か
我々はどこにいるか
我々はどこを目指すのか
どのように目標を達成するのか
我々は達成したのか
どのようにして推進力を維持するか |
55 |
7ステップの改善プロセスの最初のステップは何か |
|
|
56 |
セルフヘルプとは |
インシデントの登録やFAQ参照など、ユーザー自らがサービスデスクを利用できる仕組みのこと |
|
57 |
フォロー・ザ・サンはサービスデスクの構造か |
|
24時間365日、サービスを提供するために、世界中のサービスデスク、サポートグループを活用する。 |
58 |
アプリケーション管理の役割はどれか |
|
アプリケーションのライフサイクル(要件の収集、設計、構築、展開、運用、最適化)を通して、アプリケーションの管理に責任を負い、運用中のアプリケーションの管理とサポートを担当する組織(グループ、部門、チーム)を指す。 |
59 |
サービスレベルマネージャの役割はどれか |
SLA、OLAを文書化する責任を持つ。
また、SLAがみたされているかどうかパフォーマンスを監視する。 |
|
60 |
RACIモデル |
Responsible(責任者)
Accountable(説明責任者)
Consulted(協議先)
Informed(報告先) |
役割と責任を定義するために使用されるモデル。 |
61 |
プロセスの一部として定義されないものは |
機能 |
役割
活動
責任 |
62 |
サービスストラテジの内容で役に立つものは |
サービスを誰に提供すべきか
競合との差別化をどうするか
顧客にとっての価値をどのように実現するか |
|
63 |
構成モデルを利用するために必要なものは |
インシデントのインパクトと原因評価
変更にインパクト評価
新規・変更のサービス計画
技術の更新とソフトウェアのアップグレード計画 |
CI間の関係を含む、サービス、資産、及びインフラストラクチャのモデルのこと。 |
64 |
機能に該当するものは |
サービスデスク
技術管理
アプリケーション管理
IT運用管理 |
特定の作業に従事し、決められた成果に対して責任を負う専門組織。たとえば、サービスデスク。 |
65 |
アクセス管理の目標 |
サービスを利用できる権利を管理する |
|
66 |
事業活動あパータンの分析結果に関係のあるプロセスはどれか |
需要管理 |
|
67 |
顧客認識と事業成果は、次のどれを定義するのに役立つか |
サービスの価値 |
|
68 |
情報セキュリティ管理のよって何を保護すべきかの情報源となるものは |
ITマネジメント
事業マネジメント |
情報セキュリティ方針は、情報セキュリティ管理につぃする組織のアプローチを統制する方針のこと。情報セキュリティ方針は、情報セキュリティの全領域を網羅し、事業とITトップマネジメントにより認可される。 |
69 |
要求された標準サービスのコンポ―ネントを提供する責任のあるプロセスはどれか |
要求実現 |
|
70 |
サービスオペレーションの目的は |
|
ITサービスに関する問い合わせを受け付けたり、障害に対処するなどの活動を行い、合意済みのレベルで顧客やユーザにITサービスを提供できるようにします。 |
71 |
プロセス・モデル |
プロセスの構成要素、活動などを表現したモデル。
プロセスの特徴を理解、説明するときに使用できる。 |
プロセス:
活動、手順、役割、改善、測定基準、作業指示書
プロセスコントロール:
プロセス・オーナー、達成目標、文書、フィードバック
プロセスの実現手段:
リソース(有形資産)、能力(無形資産) |
72 |
ITIL補完ガイドで提供されるものはどれか |
業種、技術、運用モデルなどの分野別の手引きの出版物 |
コア:
サービスストラテジ
サービスデザイン
サービストランジション
サービスオペレーション
継続的サービス改善 |
73 |
サービスストラテジの説明 |
戦略的な優位性を達成し維持する能力を開発し、戦略的資産とする手引きを提供する。 |
|
74 |
情報セキュリティ管理 |
すべてのサービスとサービスマネジメントの活動(ビジネス)を保護することを目的として定義されています。 |
|
75 |
サービスオペレーションが提供する代表的手引きは |
サービスの提供とサポートの有効性と効率性を達成するための手引きを提供する |
|
76 |
事業に価値をもたらす手段 |
サービスストラテジ
サービスデザイン
サービスオペレーション
継続的サービス改善 |
サービスの価値をモデル化する。
サービスのコストの妥当性を確認する
最適化を実行され測定され
最適化の対策を明確する |
77 |
サービス・モデル |
サービスオペレーションが提供するサービス構造及び変動性を説明するもの。 |
|
78 |
サービス・ポートフォリオとは |
ITサービス・プロバイダによって管理されている全てのITサービスのこと。ITサービスのライフサイクルの管理に使用される。 |
定義、分析、承認、制定という活動を行い、事業全体のサービスマネジメントへの投資を統制し、価値を生み出すとしている目的のプロセス。
定義:サービスの目録化、ビジネスケースの確立、サービスポートフォリオの確認。
分析:ポートフォリオの価値を最大化し、サービスに対するソースの調整や優先順位を付ける。
承認:サービスと使用するリソースを許可し、ポートフォリオ。
制定:実際のリソースの割り当てやサービスの制定を行う。 |
79 |
財務管理 |
予算業務
会計業務
課金 |
会計業務:ITサービスの提供にかかる実際のコストを分類、把握する。実際のコストと見積もられたコストと比較し、予算の不一致を管理する。 |
80 |
サービスデザイン段階のおいて、事業達成目標を成り遂げるサービス設計の要件として |
品質
コンプライアンス
リスク
セキュリティ |
|
81 |
サービス・デザインパッケージ |
|
ITサービスとの要件のすべての側面について、ライフサイクルの各段階を通じて定義する文書のこと。 |
82 |
サービスデザインの5つの側面 |
サービス・ソリューションの設計
支援的な仕組みの設計(特にンサービス・ポートフォリオ)
技術アーキテクチャの設計
プロセスの設計
測定方法と測定基準の設計 |
|
83 |
ソーシング戦略 |
アウトソーシング
インソーシング:
コソーシング:
パートナーシップまたはマルチソーシング:
アプリケーション・サービス供給:
ビジネス・プロセス・アウトソーシング(BPO):
ナレッジ・プロセス・アウトソーシング(KPO) |
アウトソーシング:ITサービスの提供に必要なリソースを外部組織から調達する。
ナレッジ・プロセス・アウトソーシング(KPO):ビジネスプロセスや機能をソーシングする点はBPOと同じだが、さらに一歩進めて、KPOでは特殊で高い専門能力が必要なビジネス・プロセスや機能をソーシングする |
84 |
サービスレベルアグリーメント |
サービスレベル
顧客レベル
マルチレベル |
|
85 |
サービスストラテジ |
需要管理
財務管理 |
|
87 |
サービストランジション |
最終目標:
①移行されたサービスのパフォーマンスの予測と実際の差を確かめる
②既知のエラーを減らして、新規または変更されたサービスの移行に起因するリスクを最小化する
③サービス要件に規定された要件と制約に沿って、サービスが利用できるようにする |
変更管理
リリース管理および展開管理
サービス資産管理及び構成管理
ナレッジ管理 |
88 |
サービスオペレーション |
イベント管理
インシデント管理
要求実現
問題管理
アクセス管理
サービスデスク
技術管理
アプリケーション管理
IT運用管理 |
サービスデスク:ユーザーとの調整の窓口。
アプリケーション管理:アプリケーションのライフサイクルを通して管理をする。 |
89 |
継続的サービス改善 |
継続的サービス改善の概念
サービスライフサイクル全体でのITガバナンス |
デミング・サイクル
継続的サービス改善モデル
ベースライン
測定する理由:妥当性確認、方向付け、正当化、介入
測定基準:技術測定基準、プロセス測定基準(CSF、KPI)、サービス測定基準
ガバナンス:コーポレート・ガバナンス、ITガバナンス |
90 |
情報セキュリティ管理のフレームワーク |
ISO270001(ISMS) |
コントロール
計画
実施
評価
維持 |
91 |
サービス・ナレッジ管理システム(SKMS)
意思決定支援のがSKMS |
①中央リポジトリまたは構成管理システム(CMS)
②構成管理データベース(CMDB) |
スタッフの経験
周辺要素のレコード
サプライヤの能力
パートナー能力
ユーザーのリテラシィ?? |
92 |
変更管理の7つのR |
RAISED
REASON
RETURN
RISK
RESOURCE
RESPONSIBLE
RELATIONSHIP |
変更の要請
変更の理由
変更の成果
変更に伴うリスク
変更を実施するために必要なリソース
構築、テスト、実装の責任
この変更とほかの変更の関係 |
93 |
リリースユニットを決定する際に考慮すべきこと |
変更の容易さと変更の量
リリースの一連の活動に必要なリソースと時間
ユニットとほかのユニットとのインターフェースと構成の複雑さ
リリースの一連の活動に支援するストレージと場所 |
|
94 |
リリースのタイプ |
大規模リリース
小規模リリース
緊急リリース |
|
95 |
変更が成功しなかった場合に取るべき対応を明確に示すもの |
修復の計画 |
|
96 |
変更諮問委員会(CAB) |
変更を許可し、変更の評価及び優先度決定に置いて変更管理を支援するための機関。変更マネージャが議長を務め、変更による利害関係者(顧客、ユーザー、サービスデスク、運用スタッフ、サプライヤなど)で構成される。 |
最終的に実施の決断は変更マネージャです。 |
97 |
ナレッジ管理(DIKW)
事業が必要とするサービスを提供及びサポートするために、適切な人材が適切な時期に適切なナレッジを持っているようにする。 |
データ
情報
知識
知恵 |
イベントに関する様々の事実の集まり
データから生成され、半構造化されたコンテンツに保管される。
情報を利用しやすく加工し、意思決定を支援。
課題に関する優れる判断と適切認識ができる能力 |
98 |
リリース管理及び展開管理 |
顧客、ユーザー、サービスマネージメント・スタッフがユーザー向けの文書やトレーニングなどを満足するようにすることを達成目標とするプロセス。 |
|
99 |
既知のエラー |
診断が成功し、根本原因とワークアラウンドが識別し、文書かされた問題。 |
|
100 |
インシデント管理の最終目標 |
可能の限り迅速に通常サービスを回復する
事業運営のマナスーインパクトを最小限を抑える
品質や可用性を提供可能の最高レベルに維持する |
|
101 |
問題解決の優先度 |
重大度 |
コストはどのぐらいか
問題解決には人的リソースはどのぐらい必要か
問題解決にかかる期間
影響を受けている期間 |
102 |
継続的サービス改善7つのステップ |
①測定対象の定義
②測定できる内容の定義
③データの収集
④データの処理
⑤データの分析
⑥情報の提示、活用
⑦是正措置の実施 |
①測定対象の定義:ITサービスの改善のためには、何をどのレベルまで向上させるのかを検討して決定する必要があります。
②測定できる内容の定義:選択した項目が測定できるか検討します。
③データの収集:測定に必要なデータを収集するための方法を決定して、実際の収集を開始します。
④データの処理:収集したデータを処理して、適切な情報にします。
⑤データの分析:その情報を分析して、目標達成度の測定、不達成の場合の原因分析などを行います。
⑥情報の提示、活用:分析結果を関係者に報告します。
⑦是正措置の実施:報告により是正措置が必要と判断された場合には、それに応じてITサービスを改善します。 |
103 |
技術管理 |
技術的な専門能力をITインフラストラクチャの管理を提供する組織(グループ、部門、チーム)を指す。
アプリケーション管理とIT運用管理の一部構成。 |
ITインフラストラクチャの設計。
ITインフラストラクチャの保守。
障害発生時のサポート。 |
104 |
アプリケーション管理 |
アプリケーションが購入するか開発するかの意思決定。 |
|
105 |
CSIマネージャ |
組織全体的ベストプラクティスの実施に責任を負うオーナー |
継続的改善の提唱者となる。
CSIのプラクティスが組織に組み込まれる
CSI支援のために必要なリソースの確保
モニタリング、分析、傾向の評価、報告など継続的CSI活動
プロジェクトベースのサービス改善活動 |
106 |
継続的サービス改善 |
外部的側面
内部的側面 |
|
107 |
ITガバナンス |
サービス・ライフサイクル全体にわたって機能し、適切な方針、手順、プロセス、測定を整備し、これらが確実に実施、遵守されるようにすること。 |
組織のITを確実に持続させ、組織の戦略と達成目標を拡張できるようなリーダシップ、組織構造、プロセスから構成されます。
役員会や経営陣の責任で推進します。 |
108 |
サービス改善計画(SIP) |
|
|
109 |
サービスレビューミーティング |
|
|
110 |
SLAM |
|
|
111 |
アセスメント |
|
|
112 |
ベンチマーキング |
|
|
113 |
SWOT |
|
|
114 |
ギャップ分析 |
|
|
コメント
コメントを投稿