00このページの読み方と34個の地図
プラクティスは「部署の名前」でも「手順書」でもありません。ある種類の仕事をうまくこなすために組織が持っておくべき能力の束です。人・情報と技術・パートナー・仕事の流れという4つの側面すべてを含むので、「インシデント管理」と言ったときは、受付の手順だけでなく、担当者のスキル、使うツール、ベンダーとの取り決めまでが含まれます。
このページでは34個それぞれを、次の6項目で解説します。例はすべてこのページ用に作ったもので、原書の訳ではありません。
| 項目 |
何が書いてあるか |
| 一言で |
そのプラクティスの目的を、短く言い換えたもの |
| 防ぐ失敗 |
これが弱い組織で何が起きるか。覚えるときの手がかり |
| 中身 |
主な活動、押さえるべき用語 |
| 具体例 |
社内IT部門を想定したオリジナルの場面 |
| 混同注意 |
似たプラクティスとの見分け方 |
| 試験 |
Foundation試験での扱い（★★＝中身まで出題、★＝目的が出題、－＝出題範囲外） |
34個の地図
覚える優先順位は「★★の7個 → ★の8個 → 残り19個」です。残り19個は試験範囲外ですが、★★や★のプラクティスと一緒に働く場面が多いので、名前と役割だけでも知っておくと理解が深まります。
01一般マネジメントプラクティス（14個）
経営全般で昔から使われてきた考え方を、サービス管理に合わせて取り入れたものです。IT部門に限らず、組織のどこにでもある仕事が並びます。
Continual improvement継続的改善
★★ 中身まで出題ITIL 5: CAI
- 一言で製品・サービス・プラクティスを少しずつ良くし続け、変わっていく事業のニーズに合わせる。
- 防ぐ失敗改善が「気づいた人の善意」頼みになり、思いつきの改善が乱立する。どれが効いたのか誰にも分からない。
- 中身
- 改善の文化を育てる。改善は全員の仕事で、専任チームを置いても任せきりにしない。リーダーが率先して示す。
- 改善案は continual improvement register（CIR） に集め、価値と手間で優先順位を付ける。CIRは1つとは限らず、チームごとに持ってもよい。
- 進め方は第4章の「継続的改善モデル」（7ステップ）を使う。手法はLean、Agileのふりかえり、DevOpsの実験など何でもよい。
- サプライヤーとの契約にも、改善の義務と測り方を入れておく。
- 具体例ヘルプデスクのメンバーが「同じ質問が多い」と気づき、CIRに登録。翌月の見直しで優先度が高いと判断され、FAQ整備が改善テーマになる。
- 混同注意SVSの「構成要素としての継続的改善」、バリューチェーンの「Improve活動」、このプラクティスは別物です。順に「仕組み」「仕事の流れの中の工程」「それを支える能力と道具」と覚えます。
- 試験「改善は誰の責任か」→全員。「改善案を記録するのは」→CIR。この2つは定番です。
Information security management情報セキュリティ管理
★ 目的が出題ITIL 5: CAI
- 一言で事業を続けるのに必要な情報を守る。
- 防ぐ失敗情報漏えいや改ざんで事業が止まる。逆に守りすぎて、誰も仕事ができなくなる。
- 中身
- 守る対象は confidentiality（機密性：見てよい人だけが見られる）、integrity（完全性：正しく改ざんされていない）、availability（可用性：必要なときに使える）。加えて authentication（認証：本人であることの確認） と non-repudiation（否認防止：やったことを後から否定させない）。
- 対策は prevention（予防）、detection（検知）、correction（是正） の組み合わせ。
- 守ることとイノベーションのバランスが要る。ルールが厳しすぎると、抜け道を探す人が出てかえって危険になる。
- 一番効くのは、社員一人ひとりの意識と行動。
- 具体例退職者のアカウントを即日止める（予防）、深夜の大量ダウンロードを検知する（検知）、漏えい時に手順どおり封じ込めて報告する（是正）。
- 混同注意availabilityという言葉は可用性管理にも出てきます。セキュリティでは「守るべき性質の1つ」、可用性管理では「サービスの約束の水準」です。
- 試験目的のキーワードは「事業に必要な情報を守る」と「機密性・完全性・可用性」。
Relationship management関係管理
★ 目的が出題ITIL 5: CAI
- 一言で組織と利害関係者のつながりを、戦略と戦術のレベルで築き、育てる。
- 防ぐ失敗困ったときだけ連絡する関係になり、相手の優先順位や不満が見えない。気づいたときには信頼を失っている。
- 中身
- 利害関係者を特定し、分析し、関係の状態を見守り、改善し続ける。
- 相手の優先順位と期待を理解し、複数の関係者の期待がぶつかるときは調整する。苦情は誠実かつ正式な手順で扱う。
- 担い手の例が BRM（ビジネス関係マネージャー）。事業部門の相談相手として、ニーズを聞き、ITの提案につなげる。
- 具体例情シスの担当者が月に一度、営業部長と30分話す。来期の重点や、システムへの不満を聞いておくと、問い合わせが来る前に手を打てる。
- 混同注意SLMは「合意したサービスの水準を測って管理する」、関係管理は「その前提になる信頼関係を育てる」。数字の話か、関係の話かで見分けます。
- 試験「戦略的・戦術的なレベルで」「関係を築き、育てる」がキーワード。
Supplier managementサプライヤー管理
★ 目的が出題ITIL 5: CAI
- 一言で外部に頼っている部分の質と、提供の切れ目のなさを守る。重要なサプライヤーとは協力関係を深め、新しい価値を生み、失敗のリスクを減らす。
- 防ぐ失敗ベンダー任せで品質が分からない。契約に穴があり、障害時に誰も動かない。1社に頼りすぎて交渉力を失う。
- 中身
- 調達の型：insourcing（内製）、outsourcing（外部委託）、single source / partnership（1社に集中・提携）、multi-sourcing（複数社に分散）。
- サプライヤーは重要度と影響、リスク、コストで分類し、付き合い方の濃さを変える。
- 主な活動：サプライヤー計画、評価と選定、契約交渉、分類、契約の管理、保証（warranty）条項の管理、実績の管理、更新または終了。
- 複数のサプライヤーをまとめる service integration（サービス統合） の役割を、自社か主要サプライヤーが担うこともある。
- 具体例ヘルプデスクを外部委託するとき、応答時間の目標と月次レビューを契約に書き、毎月の実績を見て改善を求める。
- 混同注意「パートナーとサプライヤー」は4つの側面の1つ、サプライヤー管理はそれを扱うプラクティスです。側面は「考える観点」、プラクティスは「実際の仕事の能力」。
- 試験目的の「サプライヤーとその実績を適切に管理し、製品とサービスの切れ目のない提供を支える」をつかんでおけば十分です。
Architecture managementアーキテクチャ管理
－ 出題範囲外
- 一言で組織を作っている要素と、そのつながりの全体像を持ち、複雑な変化を構造的に、かつ機敏に進められるようにする。
- 防ぐ失敗部署ごとに勝手にシステムを入れ、つながらないシステムとデータが乱立する。
- 中身対象は、ビジネス、サービス、情報システム（データとアプリ）、技術、そして外部環境を描く環境アーキテクチャ。現在の姿と目指す姿、その間の道筋を示す原則・標準・道具を提供する。
- 具体例新しいSaaSを入れる前に「既存のID管理とつながるか」「同じデータを二重に持たないか」を確認する。
- 混同注意ポートフォリオ管理は「何に投資するか」、アーキテクチャ管理は「どう組み立てるか」。
Knowledge managementナレッジ管理
－ 出題範囲外
- 一言で組織の情報と知識を、効果的・効率的・便利に使える状態に保ち、良くしていく。
- 防ぐ失敗知識が特定の人の頭の中にしかなく、その人が休むと仕事が止まる。文書はあっても古くて誰も信じていない。
- 中身文書化された知識だけでなく、経験に根ざした暗黙の知識も扱う。「必要な人に、必要なときに、使える形で」届けることが目的で、量を集めることが目的ではない。
- 具体例障害対応の後に「何が起きて、どう直したか」を5行で残し、検索できる場所に置く。次の担当者が同じ障害を10分で直せるようになる。
- 混同注意構成管理は「サービスを作る部品の情報」、ナレッジ管理は「仕事のやり方や判断の知識」。
Measurement and reporting測定と報告
－ 出題範囲外
- 一言で適切なデータを集め、文脈の中で正しく評価して、判断の不確かさを減らす。
- 防ぐ失敗感覚で判断する。逆に、意味のない指標を大量に集めて誰も見ない。
- 中身
- CSF（重要成功要因）：狙った結果を得るために欠かせない前提条件。KPI（重要業績評価指標）：その達成度を測る重要な指標。
- 指標は人の行動を変える。たとえば「問い合わせの平均対応時間」だけを目標にすると、難しい案件を早く閉じる行動を招く。だから指標は意図しない副作用まで考えて選ぶ。
- 報告は、受け手が何を判断したいかに合わせて作る。
- 具体例CSF「利用者が自力で解決できる」、KPI「FAQ経由で解決した割合」。
- 混同注意SLMも測定をしますが、対象は「顧客と合意したサービスの水準」に限られます。測定と報告は組織のあらゆるものを対象にします。
Organizational change management組織変更管理
－ 出題範囲外
- 一言で変化の「人の側面」を扱い、組織の変更を円滑に成功させ、効果を長続きさせる。
- 防ぐ失敗新しい仕組みを入れたのに、現場が受け入れず元のやり方に戻る。
- 中身
- 成功の条件は4つ：明確で納得できる目的、強く本気のリーダーシップ、意欲があり準備のできた参加者、改善の持続。
- 主な活動：関係者の分析と巻き込み、コミュニケーション、抵抗への対応、研修、新しい行動の定着。
- 他のプラクティスと違い、責任を外部に移すことはできない（組織自身の変化だから）。
- 具体例紙の申請を電子化するとき、「何が楽になるか」を部署ごとに説明し、各部署に推進役を置き、旧方式の受付期限を決める。
- 混同注意Change control（変更管理）は「本番環境などへの変更の許可とリスク」、組織変更管理は「人と組織の受け入れ」。名前は似ていますが対象が違います。
Portfolio managementポートフォリオ管理
－ 出題範囲外
- 一言で限られたお金と人の中で戦略を実行できるよう、プログラム・プロジェクト・製品・サービスの組み合わせを適切に保つ。
- 防ぐ失敗声の大きい部署の案件から順に進み、戦略に効くものが後回しになる。
- 中身製品・サービスのポートフォリオ、プロジェクトのポートフォリオ、顧客のポートフォリオを扱う。重複をなくし、リスクを見て、投資の優先順位を決める。
- 具体例来年度のIT案件20件を、戦略への貢献、リスク、必要な人員で並べ、上位8件に絞る。
- 混同注意プロジェクト管理は「決まった案件を成功させる」、ポートフォリオ管理は「どの案件をやるか決める」。
Project managementプロジェクト管理
－ 出題範囲外
- 一言で組織のプロジェクトを成功させる。計画し、任せ、見守り、統制し、関わる人の意欲を保つ。
- 防ぐ失敗期限も予算も超え、終わってみたら目的とずれている。
- 中身プロジェクトは成果物を届けるための一時的な体制。要件が明確で安定していればウォーターフォール型、変わりやすければAgile型を選ぶ。今の業務を回しながら、変化を起こす必要がある。
- 具体例勤怠システムの入れ替えを、半年・5人のプロジェクトとして立ち上げる。
- 混同注意ポートフォリオ管理との違いは上を参照。
Risk managementリスク管理
－ 出題範囲外
- 一言で組織がリスクを理解し、うまく扱えるようにする。組織が続くためにも、顧客に価値を出すためにも欠かせない。
- 防ぐ失敗起きてから慌てる。または、リスクを恐れて何も新しいことができない。
- 中身
- リスクは特定され、評価され、対応されなければならない。
- リスクは事業の一部：すべてのリスクを避けるのではなく、組織が取ってよいリスクの大きさ（リスク許容度）の中で取りにいく。挑戦しないこともリスクになる。
- 具体例新しいAIツールを試すとき、「個人情報を入力しない」というルールで情報漏えいのリスクを下げた上で、試行を許可する。
- 混同注意継続性管理は「災害という特定の大きなリスク」への備え、リスク管理はあらゆるリスクの扱い方全般。
Service financial managementサービス財務管理
－ 出題範囲外
- 一言で組織のお金と投資が有効に使われるようにし、サービス管理の戦略と計画を支える。
- 防ぐ失敗どのサービスにいくらかかっているか分からず、やめる判断も増やす判断もできない。
- 中身budgeting/costing（予算と原価計算：お金の出入りを予測し管理する）、accounting（会計：お金の使われ方を明らかにする）、charging（課金：利用者に請求する。任意だが、どのサービスにも費用の把握は必要）。
- 具体例社内のPC貸与サービスの1台あたり年間コストを出し、リースと購入のどちらが安いか比べる。
- 混同注意IT資産管理も費用を扱いますが、対象は「個々の資産の一生」。財務管理は「組織全体のお金の流れ」。
Strategy management戦略管理
－ 出題範囲外
- 一言で組織の目標を決め、そこへ向かう行動と資源の配分を決める。方向、集中、優先順位、環境変化への一貫した対応を与える。
- 防ぐ失敗部署ごとに別の方向を向き、努力が分散する。
- 中身外部環境と自社の力を分析し、目指す姿を描き、実行し、見直す。
- 具体例「3年で問い合わせ対応の半分をセルフサービスに移す」とIT戦略に書き、ポートフォリオ管理で関連案件を優先する。
- 混同注意ガバナンス（EDM）は「方向が正しいかを監督する」、戦略管理は「その方向を作る」。
Workforce and talent management人材管理
－ 出題範囲外
- 一言で事業目標を支えるために、適切なスキルと知識を持つ人を、適切な役割に置く。
- 防ぐ失敗必要なスキルを持つ人がいない、いても別の仕事をしている、育てる仕組みがない。
- 中身要員計画、採用、オンボーディング、学習と育成、業績の測定、メンタリングと後継者計画。organizational velocity（組織が動く速さ・効果・効率）を高めることに直結する。
- 具体例クラウド移行に備え、運用担当2名に半年かけてクラウドの研修と実務を経験させる。
- 混同注意組織変更管理は「変化を受け入れてもらう」、人材管理は「必要な力を持つ人をそろえる」。
03技術マネジメントプラクティス（3個）
技術管理の分野から取り入れ、関心の中心を「技術そのもの」から「ITサービス」に移したものです。
Deployment management展開管理
★ 目的が出題ITIL 5: PIC
- 一言で新しい、または変更されたハードウェア・ソフトウェア・文書・プロセスなどを、本番環境へ移す。テストやステージングの環境へ移すこともある。
- 防ぐ失敗手作業の展開で設定漏れが起き、本番だけ動かない。全台一斉に入れて、全社が一度に止まる。
- 中身展開の方式。
- Phased deployment（段階的展開）：本番の一部にだけ先に入れ、順に広げる。
- Continuous delivery（継続的デリバリー）：必要なときに統合・テスト・展開を繰り返し、頻繁にフィードバックを得る。
- Big bang deployment（一斉展開）：すべての対象に同時に入れる。
- Pull deployment（プル型展開）：管理されたリポジトリに置き、利用者が自分の都合でダウンロードする。
- 具体例ブラウザの拡張機能を、まず情シス10人に入れ（段階的）、1週間後に全社へ広げる。社内アプリはポータルに置いて各自が入れる（プル型）。
- 混同注意展開＝置く、リリース＝使えるようにする、変更管理＝やってよいか決める。
- 試験目的の「本番環境へ移す」と、4つの方式の名前。
Infrastructure and platform managementインフラストラクチャおよびプラットフォーム管理
－ 出題範囲外
- 一言で組織が使うインフラとプラットフォームを監督する。外部のサービス提供者の技術も含めて把握する。
- 防ぐ失敗クラウド、社内サーバー、SaaSがばらばらに増え、全体の費用も責任範囲も見えない。
- 中身
- クラウドのサービスモデル：SaaS（クラウド上のアプリを使う）、PaaS（自分のアプリをクラウドの基盤に載せる）、IaaS（計算資源やストレージそのものを使う）。
- 配置モデル：private（1組織専用）、public（一般向け）、community（関心を共有する組織群で共有）、hybrid（組み合わせ）。
- クラウドへ移ると、ほかのプラクティスも変わる。財務（設備投資から利用料へ）、サプライヤー管理（選ぶだけから、統合して管理する方向へ）、キャパシティ（費用とセットで管理）、変更管理（提供者側の変更もあり、責任の境界を引き直す）、インシデント管理（自分で直すより、提供者との連携が中心に）、展開管理など。
- 具体例社内のファイルサーバーをSaaSのストレージに移し、障害時は提供者のステータスページを確認する手順をインシデント対応に加える。
- 混同注意アーキテクチャ管理は「全体の設計図」、こちらは「実際の基盤の運営と監督」。
Software development and managementソフトウェア開発および管理
－ 出題範囲外
- 一言でアプリケーションが、機能・信頼性・保守性・法令遵守・監査可能性の面で、社内外の関係者のニーズを満たすようにする。
- 防ぐ失敗動くが直せないコードが残り、作った人しか触れない。
- 中身ソリューションのアーキテクチャと設計（UI、CX、サービスデザインなど）、開発、テスト（単体・結合・回帰など）、コードリポジトリの管理、展開用パッケージの作成、バージョン管理。開発手法は組織と製品に合わせて選ぶ。
- 具体例社内ツールのコードをリポジトリで管理し、変更のたびに自動テストを走らせる。
- 混同注意展開管理は「作ったものを移す」、こちらは「作って、守り続ける」。
04プラクティス同士のつながり
プラクティスは単独では動きません。実際の仕事では、いくつかのプラクティスがバトンを渡し合います。代表的な3つの流れを見ておくと、「どこで何が出てくるか」がつかめます。
流れ1：障害が起きてから、二度と起きないようにするまで
- Monitoring and event management が異変に気づく（warning → exception）。
- Service desk が利用者からの連絡を受ける。
- Incident management がまず元に戻す（回避策で戻すことも多い）。
- Problem management が原因を突き止め、既知のエラーと回避策を記録する。
- Change control が恒久対策の変更を評価し、許可する。
- Deployment management が修正を本番へ移し、Release management が使える状態にする。
- Service configuration management の情報が、3〜6のすべてを速くする。
- Continual improvement が振り返り、次の改善をCIRに積む。
流れ2：新しいサービスを作って届けるまで
- Relationship management と Business analysis が事業のニーズをつかむ。
- Portfolio management と Strategy management がやるかどうかを決める。
- Architecture management が全体との整合を見る。
- Service design が使われる形に設計し、Project management が進める。
- Software development and management と Infrastructure and platform management が作る。必要なら Supplier management で外部から調達する。
- Service validation and testing が要件を満たすか確かめ、Change control・Deployment management・Release management で届ける。
- Service level management が目標を合意し、Service catalogue management がカタログに載せる。
流れ3：日々のお願いをさばく
- 利用者が request catalogue（Service catalogue management）から頼めるものを選ぶ。
- Service desk（またはポータル）が受け付ける。
- Service request management が標準化・自動化された手順で応える。手順が本番環境に触れる場合は、事前承認済みの標準変更として扱われることが多い。
- IT asset management が、配ったPCやライセンスを台帳に反映する。
ITIL 5の3クラスター（ガイドブックの説明）
ITIL 5のガイドブックは、Practice Manager向けに15個を3つにまとめています。上の流れと重ねるとよく分かります。
| クラスター |
意味 |
含まれるプラクティス |
上の流れでいうと |
| MSF（Monitor, Support and Fulfil） |
運用の安定と利用者への対応 |
Service desk、Incident、Problem、Service request、Monitoring and event |
流れ1の前半と流れ3 |
| PIC（Plan, Implement and Control） |
変更と資産の統制 |
Change enablement、Deployment、Release、Service configuration、IT asset |
流れ1の後半と流れ3の資産 |
| CAI（Collaborate, Assure and Improve） |
品質と関係の戦略 |
Relationship、Supplier、Service level、Continual improvement、Information security |
流れ2の入口と出口、流れ1の最後 |
この15個は、ITIL 4 Foundationで★★と★が付いた15個とちょうど同じです。
05理解度チェック
このページ用に作った問題です。答えを選んでから開いてください。
Q1. どのプラクティスか
社員から「来月入社する人のPCとアカウントを用意してほしい」と依頼が来た。中心になるプラクティスはどれか。
- A. Incident management
- B. Service request management
- C. Change control
- D. Problem management
答えと解説を見る
正解：B。あらかじめ決まった、通常業務としての依頼なのでサービス要求です。何も壊れていないのでインシデントではありません。アカウント作成が本番環境に触れても、通常は事前承認済みの標準変更として扱われ、依頼そのものはサービス要求管理が受け持ちます。（→Service request management）
Q2. 問題管理のフェーズ
障害の原因が「古いドライバー」だと分かったが、全台の更新はすぐにはできない。そこで原因と「当面は再起動で回避」という手順を記録した。これはどのフェーズか。
- A. Problem identification
- B. Problem control
- C. Error control
- D. Incident management
答えと解説を見る
正解：B。分析して、回避策と既知のエラーを記録するのが問題コントロールです。恒久対策（全台の更新）を検討し、変更管理につなぐのがエラーコントロールです。（→Problem management）
Q3. 変更の種類
業務時間中に、外部から攻撃されている脆弱性が見つかった。今日中にパッチを当てたい。正しい扱いはどれか。
- A. 緊急なので、評価も許可もせずに当てる
- B. 緊急の変更として、評価と許可を行い、文書化の一部は後回しにする
- C. 通常の変更として、来週の定例会議で承認を得る
- D. 標準変更として、手順書どおりに当てる
答えと解説を見る
正解：B。緊急の変更でも評価と許可は省きません。急ぐために、文書化などを後回しにできるだけです。（→Change control）
Q4. 展開とリリース
新しい機能をすでに本番環境に置いたが、利用者にはまだ見えないようにしてある。来週、営業部だけに使えるようにする。来週の作業にあたるのはどれか。
- A. Deployment management
- B. Release management
- C. Service validation and testing
- D. Change control
答えと解説を見る
正解：B。本番に置くのが展開、利用者が使えるようにするのがリリースです。feature flags などで、2つのタイミングを分けられます。（→Release management）
Q5. 監視とイベント
ディスク使用率が80%になり、通知が出た。まだ利用者への影響はない。このイベントの種類はどれか。
- A. Informational
- B. Warning
- C. Exception
- D. Incident
答えと解説を見る
正解：B。悪影響が出る前に手を打てる段階なので warning です。基準違反が起きていれば exception、実際にサービスが中断していればインシデントです。（→Monitoring and event management）
Q6. SLM
SLAの目標はすべて達成しているのに、利用部門の満足度が低い。最初にすべきことはどれか。
- A. SLAの目標をさらに厳しくする
- B. 利用部門と話し、彼らが得たい成果と、それを測る指標を見直す
- C. 満足度調査をやめる
- D. 達成の報告を増やす
答えと解説を見る
正解：B。ウォーターメロン効果です。指標が顧客の成果を表していないのが原因なので、顧客と対話して指標を作り直します。（→Service level management）
Q7. 資産と構成
「このライセンスは来年いくら払うか、余っていないか」を管理するのはどれか。
- A. Service configuration management
- B. IT asset management
- C. Service catalogue management
- D. Knowledge management
答えと解説を見る
正解：B。お金の価値と一生（購入、再利用、廃棄、契約の遵守）を見るのがIT資産管理です。サービスを作る部品とそのつながりを見るのが構成管理です。（→IT asset management）
Q8. 継続的改善
改善のアイデアを記録し、優先順位を付けて管理するために使うものはどれか。
- A. Change schedule
- B. Continual improvement register
- C. Service catalogue
- D. Known error database
答えと解説を見る
正解：B。CIRです。改善は全員の責任で、CIRは組織に1つとは限りません。（→Continual improvement）