ITIL Foundation（Version 5）解説ガイド

ITIL 5 をひとことで言うと

ITIL 5 は、「デジタルのプロダクトとサービスを、一体のものとして管理し、利用者といっしょに価値をつくるための共通言語」です。

ITIL 4 までは「IT サービスをどう管理するか」が中心でした。ITIL 5 では、アプリやシステムといったプロダクトと、それを使えるようにするサービスを、同じ1つの解決策の表と裏として扱います。開発する人、運用する人、事業の人が、同じ言葉で話せるようにするのがねらいです。

22章は、5つの問いに答える構成になっている

いちばん大事なつながり

ITIL 5 の多くの概念は、同じ「8つの活動」を別の角度から見たものです。ここを押さえると、全体が一気につながります。

8つの活動は、発見（discover）・設計（design）・取得（acquire）・構築（build）・移行（transition）・運用（operate）・提供（deliver）・サポート（support）です。この順番は、最初に丸ごと覚えてしまいましょう。

ITIL の歴史の中での位置

ITIL 5 は、ITIL 4 を捨てた「作り直し」ではなく、ITIL 4 の発展形です。価値の共創、従うべき原則、4つの側面、継続的改善といった ITIL 4 の考え方は、ほぼそのまま引き継がれています。

第1章　プロダクトとサービスの管理Product and Service Management

1. デジタル・プロダクトとサービスの管理とは

ITIL 5 では、管理の対象を「サービス」だけから「プロダクトとサービス」に広げました。これをデジタル・プロダクトとサービスの管理（digital product and service management）と呼びます。デジタルのプロダクトとサービスを通じて価値を生み出すための、組織の専門的な能力のまとまりのことです。

以前の ITIL でいう「サービスマネジメント」が発展したもの、と考えてかまいません。違いは、プロダクトとサービスを別々の部署で別々に管理するのではなく、1つの解決策の両面として一緒に管理する点です。

2. プロダクト・サービス・グッズ

プロダクトとサービスの関係は、こう考えるとわかりやすくなります。組織の資源を組み合わせてプロダクトをつくり、その一部を利用者に届ける形がサービスです。

デジタル・プロダクト（digital product）とデジタル・サービス（digital service）は、デジタル技術で実現・提供されるプロダクトとサービスです。「デジタル」は新しい種類を増やすのではなく、届け方（経路）を表しているだけです。定義の中身は変わりません。

3. サービスの4つの価値特性

サービスの良さは、1つの物差しでは測れません。ITIL 5 は次の4つの特性で考えます。

有用性と保証は ITIL 4 からある考え方です。ITIL 5 では、ここにユーザー体験と持続可能性が加わって4つになりました。

4. 一生を通して見る：ライフサイクルと継続的改善

デジタル・プロダクトとサービスの管理には、もう2つ大事な考え方があります。ITIL プロダクトとサービスのライフサイクル（生まれてから廃止まで一生を見る）と、継続的改善（continual improvement：変わる要求に合わせて良くし続ける）です。どちらもあとの章で詳しく学びます。

5. ITIL がだれの役に立つか

第2章　体験・戦略・変革Experience, Strategy and Transformation

3つのグループは、それぞれ別の問いに答えます。

1. 体験（Experience）のグループ

体験（experience）とは、人が組織とのやりとりについてどう考え、どう感じるかです。そのうち、デジタルの経路を通したものがデジタル体験（digital experience）です。

体験には、範囲の違う2つがあります。

• ユーザー体験（user experience, UX）：1つのプロダクトやサービスを使ったときの体験。
• カスタマー体験（customer experience, CX）：顧客が組織との関係全体を通じて持つ、すべてのやりとりの体験。

体験を良くするための考え方として、次の3つがあります。

• 信頼（trust）：相手が確実で誠実だと信じられること。AI の判断やデータの扱いが見えることも、信頼につながる。
• 人間中心設計（human-centred design）：人のニーズを設計の真ん中に置くこと。
• 体験レベル合意（experience level agreement, XLA）：技術的な数値（稼働率など）だけでなく、利用者の体験そのものを目標にする合意。

2. 戦略（Strategy）のグループ

戦略（strategy）は方向を決めるものです。範囲によって呼び名が変わります。

• 事業戦略（business strategy）：事業全体の方向。
• デジタル戦略（digital strategy）：デジタル技術を使って事業目標を達成する方向。デジタル中心の組織では、事業戦略とほぼ重なる。

組織の方向を示す3つの言葉は、時間の向きで区別します。

VUCAは、変動（volatility）・不確実（uncertainty）・複雑（complexity）・あいまい（ambiguity）な環境のことです。こういう環境で人を目標へ導くのがリーダーシップ（leadership）です。

3. 変革（Transformation）のグループ

第3章　サービス・オファリングService Offerings

サービス・オファリング（service offering）は、ある利用者グループに向けて、提供するサービスを正式に説明したものです。メニュー表のようなものと考えるとよいでしょう。中身は次の3つの組み合わせでできていて、組み合わせ方は利用者グループごとに変えられます。

サービス・インタラクション（service interactions）は、提供者と利用者が価値を共創するために関わり合うやり方全般を指します。デジタル・サービスでは、利用者が提供者の資源に自分でアクセスする形が中心になります。

第4章　価値の共創Value Co-creation

1. 価値とはなにか、だれが決めるのか

価値（value）は、あるものから感じられる便益・有用さ・大切さです。キーワードは「感じられる（perceived）」です。価値があるかどうかを判断するのは、提供者ではなく受け取る側です。

そして ITIL では、価値は共創される（co-created）と考えます。提供者がサービスを用意し、利用者がそれを使いこなす。この協力があって初めて価値が生まれます。どんなに優れたアプリでも、利用者が使い方を知らなければ価値は生まれません。

2. 成果を、コストとリスクと比べる

価値は、得られる良いこと（成果）と、そのために負うもの（コストとリスク）をまとめて比べて判断します。良いことが上回れば、価値があると感じられます。

3. アウトプットとアウトカム

ここは試験で特に大事な区別です。

• アウトプット（output）：活動が生み出す成果物。形があってもなくてもよい。例：月次レポート、用意したサーバー。
• アウトカム（outcome）：関係者が望む結果。1つ以上のアウトプットによって可能になる。例：よりよい意思決定、受注処理の高速化。

アウトプットは「サービスが生み出すもの」、アウトカムは「それによって可能になる結果」です。アウトプットを渡しても、アウトカムが達成されたとは限りません。レポートを送っても、だれも読まなければ意思決定は良くなりません。

4. 価値を左右するものと、フィードバック

利用者が感じる価値には、第1章の4つの特性（有用性・保証・ユーザー体験・持続可能性）がそれぞれ寄与します。そしてフィードバック（feedback）が、何をどう良くすべきかを示し、価値の共創を前に進めます。ITIL 5 では、フィードバックは最後のアンケートだけでなく、日々集まるデータとして扱う考え方が強まっています。

第5章　サービス関係Service Relationships

1. 関係の当事者

• 組織（organization）：独自の機能・権限・関係をもつ人や集団。1人の個人でも、大企業でもよい。
• サービス提供者（service provider）：サービスを提供する側。
• サービス利用者（service consumer）：サービスを受け取って使う側。
• デジタル・プロダクトのベンダー（digital product vendor）：継続的なサービス関係を運営するのではなく、デジタル・プロダクトを供給する側。

これらをまとめる大きな枠がサービス関係（service relationship）です。提供者と利用者が価値を共創するための協力関係のことです。

2. 利用者側の3つの役割

1人が複数の役割を兼ねることもあります。個人で電子書籍を買う人は、スポンサー（お金を出す）・顧客（何が欲しいか決める）・ユーザー（読む）を1人で兼ねています。

3. 関係の深さ：3つのタイプ

4. サービス・ジャーニー

サービス・ジャーニー（service journey）は、利用者がすべての接点を通して経験する、最初から最後までの道のりです。サービスを知る、選ぶ、契約する、使う、困って相談する、やめる、までの全体を指します。

5. 関係を測る：品質・レベル・SLA

第6章　4つの側面（入門）Introduction to the Four Dimensions

プロダクトとサービス管理の4つの側面（four dimensions of product and service management）は、プロダクトやサービスを4つの角度から見るための枠組みです。どれか1つが優れていても、ほかが弱ければ全体はうまくいきません。4つは全体的に（holistically）まとめて考えます。

4つは、「だれが」の2つと、「何を・どうやって」の2つに分けると覚えやすくなります。

補足です。

• 組織と人材では、ふさわしい文化と、十分な人数（キャパシティ）と能力が必要とされます。
• 情報と技術では、技術を選ぶときにセキュリティ・法令順守・目的への適合性を考えます。
• パートナーとサプライヤーでは、供給者戦略（どこまで自社でやり、どこから外部に任せるか）とサービス統合が扱われます。

第7章　内部要因と外部要因Internal and External Factors

1. 管理できるもの・できないもの

• 内部要因（internal factors）：組織が自分で形づくり、管理できるもの。体制・文化・資源・プロセスなど。4つの側面は、この内部要因を表しています。
• 外部要因（external factors）：組織の外から来て、ほぼコントロールできないもの。法律、景気、社会の流れなど。組織は、これに対応するしかありません。

外部要因は、4つの側面すべてに影響します。たとえば新しい個人情報保護の法律ができると、社員の教育（組織と人材）、委託先との契約（パートナーとサプライヤー）、データの持ち方（情報と技術）、手続きの流れ（バリューストリームとプロセス）のすべてを見直すことになります。

2. PESTLE：外部要因の6つの分類

3. 分類で迷わないコツ

「その要因は、何によって生まれたのか」を考えます。お金の動きなら経済、法律の文言なら法的、政府の姿勢なら政治的、地球環境なら環境的です。「社会」と「技術」は、自社の中の話か、世の中全体の流れかで、内部と外部を分けます。

第8章　ライフサイクル（入門）Introduction to the Product and Service Lifecycle

1. 1つの、端から端までのライフサイクル

ITIL プロダクトとサービスのライフサイクル（ITIL Product and Service Lifecycle）は、すべてのプロダクトとサービスに、一連の活動がどう当てはまるかを示す、端から端までのモデルです。機会を見つけたときから、廃止するときまでの一生全体を扱います。

ITIL 5 では、デジタル・プロダクトとサービスを「同じ技術的な解決策の2つの見方」として扱います。だから、両者は同じ1つのライフサイクルを共有し、いっしょに管理されます。このように全体を1つのつながりとして管理する考え方を、エコシステム・アプローチ（ecosystem approach）と呼びます。

2. 8つの活動

この8つは、ITIL v3 の5段階（サービスストラテジ、サービスデザイン、サービストランジション、サービスオペレーション、継続的サービス改善）を、より全体的な形に組み替えたものです。そして第13章のバリューチェーンの8活動とまったく同じです。

3. 順番どおりではない

矢印で並べましたが、これは覚えるための順番です。実際には：

• 順番どおりでも一直線でもない（not sequential nor linear）。必要な活動から使う。
• くり返し使える（iterative）。同じ活動に何度も戻ってよい。
• 同じプロダクトの別のバージョンが、同時に別の活動にいることがある。
• チームは、いくつもの活動に同時にまたがって協力できる。

これは、昔ながらの「計画→構築→運用」（plan-build-run）を順番に受け渡していくやり方に代わるものです。

4. なぜこのモデルが役立つのか

どのプロダクトやサービスにも同じモデルを当てはめるので、品質・リスク・法令順守を、一生を通して一貫したやり方で管理できます。

5. 混同しやすい4つの概念

第9章　8つの活動の目的と範囲Purpose and Scope of the Lifecycle Activities

8つの活動は、3つの役割に分けると覚えやすくなります。

まぎらわしいペアを整理する

• 発見と設計：発見は「何が必要か」を見極める。設計は「どう実現するか」を形にする。何かを手に入れたり作ったりする前の段階。
• 取得と構築：取得は資源を「持ってくる」。構築は持ってきたものを「組み立てて試す」。
• 移行：作ることと動かすことの橋渡し。リリースして展開し、本番で使える状態か確かめるまで。
• 運用と提供：ITIL 5 は、以前の「サービスオペレーション」を2つに分けました。運用は「システムを動かし続ける」（裏方）。提供は「利用者が価値を受け取れるようにする」（表側）。
• サポート：すでに本番にあるものに対応する。作らないし、展開もしない。運用・提供といっしょに本番の価値を保つ。サポートで集まった声が、発見や設計に戻るきっかけにもなる。

第10章　バリュー・システムの構成要素Components of the ITIL Value System

ITIL バリュー・システム（ITIL Value System, ITIL VS）は、機会と需要（opportunity and demand）を受け取り、価値に変えるための、組織全体のしくみです。5つの構成要素が、互いに連携しながら働きます。

なぜ「システム」なのか

5つは別々の部品ではなく、互いに支え合います。原則が判断の方向を示し、ガバナンスが方向づけと統制を行い、バリューチェーンが実際に価値を生み、プラクティスがそのための資源を与え、継続的改善が全体を良くし続けます。どれか1つだけを動かしても、価値は安定して生まれません。バリュー・システムは、縦割り（サイロ）にならないよう柔軟に設計されていて、組織全体に当てはまります。

第11章　従うべき原則The ITIL Guiding Principles

従うべき原則（guiding principle）は、どんな状況、どんな取り組みにも当てはまる推奨です。ルールや手順ではなく、迷ったときの方位磁針のようなものです。7つあり、1つずつではなく組み合わせて使います。原則どうしは互いに支え合います。

7つの原則

1. 価値に着目する（Focus on value）
組織がすることはすべて、直接か間接的に、関係者の価値につながっているべきです。価値は、提供側の都合ではなく、利用者の視点で定義します。
誤解：提供にかかるコストの大きさで価値を判断する。

2. 現状からはじめる（Start where you are）
ゼロから作り直す前に、今あるものを評価し、使えるものは再利用します。現状は、報告書などの又聞きではなく、現場を直接見て測ります（Guidebook では、仕事が行われる現場を見に行く「ゲンバ（Gemba）」という言葉で説明しています）。
誤解：「何も変えない」こと、または「全部捨てて作り直す」こと。

3. フィードバックをもとに反復して進化する（Progress iteratively with feedback）
大きな仕事を、小さく扱いやすい単位に分けて進めます。各単位の前・途中・後でフィードバックを求め、方向を修正します。
誤解：最後に一度にまとめて出し、そこで初めて意見を聞く。

4. 協働し、可視性を高める（Collaborate and promote visibility）
適切な人を巻き込み、部署の壁を越えて協力します。仕事の進み具合や影響を見えるようにします（例：カンバンボード）。
誤解：関わる人は多いほどよい。（大事なのは「適切な人」）

5. 全体的に考えて取り組む（Think and work holistically）
サービス、プラクティス、供給者などを、1つのシステムとして扱います。単独で成り立つ部分はありません。
誤解：一部だけを最適化して、全体の価値を損なう。

6. シンプルにし、実践的にする（Keep it simple and practical）
成果を出すのに必要な最小の手順にします。価値を生まない手順・作業・指標は取り除きます。
誤解：「シンプル」を「簡単」と同じだと思う。（シンプルにするのは、むしろ難しいことが多い）

7. 最適化し、自動化する（Optimize and automate）
人と技術をいちばんよく活かします。まず最適化し、そのあと価値がある所を自動化します。人の判断が本当に必要な所に、人の力を使います。
誤解：ムダの多い手順を、そのまま自動化する。（ムダが速く大きくなるだけ）

第12章　ガバナンスGovernance

ガバナンス（governance）は、組織を方向づけ、統制する手段です。責任を負うのは統治機関（governing body）、たとえば取締役会です。ガバナンスは日々の管理より上の層で働き、バリュー・システム全体を方向づけ、支えます。

ガバナンスとマネジメントの違い

ガバナンスは「何を目指し、どんなルールで動くか」を決めて確かめます。マネジメントは、その方向にそって実際に仕事を計画し、実行します。手を動かす仕事はマネジメントの役割です。

3つの活動：評価・指示・モニタリング

評価して、指示して、モニタリングし、その結果をまた評価に戻す、という流れで回ります（頭文字をとって EDM と呼ぶこともあります）。

第13章　バリューチェーンValue Chain

1. バリューチェーンとは

バリューチェーン（value chain）は、価値をつくって届けるための、互いにつながった活動からなる運営モデル（operating model）です。運営モデルとは、組織がどう価値を共創し、どう自分を動かしているかを表したものです。

Version 5 のバリューチェーンは、ライフサイクルと同じ8つの活動を持ちます。活動は順番どおりではなく、場面ごとに組み合わせて使います（その組み合わせがバリューストリーム）。活動とプラクティスは、組織のパーパス（関係者のために何をするのか、なぜか）と運営モデルを支えます。

2. 8つの活動と、成功の測り方

各活動には、その目的から導かれた主要な成功指標があります。

3. 運用の言葉：インシデントから既知のエラーまで

流れで覚えます。イベントが起き、サービスが止まればインシデント。インシデントの根っこにあるのが問題。分析して原因（エラー）がわかった問題が既知のエラーです。

4. 構築とリリースの言葉

第14章　管理プラクティスManagement Practices

1. 管理プラクティスとは

管理プラクティス（management practice）は、仕事を行う、または目的を果たすための、組織の資源のまとまりです。資源には、人、プロセス、ツール、情報、パートナーなどが含まれます。

プラクティスは「手順書」ではありません。たとえば「インシデント管理」というプラクティスには、担当する人、対応の流れ、使う道具、蓄えた知識、協力する外部の会社までが含まれます。

プラクティスとほかの概念の関係はこうです。

• プラクティスは、バリューチェーンの活動に資源を与えて、活動を可能にする。
• プラクティスは、バリューストリームの中で必要に応じて使われる。

2. 2つのグループ

Foundation 試験では、個々のプラクティスの細かい中身は問われないとされています。2つのグループの違いを押さえれば十分です。

3. ITIL プラクティス・ガイド

ITIL プラクティス・ガイド（ITIL Practice Guide）は、1つのプラクティスについての、一貫した詳しい手引きです。すべてのガイドが同じ形式で書かれていて、目的と主要な用語、そして4つの側面にそって構成されています。

4. メトリクスと重要成功要因

• メトリクス（指標）（metric）：管理や改善のために、見張ったり報告したりする測定値・計算値。
• 重要成功要因（critical success factor, CSF）：めざす結果を得るために欠かせない前提条件。

第15章　継続的改善モデルThe ITIL Continual Improvement Model

継続的改善モデル（continual improvement model）は、改善の取り組みを進めるための、くり返し使える7つのステップです。7まで終わったら、また1に戻ります。

「継続的改善」には3つの顔がある

• モデル：上の7ステップ。改善の進め方。
• 構成要素：バリュー・システムの5つの構成要素の1つ。組織のすべての層に織り込まれている。
• プラクティス：継続的改善を支える専用の管理プラクティスもある。

そして、継続的改善は全員の責任です。専任の担当者だけの仕事ではありません。

第16章　バリューストリームの主要概念Key Concepts of Value Stream Mapping and Management

1. バリューストリームとは

バリューストリーム（value stream）は、プロダクトやサービスをつくって利用者に届けるために、組織が行う一連の手順です。8つの活動を、特定の場面に合わせた道筋に組み合わせたものです。

2. バリューチェーン・バリューストリーム・プロセス

たとえると、バリューチェーンは「料理ができる台所と調理の工程の全種類」、バリューストリームは「今日のカレーを作る段取り」、プロセスは「玉ねぎを炒める手順」です。

3. コアとイネーブリング

• コア・バリューストリーム（core value stream）：外部の利用者に、直接プロダクトやサービスを届ける流れ。
• イネーブリング・バリューストリーム（enabling value stream）：社内の受け手に価値を届け、コアの流れを支える流れ。

4. マッピングと管理

• バリューストリーム・マッピング（value stream mapping）：バリューストリームの手順と流れを図にする技法。ある時点の写真。
• バリューストリーム管理（value stream management）：バリューストリームを継続的に統制し、最適化する取り組み。

詳しくは第18章で扱います。

5. 複雑性思考

複雑性思考（complexity thinking）は、仕事が置かれている状況によって、ふさわしいやり方が変わるという考え方です。状況は3つに分けられます。

• 秩序だった（ordered）：原因と結果がはっきりしている。決まった手順で進められる。
• 複雑な（complex）：原因と結果があとからしかわからない。試しながら進める。
• 混沌とした（chaotic）：原因と結果のつながりが見えない。まず状況を安定させる。

この考え方は、どこまで標準化し、どこから試行錯誤するかを決める目安になります（第17章）。

第17章　バリューストリームの適用Application of Value Streams

1. 仕事の複雑さに合わせて最適化する

流れの中の手順は、どれも同じやり方で良くすればよいわけではありません。仕事の複雑さに合わせてやり方を変えます。

2. 需要が違えば、流れも違う

バリューストリームは、8つの活動をその場面に合わせた道筋に組み合わせて作ります。

• 同じ活動が、いくつものバリューストリームに出てきてよい。
• 1つのバリューストリームの中に、同じ活動が何度出てきてもよい。
• 需要の種類が違えば、別のバリューストリームにする。

例として、運用系の流れ（インシデントの解決など）と、開発系の流れ（新機能の開発など）が挙げられます。どちらも目指すのは、仕事がよどみなく流れることです。

第18章　マッピングと管理の目的Purpose of Value Stream Mapping and Management

1. 何のために行うのか

バリューストリームのマッピングと管理の目的は、価値の流れを理解し、最適化し、改善し続けることです。具体的には、ムダ、ボトルネック（流れが詰まる所）、遅れ、チーム間の受け渡しを見つけて減らします。見つかった改善の種は、継続的改善の取り組みにつながります。

2. 2つの役割分担

マッピングが「気づき」を与え、管理がそれを「行動」に変えます。

3. バリューストリーム・マップに描くもの

• 手順の順番と、仕事と情報の流れ。
• チーム間の受け渡し（ハンドオフ）と、仕事が待たされている所。
• 価値を生む手順（value-adding）と、生まない手順＝ムダ（non-value-adding, waste）の区別。
• 各手順にかかる時間。これで、全体のリードタイム（lead time：始まりから終わりまでの時間）と待ち時間が見える。

マップは、ふつう今の実際の流れ（理想の手順書ではなく）を描きます。それが改善の出発点になるからです。時間と流れのデータから、ボトルネックと、いちばん効く改善の的がわかります。

第19章　AI 入門Introduction to AI

1. AI とは

人工知能（artificial intelligence, AI）は、ふつうは人の知能が必要な作業をこなす技術です。決まったルールに従うだけでなく、学び、推論できる点で、従来の自動化と違います。

AI 成熟度（AI maturity）は、組織の AI 活用がどれだけ進み、どれだけきちんと統制されているかの度合いです。「使っている量」だけでなく「統制の質」も含む点に注意します。

2. 3つのタイプを区別する

3. AI はどこで役立つか

• ライフサイクル全体で：要件の分析、設計案の生成、テストなど。判断の質と速さを上げる。
• プロセスの自動化で：依頼の仕分け（トリアージ）、担当への振り分け、決まった返答など。ただし、人が決めた範囲の中で動く。
• バリューチェーン全体で：需要の分析、監視、改善など。目的は価値の共創を良くすること。

第20章　ITIL の AI ガバナンスITIL AI Governance

1. AI を「使う」ことと「統制する」ことは違う

AI ガバナンス（AI governance）は、AI を責任をもって、倫理的に、統制のもとで使うための、方針・役割・責任・管理策の枠組みです。AI ツールを導入しただけでは、ガバナンスにはなりません。

AI ガバナンスが扱うこと：

• リスク・法令順守・説明責任。
• 責任ある AI（responsible AI）：透明性、説明責任、倫理的な利用を重んじる。
• 人による監督（human oversight）：完全に任せきりにせず、人が適切に見張り、関わる。
• データの品質とプライバシー：AI ガバナンスの土台。データが悪ければ AI の判断も悪くなる。

第12章のガバナンス（評価・指示・モニタリング）の考え方を、AI に当てはめたものと考えると理解しやすくなります。

2. ITIL AI 能力モデル（6C モデル）

ITIL AI 能力モデル（ITIL AI Capability Model）は、AI の能力を6つに分類し、それぞれに固有のリスクと管理策を対応させる、評価と育成の道具です。頭文字がすべて C なので「6C モデル」と呼ばれます。

手元の資料（01・02 の Guidebook）では、6つの能力は次のように説明されています。

3. AI ガバナンスと 6C モデルの関係

第21章　ITIL と DevOpsITIL and DevOps

1. DevOps とは

DevOps は、開発（Development）と運用（Operations）をつなぎ、価値を途切れなく流すための文化とプラクティスのまとまりです。ツールではありません。中心になるのは、自動化、CI/CD（継続的インテグレーションと継続的デリバリー／デプロイメント）、そして開発と運用が結果への責任を分け合う文化です。

2. 補い合う関係

ITIL が「土台と統制」を、DevOps が「速さと文化」をもたらします。組み合わせることで、速さと統制のバランスがとれます。ITIL の従うべき原則（反復して進化する、協働する、最適化してから自動化する、など）は、DevOps の働き方を後押しします。ITIL のライフサイクルは、DevOps のやり方を受け入れられるように作られています。

第22章　ITIL と PRINCE2ITIL and PRINCE2

1. なぜ ITIL にプロジェクト管理が必要か

プロジェクト（project）は、始まりと終わりが決まった一時的な取り組みです。ITIL は、変革や大きな変更を実現するときに、プロジェクトに頼ります。新しいサービスを作る、大きなシステムを入れ替える、といった仕事です。

2. PRINCE2 とは

PRINCE2（PRojects IN Controlled Environments）は、構造化されたプロジェクトマネジメントの手法です。段階を区切り、役割を決めて進めます。土台にあるのはビジネス正当性の継続（continued business justification）、つまり「このプロジェクトを続ける事業上の理由が、今もあるか」を確かめ続けることです。PRINCE2 が管理するのはプロジェクトであって、続いているサービスではありません。

3. 補い合う関係

流れで言うと、新しいサービスはプロジェクト（PRINCE2）で作られ、完成したら ITIL で運用・改善される、となります。完了したプロジェクトは、その成果物を ITIL の側に引き渡します。ITIL はほかの手法を置き換えるのではなく、ほかの手法と並んで働きます。

試験の形式

出題のされ方と解き方

• 説明文から名前を当てる：「次の説明に当てはまるのはどれか」。各章の「問題文の手がかり」の列が役立ちます。
• 似た2つを区別する：「X と Y の違いは何か」。下の「まぎらわしいペア」を確実にしておきましょう。
• 場面に当てはめる：短い場面設定から、当てはまる原則・活動・役割を選ぶ。このガイドの「例」の読み方と同じです。
• 順番を問う：継続的改善の7ステップ、関係の3タイプの深さなど。

英語の問題では、キーワードの言い回しが手がかりになります。たとえば「fit for purpose」なら有用性、「evaluate, direct, monitor」ならガバナンス、「a set of organizational resources」なら管理プラクティスです。

まぎらわしいペア　総まとめ

数で覚えるもの

• 価値の特性：4（有用性・保証・UX・持続可能性）
• サービス・オファリングの構成要素：3
• サービス関係のタイプ：3（基本的・協調的・協働的）
• 利用者側の役割：3（スポンサー・顧客・ユーザー）
• 4つの側面：4
• PESTLE：6
• ライフサイクル／バリューチェーンの活動：8
• バリュー・システムの構成要素：5
• 従うべき原則：7
• ガバナンスの活動：3（評価・指示・モニタリング）
• 管理プラクティスのグループ：2
• 継続的改善モデルのステップ：7
• 複雑性思考の状況：3（秩序だった・複雑・混沌）
• AI 能力モデル：6（6C）

おすすめの学び方

1. 「全体の地図」を読み、8つの活動を英語で言えるようにする。
2. 領域1から順に読み、各章の確認問題を、答えを開く前に自分で答える。
3. 「まぎらわしいペア」の表を、左の列だけ見て右を言えるまでくり返す。
4. 英語の模擬問題を解き、間違えた問題の章に戻る。