ITSM
読み: アイティーエスエム
ITSMとはITサービス管理の基本
ITSMはIT Service Managementの略で、ITサービスを計画的に設計、提供、運用、改善するための管理体系を指す。個々の技術ではなく、ITを「サービス」として捉え、ビジネス価値の提供を軸に運用全体を整理する考え方である。
かんたんに言うと
社内のITをホテルのサービスのように運営する仕組みである。「サーバーが動いている」ではなく「社員がストレスなく業務できている」をゴールに据える。
ITILを土台にITサービスの価値提供を体系化するITSMの基本
ITSMを語るうえでITILは避けて通れない。ITIL(Information Technology Infrastructure Library)は英国政府が1980年代にまとめたITサービス管理のベストプラクティス集で、ITSMの事実上の標準フレームワークになっている。現行のITIL 4は2019年にリリースされ、従来の「プロセス中心」からアジャイルやDevOpsの考え方を取り込んだ「バリューストリーム」へと進化した。
ITILはあくまでガイドラインであり、そのまま適用すれば機能するわけではない。自社の規模や業態に合わせてプラクティスを取捨選択する必要がある。中小企業が大企業向けのITILをフルセットで導入しても、運用コストに潰されるだけである。
インシデント管理と問題管理の違い
ITSMの中核をなすプラクティスがインシデント管理と問題管理の2つ。名前は似ているが、目的がまるで違う。
インシデント管理は「今起きている障害をとにかく早く復旧させる」ことが目的。メールが送れない、社内システムにログインできない。こうした事象をチケットとして記録し、優先度をつけ、担当者をアサインし、復旧までの時間を管理する。
問題管理は「同じ障害が繰り返し起きる根本原因を突き止めて潰す」ことが目的。毎週月曜の朝にメールサーバーが遅くなるなら、それは個々のインシデントではなく、構造的な問題である。バッチ処理とメール配信のリソース競合かもしれない。
現場ではインシデント管理だけで手一杯になり、問題管理まで手が回らないケースが多い。結果として同じ障害が何度も起き、そのたびに火消しに追われる悪循環に陥る。
変更管理とリリース管理の実務
本番環境に変更を加える。これがITにおける最大のリスク要因の一つである。
変更管理は、本番環境への変更を事前に審査し、リスクを評価し、承認プロセスを経てから実行するプラクティス。「金曜の夕方に本番デプロイして週末に障害発生」という悪夢を防ぐための仕組みでもある。
リリース管理は変更管理の一部で、ソフトウェアのリリースを計画的に行うプロセスを指す。テスト環境での検証、リリース手順書の作成、ロールバック計画の策定まで含む。
DevOpsの普及で、変更管理の在り方も変わりつつある。週1回のCAB(変更諮問委員会)で承認を取る従来型から、自動テストとCI/CDパイプラインによる高速なリリースサイクルへ。ただし金融や医療など規制の厳しい業界では、人による承認プロセスを完全に省略するのは難しい。
ITSMツールの選び方と主要プロダクト
ITSMを実践するにはツールが必要になる。ServiceNowが市場を牽引しており、エンタープライズ向けではデファクトスタンダードに近い。Jira Service ManagementはAtlassian製品との連携が強みで、開発チームとの距離が近い組織に向いている。
ツール選定で見落としがちなのが「誰が使うか」の視点。IT部門だけが使うのか、全社員がセルフサービスポータルとしてアクセスするのか。後者なら、エンドユーザーのUI/UXが選定の決め手になる。機能が豊富でも、社員が使いこなせなければチケットの起票率が上がらず、結局は電話やチャットで個別対応する羽目になる。
AIがITSMにもたらす変化
チャットボットによる一次対応の自動化は既に広まっている。パスワードリセットやVPN接続トラブルなど、手順が定型化された問い合わせをAIが処理し、人間のオペレーターは判断が必要な案件に集中する。
さらに進んでいるのが、インシデントの予兆検知。サーバーのCPU使用率やネットワークのレイテンシをAIが常時監視し、障害が起きる前にアラートを出す。これは機械学習による時系列分析の典型的な応用例である。
とはいえ、AIに任せきりにするのは危険である。自動分類の精度が低いまま運用すると、重大インシデントが「低優先度」に振り分けられてエスカレーションが遅れる。導入直後は人間がAIの判断を監視する期間を設けるべきである。
当社の見解
当社はツール選定において実用性を第一方針にしている。カタログスペックやベンチマークスコアではなく、実務で1週間使い倒して初めて判断する。フレームワークを増やすほど管理コストが増える経験もした。フックを増やしすぎてAIが情報過多でパニックになったこともある。足し算だけでなく、引き算の判断が選定の質を決める。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。