ITIL
【ITIL概要図】
ビジネスを推進するにはIT技術の導入運用することが不可欠
しっかりとしたビジネスの観点が必要で、方向性が示されないと優先順位や投資判断などに迷いが生じる
そのビジネスの観点を実現運用するために、サービスマネジメントやアプリケーション管理、セキュリティ管理がある
それを技術的にICTインフラストラクチャ管理が支えるという構図になる（右図）
---------------------------------
【ファンデーションの出題範囲】
ファンデーションは、サービスマネジメント（サービスデスクとサービスデリバリー）が主な出題範囲
１）サービスサポート
-サービスデスク
-インシデント管理
-問題管理
-構成管理
-変更管理
-リリース管理
２）サービスデリバリー
-サービスレベル管理
-ITサービス財務管理
-キャパシティ管理
-ITサービス継続性管理
-可用性管理
---------------------------------
【サービスデスク】
サービスプロバイダ＝サービスデスク＞ヘルプデスク＞コールセンタ
不平不満もサービスデスクで受け付ける
ユーザからの連絡、記録は、サービスデスクの仕事で、原因究明とその対策をすることはサービスデスクの仕事ではない。スキル型やエキスパートサービスデスクであれば自己解決を行う
非スキル型サービスデスクにおいては、インシデントの解決までは期待されない
ユーザ活動拠点内に設置するサービスデスクがローカルサービスデスクで、オンサイト対応が可能
インシデントのオーナーシップはエスカレーション先があったとしてもサービスデスクが持つ。ユーザとの単一窓口を提供しクローズするまで責任を持つ
インシデントの進捗状況は適時ユーザに連絡する
サービスデスクは問い合わせに早く対応することだけでなく、問い合わせ自体を減らす努力をしていくのが本来の姿である
---------------------------------
【インシデント管理】
インシデント管理は、イベントの受付から解決までの流れを管理するもの。問題の根本原因の解決、調査などは行わない。また、イベントを管理するためであり、基準となるサービス品質があらかじめ定義されていることが前提である
インシデントは3つに大別される。ハードウェア、ソフトウェア、その他（改善要望やマニュアル、ID忘れ対応など）
インシデント管理で扱うイベントには、エラーや問題を含まないものもある。トナーなどの消耗品要求や製品購入の問い合わせなどで、サービス要求と呼ぶ。厳密にはRFCに位置づけられるが、インシデントとして処理されることがほとんどで、インシデントの一つのカテゴリとして理解するのがよい
インシデントのライフサイクルにおいて現在の状況を表したものをワークフローポジションと呼ぶ、ステータス。
インシデントは初期サポートで、インパクト（PC1台、システム全体など影響の度合い）、緊急度（朝まで、代替機でまかなえるなど速さの度合い）、優先度（インパクトx緊急度x工数＝優先度）を分類される。また、エスカレーション先との相談の上、優先度を変更することもある
一般的に、2次、3次と進むにつれて、インシデント解決に要する期間が長く、難易度が高くなる
根本原因を調査することは、インシデント管理でなく問題管理で、インシデント管理の役目はできるだけ早く通常のサービス運用を回復させることである
---------------------------------
【問題管理】
問題管理とは、インシデントや問題の事業に対する悪影響を最小化すること、及び、エラーに関連するインシデントの再発を防ぐことである
インシデント管理やサービスデスクは、発生したインシデントに対し、できるだけ迅速に顧客のサービスを回復させるためのワークアラウンド（回避策）を提供することを主目的としているが、一方、問題管理は、インシデントの根本原因の検知と解決および予防を目的とします
問題の原因が判明してその原因に対応するためにシステムを修正する必要がある場合、その変更作業は変更管理にて計画し、実際の変更作業はリリース管理にて行う
問題コントロールのステップは大きく3つ。問題として認識が必要なものを記録、問題の分析と優先度の設定、問題の調査診断と既知のエラーの識別。その後、エラーコントロールのプロセスに移る
問題コントロールの目的は、CIの故障等の根本原因を識別し、可能であればワークアラウンドに関する情報や助言をサービスデスクに提供すること
問題コントロールで未知の問題を既知のエラーし、エラーコントロールで既知のエラーを取り除こうとします
エラーコントロールの達成目標は、エラーを識別監視し、かつ実行可能でコストが妥当であればそれらのエラーを排除することである。エラーコントロールの対象は既知のエラー
エラーコントロールも問題コントロールと同様にリアクティブな問題管理の側面を持ちます
問題とは、未知の根本原因
既知のエラーとはワークアラウンドが識別された問題
ワークアラウンドとは問題に対する回避策
---------------------------------
【構成管理】
構成管理とは、既存の構成アイテムCIのバージョンを識別、コントロール、維持、検証することにより、インフラストラクチャまたはサービスの論理的なモデルを提供すること
どんな利用環境で問題が発生しているのかという情報を提供、管理するのが構成管理。資産管理と混同して考えてはいけない。計画段階で、管理すべきCIとは何かを明確化することがとても重要。その際に、ハードウェア情報をCIとして管理するだけでは不十分です。個々のハードウェアがどのように接続されているのかや、所有者、シリアル番号などの属性を管理することも大切。
CIは、ハード、ソフト、文書が含まれる。例えば、サービス、装置、アプリケーション、ライセンス、通信サービス、設備など。
所有者や相互関係、構成文書を含む、全インフラストラクチャのCIを目に見える形で識別すること。各アイテムに管理番号のラベル付けや、バージョン名を明記するなど。
構成コントロールとは、ITサービスを構成しているCIの変更を受領から廃棄にいたるまで正確に追跡、管理すること。根拠となる管理文書なしには構成の変更を認めない。一度受け入れたCIの更新は最後まで責任をもって行う
構成管理データベース（CMDB:Configuration Management Database）とは、インシデント、問題、既知のエラー、変更、リリースを含めた全システム・コンポーネントの関係を保持し、従業員、サプライヤ、場所、事業単位といった組織データも包含したもの
棚卸などのタイミングでCMDBをリフレッシュする仕組みを導入すべき
節目となるタイミングでスナップショットとして構成ベースラインを設定する
CMDBは論理的に1つに構成され一元管理されていればよく、複数の物理的DBであっても問題ない
構成管理では、ライフサイクル全体に関して、現在および過去のすべての履歴データを報告する。これにより現在のステータスだけでなくステータスの変化を識別できるようになる
CIの識別とは、識別子やバージョン番号を割り付けること
---------------------------------
【変更管理】
変更管理とは、変更要求を受けて、その変更を効率的かつ迅速に適応するための方法や手順を確立するプロセスです。
変更管理プロセスの最終目的は、全ての変更を効率的にかつ迅速に取り扱うために、標準化された方法、手順が使われることを確実にすること
実際に変更を実施するのはリリース管理のプロセスですが、変更を実施するための計画は変更管理のプロセスで行う
変更マネージャは、すべてのRFCの受領、登録を行い、変更内容のインパクトかや緊急度から、優先順位を標準、通常、緊急に分類し、さらに多数のメンバーで検討する際のとりまとめ役を務める。インパクトが大きな変更の場合、変更諮問委員会（CAB）の召集や、緊急度が高い場合の変更諮問委員会/緊急会議（CAB/EC）の召集など体制を整備し、推進役となります。また実装した全ての変更をレビューしクローズまでの責任を持ちます。
変更管理が運用管理の中で一番神経をつかう。サーバOSの導入から必要最小限しか変更しないというポリシーや本番環境と開発環境のほかに詳細を検証するための環境の設置なども検討する
ついで作業をつい引受けてしまいがちだが、このような要望が出てきた場合にこそ、変更管理の考え方を顧客に啓蒙するチャンスである
RFC：Request for changeには、主な項目として、変更理由、変更しない場合の影響（インパクト）、変更対象であるアイテムのバージョンが挙げられます。他にはRFCの識別番号、関連するCI、RFC提出者の情報、提案日付、変更の優先度など。
CAB：Change Advisory Boardは、提出されたRFC、変更に対する許可、変更スケジュールを検討します。変更がシステムに与える影響度を正しく認識できるメンバーが参画し検討すること、ビジネス面からの優先度を正しく評価できることが必要。基本的に変更は１つずつ行われるべき。
CAB/EC:Change Advisory Board/Emergency Committeeは、CAB召集の時間がない重要度や緊急度の高い変更を緊急変更を検討するための、非常時の決定権限を持つ小さな組織です。決定が属人的になることを防ぐため、日ごろから合意された基準を文書化しておくべき。緊急変更は混乱やエラーを起こしやすいので、事前の想定や手戻りの準備、手順を試しておくことも重要
標準変更とは、手順が決まっておりリスクの少ない変更。変更マネージャの判断にて実施されCABが召集されることはありません。実施経験のある変更や実施後の影響が明らかなものと考えられる。
FSC:Forward schedule of change 将来的な変更スケジュール。あらかじめ合意した期間の実装を許可されている全ての変更と、割り当てられているリソースの詳細が記載されたもの。IT部門の視点でなく事業全体の視点で、昼休みなどの業務休止時や業務上の繁忙期を考慮してスケジューリングされる
PSA:Projected service availability サービスの予想可用性。FSCによって発生する合意済みのSLAやサービスの可用性に対する変更の詳細が記載されたもの。変更が万が一失敗した場合の影響を含めた観点でレビューされる
RFCを出す事のできないプロセスとして、構成管理、リリース管理、変更管理の3つがある。
CABでは、変更の評価や計画を行いますが実施する責任はありません
---------------------------------
【リリース管理】
リリース管理とは、変更を包括的に見渡し、技術と技術以外の視点双方を一緒に検討することを保障することで、変更管理で計画された変更の実施のため計画、テスト、配布、トレーニングなどを行う。確定したソフトやハードのバックアップの保管や構成管理へ変更後の結果を伝えることも重要。緊急の修正の重なりなどによるプログラム仕様書、ソースコード、ロードモジュール間に不整合を防止するための規則なども作成実施する。実際の変更処理自体を正しく行うことを保障するためのプロセスといえる
変更にかかるCIの集まりをリリースと呼び、ソフトウェアで言えばシステムレベル、アプリケーションレベル、モジュールレベルなどのレベルがあり、リリースユニットは、ボリューム、リリースに必要となる時間、インターフェイスの複雑さなどを考慮され設定される。
フルリリースとは、リリースユニットを構成する全コンポーネントの丸ごと置き換えを指す。一部コンポーネントだけ変更すればよい場合でも全体を置き換えます。リリースのためのコストは当然大きくなる。WinXPからWinVistaにいこうするようなケースが該当する
デルタリリースとは、実際に変更が必要なCIのみを含むリリース。セキュリティパッチの適用などが該当する
パッケージリリースとは、フルリリースとデルタリリースの双方の長所を組み合わせたやり方で、機能の単位や業務的なサブシステムの単位などひとまとめにする。通常は、複数のフルリリースやデルタリリースをひとまとめにしてパッケージリリースにする。利点は、テスト範囲が一定に絞られ構成管理がしやすくなる点。サービスパックの適用がパッケージリリースに該当する
DSL:Definitive software library 確定版ソフトウェアの保管庫。DSLには、現在の本番環境で使われているソフトウェアのコピーと、そのソフトウェアに関するソフトウェア・ライセンス証やドキュメントなどが含まれる。開発用、テスト用など各段階の保管も必要ですが、本番用とは物理的にも格納手続きも隔離されている必要があります。DSLの内容は構成管理のCMDBに一致します。
DHS:Definitive hardware store 確定版ハードウェアの予備の安全な保管場所。現在稼働中システムの障害に備えて、代替機を用意しておくこと。全て自前で用意する必要はなく、メーカ取り寄せが許容範囲であればバーチャル保管庫で対応可能。DHSの内容は構成管理のCMDBに一致していなければなりません。
リリースポリシーとは、リリース管理の主要な役割と責任について定義し、頻度とリリースユニットに関することを含みます。規模や特徴、リリースの頻度や回数、ユーザのニーズなどを考慮した上で決定します
リリースユニットは、定型的な組み合わせなどなく、変更する量、変更頻度、実装の難易度などを考慮した上で決定する
フルリリースを複数まとめたものも、デルタリリースを複数まとめたものも、パッケージリリース。
---------------------------------
【サービスレベル管理】
サービスの内容を定め（サービスレベル管理）
サービスが企業活動にとって財務上正当なものであることを考え（ITサービス財務管理）
サービスが適正に提供されていることを監視し（可用性管理、キャパシティ管理）
サービス提供を継続するための計画を練る（ITサービス継続性管理）
サービスデリバリがサービスレベルを管理し、問題や変更をサービスサポートが行う
提供しているサービスとは何かを明文化しSLAを結ぶことがサービスレベル管理の重要な役割。損害賠償など契約のペナルティため、一般的にSLAなどの契約を結ぶことに対して慎重になる傾向があるが、本来契約外である要求が出された際に、一定の歯止めを掛けられるというメリットが挙げられる。要求されたサービスレベルが達成されているかどうか監視できるようになる。またコミットメントとして目標を明確にすることや、決められたあるいは自分で決めた範囲を正確にこなすことがプロフェッショナルであるという意味もある
サービスカタログとは、全てのサービスをカタログ化定義し、サービスの特徴の要約、顧客、維持に関わる人の詳細を列挙したもの。サービスの稼動条件を9-17時と定義していた場合何の心配もなくサーバを停止しメンテができるなど計画が立てやすくなる
期待管理とは、サービス提供時間の延長や値引きなどのサービスレベル要求（SLR:Service level requirements）としてサービスカタログを作成するときの重要な要素で、現状認識と顧客の期待を管理し、顧客満足を得るため適切な顧客の期待を設定管理する組織的なプロセス
SLA:service level agreementは、ITサービスプロバイダとIT顧客の間の文書化された合意で、サービス目標値と両当事者間の責任を定義したもの。注意すべき点は、合意された内容は評価されなければならない、測定可能なサービスを定義することが大切。むやみに項目数を増やしたり、人間の判断が必要とされる部分では、あいまいな項目は入れるべきではない。また、インセンティブやペナルティを規定することがあるが、保障されることはない
SLAの内容としては、合意の当事者、合意の対象範囲、サービスの説明、サービス時間と延長に関する取り決め、可用性、信頼性、サポート時間と延長に関する取り決め、スループット、トランザクション応答時間、バッチターンアラウンドタイム、変更、ITサービスの継続性とセキュリティ、課金、サービスの報告およびレビュー、成果のインセンティブ/ペナルティなどがある
サービスベースSLAとは、一つのサービスを複数の部署が利用するという形態で用いられ、ASPサービスの合意条件などが該当する
顧客ベースSLAとは、顧客が使用する全てのサービスを対象とした一つのSLAで、情報システム部門が完全にアウトソーシングされるようなケースが該当する
マルチレベルSLAとは、SLAの頻繁な更新を避けるため、企業レベル、顧客レベル、サービスレベルの3体系を分けることにより使いやすいサイズに維持することを可能としたSLA。企業レベルでは、ほとんど更新されることのない基本コンセプトをSLAとして定義。顧客レベルでは、特定の顧客に対するサービス内容について合意。サービスレベルでは、特定の顧客に対する特定のサービスの内容について合意する。
OLA:Operational level agreementとは、SLAを実現するためのITサービスプロバイダ内の内部サポートグループ間での簡単な合意
請負契約（UC:Underpinning contract）とは、SLAを実現するためのITサービスプロバイダ内のサポートグループと外部サプライヤ間での契約
内部サポートグループとの取り決めをOLAで行い、外部サプライヤとの取り決めを請負契約UCで行う
SIP:service improvement programとは、サービス品質に悪影響を与える根本的な問題が特定された場合に、問題を克服しサービスレベルを修復するために必要とされるあらゆる処置を特定し実行するために発動されるもの。ソフトウェアではなく各種活動はプロジェクトとして実施されることが多い。このプロジェクトとの上位に位置づけられるのがプログラムになる
---------------------------------
【ITサービス財務管理】
ITサービス財務管理の主軸は、IT会計とIT予算管理と課金。サービス提供の真のコストの理解と、コストの専門的管理、また顧客への実証を狙う
IT会計では、ITサービスを提供するためのコストの管理方法（原価計算の方式など）を定義、すべてのコストを洗い出し、把握、レポートします。元来、適正なコストを管理することが重要であり、それ自体の仕組みを複雑にすると維持するためのコストが増大してしまい効果を発揮しない
課金とは、投資したコストや運用に必要となるコストをSLAに基づいて顧客に請求すること。課金することで、サービスの価値を顧客に強く意識させ投資対効果を高める。実現には、分析や請求、報告プロセスの要件によって判断される詳細レベルの健全なIT会計が必要となる。メインフレーム時代には1ヶ月のCPU使用量やコンピュータの使用時間で課金を行うケースもあった。顧客の組織の財務ポリシーに合致したものが望まれ、ITコストの回収が可能になります
コストは、サービスレベル管理（どんなサービス）、キャパシティ管理（どのように運用する）、構成管理（何をつかって）と密接な関係にある
IT予算とは、支出を予測しコントロールするプロセスで、周期的な予算折衝サイクル（年次）と日々の現行予算の監視からなる。詳細を確認すると重要性の低いシステムだということもあるので客観的に評価し適切な予算措置でコストダウンを心がける
---------------------------------
【キャパシティ管理】
キャパシティ管理とは、キャパシティに対するコスト、需要に対する供給のバランスをとる活動。ツール化が進んでおり、監視などを実現する様々なツールが販売されている。ツールがリアルタイムに事象を捉えるが、通報をわすれがち、対応すべき人間に伝わらなければ対応が遅くなる。事業キャパシティ管理、サービスキャパシティ管理、リソースキャパシティ管理の3つのサブプロセスからなる。
事業キャパシティ管理とは、将来の業務要件を確実に検討し文書化、十分なキャパシティを適切な時期に確実に計画、実装すること。人間系リソースの計画の方が重要な場合も多い
サービスキャパシティ管理とは、サービスのパフォーマンスに焦点をあてた管理。WEBシステムで言えばアクセスレスポンス実測ツールなどの導入も一つの手段
リソースキャパシティ管理とは、システムのリソースを管理する。CPU利用率やメモリ利用率が結果的にしきい値を越えたということが、後から判明してもあまり意味がなく先取りすることが重要。突発的な業務のピークはツールで監視するなどを行う
キャパシティ管理データベース（CDB）とは、事業データ、財務データ、サービスデータ、技術データ、利用データなどから構成され、管理レポートから人とシステム系リソースの管理をプロアクティブに行うことを狙う
対障害弾力性とは、障害にどれだけ弾力的に対応ができるかということ。機器の2重化などの冗長化構成など。業務設計を行う際に運用面から見て適切かを判断するためにITILという見方で設計を考える企業が増えてきた
反復的なキャパシティ管理の活動とは、監視、分析、チューニング、実装というサイクルを繰り返し行うことで進化する業務要件に適用していくこと。定期的に問題検知のしきい値のチューニングを行う
需要管理とは、キャパシティが足りないときの対策を短期的または長期的な観点から整備すること。短期的には縮退運転をする、長期的には運用を見直して負荷分散を図るなどを行う
---------------------------------
【ITサービス継続性管理】
ITサービス継続性管理とは、非常事態が発生したときに備える対策で、事業が中断した後、事前に合意されたITサービスのレベルを提供し続ける組織の能力を管理すること。ITシステムの備えだけでなく、オフィス、書類の控え、電話などの設備の準備も必要。ITシステムの面では、冗長化や2重化によって信頼性を向上しようとするリスク低減手段と、復旧のためにデータセンタを分散したり、バックアップを確実に取得したり管理するといった対策を行う
事業継続性管理（BCM）とは、ITサービス継続性管理と可用性管理の上位に位置づけられる。ITサービス継続性管理では事業に対するITサービスの継続性に、可用性管理は日常の障害に焦点を当てているのに対し、BCMでは事業を構成するすべてのサービスを対象にしている。これらは定期的な障害への対策訓練に尽きる
ITサービス継続性管理と可用性管理の範囲の線引きは、事業の要件、必要なコストなどにより変化するため一概には定義できず個別に定義するなどする
ITサービス継続性管理の適用範囲内のリスクには、自然災害、停電などの大事故、テロ事件などが含まれる。適用範囲外のリスクには、事業の方向性、多様化、リストラクチャリングといった変化に関する長期的なリスクがある。ディスク障害などの小さな故障もITサービス継続性管理の範囲外となり、インシデント管理や問題管理の対応範囲となる。適用範囲外リスクは考慮しない
ビジネスインパクト分析（BIA）とは、ビジネスが中断したときにどのくらい損失が発生するか、さらに時間の経過とともにビジネスへのインパクトがどのように変化するかを理解し、どの時点で致命的となるのかを理解する必要がある
リスク評価は次のようになる、資産x脅威X脆弱性＝リスク
リスク低減手段とは、被災を含むハードディスクの損傷に備えてバックアップを取得すること、電源供給の中断に備えて電源供給装置を用意することなどが挙げられる。セキュリティシステムの強化や変更管理のきっちり運用の習慣化なども
復旧オプションは6つ。１）何もしない（故障したら直るまでシステムを停止することが許されるケース）、2)手作業のワークアラウンド（POSが壊れたら領収書を手書きする）、3)相互協定（別の会社とあらかじめ協定を結んでおき非常時に助け合う）、4)コールドスタンバイ（場所とITインフラだけを用意しておき非常時には機器を持ち込んでシステムを再開する）、5)ウォームスタンバイ（場所とITインフラと機器を用意しておき非常時にはデータの同期をとりシステムを再開する）、6)ホットスタンバイ（常にデータの同期が取れているバックアップセンタを用意し非常時に即座にサービスの回復を実現する）
---------------------------------
【可用性管理】
可用性管理は、日常の障害に備える対策。想定内のリスクとして、データ破壊、ハード障害、ネットワーク障害、電源障害など。利用不能時間が少ないことを可用性が高いと表現する
信頼性とは、コンポーネントが故障しない能力で、通常はMTBF（平均故障間隔）で評価される。壊れないコンポーネントを信頼性が高いと表現する
保守性とは、障害が発生しサービスが停止してから回復する能力。ダウンから早く回復できるコンポーネントを保守性が高いと表現する。平均修復時間（MTTR）などの測定基準を使用する
サービス性とは、外部組織・企業が提供する可用性、信頼性、保守性を保証する契約上の取り決め。サービス性が良いと表現する？
重要ビジネス機能（VBF）とは、Vital Business Functionの略で、ITサービスを構成する特に重要かつ不可欠な機能を指す。小売業のPOS端末など
ITサポート組織とは、保守・修理・サポートのための内外部のサプライヤ。外部サプライヤとの請負契約や、内部の保守チームとOLAによる
コンポーネント障害インパクト分析（CFIA）とは、電源、サーバ、ディスク、などといった一つのコンポーネントの障害が、各サービスに対してどれだけ影響を及ぼすかをマトリクスで整理する分析手法
故障樹解析（FTA）とは、ITサービスの中断を引き起こす連鎖、関係を図に示すこと。ネットワークのダウンが、システムダウン、サービスダウンにどのような関係があるかを示したものになる
サービス停止分析（SOA）とは、各サービスの一部をサンプリングし、選定し、そのサービスについて可用性を向上させるための仮説を構築します。そしてデータの分析、キーパーソンへのインタビューなどから結論を導き出し、改善への提言をするというアプローチ
可用性＝（合意済みサービス時間-合意済みサービス時間中の実際のダウンタイム）/合意済みサービス時間x100%、どのくらい可用性が向上したかを数値で定量的に示せるというメリットがある
ファンデーション, 試験, 資格, foundation, ファウンデーション, 問題集, ファンデーション, 試験, 模擬, 試験, 試験, 問題, マネージャー, 問題, 入門, 受験, 導入, サービス, サポート, セミナー, manager, 受験料, 運用, 模擬, 問題, 研修, 練習, 問題, サービス, デスク, ファンデーション, 資格, 教科書, ポリシー, 構成, 管理, 用語, 用語, 集, 事例, ツール, 書籍, インシデント, 管理, 問題, 管理, pdf, sla, インパクト, 分析, サービス, サポート, サービス, デリバリー, 実践, 概要, 試験, 対策, 資格, 試験, practitioner, サービス, マネージャー, ファンデーション, 問題, アセスメント, セミナー, 2007, 大阪, アダルト, サービス, デリバリー, インシデント, 赤本, 手順, 書, 認定, 試験, 運用, 管理, 開発, 依頼, nec, v3, 富士通, 障害, 管理, ファンデーション, 合格, 率, ファンデーション, 練習, 問題, 構築, 導入, 事例, 過去, 問, ファウンデーション, 資格, 本, 試験, 問題集, 資格, 取得, プラクティショナー, 合格, 過去, 問題, 青本, プラクティショナ, 効果, 無料, 雛形, iso, 合格, 率, 変更, 管理, 大全, 無料, 試験, , cmdb, pd0015, subversion, サービス, カタログ, リリース, 管理, 試験, 問題, パソコン, 版, cobit, nec, pd0005, による, 運用, 管理, 実際, サービス, カタログ, サンプル, ファウンデーション, 試験, ファンデー