ITILとは?情シスに必要なプラクティスだけを取り入れる方法
ITILとITSM・ISO/IEC 20000の違い、ITIL 4の全体像、情シスが最初に取り入れる5つのプラクティスと最小限の形、後回しでよいもの、7つの原則の使い方と導入の失敗例を整理しました。
ITILとは、ITサービスを安定して提供し、改善し続けるための運用管理のベストプラクティスをまとめたフレームワークです。読み方は「アイティル」で、Information Technology Infrastructure Libraryの略です。1980年代に英国政府がまとめた手引きが始まりで、現在は民間企業が権利と資格制度を持ち、改訂を続けています。
ITILは全部を導入するものではありません。数人の情シスがすべてのプラクティスを文書化しようとすると、運用より文書づくりに時間が消えます。ITSMとの違いとITIL 4の全体像を押さえたうえで、情シスが最初に取り入れる5つのプラクティスと最小限のやり方、後回しにしてよいもの、7つの原則を日々の判断に使う方法、よくある失敗までを、小さな組織の目線で並べます。
この記事でわかること
- ITSM・ITIL・ISO/IEC 20000・ITSMツールの関係と、ITIL 4の全体像
- 情シスが最初に取り入れる5つのプラクティスと、それぞれの最小限の形
- 優先度を決める影響度×緊急度の表と、変更を3種類に分ける運用
- 後回しにしてよいプラクティスと、取り入れる条件
- 7つの原則を情シスの判断に置き換えた例と、ITIL導入でよくある失敗
ITILとは:ITSMとの違いとITIL 4の全体像
ITILとよく並べられる言葉を整理します。混同されやすいのは、考え方・手法の集まり・規格・製品という別々の階層のものが、同じ文脈で語られるからです。
| 用語 | 何を指すか | 組織としての認証 | 情シスでの使いどころ |
|---|---|---|---|
| ITSM | ITを「サービス」として提供し、運用管理する考え方と活動の総称 | - | 目指す状態そのもの |
| ITIL | ITSMのベストプラクティスをまとめたフレームワーク(書籍群) | なし(個人向けの資格のみ) | 取り入れる手法を選ぶ引き出し |
| ISO/IEC 20000 | ITSMの要求事項を定めた国際規格 | あり(第三者による認証) | 取引先に運用管理の水準を証明する必要があるとき |
| ITSMツール | チケット管理やワークフローを提供する製品(ServiceNowなど) | - | 手法を回すための道具 |
執筆時点で広く参照されているのは、2019年に公開されたITIL 4です。版の改訂が行われることがあるので、資格の受験や研修の前には最新の版を公式情報で確認してください。ITIL 4は、価値を生み出す仕組み全体をサービスバリューシステムと呼び、その中に7つの原則、ガバナンス、6つの活動からなるサービスバリューチェーン、34のプラクティス、継続的改善を置いています。プラクティスは一般的なマネジメント、サービスマネジメント、技術的なマネジメントの3群に分かれます。
以前のITIL v3は、戦略・設計・移行・運用・継続的改善という5段階のライフサイクルに沿ってプロセスを並べていました。「ITIL プロセス 一覧」で検索すると出てくる一覧の多くはこの時代のものです。2019年のITIL 4では、段階の順番ではなく、状況に応じて組み合わせる「プラクティス」の集まりとして整理し直されました。小さな情シスにとっては、この変化は追い風です。順番どおりに全段階を整える必要がなく、困っているところから選べるからです。
情シスが最初に取り入れる5つのプラクティス
| プラクティス | 一言でいうと | 最小限の形 | 見る指標の例 |
|---|---|---|---|
| サービスデスク | 利用者との窓口を1つにする | 受付をフォームかチャットの専用窓口に集め、全件にチケット番号を振る | 窓口を通らない依頼の件数 |
| インシデント管理 | 止まったものを、まず元に戻す | 影響度と緊急度で優先度を決め、優先度ごとに初動の目安を決める | 優先度別の復旧までの時間 |
| サービス要求管理 | 決まった依頼を、決まった手順でさばく | アカウント作成やソフトの導入など定型の依頼を、申請フォームと手順書に落とす | 依頼から完了までの日数 |
| 変更管理 | 本番への変更を、記録と承認つきで行う | 変更を3種類に分け、申請者と承認者を別の人にする | 変更が原因の障害の件数 |
| 問題管理 | 同じ障害を繰り返さない | 同種のインシデントが繰り返したら「問題」として登録し、原因と回避策を記録する | 再発したインシデントの件数 |
5つのうち、最初の一歩として最も効くのは、インシデントとサービス要求を分けることです。「PCが起動しない」は元に戻す話で、「新入社員のアカウントを作ってほしい」は決まった作業の依頼です。同じ受付の列に並べると、急ぎの障害が定型作業の後ろで待たされ、定型作業は毎回その場の判断でさばかれます。分けるだけで、障害は優先度で、依頼は手順書で処理する流れが生まれます。変更管理は、ITIL 4の用語ではchange enablementと呼ばれています。
インシデントの優先度は、影響の範囲(影響度)と、待てるかどうか(緊急度)の組み合わせで決めます。次は小さな組織向けに作った表の例です。
| 影響度\緊急度 | 高:業務が止まり回避策がない | 中:回避策はあるが負担が大きい | 低:当面の業務に支障がない |
|---|---|---|---|
| 高:全社または複数部門 | P1 | P2 | P3 |
| 中:1部門または1拠点 | P2 | P3 | P3 |
| 低:個人 | P3 | P4 | P4 |
初動の目安は、例としてP1はすぐに着手して30分ごとに状況を全社へ連絡、P2は当日中に着手、P3は3営業日以内、P4は計画的に対応、のように決めます。重要なのは数字そのものではなく、依頼者が自分の優先度を見て「いつごろ対応されるか」を予測できることです。役員のPCだからP1、という例外を作ると表が崩れるので、例外が必要なら影響度の定義の方を見直します。
変更は、標準変更・通常変更・緊急変更の3種類に分けます。標準変更は、手順が決まっていてリスクが低く、事前に承認済みとして扱える変更です(例:承認済みアプリの配布、新入社員のアカウント作成)。通常変更は、影響を評価して承認を受けてから行う変更です(例:ファイアウォールのルール変更、全社に効くSaaSの設定変更)。緊急変更は、障害や悪用されている脆弱性への対応で、実施を優先し、承認の記録は事後にそろえます。承認の場は、週1回15分、予定されている通常変更の一覧を見るだけの会議で足ります。
変更の承認を重くしすぎると、承認を待てない担当者が申請せずに変更するようになり、記録のない変更が増えます。これは承認がない状態より悪い結果です。何度も同じ手順で安全に終わった通常変更は標準変更の一覧へ移し、承認が要る変更を減らしていく方向で運用してください。上場企業では、変更の記録はIT全般統制の監査でも証跡として見られます。
後回しにしてよいプラクティスと、取り入れる条件
34のプラクティスのうち、次のものは小さな情シスでは後回しにして構いません。後回しにする代わりに、何で代用するかと、どうなったら取り入れるかを決めておきます。
| プラクティス | 当面の代用 | 取り入れる条件 |
|---|---|---|
| サービスレベル管理(正式なSLA) | 優先度ごとの初動の目安を社内に公開する | 外部に運用を委託する、または社内から約束を求められる |
| ナレッジ管理 | 解決した手順をチケットに残し、よく使うものだけFAQにする | 同じ質問への回答が担当者ごとに違ってきた |
| IT資産管理・構成管理 | 端末とライセンスの台帳だけを持つ | 障害の影響範囲を台帳から判断したくなった |
| キャパシティ・パフォーマンス管理 | 監視ツールのしきい値アラート | 自社でシステムを開発・運用し、利用者数が増えている |
| サービス財務管理 | 年1回の費用の棚卸し | 部門ごとにIT費用を配賦するよう経営から求められた |
| リリース管理 | 変更管理の中で扱う | 自社開発のシステムを定期的にリリースしている |
ナレッジ管理とIT資産管理は、後回しにしてよいとはいえ、条件がそろうのが早いプラクティスです。問い合わせが増えてきたらナレッジ管理を、端末が数十台を超えて台帳の手入力が追いつかなくなったらIT資産管理を始めます。資産管理の台帳とツールの作り方はIT資産管理の始め方で扱っています。
7つの原則を情シスの判断に置き換える
ITIL 4の7つの原則は、覚えるための標語ではなく、判断に迷ったときの物差しとして使うと役に立ちます。情シスの日常の判断に置き換えると次のようになります。
| 原則 | 情シスの判断に置き換えた例 |
|---|---|
| 価値に焦点を当てる | 新しいツールを入れる前に、利用者にとって何が良くなるかを1行で書く。書けなければ入れない |
| 今いる場所から始める | 今のExcelの問い合わせ台帳を捨てず、項目を足して使い、その項目のままツールへ移す |
| フィードバックを得ながら少しずつ進める | 変更の申請ルールは1部門で1か月試し、手直ししてから全社に広げる |
| 協力して見える化する | チケットの状況を依頼者が自分で確認できるようにし、「どうなっていますか」という問い合わせを減らす |
| 全体を見て考える | パスワードの定期変更をやめるかどうかを、ヘルプデスクの件数とセキュリティの両面から決める |
| シンプルで実用的に保つ | 承認者が3人いる申請は、本当に3人必要かを見直す |
| 最適化してから自動化する | 担当者ごとに手順が違う作業は自動化しない。まず手順を1つにそろえる |
情シスで最も効くのは最後の原則です。手順がばらばらのまま自動化すると、ばらつきごとスクリプトに固定され、例外処理だらけの壊れやすい仕組みができます。自動化の前に、手順書を1本にそろえ、2〜3回その手順で回してから自動化の対象にしてください。
ITIL導入でよくある失敗
| 失敗 | 何が起きるか | 避け方 |
|---|---|---|
| ITSMツールを買えば導入完了と考える | ツールの画面に合わせて手順を作り、現場が入力しなくなる | 先に分類と手順を紙で決め、ツールはそれに合わせて設定する |
| 全プラクティスの文書化から始める | 文書が厚くなり、誰も読まない | 5つのプラクティスを1枚ずつの手順にして回し始める |
| 用語を利用者に押し付ける | 利用者が「インシデント」と「サービス要求」を選べず、分類がでたらめになる | 受付画面は「困っている」「お願いしたい」の2択にし、分類は情シスが付ける |
| 件数だけを追う | 分類の粒度が担当者でばらつき、数字が比べられない | 分類の定義を1枚にまとめ、月1回、分類を付け直す時間を取る |
| 承認フローを増やしすぎる | 無申請の変更が増え、記録の信頼性が落ちる | 標準変更の一覧を育て、承認が要る変更を減らす |
3行目の「2択の受付画面」は、今日から変えられる改善です。利用者にITILの言葉を覚えてもらう必要はありません。情シスの内側だけで用語をそろえ、受付の段階では利用者の言葉で受けてください。ヘルプデスク全体の効率化は社内ヘルプデスクの効率化で詳しく扱っています。
ITILは組織を認証する制度ではないので、会社として「ITIL準拠」を第三者に証明する方法はありません。取引先から運用管理の水準の証明を求められたときに使えるのは、ITSMの国際規格であるISO/IEC 20000の認証です。個人の資格であるITIL Foundationの合格者数を、組織の運用品質の証明として出すのは避けてください。
よくある質問
ITILの7つの原則は?
7つの原則は、ITIL 4で示された行動の指針で、価値に焦点を当てる、今いる場所から始める、フィードバックを得ながら少しずつ進める、協力して見える化する、全体を見て考える、シンプルで実用的に保つ、最適化してから自動化する、の7つです。どれか1つを選ぶためではなく、判断に迷ったときに照らし合わせる物差しとして使います。
ITILの具体例は?
情シスの日常に置き換えると、問い合わせを1つの窓口で受けてチケット番号を振る(サービスデスク)、PCが動かないという連絡を影響度と緊急度で順位付けする(インシデント管理)、同じ障害の根本原因を調べて再発を防ぐ(問題管理)、ファイアウォールの設定変更を申請・承認・記録する(変更管理)、といった形です。
ITILの最上位の資格は?
ITIL 4の資格体系では、入門のFoundationの上に実務者向けのモジュールと、それらを組み合わせて得る称号があり、最上位はITIL Masterとされています。体系は改訂されることがあり、上位の資格では認定研修の受講が条件になるものもあるため、受験の前に公式サイトで最新の体系を確認してください。
ITILの勉強時間はどのくらいですか?
実務経験で大きく変わります。インシデント管理や変更管理を日常的に回している人は、用語と自分の仕事を対応づけるだけで済むので短く、運用の経験がない人は概念の理解に時間がかかります。時間の目安を探すより、自社のチケットや変更の記録を教材にして、用語を実物に結びつけながら学ぶ方が身につきます。
まとめ
ITILは導入する対象ではなく、困りごとに効くプラクティスを選ぶための引き出しです。最初はサービスデスク、インシデント、サービス要求、変更、問題の5つを最小限の形で回し、標準変更の一覧と解決手順の記録を育てながら範囲を広げます。迷ったら7つの原則に照らし、とくに「最適化してから自動化する」を守れば、ツール先行の失敗は避けられます。