ITILを理解するための解説

01ITILは何を解こうとしているのか

一言でいうと、ITILは「IT部門が頑張っているのに、事業からは役に立っていないと言われる」というズレを埋めるための枠組みです。この問題意識を頭に置いておくと、以降の用語が全部その答え方として読めます。

よくあるズレ

• サーバーの稼働率は99.9%なのに、営業は「月末に限って精算システムが遅くて仕事にならない」と怒っている
• 問い合わせは全件「対応済み」で閉じているのに、同じ障害が毎月起きる
• 新しいツールを導入したのに、誰も使わず元のエクセルに戻った

どれも、IT側が「自分の作ったもの」を基準に評価し、使う側が「自分が得た結果」を基準に評価しているのが原因です。ITILの第2章が output と outcome をしつこく区別するのは、このためです。

バージョンごとの「答え方」の変化

ITIL 4を読むときの前提

• ITIL 4は「こうやれ」という手順書ではなく、「こう考えれば、自分の組織に合うやり方を作れる」という考え方の枠組みです。だから本文には「例は規範ではない」「組織に合わせて調整する」という断りが何度も出てきます。
• 試験でも、「必ずこの順番で行う」「すべての変更を委員会が承認する」のように硬直的な選択肢は、たいてい誤りです。柔軟性、価値、協働を重んじる選択肢が正解になりやすい、という地図を持っておきましょう。

02価値の考え方：なぜ価値は「渡せない」のか

ITILで一番大事なのは、価値を「モノ」ではなく「受け取った人の実感」として扱うことです。ここを外すと、以降の談りがすべて空回りします。

2.1 価値は「実感」だから、提供者だけでは作れない

• 価値は「知覚された（perceived）」便益です。同じものでも、受け取る人と状況で価値は変わります。
• 例：オンライン英会話の「レッスン無制限プラン」。毎日受けられる学生には大きな価値ですが、週に1回しか時間が取れない会社員には割高なだけです。提供者が同じものを用意しても、価値は利用者の事情で決まります。
• さらに、利用者が実際にレッスンを予約して受けなければ、価値は生まれません。これが value co-creation（価値の共創） の意味です。提供者は価値を「届ける」のではなく、消費者が価値を得られるように「手助けする」役割です。
• だからITILは、提供者だけで要件を決めず、消費者を要件定義や設計に巻き込むことを勧めます。

2.2 outputとoutcome：「作ったもの」と「得られた結果」

• outputは「1つ以上の」outcomeを可能にする手段にすぎません。outputが完璧でも、outcomeが生まれなければ価値はありません。
• 試験での見分け方：選択肢が「引き渡されたもの」を指していればoutput、「相手の状態の変化」を指していればoutcomeです。

2.3 サービスの本質は「コストとリスクの引き受け」

• サービスの定義には「顧客が特定のコストとリスクを管理しなくて済むように」という一節があります。ここがサービスと「ただの購入」の違いです。
• 例：社内のファイルサーバーをクラウドストレージに変えると、機器の購入費や故障時の交換というコストとリスクは提供者が引き受けます（removed＝取り除かれる）。代わりに、月額料金や移行の手間、提供者の障害やサービス終了という新しいコストとリスクを負います（imposed＝課される）。
• 価値があるのは、「得られる成果＋取り除かれるもの」が「課されるもの」を上回ったときだけです。外部委託の判断は、まさにこの天秤です。
• リスクは提供者が全部引き受けるわけではありません。消費者も、要件をはっきり伝える、成功の条件（CSF）と制約を共有する、必要な自社の資源に触れられるようにする、という形でリスク低減に参加します。ここでも「共創」の考え方が通っています。

2.4 utilityとwarranty：「何ができるか」と「ちゃんとできるか」

• utility＝そのサービスは何をしてくれるのか（fit for purpose）。消費者の成果を後押しするか、制約を取り除くか。
• warranty＝それを、必要なときに、必要な量だけ、安全に、止まらずにやってくれるか（fit for use）。可用性・容量・セキュリティ・継続性。
• 例：社内のAIチャットボット。社内規程を正確に答えられるのはutility。午前9時に全社員が一斉に使っても止まらず、個人情報を外に出さないのはwarranty。どちらかが欠ければ、社員は使わなくなります。
• 試験での見分け方：「機能、用途、できること」ならutility、「稼働、性能、安全、復旧」ならwarrantyです。

03関係者と関係：「誰か」ではなく「どの役割か」で考える

ITILの用語は、人や組織に貼るラベルではなく、その場面で担っている役割の名前です。これを知っているだけで、関係者の問題のほとんどが解けます。

3.1 同じ組織が、提供者にも消費者にもなる

• 社内情シスを例にすると、社員に対しては提供者です。しかしSaaSベンダーに対しては消費者です。そのSaaSベンダーも、クラウド事業者の消費者です。
• この連鎖が service relationship model（サービス関係モデル）です。受け取ったサービスは自分の「資源」になり、それを組み合わせて次の相手に提供します。
• だから、自分のサービスの品質は、上流のサプライヤーの品質に左右されます。サプライヤー管理や「パートナーとサプライヤー」の側面が重視されるのはこのためです。

3.2 customer・user・sponsorの見分け方

3つの役割は、「何を決める人か」で分けると覚えやすくなります。

• 役割は兼務できます。個人で携帯契約する人は、3つを一人で担います。
• 役割ごとに価値の感じ方が違います。スポンサーは費用対効果、顧客は業務課題の解決、利用者は使いやすさを気にします。ここが衝突するので、役割を特定しておく必要があります。
• 試験の引っ掛け：「要件を決める」が出てきたらcustomer。「予算を承認する」ならsponsor。「契約を交渉する」もcustomer側の仕事です。

3.3 オファリングの3要素は「所有権」で見分ける

• 貸与PCは迷いやすい例です。会社の資産のままなら「資源へのアクセス」、社員に譲渡するなら「物品」です。問題文で所有権が移るかどうかを確かめましょう。
• 1つの製品から複数のオファリングを作れます（無料プランと有料プランなど）。製品＝資源の組み合わせ、オファリング＝それを相手向けに切り出して見せたもの、という関係です。

3.4 「提供」「消費」「関係管理」は誰の活動か

• Service provision：提供者がやること。資源の管理、利用者へのアクセスの確保、約束した作業の実施。
• Service consumption：消費者がやること。使うために自分の資源（PCや人員など）を用意し、実際に使い、依頼する。
• Service relationship management：両者が一緒にやること。価値が生まれ続けているかを確かめ、調整する。
• 「消費者にもやることがある」という点が共創の具体的な中身です。社員が新しいツールの使い方を学ばなければ、ツールがどれだけ良くても価値は生まれません。

044つの側面：「見落としを防ぐチェックリスト」として読む

4つの側面は、何かを始めるときに「この4つを全部考えたか？」と自問するためのチェックリストです。プロジェクトが失敗するときは、たいていどれか1つが抜けています。

4.1 なぜこの4つなのか

何かを届けるには、「誰が（人）」「何を使って（情報と技術）」「誰の力を借りて（外部組織）」「どういう流れで（仕事の進め方）」の4つが必ず要ります。この4つがそのまま4つの側面です。

• 4つは「バランス」が大事です。1つを極めても、他の弱さは埋められません。最新のツールを入れても、使う人の役割と文化が変わらなければ効果は出ません。
• 4つの側面は「個々のサービス」にも「SVS全体」にも当てはまります。小さな改善でも、組織全体の仕組みづくりでも使えるチェックリストです。

4.2 外側にあるPESTLE

• 4つの側面は組織が自分で動かせるもの、PESTLEは自分では動かせない外部の力です。
• 外部の変化は、たいてい複数の側面に同時に波及します。例：個人情報の規制が強まる（Legal）と、データの持ち方（情報と技術）、委託先との契約（パートナーとサプライヤー）、社員の研修（組織と人材）、申請の流れ（プロセス）をすべて見直すことになります。

4.3 問題文から側面を当てるコツ

• 「プロセス」と「バリューストリーム」の違い：プロセスは「入力を出力に変える活動のまとまり」で、部分を表します。バリューストリームは「需要から価値までの一連の流れ」で、端から端を表します。バリューストリームを描くと、プロセスのつなぎ目のムダ（待ち、手戻り、二重入力）が見えます。

05SVSとバリューチェーン：組織を「部署の集まり」ではなく「価値を生む装置」として見る

5.1 なぜ「システム」と呼ぶのか

• 組織図は「誰がどこに属するか」を示しますが、「需要がどう価値に変わるか」は示しません。SVSは後者を描くための図です。
• 左から Opportunity（機会）とDemand（需要） が入り、中の仕組みを通って、右から Value（価値） が出ていく。この流れを妨げる最大の要因が、部署ごとに閉じた縦割り（silo）です。
• 縦割りは部署だけでなく、プラクティスの間にも生まれます。例：障害対応チームと変更管理チームが情報を共有しないと、「この障害は昨日の変更が原因」と気づくまでに何時間もかかります。

5.2 機会と需要の違い

• どちらも、入ってきたものを全部引き受けるわけではありません。優先順位を付け、資源をどこに使うかを決めるのもSVSの仕事です。

5.3 5つの構成要素の「役割分担」

SVSの5要素を、会社を動かすときの役割にたとえると位置づけがつかめます。

5.4 バリューチェーンの6活動は「部品」であって「工程順」ではない

• 6活動（Plan / Improve / Engage / Design and transition / Obtain/build / Deliver and support）は、上から順に進む工程ではありません。場面に応じて必要な部品を選んでつなぐものです。このつなぎ方が value stream（バリューストリーム） です。
• 例：社員から「プリンターが印刷できない」と連絡が来たときの流れ。 1. Engage：問い合わせを受け付け、状況を聞き取る 2. Deliver and support：原因を調べ、ドライバーを入れ直して復旧させる 3. Engage：社員に直ったことを確認して閉じる 4. Improve：同じ問い合わせが多ければ、手順書を公開して自己解決できるようにする
• PlanもDesign and transitionも登場しません。新しいサービスを作るバリューストリームなら、逆にPlan→Design and transition→Obtain/buildが中心になります。

5.5 「共通ルール」はなぜそうなっているのか

• 試験では「この活動はどれか」を問う問題が多く出ます。外部との接点ならEngage、作る・買うならObtain/build、品質・コスト・投入時期の期待を満たす設計と移行ならDesign and transition、というように、動詞で判別しましょう。

067つの原則：それぞれ「よくある失敗」への解毒剤

原則は、組織が繰り返してきた失敗を裏返したものだと読むと腹落ちします。「この原則がなければ何が起きるか」を一緒に覚えると、場面問題で選べるようになります。

6.1 原則ごとの「誤解しやすい点」

• Focus on value：価値を考えるのは新規プロジェクトの担当者だけではありません。日々の運用をする人も、自分の仕事が誰の価値につながっているかを知っているべきです。また、価値には理屈だけでなく感情（顧客体験）も含まれます。
• Start where you are：「現状を全部認める」という意味ではありません。使えるものは使い、使えないものは変える。一から作り直すべき場合もあるが、それはまれ。また、現状は報告書より自分の目で確かめるべきです。数字だけを見ると、測り方そのものが人の行動を変えていることに気づけません。
• Progress iteratively with feedback：「小さく速く」は「雑でよい」という意味ではありません。1回分の成果物には、使えるための要素がすべて入っている必要があります（MVPの考え方）。逆に、全体を完璧に理解してから動こうとすると、分析だけで終わります。
• Collaborate and promote visibility：協働は「全員の賛成を得ること」ではありません。必要な人を、必要な役割で巻き込むことです。仕事の量、滞っている箇所、余力を見えるようにすると、「なぜこれを優先するのか」を説明しなくても伝わります。
• Think and work holistically：組織は複雑なので、単純な状況向けのルールを当てはめるとかえって害になります。全体を見るには、関係者が適時に話せる仕組みと、端から端まで見える仕組み（自動化もその一つ）が必要です。
• Keep it simple and practical：「簡単にする」は「手を抜く」ではありません。価値を生むものだけを残し、例外は個別に扱うルールを作ることです。簡単な手順ほど定着し、早く成果（quick win）が出ます。
• Optimize and automate：順番が大事です。まず簡素化と最適化、その後に自動化。成果は自動化の前後で同じ指標を使って測ります。人の判断は、本当に価値を生む場面に取っておきます。

6.2 原則同士は「引っ張り合い」、「支え合う」

• 支え合う例：「反復して進める」なら、各回に必要な要素をそろえるために「全体的に考える」必要がある。「価値に着目」すると、何を捨てるかが決まり「シンプルにする」ことができる。
• 引っ張り合う例：「全体的に考える」と検討範囲が広がり、「シンプルにする」と衝突します。シンプルにした手順が最適とは限らず、「最適化」と両方を見る必要があります。
• だからITILは「1、2個の原則だけ使うのではなく、毎回全部を見直して、その場面での重みを判断する」よう勧めています。

6.3 場面問題での選び方

問題文の「悪いところ」を探し、それを直す原則を選びます。

07ガバナンスと継続的改善：「誰が方向を決め、どう良くし続けるか」

7.1 ガバナンスとマネジメントは別物

• ガバナンス（統治）：「正しいことをやっているか」を見る。取締役会などの統治機関が担う。
• マネジメント（管理）：「やると決まったことを、正しくやっているか」を見る。各部門の責任者が担う。
• ガバナンスは3つの動詞で覚えます。 1. Evaluate（評価）：今の戦略や事業の組み合わせは妥当かを確かめる 2. Direct（指示）：方針と戦略を決め、誰が責任を持つかを割り当てる 3. Monitor（監視）：指示どおりに結果が出ているかを見る
• この3つは一度きりではなく、状況が変わるたびに繰り返す循環です。一部の部門に権限を委譲してもよいが、全体の監督だけは統治機関が手放さない、というのがポイントです。
• 試験の引っ掛け：「日々の運用の細かい判断」はガバナンスの仕事ではありません。ガバナンスは方向づけと監督です。

7.2 継続的改善モデルは「旅の計画」として読む

7つのステップは、旅行の計画と同じ順番です。そう考えると、なぜこの順番なのかが自然に分かります。

• ステップ6は「進捗」と「価値」の2つを確かめます。目標は達成したか（進捗）、その目標は今も意味があるか（価値）。ここを分けて考えるのが大事です。
• モデルは一方通行ではありません。必要なら前のステップに戻れますし、Agileでも従来型でも使えます。
• 「改善」は3か所に登場するので混同しないようにしましょう。
• SVSの構成要素としての継続的改善：組織全体の改善の仕組み
• バリューチェーンの活動としてのImprove：日々の仕事の流れに組み込まれた改善
• プラクティスとしての継続的改善：改善を進めるための能力と道具（CIRで管理、全員の責任）

08プラクティスを物語でつなぐ

プラクティスは34個ありますが、バラバラに覚えるとすぐ混ざります。そこで、ある会社で起きた架空の出来事を追いかけながら、試験に出るプラクティスがどうつながるかを見ていきます。

8.1 出来事：経費精算システムが月末に止まる

1. Monitoring and event management：月末の午前、監視ツールが「データベースの応答が遅い」という警告（warning）を出す。まだ利用者に影響はない。やがて応答が限界を超え、例外（exception）に変わる。
2. Service desk：同時に、社員から「申請画面が開かない」という連絡が続々と届く。サービスデスクは、すべての利用者にとっての入口です。
3. Incident management：これは「計画外の中断」なのでインシデントです。目的は「原因を究明すること」ではなく、一刻も早く元に戻すこと。影響が大きいので主要インシデントとして扱い、アプリ、DB、インフラの担当が集まって一緒に調べる（swarming）。
4. ワークアラウンド：サーバーを再起動すると復旧した。しかしなぜ遅くなったかは分かっていない。インシデントはここで終了。
5. Problem management：過去の記録を見ると、同じ障害が3か月続けて月末に起きていた（problem identification）。分析すると、月末の集計処理が大量のデータを一度に読み込んでいた（problem control）。すぐには直せないので、「既知のエラー」として記録し、「月末は再起動で復旧」というワークアラウンドを共有する。
6. Change control：恒久対策として集計処理を分割することにした（error control）。これは本番環境に手を入れるので「変更」です。初めての作業でリスクもあるので「通常の変更」として評価し、月末を避けた日程を変更スケジュールに入れる。
7. Deployment management：修正したプログラムを本番環境に置く。まず一部のサーバーだけに入れて様子を見る（phased deployment）。
8. Release management：全社員が新しい仕組みを使える状態にする。展開（置くこと）とリリース（使えるようにすること）は別のタイミングにできる。
9. Service configuration management：どのサーバーに何が入っていて、どのサービスがどのDBに依存しているか。この情報（CIとその関係）があったから、最初の調査も影響範囲の評価も速くできた。
10. Service level management：SLAでは「月の稼働率99.5%」と定めていて、数字は達成していた。しかし経理部は「月末に止まるなら意味がない」と満足していない。これが watermelon SLA（外が緑で中が赤）です。経理部と話し合い、「月末3営業日の稼働」を別の目標として加える。
11. Continual improvement：最後に振り返り、「月末の負荷を事前に予測する」という改善案をCIRに登録する。

8.2 混同しやすいペアの見分け方

8.3 変更の3種類は「リスクと急ぎ具合」で決まる

• 毎回同じ手順でリスクが低い（例：社員のメールボックス容量を決まった範囲で増やす）→ Standard change。手順を作ったときに一度だけ評価して、あとは事前承認。
• その都度評価が要る（例：集計処理の分割）→ Normal change。リスクが低ければ現場の責任者、高ければ経営層と、許可者を変える。
• 今すぐやらないと危ない（例：攻撃されている脆弱性の緊急パッチ）→ Emergency change。評価と許可は省かないが、書類仕事を後回しにできる。
• 試験の引っ掛け：「緊急の変更は許可不要」「標準変更は一度もリスク評価しない」はどちらも誤りです。

8.4 目的だけ問われるプラクティスは「何を守るか」で覚える

09ITIL 5で何が変わったか：「作る人」と「運ぶ人」の境目をなくす

ガイドブックの説明をもとに、ITIL 4との対応関係で整理します。細かい数値や資格要件は公式情報で確認してください。

9.1 変化の背景

• アプリやSaaSでは、「製品を作ること」と「サービスとして提供すること」が切り離せません。リリースは毎週で、運用しながら作り続けます。
• ITIL 4のSVCは「サービスの運用モデル」として作られ、製品開発の言葉（発見、設計、構築）とはやや距離がありました。ITIL 5は、開発と運用が同じ言葉で話せるようにした、と読めます。
• もう1つの背景はAIです。AIが障害の切り分けや問い合わせ対応をし始めると、「誰が判断に責任を持つのか」を決めないと統制できません。

9.2 SVCの6活動とPSLMの8活動の対応（このノートの対応付け）

ガイドブックには対応表はありません。下は理解のためにこのノートで作った対応づけで、公式の対応ではありません。

• 前半（Discover〜Build）は製品の言葉、後半（Deliver・Support）はサービスの言葉、TransitionとOperateがその橋渡しです。この構造さえつかめば、8つの名前は自然に並びます。
• SVCと同じく、PSLMも「工程順」ではなく「部品」です。場面に応じて組み合わせ、バリューストリームを作ります。

9.3 変わらないもの：土台はITIL 4のまま

• 価値と共創、outputとoutcome、utilityとwarranty、customer・user・sponsor、オファリングの3要素
• 4つの側面とPESTLE、SVSの5要素、EDM、従うべき7原則、34プラクティス
• つまり、このページの1〜8節はそのままITIL 5の土台になります。

9.4 新しく加わった考え方の「なぜ」

• クラスターは、このページの8.1の物語と重ねると覚えやすくなります。監視・デスク・インシデント・問題・要求がMSF、変更・展開・リリース・構成・資産がPIC、SLM・関係・サプライヤー・改善・セキュリティがCAIです。ちょうどFoundation試験で問われる15個と重なっています。

10理解度チェック：場面問題

このノート用に作った問題です。答えを選んだら、解説で「なぜ他の選択肢ではないのか」まで確かめてください。証拠になる節番号も付けています。