ITIL4 Foundationの勉強をしてるけど,日本語のなんと難しいこと・・・.本などを見ながらメモして,少しでも記憶の助けにすべく.
この一覧を丸暗記すれば,ITIL4 Foundation の試験にはたぶん合格するでしょう.
追記 on 2025/4/18 ・・・ 無事 ITIL4 Foundation に合格しました♪
サービスマネジメントの主要概念
用語など | 説明 |
---|---|
サービスマネジメント | 顧客にとっての価値をサービスの形で実現する、組織の専門能力の集まり。 |
価値および価値共創 | 組織の目的は、利害関係者にとっての価値を創出することです。 |
価値 | 知覚されている便益、便利さおよび何らかの重要性。 |
組織 | 自らの目的を達成するため、責任、権限および相互関係を伴う機能をもつ、個人または人々の集まり。 |
サービス消費者 | サービスを受けるとき、組織はサービス消費者の役割を担います。 |
サービス・プロバイダ | サービスを供給するとき、組織はサービス・プロバイダの役割を担います。プロバイダが消費者の組織に対して外部の場合もあれば、両者が同じ組織に属している場合もあります。 |
顧客 | サービスの要件を定義し、サービスを消費した成果に対して責任を負う役割。 |
ユーザ | サービスを利用する役割。 |
スポンサ | サービスの消費の予算を承認する役割。 |
価値創出のためのリソースの構成 | 組織が提供するサービスは、その組織の 1 つまたは複数の製品に基づいています。組織は、人材、情報と技術、バリューストリームとプロセス、サプライヤおよびパートナを含むさまざまなリソースを所有しているか、またはそれらのリソースにアクセスできます。製品とは、組織によって創出される、それらのリソースの構成であり、組織の顧客にとって価値あるものとなる可能性があります。 |
サービス | 顧客が特定のコストやリスクを管理することなく、望んでいる成果を得られるようにすることで、価値の共創を可能にする手段。 |
製品 | (サービス)消費者に価値を提供できるように設計された、組織のリソースの構成。 |
サービス提供物 | サービス・プロバイダは、1 つまたは複数の製品に基づく、1 つまたは複数のサービスを表すサービス提供物という形で消費者にサービスを提示します。 対象とする消費者グループのニーズに対処することを目的とした、1 つまたは複数のサービスについての形式的な説明。サービス提供物には、物品、リソースへのアクセス、サービス活動などが含まれる。 |
サービス関係 | サービス関係は、価値を共創するために 2 つ以上の組織間で確立されます。サービス関係の中で、組織はサービス・プロバイダおよびサービス消費者の役割を担います。この 2 つの役割は相互排他的なものではなく、組織は一般に、いつでも複数のサービスを提供し、消費します。 |
サービス関係 | サービス・プロバイダおよびサービス消費者間の協力関係。サービス関係には、サービス供給、サービス消費およびサービス関係管理が含まれます。 |
サービス供給 | 組織がサービスを供給するために実施する活動。サービス供給には、以下のようなものがあります。 • サービスを提供するために構成されたプロバイダのリソースの管理 • ユーザがこれらのリソースに確実にアクセスできるようにすること • 合意済みのサービス活動の実現 • サービスレベル管理および継続的改善 サービス供給には、さらに、商品の供給が含まれる場合もあります。 |
サービス消費 | 組織がサービスを消費するために実施する活動。サービス消費には、以下のような ものがあります。 • サービスを利用するために必要な(サービス)消費者のリソースの管理 • プロバイダのリソースの使用やサービス活動の実現要求など、ユーザが実施するサービス活動 サービス消費には、商品の受け取り(入手)も含まれる場合があります。 |
サービス関係管理 | 合意済みの利用可能なサービス提供物に基づいて継続的な価値の共創を確実にするために、サービス・プロバイダとサービス消費者が共同で行う活動。 |
価値: 成果、コストおよびリスク | 望ましい成果を達成するにはリソース(およびそのコスト)が必要であり、多くの場合リスクが伴います。サービス・プロバイダは消費者が成果を達成するのを支援し、そうすることで関連するリスクやコストの一部を負担します(セクション 2.3.1 のサービスの定義を参照)。一方で、サービス関係は新たなリスクやコストを生じさせる可能性があるほか、場合によっては、意図した成果の達成をサポートしながらも、その一部にマイナスの影響を与えることがあります。 |
アウトプット | 活動の有形または無形の成果物。 ※ 単純な「モノ」のようなイメージ |
成果 | 1 つまたは複数のアウトプットによって可能になる利害関係者にとっての結果。 ※ 益となるもの享受することのようなイメージ |
コスト | 特定の活動またはリソースに費やされた金銭の額。 |
リスク | 損害や損失を引き起こす、または達成目標の実現をより困難にする可能性があるイベント。成果の不確実性と定義することもでき、プラスの成果とマイナスの成果の確率測定に関連して使用できます。 |
有用性 | 特定のニーズを満たすために製品またはサービスによって提供される機能。有用性は「サービスが何を行うか」であると言いかえられ、サービスが「目的に適しているか」を判断するために使用できます。サービスが有用性を持つためには、(サービス)消費者のパフォーマンスをサポートするか、または(サービス)消費者の制約を取り除くか、いずれかをしなければなりません。多くのサービスは、その両方を行っています。 |
保証 | 製品またはサービスが合意済みの要件を満たすことに対する確約。保証は、「サービスがどのように提供されるか」であると言いかえられ、サービスが「使用に適している」かを判断するため に使用できます。多くの場合、保証はサービス消費者のニーズに沿ったサービスレベルに関連します。これは、正式な合意に基づく場合や、広告メッセージやブランド・イメージである場合がありま す。保証は、一般的にサービスの可用性、キャパシティ、セキュリティ・レベルおよび継続性などの領 域を対象とします。定義され合意された条件がすべて満たされている場合、サービスは受け入れ可能であることの確約、つまり「保証」を提供していると言えます。 |
サービスマネジメントの4つの側面
用語など | 説明 |
---|---|
組織と人材 | 組織はますます複雑化しているため、組織の構造化や管理の仕組みに加え、組織の役割、実行責任および権限やコミュニケーションのシステムが適切に定義され、戦略および運用モデル全体を支えている状態を実現することが重要です。 |
情報と技術 | SVS(サービスバリューシステム) に適用される場合、情報と技術の側面には、サービスを管理するために必要な情報、知識および要求される技術が含まれます。また、活動やプラクティスのインプットおよびアウトプットなど、SVS のさまざまなコンポーネント間の関係も含まれます。 |
パートナとサプライヤ | パートナとサプライヤの側面には、組織のサービスの設計、開発、展開、提供、サポート、または継続的改善(あるいはそのすべて)に伴う他の組織との関係が含まれます。また、組織とそのパートナまたはサプライヤとの間で交わされる契約およびその他の合意も含まれます。 |
バリューストリームとプロセス | 組織とその SVS に適用されるバリューストリームとプロセスの側面は、製品およびサービスを通じて価値の創出を実現するうえで、組織のさまざまな要素が統合および調整された形でどのように機能するかに関連しています。この側面では、組織が取り組む活動や、その編成方法のほか、すべての利害関係者にとっての効率的かつ効果的な価値創出をどのように実現しているかという部分に重点が置かれています。 |
クラウド・コンピューティング | 管理の手間やプロバイダとのやり取りを最小限に抑えて迅速に提供できる、構成可能なコンピューティング・リソースから成る共有プールへの、オンデマンドのネットワーク・アクセスを実現するためのモデル。 |
サービスマネジメントのバリューストリーム | バリューストリームとは、製品やサービスを創出し、サービス消費者に提供するために組織が使用する一連の手順です。バリューストリームは組織のバリューチェーン活動を組み合わせたものです。 |
バリューストリーム | 製品およびサービスを作成し、(サービス)消費者に提供するために組織が取り組む一連のステップ。 |
プロセス | プロセスとは、インプットをアウトプットに変換する一連の活動です。プロセスは達成目標を達成するためにどのようなことが行われるのかを表しており、明確に定義されたプロセスは、組織内および組織全体の生産性を改善することができます。プロセスの詳細は、通常、プロセスの関係者を概説する手順と、プロセスの実行方法を説明する作業指示書に示されます。 インプットをアウトプットに変換する、相互につながりがあるまたはやり取りする一連の活動。プロセスは、1 つまたは複数の定義済みのインプットを受け取り、定義済みのアウトプットに変換します。プロセスは活動の順序と活動間の依存関係を定義します。 |

サービスバリュー・システム
用語など | 説明 |
---|---|
サービスバリュー・システムの概要 | ITIL SVS は、組織のあらゆる要素と活動が 1 つのシステムとして機能し、価値創出を実現する方法を示します。それぞれの組織の SVS には他の組織とのインタフェースがあり、組織、その顧客、その他の利害関係者にとっての価値を促進できるエコシステムを形成しています。 |
機会、需要、価値 | 機会と需要は ITIL SVS 内での活動のきっかけとなり、この活動が価値の創出につながります。機会と需要は常にシステムに入ってきますが、組織がすべての機会を自動的に受け入れたり、すべての需要に応えたりするわけではありません。 ※ 機会/需要がインプットで,価値がアウトプット |
従うべき原則 | 従うべき原則は、組織の目標、戦略、業務の種類、管理構造が変化したとしても、あらゆる状況で組織 を導くことができる推奨事項です。従うべき原則は、汎用的かつ永続的です。 |
価値に着目する | 利害関係者にとっての価値に、それが直接的であろうと間接的であろうと、関連付ける必要があります。 「価値に着目する」という原則には、顧客とユーザの経験を含む多くの観点が内包されます。 |
現状からはじめる | 新しいものをゼロから構築するのではなく、すでにある利用可能なものを活用することを検討します。現行のサービス、プロセス、プログラム、プロジェクト、プログラムおよび人材などの中に、求められる成果を生み出すために利用できるものが十分に存在している可能性があります。 現状に直接目を向けて調査し、完全に把握する必要があります。 |
フィードバックをもとに反復して進化する | 何もかもを一度に片づけようとしてはいけません。大規模な取り組みであっても、反復的な活動によって達成する必要があります。作業をより小さく扱いやすいセクションに分割し、実行と完了をタイミングよく行えるようにすることで、一つ一つの取り組みに集中しやすくなります。 それぞれの反復の実行前、実行中および実行後にフィードバックを利用して、状況が変化している場合でも、適切なアクションを集中的に実行できるようにします。 ※ アジャイルのイメージ |
協働し、可視性を高める | 境界を超えて協力することで、より大きな賛同が得られ、達成目標への関連性が高まり、長期的な成功の可能性が高まります。 達成目標を実現するには、情報、理解および信頼が必要です。作業および結果を可視化し、隠れた意図を入れないようにし、情報を可能な限り共有する必要があります。 |
包括的に考え、取り組む | サービス、またはサービスの提供に使用される要素が、単独で存在することはありません。組織が、サービスの一部ではなく全体に対して取り組まなければ、サービス・プロバイダとサービス消費者が得られる成果は貧弱なものになります。 内部顧客および外部顧客に結果をもたらすには、情報、技術、組織、人材、プラクティス、パートナ、合意を効果的かつ効率的に管理し、動的に統合する必要があります。定義された価値を提供するには、こういったすべてのことの調整が必要になります。 |
シンプルにし、実践的にする | 価値をもたらさない、あるいは有用な成果を生み出さないプロセス、サービス、アクション、測定基準は、除外してください。プロセスまたは手順のステップは、達成目標に必要な最小限に留めます。常に成果に基づいて思考し、結果をもたらす実践的なソリューションを生み出します。 |
最適化し、自動化する | あらゆる種類のリソース、特に人材を最大限効果的に利用すべきです。本当に無駄な物を全て排除し、技術で解決できることには技術を利用します。人が関わるのは、そうすることで本当に価値に貢献する場合に限ります。 |
ガバナンス | すべての組織は経営陣、つまり組織のパフォーマンスおよびコンプライアンスについて最も高いレベルで責任を負う人物または人員のグループによって指導されます。あらゆる規模および種類の組織がガバナンス活動を実行します。ガバナンス活動を行う際、経営陣は別のガバナンスの役割を担う取締役または経営幹部である場合があります。経営陣は方針やさまざまな外部規制に対する組織のコンプライアンスに責任を負います。 |
サービスバリュー・チェーン | 6 つのバリューチェーン活動は次のとおりです: • 計画 • 改善 • エンゲージ • 設計および移行 • 取得/構築 • 提供およびサポート これらの活動は、組織が価値の創出において実行するステップを表します。それぞれの活動によってインプットがアウトプットに変換されます。これらのインプットは、バリューチェーン外からの需要や他の活動からのアウトプットである場合があります。すべての活動が相互接続され、それぞれの活動がトリガを受け取ったり渡したりすることで、さらなる活動が実施されます。 |
計画 | 計画バリューチェーン活動の目的は、4 つ全ての側面モデルと全製品および全サービスに関するビジョン、現状および改善指示に関する理解を組織全体で確実に共有することです。 |
改善 | 改善のバリューチェーン活動の目的は、すべてのバリューチェーン活動とサービスマネジメントの 4 つ の側面において、製品、サービスおよびプラクティスを継続的に改善することです。 |
エンゲージ | エンゲージのバリューチェーン活動の目的は、利害関係者のニーズ、透明性、継続的なエンゲージメン トについて十分な理解を促し、すべての利害関係者と良好な関係を実現することです。 |
設計および移行 | 設計および移行のバリューチェーン活動の目的は、製品とサービスが品質、コストおよび市場投入までの期間について、利害関係者からの期待に継続的に応えられるようにすることにあります。 |
取得/構築 | 取得/構築のバリューチェーン活動の目的は、サービス・コンポーネントが合意された仕様を満たし、必要なときに必要な場所で利用できるようにすることにあります。 |
提供およびサポート | 提供およびサポートのバリューチェーン活動の目的は、利害関係者の期待に応じて、合意された仕様に従ってサービスの提供およびサポートを実施することにあります。 |
継続的改善 | 継続的改善は、戦略から運用にいたるまで、組織のあらゆる領域とレベルで実行されます。サービスの有効性を最大限に高めるには、サービスの提供に貢献する各人が継続的改善に留意し、常に改善の機会を追求するべきです。 |
継続的改善管理表 | 「継続的改善管理表(Continual Improvement Register, CIR)」とは、組織がサービスやプロセスの改善を体系的に管理するためのツールです。CIRは、改善のアイデアや提案を記録し、優先順位を付け、進捗状況を追跡するために使用されます。 具体的には、以下のような情報が含まれます: 改善のアイデアや提案:どのような改善が必要か、具体的な内容。 優先順位:改善の重要度や緊急度に基づく優先順位。 進捗状況:改善活動の進行状況や成果。 この管理表を活用することで、組織全体で継続的な改善を促進し、サービスの品質向上を図ることができます。 |




管理プラクティス
用語など | 説明 |
---|---|
管理プラクティス | 管理プラクティスとは、業務遂行または達成目標に到達するための組織リソース一式を指します。このプラクティスの起源は次のとおりです。 • 一般的な事業マネジメント分野における一般的マネジメントプラクティスが、サービスマネジメントに導入、適用されてきました。 • サービスマネジメント業界および ITSM 業界で、サービスマネジメント・プラクティスが構築されてきました。 • 技術分野の技術的マネジメントプラクティスが、その焦点を技術ソリューションから IT サービスに拡大あるいはシフトすることで、サービスマネジメントに適用されてきました。 |
一般的マネジメントプラクティス | アーキテクチャ管理 継続的改善 情報セキュリティ管理 ナレッジ管理 測定および報告 組織変更の管理 ポートフォリオ管理 プロジェクト管理 関係管理 リスク管理 サービス財務管理 戦略管理 サプライヤ管理 |
サービスマネジメント・プラクティス | 要員およびタレント管理プラクティス 可用性管理 事業分析 キャパシティおよびパフォーマンス管理 変更実現 インシデント管理 IT 資産管理 モニタリングおよびイベント管理 問題管理 リリース管理 サービス・カタログ管理 サービス構成管理 サービス継続性管理 サービスデザイン サービスデスク サービスレベル管理 サービス要求管理 |
技術的マネジメントプラクティス | サービスの妥当性確認およびテスト 展開管理 インフラストラクチャおよびプラットフォーム管理 ソフトウェア開発および管理 |
アーキテクチャ管理 | アーキテクチャ管理プラクティスの目的は、組織を構成するあらゆる要素と、これらの要素の相互関係を把握し、組織が現在および将来の達成目標を効果的に達成できるようにすることです。アーキテクチャ管理プラクティスは、組織が体系的かつアジャイルな方法で複雑な変更を管理できる原則、標準およびツールを提供します。 |
ポートフォリオ管理 | ポートフォリオ管理プラクティスの目的は、組織がプログラム、プロジェクト、製品およびサービスを適切に組み合わせて、資金とリソースの制約がある中で戦略を実行できることを確実にすることです。 |
プロジェクト管理 | プロジェクト管理プラクティスの目的は、組織内のすべてのプロジェクトが成功裏に遂行されることを確実にすることです。これは、プロジェクトのあらゆる側面のコントロールを計画、委任、モニタリング、維持して、関係者のモチベーションを保つことで実現されます。 |
関係管理 | 関係管理プラクティスの目的は、戦略レベルおよび戦術レベルで組織と利害関係者との間につながりを確立し、深めることです。そのために、利害関係者との関係の識別、分析、モニタリング、継続的改善などを行います。 |
リスク管理 | リスク管理プラクティスの目的は、組織がリスクを把握して有効に対処できるようにすることです。リスク管理は、組織が継続的な持続性を確保し、顧客にとっての価値を創出するうえで欠かせないものです。リスク管理は組織内のあらゆる活動と不可分なため、組織の SVS の要であると言えます。 |
サービス財務管理 | サービス財務管理プラクティスの目的は、組織による財源と資金の効果的な利用を確実にすることで、組織のサービスマネジメントの戦略および計画を支援することです。 |
戦略管理 | 戦略管理プラクティスの目的は、組織の最終目標を策定し、それらの最終目標を実現するために必要な一連の行動およびリソース割り当てを決めることです。戦略管理を行うと、組織の方向性が定まり、取り組むべきことが絞り込まれます。また、組織の優先度が定義または明確化されるほか、環境に応じた一貫性とガイダンスが提供されます。 |
サプライヤ管理 | サプライヤ管理プラクティスの目的は、高品質な製品とサービスが円滑に提供されるように、組織のサプライヤおよびそのパフォーマンスを適切に管理することを確実にすることです。これには、新しい価値を発見して実現したり、障害のリスクを減らしたりするために、主要なサプライヤとのより緊密で協力的な関係を作ることが含まれます。 |
要員およびタレント管理 | 要員およびタレント管理プラクティスの目的は、事業達成目標の達成を支援するために、適切なスキルとナレッジを備えた優れた人材を組織内の適切な役割に確保することです。このプラクティスは、組織の従業員や人材リソースと良い関係を築くことが重視される、幅広い活動が対象となります。例えば、計画、採用、新人研修、学習と能力開発、パフォーマンス測定および後継者育成などの活動です。 |
可用性管理 | 可用性管理プラクティスの目的は、顧客およびユーザのニーズを満たすために、サービスが合意されたレベルの可用性を確実に提供することです。 |
事業分析 | 事業分析プラクティスの目的は、事業またはその何らかの要素を分析し、それに関するニーズを定義して、それらのニーズへの対応やビジネス上の問題の解決を行うためのソリューションを推奨することです。それにより、利害関係者のために価値創出を促進しなければなりません。組織は事業分析を実施することで、有意義な方法でニーズを明らかにし、変更の論理的根拠を明示できるほか、組織の達成目標に沿った価値創出を可能にするソリューションを設計および記述できます。 |
キャパシティおよびパフォーマンス管理 | キャパシティおよびパフォーマンス管理プラクティスの目的は、サービスが合意済みで期待されたパフォーマンスを達成し、費用対効果の高い方法で現在および将来の需要を満たすことを確実にするこ とです。 |
パフォーマンス | システム、人、チーム、プラクティス、またはサービスによって達成または提供されたものの尺度 |
変更実現 | 変更実現プラクティスの目的は、リスクの適切な評価を確実に行い、変更の進行を承認し、変更スケジュールを管理することで、サービスおよび製品の変更が成功する回数を最大化することです。 |
変更 | サービスに直接的または間接的な影響を及ぼす可能性がある何らかの追加、修正、削除。 |
通常の変更 | リスク評価や承認プロセスが必要です。例えば、新しい機能の追加やシステムのアップグレードなど。 ※ 緊急ではないけど,プロセスが決まっていない変更 |
緊急の変更 | 重大な障害やセキュリティ問題の修正など、即時対応が求められる状況で使用されます。 ※ インシデント発生時など,字面のとおり,緊急対応のときの変更 |
標準的な変更 | 事前に承認された定型的な変更で、定着した手順に従って処理されます。 ※ ユーザの新規追加など,決まったプロセスに従った変更 |
インシデント管理 | インシデント管理プラクティスの目的は、通常のサービス運用を可能な限り迅速に復旧することでイン シデントの悪影響を最小限に抑えることです。 |
インシデント | サービスの計画外の中断、またはサービスの品質の低下。 |
スォーミング | インシデントが発生すると複数の担当者が協力して迅速に解決を目指します。 |
IT 資産管理 | IT 資産管理プラクティスの目的は、組織の役に立つようにすべての IT 資産のライフサイクル全体を計画して管理することです。 • 価値の最大化 • コストのコントロール • リスクの管理 • 資産の購入、再利用、除却、および廃棄に関する意思決定のサポート • 規制上および契約上の要件への対応 |
IT 資産 | IT 製品または IT サービスの提供に利用できる、経済的な価値を持つすべてのコンポーネント。 |
モニタリングおよびイベント管理 | モニタリングおよびイベント管理プラクティスの目的は、サービスおよびサービス・コンポーネントを体系的に監視し、イベントとして識別された状態の変更を選別して記録および報告することです。このプラクティスでは、インフラストラクチャ、サービス、ビジネス・プロセス、および情報セキュリティのイベントを識別し、優先度を付けます。さらに、障害やインシデントの発生につながりかねないイベントや状況に対する適切な対応を確立します。 |
イベント | サービスやその他の構成アイテム(CI)を管理するうえで重要な意味を持つ状態の変更。イベントは通常、IT サービス、CI、またはモニタリング・ツールによって作成された通知によって識別されます。 |
問題管理 | 問題管理プラクティスの目的は、インシデントの実際の原因と潜在的な原因を特定し、ワークアラウンドと既知のエラーを管理することで、インシデントの発生する可能性とインパクトを抑えることです。 |
問題 | 1 つまたは複数のインシデントの原因、または潜在的原因。 |
既知のエラー | 分析済みだが未解決の問題。 |
ワークアラウンド | まだ完全な解決策がないインシデントや問題のインパクトを軽減または排除するソリューション。インシデントの発生する可能性を抑えるためのワークアラウンドも存在します。 |
リリース管理 | リリース管理プラクティスの目的は、新規および変更されたサービスと特性を利用可能な状態にすることです。 ※ 「リリース」=「ユーザーが使える状態にする」,「展開」=「サービスを本番環境に移動する」 |
リリース | 使用可能にしたサービスまたは他の構成アイテムのバージョン、あるいは構成アイテムの集合。 |
サービス・カタログ管理 | サービス・カタログ管理プラクティスの目的は、すべてのサービスとサービス提供に関する一貫した情報を一元管理し、その情報を関係者が利用できるようにすることです。 |
リクエスト・カタログ | サービス・カタログのビューの 1 つ。既存および新規のサービスに対するサービス要求の詳細をユーザに提供します。 |
サービス構成管理 | サービス構成管理プラクティスの目的は、サービスの構成およびそれらを支援する CI に関する正確で信頼できる情報を、必要なときに必要なところで利用可能であることを確実にすることです。これには、CI を構成する方法と CI 間の関連性についての情報が含まれます。 |
構成アイテム | IT サービスを提供のために管理する必要がある、あらゆるコンポーネント。 |
構成管理システム | サービス構成管理を支援するために使用される一連のツール、データ、および情報。 |
サービス継続性管理 | サービス継続性管理プラクティスの目的は、災害の発生時にサービスの可用性およびパフォーマンス を十分なレベルで維持することを確実にすることです。このプラクティスは、主要な利害関係者の利益 および組織の評判、ブランドおよび価値創出活動を保護する効果的な対応を生み出す機能を備えた、 組織の対障害弾力性を強化するためのフレームワークを提供します。 |
サービスデザイン | サービスデザイン・プラクティスの目的は、目的に適し、使用に適し、さらに組織およびそのエコシステムによって提供できる製品およびサービスを設計することです。これには、要員の計画および編成、新規または変更された製品およびサービスに関するプラクティス、パートナおよびサプライヤ、情報、コミュニケーション、技術、そして組織とその顧客の間のやり取りが含まれます。 |
サービスデスク | サービスデスク・プラクティスの目的は、インシデント解決およびサービス要求の需要を収集することです。サービスデスクはまた、サービス・プロバイダがすべてのユーザに用意するエントリ・ポイントおよび単一の窓口であるべきです。 |
サービスレベル管理 | サービスレベル管理(SLM)プラクティスの目的は、サービスレベルの明確な目標値を事業に基づいて設定し、その目標値に対して、サービスの提供を適切に評価、モニタリングおよび管理を確実にすることです。 |
サービスレベル | 期待または実現されるサービス品質を定義する 1 つ以上の測定基準。 |
サービスレベル・アグリーメント | 必要とされるサービスとサービスで期待されるレベルを規定するための、サービス・プロバイダと顧客との間で結ばれる合意文書。 |
サービス要求管理 | サービス要求管理プラクティスの目的は、事前に定義され、ユーザが開始したすべてのサービス要求を効果的かつユーザ・フレンドリーな方法で処理することによって、合意済みのサービス品質を支援することです。 |
サービス要求 | 通常のサービス提供の一部として合意されたサービス活動を開始する、ユーザまたは権限を与えられたユーザ代理人からの要求。 |
サービスの妥当性確認およびテスト | サービスの妥当性確認およびテスト・プラクティスの目的は、新規または変更された製品およびサービスが、定義された要件を満たすことを確実にすることです。サービス価値の定義は、顧客からのインプット、事業達成目標、規制上の要件に基づいており、設計および移行のバリューチェーン活動の一環として文書化されます。これらのインプットは、保証基準とテスト要件の定義を支援する測定可能な品質とパフォーマンスの指標を確立するために使用されます。 |
展開管理 | 展開(デプロイメント)管理プラクティスの目的は、新規または変更されたハードウェア、ソフトウェア、文書、プロセスまたはその他のコンポーネントを稼働環境に移動することです。テストやステージングなど、その他の環境へのコンポーネント展開に関わる場合もあります。 |
展開(デプロイメント) | 任意のサービス・コンポーネントを任意の環境に移動すること。 ※ 「リリース」=「ユーザーが使える状態にする」,「展開」=「サービスを本番環境に移動する」 |
インフラストラクチャおよびプラットフォーム管理 | インフラストラクチャおよびプラットフォーム管理プラクティスの目的は、組織が使用するインフラストラクチャとプラットフォームを監視することです。このプラクティスを正しく実行すれば、外部サービス・プロバイダの技術も含めて、組織が利用できる技術ソリューションをモニタリングできます。 |
ソフトウェア開発および管理 | ソフトウェア開発および管理のプラクティスの目的は、アプリケーションが機能性、信頼性、保守性、コンプライアンス性および監査性の面で内外の利害関係者のニーズを確実に満たせるようにすることです。 |
参考:Gemeni Deep Research によるまとめ
生成AIのDeep Researchがまとめたらどうなるんだろう・・・,とやってみました.
そのまま出力しています.
ITIL 4 Foundation 試験対策:頻出用語とその解説
1. はじめに
ITIL(Information Technology Infrastructure Library)は、世界で最も広く受け入れられているITサービスマネジメントのアプローチです 1。ITIL 4 は、現代のデジタル環境に合わせて設計された、ITサービスマネジメント(ITSM)のための包括的なフレームワークを提供します 1。このフレームワークは、組織内におけるITサービスのガバナンスと管理のための効果的、効率的、柔軟、協調的、そして統合されたシステムを確立することを目的としています 1。ITIL 4 は、ITプロフェッショナルのための明確なキャリアパスを提供するために、Foundationレベルからより高度な資格へと段階的に構成されています 1。
本レポートは、ITIL 4 Foundation 試験の準備をされている方を対象に、頻出する用語とその解説をまとめたものです。試験の合格には、ITIL 4 フレームワーク内で使用される主要な概念と用語の定義を理解することが不可欠です 2。特に、多くのITIL用語は、通常の日本語とは異なる特定の意味を持つ場合があるため、試験準備においてはこれらの違いを明確に把握しておくことが重要となります。本レポートでは、試験で問われやすい用語、ITIL 4 における定義、覚えるべきポイント、そして通常の日本語との意味の違いで注意すべき点を、表形式で分かりやすく整理しています。
2. ITIL 4 の基礎概念
個々の用語の解説に入る前に、ITIL 4 フレームワークの根幹をなす基礎概念を理解することが重要です。これらの包括的な原則とモデルを把握することで、個々の用語の定義をより深く理解することができます。
- サービスバリューシステム(SVS)4 ITIL 4 サービスバリューシステム(SVS)は、ITを活用したサービスを通じて価値を創造するために組織が使用するすべてのコンポーネントと活動を表します 4。これは、すべてのステークホルダーとの価値共創を重視する、包括的かつ統合的なアプローチです 5。SVS は、連携して機能する5つの主要な要素で構成されています。
- 指導原則: これらは、組織の目標、戦略、業務の種類、管理構造の変化に関係なく、あらゆる状況において組織の行動と意思決定を導く7つの普遍的に適用可能な推奨事項です 4。
- 価値に焦点を当てる:すべての行動と投資は、直接的または間接的にステークホルダーへの価値に貢献すべきです 4。
- 現状から始める:組織は、ゼロから始めるのではなく、既存のリソースと能力を活用すべきです 4。
- フィードバックを取り入れながら反復的に進める:改善は、ニーズとの整合性を確保するために定期的なフィードバックループを取り入れながら、管理可能な段階的なステップで実装されるべきです 4。
- コラボレーションと可視性を促進する:効果的なチームワークと透明性は、共通の目標を達成するために不可欠です 4。
- 全体論的に考え、働く:価値を創造するためには、サービスマネジメントのすべての側面を考慮した包括的な視点が必要です 4。
- シンプルで実用的に保つ:プロセスと手順は可能な限り簡潔にし、価値を提供する実用的なソリューションに焦点を当てるべきです 4。
- 最適化と自動化:組織は、最適化と戦略的な自動化の活用を通じて、効率性と有効性を向上させるよう努めるべきです 4。
- ガバナンス: これは、組織に方向性と管理を提供し、すべての活動が戦略的目標とポリシーに沿っていることを保証します 6。
- サービスバリューチェーン(SVC): SVC は SVS の中核となる運用モデルであり、組織がステークホルダーと価値を共創するために実行する6つの主要な活動(計画、改善、エンゲージ、設計と移行、取得/構築、提供とサポート)を概説しています 4。
- プラクティス: ITIL 4 には、作業を実行したり目標を達成したりするために設計された組織的リソースのセットである34の管理プラクティスが含まれています 3。これらのプラクティスは、一般的な管理プラクティス、サービス管理プラクティス、および技術的な管理プラクティスの3つのカテゴリに分類されます 3。
- 継続的改善: これは、サービスバリューシステムのあらゆる側面に対する改善の継続的な特定、分析、および実装に焦点を当てた、包括的な原則であり、専用のプラクティスでもあります 3。
- 指導原則: これらは、組織の目標、戦略、業務の種類、管理構造の変化に関係なく、あらゆる状況において組織の行動と意思決定を導く7つの普遍的に適用可能な推奨事項です 4。
- 4つの側面モデル4 サービスマネジメントへの全体的なアプローチを保証するために、ITIL 4 は、ITサービスを設計、管理、および改善する際に組織が考慮する必要がある4つの側面を定義しています 4。これらの側面は、サービスコンシューマーに効果的かつ効率的に価値を創造するために不可欠な4つの主要な視点を表しています 5。
- 組織と人:この側面は、組織構造、役割、責任、文化、およびサービスバリューシステムに関与する人々の必要なスキルとコンピテンシーを考慮します 4。
- 情報とテクノロジー:この側面には、データ管理、アプリケーション、インフラストラクチャなど、サービスバリューシステムをサポートおよび有効にするために使用される情報、知識、テクノロジー、およびツールが含まれます 4。
- パートナーとサプライヤー:この側面は、サービスの設計、開発、展開、提供、サポート、および継続的改善に関与する外部組織との関係に焦点を当てています 4。
- バリューストリームとプロセス:この側面は、組織内のさまざまな活動、ワークフロー、制御、および手順が、ステークホルダーに価値を提供するためにどのように組織化および統合されているかを記述します 4。
Insight 2: SVS と 4 つの側面モデルを理解することは、すべての ITIL 4 の概念と用語が動作する包括的なフレームワークを提供する上で最も重要です。SVS は価値創造のための戦略的要素を概説し、4 つの側面モデルはサービスマネジメント活動を見て分析するための包括的なレンズを提供します。これらの基礎的な要素の相互接続性を認識することは、ITIL 4 の用語をより深く理解するために不可欠です。たとえば、「サービス」を定義する場合、その価値は常に SVS のコンテキスト内で考慮され、4 つの側面の考慮事項によって形作られます。
3. ITIL 4 Foundation 試験 – 頻出用語とその解説(表)
- このセクションでは、ITIL 4 Foundation 試験で頻出する用語の詳細な表を示します。この表には、用語自体(英語と、明確にするために日本語も含む)、公式の ITIL 4 の定義、試験のために覚えておくべき重要なポイント(多くの場合、ニュアンスや混乱しやすい点に焦点を当てる)、および ITIL 4 の定義が通常の日本語での用語の理解と異なる可能性がある場合の具体的な注意点が含まれます。
- 表内の用語は、SVS の構造(指導原則、サービスバリューチェーンの活動、プラクティス)に従うか、研究スニペットでの出現頻度や ITIL 4 フレームワークにおける一般的な重要性に基づいて、テーマ別に整理されます。このテーマ別の整理は、異なる用語間の関係を理解するのに役立ちます。
用語 (ITIL 4 用語) | ITIL 4 における定義 | 覚えるポイント | 通常の日本語との意味の違い – 注意点 | 関連スニペット |
Service (サービス) | 顧客が望む成果を、顧客が特定のコストとリスクを管理することなく達成できるようにすることで、価値共創を可能にする手段 4 | 価値共創と成果に焦点を当てる。顧客は、サービス提供に関連する内部のコストとリスクを管理しない。 | ITIL の定義は具体的であり、価値創造のためのパートナーシップを強調しており、単に何かを提供するという一般的な「サービス」の理解とは異なる可能性がある。 | 4 |
Value (価値) | 何かの知覚される利点、有用性、重要性 11 | 主観的であり、ステークホルダーによって異なる。ITIL は、すべての活動において価値を提供し、可能にすることを強調する。 | 一般的な日本語の理解と一致するが、ITIL はこれをすべてのサービスマネジメント活動の中心的な推進力として位置づけている。 | 11 |
Outcome (成果) | 1つ以上の出力によって可能になった、ステークホルダーにとっての結果 14 | サービスが提供するものだけでなく、顧客が達成すること、または顧客が実現する利点に焦点を当てる。 | 結果 (kekka) と似ているが、ITIL では、サービスの使用を通じてステークホルダーが経験する価値と利点に特に結び付けられている。 | 14 |
Output (出力) | 活動の有形または無形の成果物 16 | サービスが顧客に生産または提供するもの。成果を可能にする手段である。 | 出力 (shutsuryoku) と似ているが、ITIL では、サービスの活動の直接的な産物であり、それがステークホルダーにとって望ましい成果に貢献する。 | 16 |
Utility (効用) | 特定のニーズを満たすために製品またはサービスによって提供される機能。効用は「サービスが何をするか」と要約でき、「目的に適合しているか」を判断するために使用できる 14 | サービスの機能と性能に関連する。意図された目的に適しているか? | 一般的な日本語の便利さ (benrisa) よりも技術的な可能性がある。「目的に適合している」という側面を強調する。 | 14 |
Warranty (保証) | 製品またはサービスが合意された要件を満たすという保証。保証は「サービスがどのように実行されるか」と要約でき、「使用に適しているか」を判断するために使用できる。保証はしばしばサービスレベルに関連する 14 | サービスの信頼性、可用性、キャパシティ、およびセキュリティに関連する。信頼性があり、安全か? | 欠陥に対する保証としての一般的な日本語の保証 (hoshō) と混同される可能性がある。ITIL の保証は、サービスの性能と合意された品質レベルに焦点を当てる。 | 14 |
Customer (顧客) | サービスの要件を定義し、サービス消費の結果に責任を負う人 13 | ニーズを定義し、サービスの使用結果に責任を負う。 | 一般的な日本語の顧客 (kokyaku) と一致する。 | 13 |
User (利用者) | サービスを利用する人 13 | サービスを直接操作し、利用する。 | 一般的な日本語のユーザー (yūzā) または利用者 (riyōsha) と一致する。 | 13 |
Sponsor (出資者) | サービス消費の予算を承認する人 14 | サービスの財源を提供する。 | スポンサー (suponsā) と理解されるかもしれないが、ITIL の文脈では、サービス消費のための予算承認に特に関連する。 | 14 |
Organization (組織) | 独自の機能、責任、権限、および目的を達成するための関係を持つ、個人または人々のグループ 13 | 定義された構造と目標を持つあらゆる主体。 | 一般的な日本語の組織 (soshiki) と一致する。 | 13 |
Service Management (サービスマネジメント) | サービスという形で顧客に価値を提供するための、特殊な組織能力のセット 4 | IT サービスの計画、提供、管理、および改善に必要なすべての活動とリソースを含む。 | 個々の単語は一般的だが、結合された用語は ITIL において特定の意味を持ち、サービスを通じての価値創造に焦点を当てた組織能力を強調する。 | 4 |
IT Service (ITサービス) | テクノロジーの利用に基づいたサービス。ITSM は、ビジネスのニーズを満たす方法でこれらの IT サービスを管理することである 10 | 情報技術によって実現されるサービス。ビジネス成果を満たすためにこれらのサービスを管理することに重点を置く。 | 一般的な日本語の IT サービス (IT sābisu) と一致する。 | 4 |
Configuration Item (CI) (構成アイテム) | IT サービスを提供するために管理する必要があるコンポーネント 3 | ハードウェア、ソフトウェア、ドキュメント、人員など、サービスに貢献するあらゆるもの。 | 個別設定項目 (kobetsu settei kōmoku) が翻訳として考えられるかもしれないが、ITIL の用語はサービス提供に不可欠な、より広範な管理対象コンポーネントを含む。 | 3 |
Incident (インシデント) | サービスの品質の計画外の中断または低下 3 | 通常のサービス運用を中断するあらゆるイベント。インシデント管理の目標は、サービスを迅速に復旧することである。 | 一般的な日本語のインシデント (inshidento) または IT 文脈での事故 (jiko) と一致する。 | 3 |
Problem (問題) | 1つ以上のインシデントの原因、または潜在的な原因。原因を特定し、回避策を開発し、長期的な解決策を推奨するために、調査と分析が必要となる 3 | インシデントの根本原因。将来のインシデントを防止するために根本原因を特定し、解決することに焦点を当てる。 | 一般的な日本語の問題 (mondai) と一致するが、ITIL では、インシデントの根本原因に特に言及する。 | 3 |
Known Error (既知のエラー) | 分析済みだが、まだ解決されていない問題 3 | 文書化された回避策または一時的な修正がある問題。 | 同じ特定の ITIL の意味を持つ直接的な一般的な日本語の同等語がないかもしれない。理解されているが、まだ完全に修正されていない問題として説明する。 | 3 |
Change (変更) | IT サービスに直接的または間接的な影響を与える可能性のあるものの追加、修正、または削除 3 | IT インフラストラクチャまたはサービスへのあらゆる変更。中断を避けるために慎重な管理が必要である。 | 一般的な日本語の変更 (henkō) と一致する。 | 3 |
Event (イベント) | サービスまたはその他の構成アイテムの管理にとって重要な状態の変化。通常、通知を通じて認識される 3 | 潜在的な問題またはステータスの変化を示す可能性のあるあらゆる出来事。多くの場合、アラートをトリガーしたり、注意が必要になったりする。 | 一般的な日本語のイベント (ibento) または IT 文脈での出来事 (dekigoto) と一致する。 | 3 |
Release (リリース) | サービスまたはその他の構成アイテムのバージョン、または使用可能になった構成アイテムのコレクション 3 | ユーザーが使用できる新しいまたは更新されたサービスまたはコンポーネントを作成する。 | 一般的な日本語のソフトウェア開発または IT 文脈でのリリース (rirīsu) と一致する。 | 3 |
Service Request (サービス要求) | 標準的なサービス提供、何かへのアクセス、アドバイス、または情報に対するユーザーまたは承認された代表者からの要求 3 | 一般的なサービス、情報、またはアクセスに対するユーザー主導の要求。通常、定義済みの手順を通じて処理される。 | 単なるサービス要求 (sābisu yōkyū) よりも広範である可能性がある。「標準」および「ユーザー主導」の側面を強調する。 | 3 |
Practice (プラクティス) | 作業を実行したり目標を達成したりするために設計された組織的リソースのセット 4 | 成功することが証明されている働き方。ITIL 4 には、サービスマネジメントのさまざまな側面をカバーする 34 のプラクティスが含まれている。 | 慣行 (kankō) が翻訳として考えられるかもしれないが、ITIL の用語は、特定の目標を達成することを目的とした組織的能力とリソースの特定のセットを指す。IT では一般的に借用語のプラクティス (purakutisu) が使用される。 | 4 |
Incident Management (Practice) (インシデント管理) | 通常のサービス運用を可能な限り迅速に復旧することにより、インシデントの負の影響を最小限に抑えるプラクティス 3 | サービスへの中断を最小限に抑え、迅速な解決に焦点を当てる。主な活動には、インシデントの記録、優先順位付け、および解決が含まれる。 | 一般的な日本語のインシデント管理 (inshidento kanri) と一致する。 | 3 |
Problem Management (Practice) (問題管理) | インシデントの実際の原因と潜在的な原因を特定し、回避策と既知のエラーを管理することにより、インシデントの可能性と影響を減らすプラクティス 3 | 根本原因を特定し、対処することでインシデントを防止することに焦点を当てる。プロアクティブなアプローチとリアクティブなアプローチを含む。 | 一般的な日本語の問題管理 (mondai kanri) と一致する。 | 3 |
Change Enablement (Practice) (変更イネーブルメント) | リスクが適切に評価され、変更の進行が承認され、サービスと製品の変更の成功数を最大化するために変更スケジュールが管理されることを保証するプラクティス 3 | リスクを最小限に抑え、実装の成功を保証するために、変更を管理および制御することに焦点を当てる。以前は変更管理として知られていた。「イネーブルメント」という用語は、肯定的な結果を可能にするという積極的な側面を強調する。 | 一般的な日本語の変更管理 (henkō kanri) と一致する。イネーブルメント (inēburumento) の使用は、成功する変更を可能にするという積極的な側面を強調する。 | 3 |
Service Desk (Practice) (サービスデスク) | インシデント解決とサービス要求の需要を把握するプラクティス。また、すべてのユーザーにとってのエントリーポイントおよび単一の連絡窓口となるべきである 3 | 問題を報告し、サービスを要求し、情報を求めるためのユーザーの中心的な連絡窓口を提供する。コミュニケーションにおいて重要な役割を果たす。 | 一般的な日本語のサービスデスク (sābisudesuku) またはヘルプデスク (herupudesuku) と一致する。 | 3 |
Service Level Agreement (SLA) (サービスレベル契約) | サービスプロバイダーと顧客間の正式な合意であり、期待されるサービスレベルを概説する。パフォーマンス目標、責任、およびメトリクスを含む 3 | サービスプロバイダーと顧客の両方に対して期待値を設定し、サービスの合意された品質と性能を定義する。 | 一般的な日本語のサービスレベル契約 (sābisu reberu keiyaku) と一致する。 | 3 |
Continual Improvement (Practice) (継続的改善) | 製品とサービスの効果的な管理に関与するすべての要素の継続的な特定と改善を通じて、組織のプラクティスとサービスを変化するビジネスニーズに合わせるプラクティス 3 | サービス、プロセス、および全体的なサービスマネジメント能力を向上させるための継続的な努力の重要性を強調する。継続的改善モデル 3 のような構造化されたモデルに従うことが多い。 | 一般的な日本語の継続的改善 (keizokuteki kaizen) と一致する。 | 3 |
IT Asset (IT資産) | 製品またはサービスの提供に貢献する、経済的に価値のあるコンポーネント 3 | 組織によって管理される、経済的価値のあるあらゆる IT 関連アイテム。ハードウェア、ソフトウェア、ライセンスなどを含む。 | 一般的な日本語の IT 資産 (IT shisan) と一致する。 | 3 |
Availability (可用性) | IT サービスまたはその他の構成アイテムが、要求されたときに合意された機能を実行できる能力 6 | 合意された目標に従って、サービスとコンポーネントがアクセス可能で運用可能であることを保証する。 | 一般的な日本語の可用性 (kayōsei) と一致する。 | 6 |
Capacity Management (Practice) (キャパシティ管理) | サービスがコスト効率の高い方法で需要を満たすのに十分なキャパシティを持つことを保証するプラクティス 6 | 現在および将来のサービスのビジネス需要を満たすために、IT リソースの計画と管理に焦点を当てる。パフォーマンスやコストなどの側面を含む。 | 一般的な日本語のキャパシティ管理 (kyapashiti kanri) または能力管理 (nōryoku kanri) と一致する。 | 6 |
Service Catalog Management (Practice) (サービスカタログ管理) | すべてのサービスおよびサービスオファリングに関する一貫性のある情報の単一のソースを提供するプラクティス 6 | ユーザーが利用できるすべての IT サービスの包括的で最新のリストを提供し、各サービスの詳細を含む。 | 一般的な日本語のサービスカタログ管理 (sābisu katarogu kanri) と一致する。 | 6 |
Business Relationship Management (Practice) (ビジネス関係管理) | 戦略的および戦術的レベルで、組織とそのステークホルダー間のリンクを確立し、育成するプラクティス 3 | 顧客やその他の主要なステークホルダーとの良好な関係を構築および維持することに焦点を当て、彼らのニーズを理解し、価値の提供を保証する。 | 一般的な日本語のビジネス関係管理 (bijinesu kankei kanri) または関係管理 (kankei kanri) と一致する。 | 3 |
Information Security Management (Practice) (情報セキュリティ管理) | 組織がビジネスを行うために必要な情報を保護するプラクティス。これには、情報の機密性、完全性、および可用性に対するリスクの理解と管理が含まれる 3 | 組織の情報資産を不正アクセス、使用、開示、中断、改ざん、または破壊から保護することに焦点を当てる。 | 一般的な日本語の情報セキュリティ管理 (jōhō sekuriti kanri) と一致する。 | 3 |
IT Asset Management (Practice) (IT資産管理) | 組織が価値を最大化し、コストを管理し、リスクを管理し、意思決定をサポートし、規制および契約上の要件を満たすのを支援するために、すべての IT 資産のライフサイクル全体を計画および管理するプラクティス 3 | 取得から廃棄まで、IT 資産のライフサイクル全体を管理することに焦点を当て、その価値が最大化され、リスクが軽減されるようにする。 | 一般的な日本語の IT 資産管理 (IT shisan kanri) と一致する。 | 3 |
Knowledge Management (Practice) (知識管理) | 組織全体での知識と情報の効果的な使用を維持および改善するプラクティス 6 | 意思決定をサポートし、サービス提供を改善するために、組織内での知識と情報の作成、共有、使用、および管理に焦点を当てる。 | 一般的な日本語の知識管理 (chishiki kanri) と一致する。 | 6 |
Major Incident (重大インシデント) | ビジネスオペレーションに重大な影響を与えるインシデント 10 | 重大な影響とビジネスインパクトがあり、専門的で多くの場合迅速な対応が必要なインシデント。 | 一般的な日本語の重大インシデント (jūdai inshidento) と一致する。 | 10 |
Emergency Change (緊急変更) | できるだけ早く実装する必要がある変更。「スピードの必要性」は通常、変更がリスクの増加と事後活動を伴って迅速に進められることを意味する 3 | サービスを復旧したり、重大なビジネスインパクトを防ぐために必要な緊急の変更。標準的な変更プロセスをバイパスすることが多い。 | 一般的な日本語の緊急変更 (kinkyū henkō) と一致する。緊急性とリスク増加の可能性を強調する。 | 3 |
Escalation (エスカレーション) | ITSM タスクを進捗させるために、専門家の助けやより高いレベルの支援または意思決定を求めること 3 | タイムリーな解決を保証するために、インシデント、問題、またはサービス要求をより専門知識や権限のある人に転送する。 | 一般的な日本語のエスカレーション (esukarēshon) と一致する。 | 3 |
Four Dimensions of Service Management (サービスマネジメントの4つの側面) | サービスとサービスマネジメントシステム全体を設計、管理、および改善する際に考慮する必要がある4つの視点。これらは、組織と人、情報とテクノロジー、パートナーとサプライヤー、バリューストリームとプロセスである 4 | サービスマネジメントに関与するすべての主要な要素を考慮するための全体的なフレームワーク。4つのカテゴリとその範囲を覚える。 | 個々のコンポーネントは日本語で理解できるが、「4つの側面」という構造化されたモデルとしての結合された概念は ITIL 4 に特有である。 | 4 |
Guiding Principles (指導原則) | 組織の目標、戦略、業務の種類、または管理構造の変化に関係なく、あらゆる状況において組織を導くことができる7つの推奨事項。価値に焦点を当てる、現状から始める、フィードバックを取り入れながら反復的に進める、コラボレーションと可視性を促進する、全体論的に考え、働く、シンプルで実用的に保つ、最適化と自動化 4 | 優れたサービスマネジメントプラクティスのための普遍的な原則。各原則とそのさまざまな状況への適用方法を理解する。 | 個々の原則は一般的に適用可能だが、ITIL 4 フレームワーク内での特定の表現と一連としての重要性が鍵となる。 | 4 |
Service Value System (SVS) (サービスバリューシステム) | 組織のすべてのコンポーネントと活動が連携して価値創造を可能にするシステムとして機能する方法を表すモデル。これには、指導原則、ガバナンス、サービスバリューチェーン、プラクティス、および継続的改善が含まれる 4 | ITIL 4 における価値創造のための包括的なフレームワーク。その5つのコンポーネントとその相互作用を理解する。 | これは ITIL 4 に特有の中核概念であり、一般的な日本語を超えた特定の理解が必要となる。借用語のサービスバリューシステム (sābisu baryū shisutemu) が使用される。 | 4 |
Service Value Chain (SVC) (サービスバリューチェーン) | SVS の中心的な要素であり、組織が価値を提供するために実行する6つの主要な活動(計画、改善、エンゲージ、設計と移行、取得/構築、提供とサポート)を概説する 4 | 価値創造のための運用モデル。6つの活動とそのバリューストリームにおける目的を覚える。 | 個々の活動は理解できるが、SVC 内での特定の順序と目的は ITIL 4 に固有である。借用語のサービスバリューチェーン (sābisu baryū chēn) が使用される。 | 4 |
4. 結論
ITIL 4 Foundation 試験での成功には、これらの主要な用語を徹底的に理解することが不可欠です。試験では、これらの定義と概念の想起と理解が大きく問われます 1。
表に示された定義、覚えておくべきポイント、および通常の日本語との違いに関する注意点を注意深く見直すことをお勧めします。フラッシュカードを作成したり、その他の暗記テクニックを使用したりして、理解を深めることを検討してください。
本レポートでは、頻繁に使用される用語の多くを取り上げましたが、完全に網羅しているわけではありません。すべての関連用語を完全に理解するためには、Axelos または認定トレーニング機関が提供する公式の ITIL 4 用語集およびその他の学習教材を参照することをお勧めします 17。
試験準備において、皆様の成功を心よりお祈り申し上げます。
コメント