ITIL（Version 5）の情報を受けて、「ITIL 4の手順書をすべて書き換えるべきか」 「新しい資格へ一斉に切り替えるべきか」と検討している組織もあるでしょう。 しかし、版が変わったことと、現場のサービスマネジメントを全面刷新することは同じではありません。 先に変える対象を広げすぎると、機能している運用まで崩し、利用者や事業への価値が見えにくくなります。

PeopleCertの公式説明では、ITIL（Version 5）はITIL 4をリセットするものではなく、 デジタル製品・サービス、AI、体験、組織横断の価値創出へ適応させる進化と位置づけられています。 34のマネジメントプラクティスも大部分は継続し、ITIL 4の資格はVersion 5上位資格の前提として認められています。 ITIL 4モジュールは2027年12月31日に終了する計画が示されていますが、 これは資格体系の予定であり、各社の運用を同日までに一括変更すべきという意味ではありません。

本記事では、ITIL 4で培った価値重視、価値ストリーム、継続的改善などを土台に、 Version 5の新しい視点を必要なところから接続する段階移行を整理します。 公式情報は2026年7月31日時点のものであり、資格・教材・提供時期は更新される可能性があるため、 実際の判断時には最新情報を確認してください。

具体的な課題：「新版対応」が先行すると、改善が止まる

移行プロジェクトが用語、文書、資格、ツール設定の置き換えに集中すると、 何の事業課題を解決するのかが後回しになります。 現場には追加作業が生まれても、利用者の体験、変更の速度、サービスの信頼性は変わらないという状態です。

  • 文書の一括更新：実際に使われている手順と、監査や説明のためだけに残る手順を区別せず書き換える。
  • 資格取得の目的化：学習計画はあるが、役割、権限、価値ストリームの変化へつながらない。
  • 既存運用の未評価：ITIL 4で機能している判断、データ、会議、改善活動まで廃止対象にしてしまう。
  • 製品とサービスの分断：開発、業務、運用、外部委託先が別の目標と指標を持ち、全体の成果を説明できない。
移行の対象はフレームワークの名称ではなく、事業成果を妨げている働き方と接続の不足です。

考え方：残す・つなぐ・更新する・測る

全面刷新ではなく、四つの層で移行対象を整理します。 「残す」を明示することで現場の安定性を守り、「つなぐ」と「更新する」で新しい視点を取り込み、 「測る」で移行そのものを継続的改善の対象にします。

  1. 残す：サービスの価値、継続的改善、役割分担、記録、リスク管理など、成果に寄与しているITIL 4の実践。
  2. つなぐ：デジタル製品とサービス、開発と運用、社内チームと外部提供者を、共通の価値ストリームで接続する。
  3. 更新する：利用者体験、製品・サービスのライフサイクル、AIを含む新技術、組織変革の観点を不足箇所へ加える。
  4. 測る：文書更新数や受講者数ではなく、事業成果、体験、速度、信頼性、コストの変化を確認する。

ITIL（Version 5）が示す製品・サービスのライフサイクルは、 製品開発とサービス運用を別々に最適化するのではなく、 構想から価値実現までを一つのエコシステムとして捉える視点です。 ITIL 4の価値ストリームを捨てるのではなく、より広い組織境界へ伸ばすと理解すると、 現行運用との接続点を見つけやすくなります。

実践手順1：移行目的を一文で定義する

最初に「Version 5へ移行する」ではなく、変えたい事業成果を一文で表します。 たとえば「新機能の企画から安定利用までの引き渡しを減らし、利用者の立ち上がりを早める」 「外部サービスを含む障害時の責任境界を明確にし、復旧判断を速める」という形です。

経営責任者、製品・サービス責任者、開発、運用、サービスデスク、セキュリティ、 調達・委託先など、成果に影響する役割を特定します。 移行スポンサーには予算承認だけでなく、部門間の目標と権限を調整する責任を持たせます。

実践手順2：現行のITIL 4運用を棚卸しする

手順書の有無ではなく、実際の仕事を観察します。 代表的な価値ストリームを一つ選び、需要の発生から価値の確認までに、 誰が何を判断し、どの情報を使い、どこで待ち時間や手戻りが生じるかを記録します。

各活動を「成果に寄与している」「必要だが改善が必要」「根拠が不明」に分けます。 変更承認やインシデント報告を一律に廃止・簡略化するのではなく、 守るべきリスク、必要な証跡、利用者への影響を確認します。 既存の指標、サービス構成情報、ナレッジ、役割定義も再利用可能な資産として扱います。

実践手順3：製品・サービス・価値ストリームを接続する

対象となるデジタル製品、それを利用可能にするサービス、利用者の行動、 支えるシステムと外部提供者を一枚に描きます。 開発完了やリリースを終点にせず、利用者が価値を得て、運用から得た学びが次の改善へ戻るまでを含めます。

  • 共通成果：製品チームとサービスチームが共有する利用者・事業成果は何か。
  • 引き渡し：設計、移行、運用で情報や責任が途切れる場所はどこか。
  • 意思決定：優先順位、リスク受容、提供開始、停止を誰が判断するか。
  • 学習ループ：問い合わせ、障害、利用状況、体験の情報を製品改善へどう戻すか。

実践手順4：一つのサービスで新しい視点を試す

事業影響が見え、関係者を集めやすいサービスを選び、8〜12週間程度の試行計画を置きます。 期間は一例であり、サービスの変更頻度やリスクに合わせて調整します。 全プラクティスを同時に変えるのではなく、棚卸しで見つかった接続不足を一つか二つ改善します。

たとえば、設計段階からサービスデスクを参加させる、利用者体験の確認をリリース判定へ加える、 AI機能を使う場合の責任・データ・停止条件を変更評価へ組み込む、といった小さな変更です。 変更前の基準値を取り、試行中は利用者・現場の定性情報も集めます。

実践手順5：成果で拡大・修正・保留を判断する

移行の進捗を研修受講率や更新文書数だけで測らず、 目的に対応した事業成果とガードレールを組み合わせます。 企画から安定利用までの所要時間、再作業、問い合わせ理由、利用者体験、重大障害、 変更による影響、運用コストなどから必要な指標を選びます。

改善が確認できた実践は別のサービスへ展開し、効果が曖昧なものは仮説や測定方法を修正します。 負荷やリスクが増えたものは保留し、元の方法へ戻せるようにします。 四半期ごとなど一定の周期で、公式情報、教育計画、運用変更、ツール設定の優先順位を更新します。

注意点：資格移行と組織変革を混同しない

  • 終了予定だけで急がない：資格・教材の提供予定と、組織の運用変更計画を分けて管理する。
  • 用語だけを置き換えない：名称を変えても、役割、権限、指標、引き渡しが同じなら成果は変わりにくい。
  • 教育だけに任せない：学習は共通言語を作る手段であり、経営判断や組織設計の代わりにはならない。
  • ツール設定を先行させない：価値ストリームと判断基準を確認してから、ワークフローや自動化を変更する。
  • 公式情報の確認日を残す：資格体系、言語、移行経路、終了予定は変更され得るため、参照日と判断根拠を記録する。
  • 他の要求事項と整合させる：セキュリティ、個人情報、契約、監査などは、関係部門や必要に応じて専門家へ確認する。

まとめ

ITIL（Version 5）への対応は、ITIL 4を捨てるプロジェクトではありません。 現行運用から価値を生んでいる実践を残し、製品とサービスを一つのライフサイクルへつなぎ、 体験、AI、組織変革など不足する視点を加え、成果で改善を続ける取り組みです。

まず一つのサービスを選び、移行目的、現行の価値ストリーム、接続が切れている場所を一枚にしてください。 その上で小さく試し、事業成果とガードレールを見ながら拡大・修正・保留を判断します。 版の変更を期限対応で終わらせず、サービスマネジメントを経営と現場の共通言語へ進化させる機会にできます。

参考にした公式資料

本記事は公式資料をもとに一般的なITサービスマネジメントの考え方を整理したものであり、 個別組織の認証取得、契約、法令適合性その他の専門的判断を保証するものではありません。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る