社内システムやITサービスを運用していると、「障害対応が属人化している」「問い合わせが多すぎて対応状況が見えない」「システム変更のたびにトラブルが起きる」「IT部門の仕事が評価されにくい」といった悩みが出てきます。
ITは、今やほとんどの業務に欠かせない基盤です。営業管理、受注処理、会計、人事、製造、研究開発、顧客対応など、多くの仕事がITサービスに支えられています。
しかし、ITサービスは導入して終わりではありません。安定して使えるように運用し、障害が起きたら早く復旧し、変更するときはリスクを管理し、利用者の満足度を高めていく必要があります。
そこで役立つのが、ITILです。
ITILは、ITサービスを適切に管理・運用するためのベストプラクティスをまとめたフレームワークです。初心者はまず「ITを安定して提供し、利用者に価値を届けるための運用の型」と理解すれば十分です。
ITILを知ることで、IT部門だけでなく、システムを使う業務部門や管理職も、ITサービスをどう改善すべきかを考えやすくなります。
この記事でわかること
・ITILとは何か
・ITILは何に使うのか
・ITILの基本的な考え方
・ITILの使い方
・ITILの具体例
・関連フレームワークとの違い
最初から完璧に使いこなす必要はありません。まずは「ITILはITサービスを安定して運用・改善するための型だ」とつかめれば十分です。
ITILとは？
ITILとは、Information Technology Infrastructure Libraryの略で、ITサービス管理のベストプラクティスをまとめたフレームワークです。
ITサービス管理とは、ITを単なる機械やシステムとして見るのではなく、利用者や事業に価値を提供するサービスとして管理する考え方です。
たとえば、社内のメール、グループウェア、基幹システム、営業支援システム、ワークフロー、ファイル共有、ネットワーク、ヘルプデスクなどは、すべてITサービスと考えることができます。
ITILでは、こうしたITサービスを安定して提供し、継続的に改善するために、さまざまな管理プロセスや考え方を整理しています。
初心者向けに言い換えると、ITILは「IT部門の仕事を、場当たり的な対応から、標準化されたサービス運用へ変えるための考え方」です。
たとえば、パソコンが使えない、システムにログインできない、帳票が出力されない、ネットワークが遅いといった問い合わせが来たとき、担当者が毎回その場の判断で対応していると、対応品質にばらつきが出ます。
ITILの考え方を使うと、問い合わせ受付、優先度判断、対応記録、復旧、原因分析、再発防止、変更管理といった流れを整理できます。
一言でいうと、ITILはITサービスを安定的に提供し、継続的に改善するためのフレームワークです。
ITILは何に使うのか
ITILは、ITサービスの運用、改善、管理に使います。
主な用途は次のとおりです。
・IT問い合わせ対応を標準化する
・障害対応の流れを整理する
・システム変更時のリスクを管理する
・ITサービスの品質を改善する
・サービスデスクの運用を整える
・インシデント対応を迅速化する
・障害の根本原因を分析し、再発防止する
・IT資産や構成情報を管理する
・業務部門とのサービスレベルを明確にする
・IT部門の活動を事業価値と結びつける
ITILは、システムを作るためのフレームワークというより、システムやITサービスを運用するためのフレームワークです。
たとえば、社内システムで障害が起きたときに、「誰が受付するのか」「どのように優先度を判断するのか」「いつまでに復旧させるのか」「利用者にどう連絡するのか」「原因分析を誰が行うのか」を決めておく必要があります。
ITILを使うと、このようなIT運用のルールや流れを整理できます。
どんな人に向いているか
ITILは、次のような人に向いています。
・情報システム部門で働く人
・社内ヘルプデスクやサービスデスクを担当する人
・IT運用や保守を担当している人
・システム障害対応に関わる人
・ITサービスの品質を改善したい人
・業務部門とIT部門の窓口になる人
・DX推進でIT運用体制を整えたい人
・外部ベンダーにIT運用を委託している人
・管理職としてITサービスの品質を見たい人
・システム導入後の運用設計を考える人
特に、IT部門が「問い合わせ対応に追われている」「障害対応が属人化している」「変更作業のたびにトラブルが起きる」と感じている場合、ITILの考え方は役立ちます。
また、業務部門の人にとってもITILは有用です。
なぜなら、ITサービスの品質は業務効率に直結するからです。システムが止まれば業務も止まります。問い合わせ対応が遅ければ、現場の不満も高まります。ITILを知っておくと、IT部門と業務部門が共通の言葉で改善を話しやすくなります。
ITILの基本的な考え方
ITILの基本的な考え方は、ITを「サービス」として管理することです。
システムそのものを管理するだけでなく、利用者がそのITサービスを使ってどのような価値を得るのかを重視します。
初心者がまず押さえておきたい考え方は、次の5つです。
・ITサービス管理
・サービスデスク
・インシデント管理
・問題管理
・変更管理
ITサービス管理
ITサービス管理とは、ITを利用者や事業に価値を提供するサービスとして設計、運用、改善する考え方です。
たとえば、メールシステムは単なるメールサーバーではありません。社員が社内外と連絡を取り、業務を進めるためのサービスです。
営業管理システムは単なるソフトウェアではありません。営業案件を管理し、売上見込みを把握し、顧客対応を改善するためのサービスです。
ITILでは、このようにITを「技術」ではなく「サービス」として捉えます。
サービスデスク
サービスデスクとは、利用者からの問い合わせや依頼を受け付ける窓口です。
たとえば、次のような問い合わせに対応します。
・パスワードを忘れた
・システムにログインできない
・パソコンが起動しない
・プリンターで印刷できない
・アカウントを追加してほしい
・業務システムの使い方を知りたい
サービスデスクは、単なる問い合わせ窓口ではありません。利用者とIT部門をつなぐ重要な接点です。
対応履歴を記録し、よくある問い合わせを分析し、マニュアルやFAQを整備することで、ITサービス全体の改善にもつながります。
インシデント管理
インシデント管理とは、ITサービスに発生した障害や利用者の困りごとを、できるだけ早く通常状態に戻すための管理です。
インシデントとは、サービスの中断や品質低下のことです。
たとえば、次のようなものがインシデントです。
・システムにログインできない
・ネットワークが遅い
・メールが送受信できない
・帳票が出力できない
・業務システムが停止している
・一部の画面でエラーが出る
インシデント管理で重要なのは、まず復旧を優先することです。
原因を完全に突き止める前でも、代替手段や一時対応で業務を再開できるなら、まず利用者の業務影響を減らします。
問題管理
問題管理とは、インシデントの根本原因を分析し、再発防止を行うための管理です。
インシデント管理が「早く復旧すること」を重視するのに対して、問題管理は「なぜ起きたのかを突き止め、再発を防ぐこと」を重視します。
たとえば、毎週のように同じシステムでエラーが起きる場合、毎回復旧するだけでは不十分です。根本原因を調べ、設定ミス、容量不足、設計上の問題、運用手順の不備などを見つける必要があります。
問題管理を行うことで、IT運用が場当たり的な火消しから、継続的な改善へ変わります。
変更管理
変更管理とは、システムやITサービスに変更を加えるときに、リスクを管理しながら進めるための仕組みです。
たとえば、次のような変更があります。
・システムのバージョンアップ
・サーバー設定の変更
・ネットワーク設定の変更
・新機能の追加
・セキュリティパッチの適用
・ユーザー権限の変更
・外部システムとの連携変更
変更作業は必要ですが、同時にリスクもあります。設定を誤るとシステム障害につながることがあります。
変更管理では、変更内容、影響範囲、実施日時、承認者、作業手順、戻し手順、利用者への連絡などを整理します。
ITILの使い方
手順1 現在のITサービスを整理する
まず、自社や自部門で提供しているITサービスを整理します。
たとえば、次のようなサービスがあります。
・社内ネットワーク
・メール、チャット、グループウェア
・ファイル共有
・基幹システム
・営業管理システム
・会計システム
・人事システム
・ワークフローシステム
・社内ポータル
・ヘルプデスク
このとき、単にシステム名を並べるだけでなく、「誰が使っているか」「どの業務を支えているか」「止まるとどの程度影響があるか」を整理します。
ITサービスを一覧化すると、重要度の高いサービス、問い合わせが多いサービス、改善が必要なサービスが見えやすくなります。
手順2 問い合わせと障害の受付ルールを決める
次に、問い合わせや障害をどのように受け付けるかを決めます。
よくある問題は、問い合わせがメール、電話、チャット、口頭などに分散していることです。この状態では、対応状況が見えにくくなり、抜け漏れも発生します。
受付ルールでは、次のような点を決めます。
・問い合わせ窓口をどこにするか
・緊急時の連絡方法をどうするか
・受付内容をどのように記録するか
・問い合わせの分類をどうするか
・優先度をどう判断するか
・対応状況を誰が確認するか
・利用者への回答方法をどうするか
サービスデスクの仕組みを整えることで、IT部門の対応品質が安定しやすくなります。
手順3 インシデント管理を整える
次に、インシデント管理の流れを整えます。
インシデント管理では、発生した障害や不具合に対して、できるだけ早く通常状態に戻すことを重視します。
基本的な流れは次のようになります。
・インシデントを受け付ける
・内容を記録する
・影響範囲と緊急度を確認する
・優先度を決める
・担当者を割り当てる
・一時対応または復旧対応を行う
・利用者に状況を連絡する
・対応結果を記録する
・必要に応じて問題管理へつなげる
重要なのは、対応履歴を残すことです。
対応履歴が残っていないと、同じ障害が再発したときに過去の対応を活かせません。また、どのサービスに問い合わせが多いか、どの障害が業務に大きな影響を与えているかも分析しにくくなります。
手順4 問題管理で再発防止する
インシデントを復旧した後、必要に応じて問題管理を行います。
すべてのインシデントに対して詳細な原因分析を行う必要はありません。しかし、影響が大きい障害、頻繁に繰り返される障害、原因不明の障害については、問題管理が必要です。
問題管理では、次のような観点で整理します。
・同じインシデントが繰り返されていないか
・根本原因は何か
・暫定対応と恒久対応を分けているか
・再発防止策はあるか
・手順書やマニュアルを修正すべきか
・システム構成や設定を見直す必要はあるか
・利用者教育が必要ではないか
たとえば、毎月の締め処理時にシステムが遅くなる場合、単に「その都度再起動する」だけでは不十分です。データ量、処理性能、バッチ処理、同時アクセス、運用手順などを分析し、根本対策を考える必要があります。
手順5 変更管理でリスクを抑える
次に、システム変更の管理を整えます。
変更管理では、変更による業務影響や障害リスクを事前に確認します。
整理すべき項目は次のとおりです。
・変更の目的
・変更内容
・対象システム
・影響範囲
・実施日時
・作業担当者
・承認者
・利用者への連絡
・テスト結果
・戻し手順
・実施後の確認方法
変更管理が弱いと、小さな設定変更が大きな障害につながることがあります。
たとえば、ネットワーク設定を変更した結果、一部の拠点から基幹システムにアクセスできなくなることがあります。権限変更によって、利用者が必要なデータを見られなくなることもあります。
変更前に影響範囲と戻し手順を確認しておくことで、トラブルを減らせます。
手順6 継続的にサービスを改善する
ITILでは、ITサービスを一度整備して終わりとは考えません。継続的な改善が重要です。
改善では、次のような情報を活用します。
・問い合わせ件数
・インシデント件数
・復旧までの時間
・同じ障害の再発回数
・利用者満足度
・サービス停止時間
・変更作業の成功率
・FAQやマニュアルの利用状況
これらを見ながら、サービスデスクの改善、運用手順の見直し、マニュアル整備、システム改修、利用者教育などにつなげます。
ITサービスは、業務や組織の変化に合わせて改善し続ける必要があります。
ITILの具体例
例 社内ヘルプデスクを改善する場合
ある会社では、情報システム部門への問い合わせがメール、電話、チャット、口頭でバラバラに届いていました。
担当者はその都度対応していましたが、次のような問題がありました。
・誰がどの問い合わせに対応しているかわからない
・対応漏れや二重対応が起きる
・よくある質問が毎回個別対応になる
・対応履歴が残っていない
・緊急度の高い障害と簡単な質問が混在している
・IT部門の負荷が見えない
この場合、ITILの考え方を使って、サービスデスクとインシデント管理を整えます。
まず、問い合わせ窓口を一本化します。たとえば、専用の問い合わせフォームやチケット管理ツールを使い、受付内容を記録します。
次に、問い合わせを分類します。
・障害
・操作方法の質問
・アカウント申請
・機器トラブル
・権限変更依頼
・システム改善要望
さらに、優先度を決めます。
・全社業務が止まる障害
・特定部門の業務に影響する障害
・個人の作業に影響するトラブル
・緊急度の低い質問
・将来対応でよい改善要望
このように整理すると、重要なインシデントを優先して対応できます。
また、対応履歴を蓄積することで、FAQやナレッジベースを作ることができます。よくある質問に対しては、利用者が自分で解決できるようにすることで、問い合わせ件数を減らすこともできます。
別の例 システム変更による障害を減らす場合
別の例として、社内の基幹システムで変更作業のたびにトラブルが起きていたケースを考えます。
毎月のように小さな改修や設定変更が行われていましたが、変更内容や影響範囲が十分に確認されておらず、次のような問題が発生していました。
・改修後に一部機能が使えなくなる
・利用者への事前連絡が不足している
・テストが不十分なまま本番反映される
・障害発生時の戻し手順がない
・誰が承認した変更か分からない
・変更履歴が整理されていない
この場合、ITILの変更管理を導入します。
まず、変更依頼を記録します。
・なぜ変更するのか
・何を変更するのか
・どのシステムに影響するのか
・どの利用者に影響するのか
・いつ実施するのか
・誰が作業するのか
・失敗した場合にどう戻すのか
次に、変更内容に応じて承認ルールを決めます。
小さな定型変更は簡易承認、大きな影響がある変更は関係者レビューを行う、といった形です。
さらに、本番反映前にテスト結果を確認し、実施後には正常動作を確認します。
このように変更管理を整えることで、システム変更による障害を減らし、利用者への影響を抑えられます。
具体例でわかるポイント
具体例から学べるポイントは次のとおりです。
・ITILはIT運用を標準化するために使える
・問い合わせを一元管理すると対応漏れを減らせる
・インシデント管理では早期復旧を重視する
・問題管理では根本原因と再発防止を重視する
・変更管理では影響範囲と戻し手順が重要になる
・対応履歴を残すことで改善につなげられる
・IT部門の仕事を可視化しやすくなる
・利用者満足度の向上にもつながる
ITILは、IT部門のためだけのものではありません。ITサービスを使うすべての業務部門にとって、安定した業務運営を支える考え方です。
ITILを使うメリット
ITILを使うメリットは、ITサービスの運用品質を高め、利用者と事業に安定した価値を提供しやすくなることです。
主なメリットは次のとおりです。
・問い合わせ対応を標準化できる
・障害対応のスピードと品質を上げられる
・対応履歴を蓄積して改善に活用できる
・同じ障害の再発を減らせる
・システム変更時のトラブルを減らせる
・IT部門の業務負荷を見える化できる
・利用者満足度を高めやすい
・外部ベンダーとの運用ルールを明確にできる
・サービスレベルを管理しやすくなる
・ITを事業価値に結びつけやすくなる
特に大きなメリットは、IT運用が「担当者の経験頼み」から「組織として管理できる状態」へ変わることです。
属人的な運用では、担当者が休むと対応できない、過去の対応が引き継がれない、同じトラブルが繰り返されるといった問題が起こります。
ITILを使うことで、受付、対応、記録、原因分析、変更、改善の流れを標準化できます。
ITILを使うときの注意点
ITILは便利ですが、使い方を間違えると、手続きが重くなりすぎることがあります。
よくある失敗例は次のとおりです。
・ルールを細かくしすぎて現場が使えない
・チケット入力が目的になり、改善に活かされない
・すべての変更に過剰な承認を求める
・インシデント管理と問題管理を混同する
・復旧より原因追及を優先してしまう
・現場の業務影響を確認しない
・サービスデスクが単なる苦情受付になる
・対応履歴を記録するだけで分析しない
・利用者への連絡が不足する
・IT部門だけで運用ルールを決めてしまう
特に注意したいのは、ITILをそのまま完璧に導入しようとしないことです。
組織の規模やITサービスの重要度によって、必要な管理レベルは異なります。小さな組織で大企業並みの重い手続きを導入すると、かえってスピードが落ちます。
実務では、まず問い合わせ管理、インシデント管理、変更管理など、効果が出やすい部分から始めるのがおすすめです。
また、ITILはIT部門だけで完結するものではありません。利用者である業務部門と合意しながら、サービスレベルや連絡ルールを決めることが重要です。
関連フレームワークとの違い
ITILと関連するフレームワークには、COBIT、TOGAF、DevOps、BPMN、Zero Trustなどがあります。それぞれ目的が異なります。
COBITとの違い
COBITは、ITガバナンスとITマネジメントのためのフレームワークです。
経営目標とIT活動を結びつけ、ITが適切に統制され、価値を生み、リスクが管理されているかを確認するために使います。
ITILは、ITサービスを安定して提供し、運用改善するためのフレームワークです。
COBITが「ITをどう統制し、経営に貢献させるか」に強いのに対して、ITILは「ITサービスをどう運用し、利用者に価値を届けるか」に強いと考えると分かりやすいです。
TOGAFとの違い
TOGAFは、企業全体の業務、データ、アプリケーション、技術基盤を整理するためのエンタープライズアーキテクチャのフレームワークです。
ITILは、ITサービスの運用管理に焦点を当てます。
TOGAFが「企業全体のIT構造をどう設計するか」に向いているのに対し、ITILは「設計されたITサービスをどう安定運用するか」に向いています。
DevOpsとの違い
DevOpsは、開発チームと運用チームが連携し、継続的に価値を届けるための考え方です。
ITILは、ITサービス管理の標準化や安定運用を重視します。
以前は、ITILは安定重視、DevOpsはスピード重視と見られることもありました。しかし、実務では両方を組み合わせることができます。
たとえば、DevOpsで素早くリリースしながら、ITILの変更管理やインシデント管理の考え方でリスクを管理することができます。
BPMNとの違い
BPMNは、業務プロセスを図で可視化するための記法です。
ITILでは、インシデント管理、問題管理、変更管理などのプロセスを整理する際に、BPMNのような業務フロー図を使うことがあります。
つまり、ITILはITサービス管理の考え方であり、BPMNはそのプロセスを図で表すための道具です。
Zero Trustとの違い
Zero Trustは、セキュリティアーキテクチャの考え方です。
「社内だから安全」と考えず、すべてのアクセスを検証する考え方を取ります。
ITILは、ITサービスを安定して運用するためのフレームワークです。Zero Trustがセキュリティ設計に関する考え方であるのに対し、ITILはサービス運用全体の管理に関わります。
ただし、ITILの変更管理、インシデント管理、構成管理などは、セキュリティ運用にも関係します。
ITILはどんな場面で使うと効果的か
ITILは、次のような場面で使うと効果的です。
・社内ヘルプデスクを整備するとき
・問い合わせ対応を標準化したいとき
・システム障害対応を改善したいとき
・インシデント対応のスピードを上げたいとき
・同じ障害の再発を減らしたいとき
・システム変更時のトラブルを減らしたいとき
・外部ベンダーとの運用ルールを明確にしたいとき
・ITサービスの品質を可視化したいとき
・サービスレベルを管理したいとき
・IT部門の業務を改善したいとき
特に、ITサービスが業務に深く関わっている会社ではITILが有効です。
システムが止まると業務が止まる、問い合わせ対応が遅いと現場の生産性が落ちる、変更作業の失敗が顧客対応に影響する、といった状況では、IT運用の品質が事業に直結します。
ITILを使うことで、IT運用を場当たり的な対応から、継続的に改善できるサービス管理へ変えていくことができます。
まとめ
ITILとは、ITサービスを安定して提供し、継続的に改善するためのフレームワークです。
Information Technology Infrastructure Libraryの略で、ITサービス管理のベストプラクティスをまとめたものです。
ITILでは、ITを単なるシステムや機器としてではなく、利用者や事業に価値を提供するサービスとして考えます。
初心者がまず押さえたいのは、サービスデスク、インシデント管理、問題管理、変更管理です。
サービスデスクは利用者との窓口です。インシデント管理は、障害や不具合から早く復旧するための考え方です。問題管理は、根本原因を分析して再発を防ぐ考え方です。変更管理は、システム変更によるリスクを抑える考え方です。
ITILを使うことで、問い合わせ対応、障害対応、変更作業、サービス改善を標準化できます。また、IT部門の活動を見える化し、業務部門との信頼関係を高めることにもつながります。
まずは、自社や自部門のIT問い合わせを一覧化し、どのような内容が多いのか、どこで対応が滞っているのかを確認するところから始めてみましょう。
次に読みたい関連記事
まず全体像を見たい方へ
仕事で使えるフレームワーク一覧｜初心者向けに意味・種類・使い方をわかりやすく解説
あわせて読みたい関連記事
COBITとは？初心者向けに意味・使い方・具体例をやさしく解説
DevOpsとは？初心者向けに意味・使い方・具体例をやさしく解説
CI/CDとは？初心者向けに意味・使い方・具体例をやさしく解説
目的別にまとめて読みたい方へ
IT・システム・業務設計で使うフレームワークまとめ｜初心者向けに種類・使い方・選び方をわかりやすく解説
