データインサイダー

ITSMとは?

ITSM (ITサービス管理)は、組織とその従業員、顧客、ビジネスパートナーへITサービスおよびサポートを提供するための戦略です。その主眼は、エンドユーザーが何を期待しているかを理解し、ITサービスとその提供方法の両方を改善していくことにあります。

コンピューターが世に現れて間もないころ、コンピューターに問題が生じたときに従業員が頼りにしたのは、社内のIT部門でした。しかし、時を経て企業のコンピューターのインフラが劇的に拡大し、従来のIT部門ではその規模に対応していくことが難しくなったことで、1980年代初期に正式なサービスデスク、すなわち「ヘルプデスク」モデルが登場しました。

1989年には、ITSMのベストプラクティスがITIL (Information Technology Infrastructure Library)として初めて体系化され、それまで受動的だったITサービスを、ビジネス全体のニーズに沿ったプロアクティブな機能へと転換しました。その後、企業ではCOBIT、Six Sigma、TOGAFなど、数々のITSMフレームワークが採用されてきていますが、ITILは今でもデファクトスタンダードのフレームワークとして健在です。

ITSMは、業務を合理化し、多くのサービス要求を自動処理して、業務の効率と即応性を高めます。さらに、従業員の生産性を引き上げ、カスタマーエクスペリエンスを改善し、ユーザー満足度を向上させることで、結果的にビジネスによりよい成果をもたらします。ここでは、企業が活用できる各種ITSMツールとフレームワーク、ITSMがもたらす多くのメリット、そしてITSMの実際の導入方法についてご紹介します。

ITSMとは:目次

さまざまなITSMフレームワーク

ITSMフレームワークには、ITサービスの導入と管理を効率よく行うためのプロセスとポリシーがまとめられています。代表的なフレームワークはITILですが、Microsoft Operations Framework (MOF)、Control Objectives for Information and Related Technologies (COBIT)、Business Process Framework (eTOM)もよく使用されています。

それぞれのITSMフレームワークには数十ものプロセスが定義されています。たとえばITILには、3つにグループ分けされた、34のITサービス管理プラクティスが含まれています。一般的なプロセスは以下のとおりです。

  • 要求実現:ユーザーからのあらゆるサービス要求のライフサイクルを管理します。 
  • インシデント管理:ヘルプ要求への対応や問題の修復を行い、サービスを通常状態に復帰させて、ビジネスへの影響を最小限に抑えます。 
  • 変更管理:ITサービスにおいて実施されるあらゆる変更の管理手順を標準化します。 
  • ナレッジ管理:IT製品およびサービスの情報を整理し、ユーザーが利用できるようにする方法がまとめられています。 
  • 可用性管理:サービスの中断を最小限に抑えるために、ITインフラのサービス、性能、サポートを最適化する方法が定義されています。 
  • サービスレベル管理:顧客に提供するサービスレベルを改善および管理し、サービスレベル契約を遵守する方法がまとめられています。

ITSMフレームワークには、上記をはじめとするプロセスがあらかじめ定義されており、既存、新規の両ITサービスを運営し改善していくための枠組みとガイドラインが示されています。すでに数多くの組織が実際に試した方法を踏襲できるため、独自のプロセスをゼロから構築するよりも効率的かつ低リスクです。

ITSMのメリット

ITSMがITサービスおよびサポートにもたらすメリットには、以下のようなものがあります。

  • 一貫性:ITSMという1つの基盤に統合することで、ITプロセスが標準化され、IT業務の速度と質を高められます。
  • 効率の向上:自動化などのテクノロジーをワークフローに組み込むことにより、反復的で単純なタスクを手動で行う必要がなくなります。また、チケット発行やインシデント管理のプロセスも簡素化されるため、チームはより価値の高いタスクに注力できます。
  • サービスベースのインシデント管理:ITSMはサービス障害からの復旧速度に重点を置いており、繰り返し発生する問題の削減と、それらの問題による影響の最小化に効果があります。 
  • ダウンタイムの低減:サービスやビジネスを中断させる問題の予測と防止が可能になり、問題が発生した場合でもより迅速に復旧できます。
  • 業務コストの削減:プロセスの合理化やタスクの自動化によって手作業の必要が減ることで、過剰な人員を抱えることなく、IT業務の拡大に対応できるようになります。
  • 説明責任の向上:サービスの標準化は、種類を問わずあらゆるITサービスのプロセスを文書化することで実現されます。そのため、各ITサービスがどのように提供されているかを詳細に可視化できるようになり、組織全体で一貫性とコンプライアンスを担保したサービス提供が可能になります。

ITSMとITILの違い

ITSMとITILは同じ意味で使用されることもありますが、実際にはそれぞれ別の目的を持つフレームワークです。

ITSMとは、ITサービスの提供に関連して、組織が人、プロセス、テクノロジーをまとめて管理するための手法を意味し、その対象範囲はITサービスのライフサイクル全体、つまり設計や開発から、デリバリー、サポート、保守にまでにおよびます。範囲の広さに伴ってタスクも多く、ITシステムの計画と管理から、ITの問題の修復と防止、IT予算の管理など、多岐にわたります。そのため、ITSMは単なるITサポートを超え、ビジネス価値の実現に貢献します。

一方、ITILはベストプラクティスのフレームワークであり、組織がITSMに取り組む際の手引きとなります。その目的は、ITを戦略的なビジネスの目標とニーズに結び付け、効率的なサービス提供を実現することで目標の達成につなげることにあります。最新版であるITIL 4のプロセスは、最近の働き方の変化や、アジャイルおよびDevOps方法論の普及、デジタルトランスフォーメーションのニーズに対応しており、具体的には、コラボレーションの強化、サイロの抑制、組織全体のコミュニケーション向上が奨励されています。

ITILは現在でも代表的なITSMフレームワークであり、組織に以下のメリットをもたらします。

  • 標準化したサービス提供で、全体的な効率を高める。
  • 規制コンプライアンス要件の遵守方法を改善する。
  • 反復的な手動作業を排除し、より革新的で付加価値を生むサービスを提供することへの注力を可能にする。
  • エンドユーザーのみでなく、サービスの関係者全員を考慮できる。
  • 価値を実現するための反復的アプローチで、サービスを継続的に改善する。

ITSMとITILは明らかに重なる部分がありますが、この2つは別々の、相互に補い合うコンセプトです。簡単に言うと、ITSMは1つの独立した分野のフレームワークであり、ITILは組織がITSMを成功させるための補助を提供します。

ITSMとDevOpsは両立するか?

ITSMとDevOpsはどちらもテクノロジーを開発および管理する手法ですが、表面的にはアプローチが大きく異なります。ITSMは、反復可能なフレームワークと明確に定義された役割および責任を用いて、サービス提供ライフサイクルに標準化とガバナンスをもたらします。一方でDevOpsは、ソフトウェア提供における速度、俊敏性、サイロ解消に重点があります。DevOpsはコラボレーション、透明性、オープンなコミュニケーションといったコアバリューを重視しますが、その手引きとなるベストプラクティスは正式に文書化されていません。

このことが原因で、ITSMとDevOpsでできることや、この2つを両立させる方法、または両立できない理由に関して、多くの人が誤解をしています。以下は、よくある間違いの例です。

  • DevOpsはITSMに代わる存在である:ITSMとDevOpsは相いれない方法論であると、多くの組織が誤解しています。実際には、サポート、ガバナンス、予算管理といったITSMの機能は現代のあらゆるビジネスにおいて不可欠ですが、DevOpsではこれらを取り扱いません。
  • DevOpsは自動化と継続開発に特化している:CI/CDや自動デリバリーなどのプラクティスはDevOpsの代表的な要素ですが、それがすべてと考えるのは間違いです。DevOpsの本質は、共通の目標に向かって、コラボレーション、実験、学習ができ、失敗を責めない文化を醸成することにあります。 
  • ITSMはプロセス偏重で、組織を減速させる:ITSMがプロセスフレームワークを基礎としているのは事実ですが、厳格に適用されるルールではありません。ITILなどのフレームワークは、意思決定を強制するものではなく、導くものです。複雑なITプロセスを速やかに理解して整理できるようになるため、組織を減速させるよりも、むしろ業務とサービス提供が効率化されます。
  • ITSMを必要とするのは大企業だけ:早くからITSMを導入したのは大企業でしたが、スタートアップや中規模企業にもITの体制整備は必要です。ITSMの変更管理、構成管理、問題管理、インシデント管理の戦略は、大企業でなくても、同様のメリットがあります。

ITSMとDevOpsはどちらか一方を選ぶものではなく、互いに補い合うプラクティスであり、どちらもビジネス価値をもたらすものとして考えるべきです。高いパフォーマンスを実現している組織は、ITSMのプロセス管理とDevOpsのスピードおよびコラボレーションを両立させ、双方のメリットを引き出しています。

ITSMにおける変更管理の追跡方法

ITSMにおける変更管理は、テクノロジーインフラに変更を行う際に、移行によるITサービス中断を最小限に抑えるためのプラクティスです。文書化した正式な変更管理プロセスにより、すべてのサービス提供者と関係者を連携させます。また、変更が適切に開始されなかった場合は、変更をロールバックできます。

ITIL4では、3種類の変更が定義されています。

  • 標準変更:リスクの低い、事前に承認された変更。サービス要求として開始されることが多く、業務の変更である場合もあります。標準変更の手順を作成または変更した後は、完全なリスク評価と承認が必要です。
  • 通常変更:所定のプロセスに沿ってスケジュールを設定し、評価し、承認することを必要とする変更。リスクの低い通常変更はローカルの組織や管理者が承認できますが、重大な通常変更には経営層の承認が必要になることもあります。 
  • 緊急変更:可能な限り速やかに実装する必要のある変更であり、通常は変更スケジュールに組み込みません。迅速に実装できるよう、多くの場合は評価と承認のプロセスを速めます。テスト、評価、承認は可能な限り通常変更と同様に行うべきですが、スケジュール設定と文書化の優先度は下がります。

これらの変更を管理するために、明確に定義された一連の変更実装手順を遵守します。この手順は、ワークフローを中断せず、ユーザーと管理者が困惑することなく変更を実装できるように定義されています。

ITILのガイドラインでは、変更管理は通常、ユーザーが生成する変更要求(RFC)によって開始されます。変更が提案されるとIT組織がそれを評価して、変更の種類や緊急度を判断し、計画されている他の変更を考慮してスケジュールを検討します。

そして、適切な意思決定者に変更の許可を申請します。多くの場合はここで、変更諮問委員会(CAB)による変更の評価、優先順位付け、承認も行われます。

承認されなかった変更は、後で更新して、承認を再申請できます。必要な承認をすべて得た変更は、リリース管理チームがテスト、統合、導入を行います。実装後は変更管理チームがフォローアップし、変更が期待された成果を上げているか確認します。

 

ITSMに必要な分析

ほとんどのITSMツールが何十ものメトリクスを追跡しますが、データは、結局のところ、ITサービスの管理者がITサービスチームのパフォーマンスを把握するためのものです。その点で言うと、特に重要なのはこれらのメトリクスです。

  • チケットあたりのコスト:ITサービスおよびサポートの効率を知るために役立つメトリクス。サービスデスクの月間合計運用費(給与、テクノロジーおよび設備費、オフィス用品など)を月間合計チケット数で割って算出します。
  • 顧客満足度:組織のITサービスおよびサポートのパフォーマンスを知りたいとき、一般的に最も適した指標はユーザーの満足度です。
  • 一次解決率:ユーザーとの初回コンタクトで解決したチケットの割合を測定したもの。一次解決率の高さと顧客満足度の高さには、強い相関があります。
  • 技術者の稼働率:労働効率を測定したものであり、チケットあたりのコストと密接な関連があります。通常は、技術者の稼働率が高いとチケットあたりのコストが低く、技術者の稼働率が低いとチケットあたりのコストが高くなります。
  • 一次レベル解決率:総所有コスト(TCO)にかかわる指標の1つであり、ITサポートの真の効率を見極めるために役立ちます。たとえば、ある一次レベルのサービスデスクのチケットあたりのコストが低い理由が、上位レベルのサポートへエスカレーションしているからだとします。その場合、効率的なサービスデスクという印象を与える一方で、TCOは増加します。
  • 技術者の職務満足度:当然ながら、技術者の職務満足度が高ければ離職や常習的な欠勤は少なくなります。それだけでなく、一次解決率の高さと処理時間の短さとも相関します。結果として、チケットあたりのコストの低減と、顧客満足度の向上につながります。
  • 平均解決時間(MTTR):問題解決にかかる平均業務時間(チケットのオープンからクローズまで)を測定する、サービスレベルのメトリクス。
ITSMに必要な分析 ITSMに必要な分析

ITSMにおける自動化とAIのメリット

ITSMにおけるワークフローの自動化やその他のAI実装は、以下のようにさまざまなメリットがあります。

  • 業務効率の向上:自動化により、手動で行う反復的なIT業務作業が削減され、ITサービスデスクのタスクを迅速化できるため、より価値の高い活動に注力できるようになります。また、プロセスが自動化されることで、スタッフを再トレーニングする必要がなくなり、サービス業務の負担も軽減されます。
  • インシデント解決の迅速化:よくある単純な修復(サーバーのリブートなど)はボタンをクリックするだけで実行できるため、担当の技術者を探して、その技術者の手が空くまで待たなければならないということがなくなります。
  • コストの削減:自動化によって手動作業が減ることで、労力を節約できるとともに、人的エラーによって生じる修正コストも削減できます。
  • フィードバック収集の向上:プロセスを自動化することで、ITスタッフが貴重な時間を割いてユーザーとやりとりしなくてもフィードバックを集められるようになるため、サービスの継続的な改善が容易になります。 
  • ユーザー満足度の向上:自動化を活用してユーザーにセルフサービスのオプションを提供することで、待ち時間や問題解決までの時間が短縮し、ユーザーエクスペリエンスが向上します。

 

考慮すべき主なITSMソフトウェア機能

ITSMプロセスの確立に必要なものがフレームワークであれば、プロセスの支援に不可欠なものはITSMツールです。ITSMツールは、ヘルプデスク管理にとどまらず、ITプロセスの簡素化にも貢献します。ソフトウェアプラットフォームによって、資産の発見、チケットシステムの保守、問題の追跡と解決、サービス提供の改善機会の発見がしやすくなります。機能はプラットフォームによって異なりますが、ITSMツールとして効果を発揮するには、少なくとも以下の機能が必要です。

  • 資産管理:ITSMが効果を発揮するためには、すべてのハードウェアおよびIT資産に対する詳細な可視性と統制が必要です。ITSMツールでは、これらの資産を簡単に追跡でき、そのライフサイクル全体にわたって構成、ライセンス、インシデントを管理できる必要があります。
  • 問題管理とインシデント管理:一般的にITSMツールには問題管理とインシデント管理が含まれています。これらはエンドユーザーに影響を与える前に問題を取り除くために役立ちます。ログやイベントデータからのノイズ除去、異常パターンの発見、根本原因の究明に、機械学習を活用しているツールもあります。
  • チケット管理:現在でもチケット管理はITサービスの基礎です。優れたITSMツールを導入すれば、要求の追跡、チームメンバーの技術経験に基づいた作業割り当てなど、プロジェクト管理機能の実施がさらに容易になります。
  • セルフサービスポータル:一部のITSMツールにはセルフサービスポータルがあり、従業員がIT部門と直接かかわることなく、解決策を見つけられます。たとえば、従業員が新しいノートPCを要求する際に、電話口で技術者を待つ必要がなくなります。スピードと自律性が求められるDevOps組織では、セルフサービスのITサービスプロビジョニングが特に重要です。 
  • 高度な分析とレポート:直感的でリアルタイムなダッシュボードを作成したり、カスタマイズレポートを生成することができるITSMツールは、導入する価値があります。これらの機能は、パフォーマンスを把握し、改善の必要な部分を特定して、サービス戦略を策定、修正するのに役立ちます。さらに、分析ツールがAIや機械学習に基づくものであれば、これらのインサイトをほぼリアルタイムで生成でき、市場での競争力を高めることができます。 
  • ITサービスモデルに対応:ITILなどのベストプラクティスのフレームワークと融合したITSMツールを使用すると、より容易にITSMを導入できます。

ITSMツールを選定する際は常に、特定の機能セットを求めるよりも、組織のニーズを優先すべきです。そのためには、ビジネスに不可欠なサービス提供とサポートのプロセスを明らかにし、自動化やセルフサービス機能で効率化できる箇所や、難しさが解消されたり、ユーザーエクスペリエンスの向上が見込める部分はどこなのかを見極めることが重要になります。

結論:あらゆるIT組織にITSMは有効

今や、どのような組織にもITは欠かせません。これまで組織は、相互に連携しない複数のシステム、その場しのぎのプロセス、非効率な作業負荷のせいで、ユーザーのニーズに応えていくことに苦労してきました。ITSMは、明確な役割、反復可能なプロセス、ワークフローの自動化によって、ITに統一性をもたらし、結果として、ITサービスとその提供の管理および即応性を向上させます。新しいアプローチを導入する際に文化の転換が求められるのは、ITSMの場合も同じです。しかし、ITSMがユーザーとビジネスにもたらす価値は、その困難をはるかに上回るでしょう。

参考リソース: