ITパスポート単語帳 - サービスマネジメント

企業などの組織が、従業員や顧客、取引先などのニーズや目的を満たすため、コンピュータなどの情報機器や通信ネットワーク、ソフトウェア、ネットサービスなどを組み合わせ、必要なときに必要なIT機能を提供可能な状態に維持する一連の活動を意味する。

一般的には、企業などのIT部門が従業員向けにITシステムを運用したり、機材やソフトウェアを手配して利用可能な状態を維持する業務を指すことが多い。そのための体系化された仕組みを「ITサービスマネジメントシステム」(ITSMS)という。

ITサービスマネジメントに含まれる業務には、IT提供の戦略や計画の策定、設計、実装や調達、運用開始や移行、運用や保守、管理、改善や見直しなどのプロセスが含まれる。この一連の流れを一つのサイクルと捉え、循環的に繰り返すことで組織内のITサービス提供を持続・改善する。

特に重視されるのはITサービスの運用プロセスで、利用者に対するサービスの中断に対応する「インシデント管理」、インシデントの原因を調査・排除する「問題管理」、サービスの構成要素の変更や更新を体系立てて行う「変更管理」、サービスの構成要素の構成や設定、状態を把握する「構成管理」などの活動、ITに関する総合的な窓口となる「サービスデスク」といった要素で構成される。

標準規格

ITSMSについての標準規格としては、イギリス政府がIT運用の模範的な事例(ベストプラクティス)を調査して体系化した「ITIL」(IT Infrastructure Library)がよく知られる。初版は1989年に発行され、1995年に英国家規格「BS 15000」として標準化された。

これは2005年にISO/IECによって「ISO/IEC 20000」として国際標準となっており、日本では2007年にほぼ同じ内容が「JIS Q 20000」として国内標準化されている。国内ではこの規格に基づいて、JIPDEC(情報経済社会推進協会)が「ITSMS適合性評価制度」を運用している。

利用者が情報機器などを使って目的を遂行できる状態を維持することを「ITサービス」と捉え、その適切な維持、管理のための方法論をまとめている。ITサービスの例として、企業内で情報システム部門がコンピュータやネットワークを管理し、従業員が業務に使用できる状態を維持する活動(システム運用)が挙げられる。

ITILは分野ごとに一冊の書籍としてまとめられており、2001年に発行されたITIL V2では「サービスサポート」「サービスデリバリ」の2冊が、2007年のITIL V3では「サービス戦略」「サービス設計」「サービス移行」「サービス運用」「継続的なサービス改善」の5冊が中核となっている。それぞれが数個から十数個のより具体的な要素やプロセスで構成され、解説されている。

ITILの普及を推進するための民間非営利団体としてitSMF(IT Service Management Forum)があり、各国支部がITILの翻訳・出版などを担当している。日本でもitSMF Japanが日本語版を発行している。ITILの知識や技能を認定する資格試験も運用されており、初級から順にファウンデーション(foundation)、プラクティショナー(practitioner)、インターメディエイト(intermediate)、エキスパート(expert)、マスター(master)の5段階の資格に分かれている。

歴史

1980年代、イギリス政府はIT投資に期待した効果がなかなか得られないことから、IT活用の先進事例を調査し、模範的な事例(ベストプラクティス)を収集、政府におけるIT提供の標準として1989年に最初のITILを発行した。

2000年から2001年にかけて「ITIL V2」書籍群が刊行され、日本ではこれが紹介されて広く普及し始めた。2007年には全面的に改定された「ITIL V3」が刊行され、2011年にはV3の小幅な改訂となる「ITIL 2011」が出版された。V2とV3・2011では体系が大きく異なるため実際上はそれぞれ別物として扱う(どちらを指すのか明記する)ことが多い。

提供するITサービスの可用性や性能などの品質について保証する項目と水準を定め、利用開始時に双方で合意した文書や契約を指す。それらを実現できなかった場合に料金を一定割合で返金するなど、補償についての規定も定めておくことが多い。

規定される項目は原則として客観的に決定でき、定量的に計測可能なもので、上限や下限、平均などを数値で表し、測定方法なども定義しておく。例えば、混雑時でも最低限保証する通信速度や処理性能、障害などによる平均故障間隔(MTBF)や平均修復時間(MTTR)、稼働率の下限などを定める。

利用者にとっては、メニューなどで謳われている性能や機能がどの程度の水準で保証されるのか事前に知ることができる。また、サービス内容などが同程度の事業者の中から、サービス提供の品質水準とコストを比較して事業者を選定することができる。

事業者にとっては、形式的な性能表記などでは比較しにくい高いサービス品質をアピールしたり、逆に廉価である理由を合理的に説明することができる。顧客に想定以上の品質や対応を求められてコストが嵩んだり、責任範囲についての認識の齟齬からトラブルに発展することを未然に防ぐことも期待できる。

もともとアメリカの大手通信事業者などが通信サービスについて導入したものが広まったもので、現在では通信サービスや各種のオンラインサービス、IT関連サービスで広く普及している。組織内の部門間で似たような合意文書を交わす場合もあり、「OLA」(Operational Level Agreement：運用レベル合意書)と呼ばれる。

提供するサービスやシステム、機材などに関して、性能や可用性、データ管理、運用、サポート、セキュリティなどの目標水準や目標値を設定する。単に数値などを定めるだけでなく、評価基準や裏付けとなるシステム構成や運用・管理体制、準拠する標準規格などを具体的に定義する場合もある。

一方、事業者と契約者の間でサービス品質の最低限度の保証について取り交わす契約のことは「SLA」(Service Level Agreement)という。一般にSLOはSLAを遵守するための目標として設定することが多く、事業者の内部的な利用に留めて利用者側には開示されないこともある。

一台のコンピュータに複数の同社製ビデオカードを装着してSLIで接続することにより、カード内のGPU(Graphics Processing Unit)を協調して動作させ、グラフィックス処理を分散して並列に実行することができる。

通常は2枚のカードを連結するが、両GPU間の連携や通信のために負荷(オーバーヘッド)が生じるため性能は単純に2倍になるわけではないものの、2倍に近い演算性能が得られるとされる。機種によっては3枚を連結する「3-way SLI」や4枚を連結する「Quad SLI」に対応しているものもある。

コンピュータ本体やソフトウェア側からは1枚のカードのように見えるため、この機能を利用するために特別な対応は必要ないが、ビデオカードおよびマザーボード上のチップセットはSLI対応機種である必要があり、コンピュータ側の拡張スロットも枚数分の空きを要する。

Scan-Line Interleave

元は「Scan-Line Interleave」という名称で、米3dfx社の「Voodoo2」というカードを2枚連結できる機能だった。これは、2枚のカードが画面の奇数番目のラインと偶数番目のラインをそれぞれ担当することで描画速度を向上させる技術だった。同社がNVIDIA社に買収されたことで、より汎用性を高めた「Scalable Link Interface」として生まれ変わった。

社内サービスデスクは運用中のITシステムや社内に配備されたIT機器、通信ネットワーク、業務用ソフトウェアなどに関して、他部署の従業員から使い方などの問い合わせに回答したり、トラブルへの対応、苦情や要望の聞き取りなどを行う部門を指す。情報システム部門の一部として設置されることが多い。

「ヘルプデスク」と「サービスデスク」はほぼ同義として用いられることが多く、両者を異なるものとして両方設置することはまずありえない。ただし、ヘルプデスクが利用者側から持ち込まれた問題への対応という受け身の業務であるのに対し、サービスデスクはこれを含むより包括的なサービス窓口という意味合いで区別されることもあり、技術関連以外の様々な分野の問い合わせへの対応や積極的な情報発信などの業務を含む場合がある。

サービス品質の目標水準(SLO：Service Level Objective)を定め、サービスを構成するシステムや機材、作業プロセスなどについて、稼働状況や対応状況を継続的に記録し、目標とする水準を維持しているか監視する。問題が発見された場合は改善策を検討し実施する。

対象となる項目はサービスの内容に応じて変わるが、一般的にはシステムの性能や可用性、データ管理、運用体制、サポート体制、セキュリティなどが含まれることが多い。

保証するサービスの品質水準は提供者と利用者の間で事前に文書などの形で合意・契約することがあり、これを「SLA」(Service Level Agreement)という。サービスレベル管理の検証はSLAで合意した水準を基準に行われ、状況によってはSLAの見直し、再検討などを含む場合もある。

情報システムにおける「インシデント」(incident)とは、システム障害や装置の故障などとは異なる概念であり、利用者にとって、「システムを使ってやりたいことができない状態」を意味する。例えば、「コンピュータが故障して使えない」という事態が発生した場合、「コンピュータが使えないこと」がインシデントであり、「コンピュータの故障」はその原因となる。

また、機器やシステムの側に不備や不具合がない場合でも、「このソフトウェアのこの機能の使い方が分からない」「ログインのためのパスワードを忘れてしまった」といった状況が生じる場合があり、これもインシデント管理の対象となる。

コンピュータの故障の例では、障害対応・復旧の観点からは「故障箇所を特定して修理する」が典型的な対応策となるが、インシデント管理の観点からは「代わりのコンピュータを用意する」なども考えられる。利用者がやりたいことをできるようにする施策を講じることが重要となる。

インシデント管理は利用者がITを使用できる状態を維持するITサービスマネジメントの重要なプロセスの一つとされ、ITILやISO/IEC 20000といった規格やガイドラインにより標準的な体制やプロセスの体系が定められている。

組織内でのITサービスの提供において、利用者が目的のIT機能を利用できない状態・事象のことを「インシデント」(incident)と呼び、インシデントを引き起こす原因のことを「問題」(problem)という。

例えば、「プリンタで印刷ができない」はインシデントで、「プリンタが故障している」が問題にあたる。この場合、問題を解決するには「修理に出す」「買い換える」などの手段が必要となるが、単にインシデントを解消するだけなら、例えば「動いている他のプリンタで印刷する」という選択肢もあり得る。

ITILなどのITサービス運用の規格では、インシデントと問題は区別し、それぞれについて記録、対応することが求められる。一般的にはインシデント対応を優先させ、その後に問題の識別、分類、記録、優先度の設定、調査、診断、解決策の策定と実行という手順を踏むことが多い。

問題管理プロセスでは専用の管理ツールなどを用いて問題を一件ずつ台帳に記録し、詳細や現在の状態、過去に登録された問題の一覧などをサポート部門内で共有できるようにする。また、発生したインシデントから原因となる問題を探るだけでなく、将来インシデントを発生させうる潜在的な問題を探索する活動が行われる場合もある。

ITシステム全体を対象とする場合、システムを構成するサーバなどの機器(ハードウェア)や主要部品、OSやミドルウェア、アプリケーションなどのソフトウェア、商用ソフトウェアのライセンス、ネットワークの配線や配置、ソフトウェアやネットワークの設定情報などが管理対象となる。

これらを構成管理ツールなど専用のソフトウェアで台帳のようなデータベース(CMDB：Configuration Management Database)に記録し、個々の要素について識別情報や属性、状態、設定、変更履歴、要素感の関連などの情報を一元的に管理する。システムのどこにどのような要素があり、来歴や現状がどうなっているのかを素早く把握することができる。

こうした情報はシステムの現状把握や問題解決、改善などを行う際の基礎的な資料として活用できる。例えば、利用者からの要望の答えるためにどこにどのような機器を増強すべきか判断したり、障害発生時に影響範囲の特定や原因の調査を行ったり、商用ソフトウェアのライセンス違反を防止する際などに役立つ。

ITILなどに基づくITサービスマネジメントでは、ITサービス提供の最適化のために必要なプロセスの一つとして構成管理が重視される。インシデント管理、問題管理、変更管理など他の活動を効率的に行うための基礎としても、構成管理を通じてCMDBの構築と管理をしっかり行うことが重要となる。

ソフトウェア環境の構成管理では、OSや言語処理系、サーバソフトウェアなどの構成や設定をある種のコンピュータプログラムとして記述し、ツールを通じて自動的に適用する「IaC」(Infrastructure as Code)という仕組みが注目されている。同じ設定のサーバを多数用意する場合などに管理作業を自動化、効率化することができ、履歴の把握や変更の管理も容易になる。

システムへの変更が野放図に行われることでサービスの提供に支障が生じたり、無計画なサービスの中断が起きることを防ぎ、停止時間(ダウンタイム)の最小化、サービス品質の安定、変更に伴うリスクの管理を可能とする。

変更管理の対象は分野や業務により様々だが、ITシステムの場合にはオペレーティングシステム(OS)やアプリケーションソフトの新規導入やアップデート、機器や配線などの増設や交換、撤去、移動、組織体制の変更や担当者の異動、担当業務の変更、業務運用の見直しなどがある。ソフトウェアやシステムの導入については「リリース管理」「デプロイ管理」などとして別に管理することもある。

既存のデータを修正・更新する際に元のデータを直接上書きしてしまうと、後で誤りに気づいても以前の状態に戻すことができない。データ更新の際に誰が、いつ、どのように変更したのかを履歴として蓄積していれば、後から過去の任意の時点の状態に戻して修正し直すことができる。

また、ある版と別の時点の版を比較してどこがどのように変更されたのかを調べたり、複数人で共同作業する際に他の人の更新内容を上書きして消してしまうのを防いだりすることもできる。ある時点の版を元に本筋とは異なる変更、追加を行い、派生的な成果物を作ることも容易となる。

バージョン管理システム

バージョン管理を行うための専用のソフトウェアを「バージョン管理システム」(VCS：Version Contorol System)という。現代では単にバージョン管理という場合はデータをそのようなシステムに保存して管理することを意味することが多い。

ファイルシステムと同じように複数のファイルを階層的なディレクトリに整理でき、全体をまとめてプロジェクトとして管理することもできる。ファイルとその変更履歴やバージョン番号(リビジョン)などの管理情報は「リポジトリ」(repository)と呼ばれる一種のデータベースにまとめて集積される。

利用者はクライアントソフトを用いてリポジトリにアクセスし、あるファイルの最新版や過去の版を指定して取り出したり、編集した新しい版を登録することができる。変更履歴の流れをある時点を起点に分岐(フォーク)させて派生版を作成したり、再び元の流れに統合(マージ)することもできる。分岐した時系列を「ブランチ」(branch)という。

ネットワーク上に設置したサーバ上でリポジトリを運用すれば、離れた場所にいるメンバー同士が内容の整合性を保ちながら共同で編集作業を進めることができる。現代の大規模なソフトウェア開発には欠かせない仕組みとなっている。

PDCAは4つのステップから成る。“Plan” (計画)では、目標を設定してそれを達成するための行動計画を作成する。“Do” (実行)では、策定した計画に沿って実際に業務を遂行する。“Check” (評価)では、実施した結果についての情報を集めて整理し、当初の目標や以前のサイクルの結果などと比較するなどして評価を行う。

“Act” (「行動」「処置」の意だが改善と訳されることが多い)は “Adjust” (調整)とも呼ばれ、評価を受けて問題点の洗い出しや成功・失敗の要因を分析し、プロセスや計画の調整、実施体制の見直しなどの処置を行なう。

“Act” まで一通りの活動が終わると、その結果を反映して再び “Plan” から一連の活動を行う。このP→D→C→Aの流れを継続的に繰り返すことを「PDCAを回す」などと言い、螺旋を描くようにプロセスの改善が行われることが期待される。

PDSサイクル (Plan-Do-See cycle)

循環的なプロセスの改善手法として、“Plan” (計画)→ “Do” (実行)→ “See” (評価)の3段階とする場合もあり、PDSサイクルという。

上位者への引き継ぎ

システム運用や利用者サポートなどの業務で、システムの障害や利用者からの質問・クレームなどに担当者・チームが対処できない場合に、上位の組織や担当者、管理者などに連絡し、対応を引き継ぐことをエスカレーションという。この用法はIT分野以外でも一般のビジネス用語として用いられる。

ロックのエスカレーション

データベース管理システム(DBMS)の機能で、同じテーブルに対して行単位やページ単位などのロックが頻発した際に、それらをまとめてテーブル全体をロックすることを「ロックのエスカレーション」という。

ロックの粒度を大きくすることで負荷を減らし効率を高めることができるが、本来のロック指定では無関係な要素まで巻き添えでロックされるため処理の並列度は低下する。

例外処理のエスカレーション

プログラミングにおいて、エラーや例外が発生したときに、対処するルーチンが無かったり適切に処理できない場合に、より上位のクラスの対応ルーチンに処理を依頼することを「例外処理のエスカレーション」という。

開発者はすべての例外について対応する処理を記述する必要はなく、上位クラスなどが提供する処理で良い場合は対応を任せることができる。

企業などのITサービスマネジメント(ITSM)では、組織内で運用する情報システムについて、利用者(従業員や関係先など)からの問い合わせを受け付けるサービスデスク(ヘルプデスク)は複数設けず、一箇所に集中させるべきとする原則がある。

システム運用では対象や問題の種類ごとに担当者や担当部門が異なる場合があるが、利用者はシステムや運用部門の細かい構成や体制、事情に熟知しているとは限らず、また、本来そのような詳細を知っている必要はないはずである。

運用部門内にシステム全体に対する唯一の連絡先、問い合わせ窓口を設けて「交通整理」を行い、必要に応じて適切な担当者や関係先への連絡や問い合わせ、対応要請などを行うことで、利用者側にとっても個々の担当部門、担当者にとっても効率的に問題解決ができるようになる。

製品や分野についての初心者向けの手引きや、サービスの加入者向けWebサイトなどによく掲載される。よくある基本的な疑問は自ら解決するよう促すことで、質問する手間、回答する手間を省くことを期待して作成される。

過去に実際に多かった質問をまとめる場合だけでなく、初歩的な内容を読みやすいように一問一答の形式でまとめたり、よく聞かれることになると予想される質問を回答側があらかじめ想定して作成する場合もある。

原則として、簡潔で一般的(過度に詳細で個別的な内容を含まない)質問と、それに対する回答を並べた形式を取るが、英語圏のビデオゲーム情報サイトなど一部の分野では、一問一答形式だけでなく特定のトピックについての網羅的なガイドやリストなどもFAQと呼ぶ場合もある。

歴史

何らかの対象について問答集の形で情報をまとめた文書は中世の文献などにも見られ、古くからよくある形式だったが、「FAQ」という名称は比較的最近付けられたものである。

1980年代初頭に、インターネット(当時のARPANET)上の情報交換システムの一つである「Usenet」(ユーズネット)で、新規参加者が皆同じ質問を繰り返すのにうんざりした古参利用者が頻繁に尋ねられる内容をFAQの名称でまとめて掲載したのが始まりと言われている。

日本でも、1980～90年代に一般に開放される以前の大学などを中心としたインターネット上のメーリングリストやNetNews(ネットニュース)などを通じて広まり、そのまま主にIT系の分野で問答集をFAQと呼ぶことが定着した。

Q&Aとの違い

IT以外の分野では、このような問答集のことを「Q&A」(Questions and Answers/キューアンドエー)と呼び、古くから様々な分野で作成されてきた。FAQとQ&Aに定義上の厳密な違いはなく実質的には同じものである。

時折「FAQは過去に実際に多かった質問をまとめたもの、Q&Aはそれに限らず想定問答などを含む」といった違いについての説明を見かけるが、少なくとも現在そのような違いが広く浸透して適切に使い分けられているとは言い難く、実質的にはほぼ同義語として扱われていると見るべきであろう。

人間が自然言語(日本語や英語など人間が日常的に使うことば)による文字メッセージを送信すると、その内容を解析し、内蔵された応答ルールやデータベースなどを駆使して何を返答すべきかを決定し、自然言語の応答文を生成して送り返す。「チャットボット」の名称は “chat” (おしゃべり)と “robot” (ロボット)を組み合わせた造語である。

古くから単純なルールに基づいて人間のような受け答えを行う「お遊び」のプログラムが存在し、人工知能をもじって「人工無脳」などと呼ばれていた。近年では機械学習などの技術を応用して実用的な意味のある機能を提供できる「AIチャットボット」が開発され、注目されている。

2016年頃から実用化が進み始め、企業のWebサイトで来訪者の質問に自動的に回答したり、顧客のサポート窓口として問い合わせや要求を取り次いだりするシステムが投入されている。また、メッセンジャーやSNSなどのサービスと連携し、人間のスタッフのように振る舞って情報やサービスを提供するシステムも開発されている。

企業などが業務に用いる施設や設備を総合的に管理・運営し、業務に適した環境を維持する活動を「ファシリティマネジメント」(facility management)という。単なる個別の施設や設備の管理に留まらず、事業や人に適した環境の整備・維持のための総合的なマネジメントという意味合いで用いられる。

「プロパティ」(property)や「アセット」(asset)も不動産やビルなどを指すことがあるが、これらは賃貸ビルなど外部に提供したり転売するなどして収益を得るための資産・物件という意味合いで用いられることが多い一方、「ファシリティ」は自社の営業活動のために用いる施設を指すという違いがある。

一般的には、通常の商用電源(家庭用の100V交流電源など)に接続して給電を受け、同じ規格の電力を外部に供給する装置を意味する。コンピュータなどの電気機械をUPSを介して電源に接続することにより、停電が起きても暫くの間稼働を続けることができる。

落雷などによる電源の瞬断や一時的な電圧低下などが機器の動作に影響することも回避できるが、UPS自体はこうした電源異常に対する耐性や防護機能があるわけではないため、対策が必要な場合はサージ防護機器などを別途導入する必要がある。

ビルの電気設備に組み込まれ、建物内の電源全体を保全する大型の製品はデータセンター施設などで用いられる。より一般的なのはコンピュータなどの機器と電源(コンセント)の間に設置する小型の製品で、IT分野だけでなく医療や防災、放送などで重要な電気製品を稼働させるために導入される。

コンピュータ向けの製品の中には通信ケーブルで接続して通知や制御を行う機能を持ったものもある。停電すると自動的に稼働中のオペレーティングシステム(OS)にシャットダウン操作を行い、突然の電源断によるデータの喪失やストレージ装置の破損などを防止する。

CVCFとの違い

常に一定の電圧および周波数で電力を供給する交流電源(装置)、および、電源装置などが持つそのような出力電流の安定化機能を「CVCF」(Constant-Voltage Constant-Frequency：定電圧定周波数装置/交流安定化電源)という。

外部の電源から入力された電気を元に独自に一定の電圧・周波数の交流電流を起こし、これを出力側に送出する。不安定な外部電源による電圧や周波数のノイズ、瞬間的な変動などの影響を取り除き、常に一定の品質の交流電流を提供する。出力する電流は入力側と異なる電圧・周波数でも構わないため、電圧や周波数の変換機能を内蔵しているものもある。

UPSとCVCFは役割が似ており、実際、UPSの中にはCVCFとしての機能が組み込まれたものが多く、逆にCVCF装置も蓄電池を内蔵しており電源の瞬断などに対応できるものが多い。両者が混同されることも多いが、UPSは電源の瞬断や停電時に電力供給が途絶えないようにすることが目的であるのに対し、CVCFは電圧と周波数の安定化が目的という違いがある。

「ファシリティ」(facility)とは施設、設備といった意味の英単語で、管理・修繕を中心とする従来のいわゆる「施設管理」を含む、より包括的な概念とされる。経営的な視点から施設・設備の全体最適を追求する継続的な業務の総体を意味する。

必要な施設・設備の構想や選定、調達方法(購入・建設か、賃貸・レンタル・リースか)の選択、維持・運用、より適した形への改善(移転や統廃合、新設など)などの業務や事業が含まれる。空調や照明、防災設備などのハードウェア的な側面と、清掃や警備などのサービス、ソフトウェア的な側面に分かれる。

ITのグリーン化

半導体技術の高度化や社会のコンピュータ利用の広まりと共に、コンピュータシステムの電力消費や発熱の増大が問題視されるようになり、これらを低減することでコスト削減と環境対策の両立を目指す取り組みとして、グリーンITという用語が使われるようになった。

具体的には、消費電力を抑えた半導体製品の活用や、サーバ統合や仮想化、クラウド化などを活用した機器の台数削減や利用効率の向上などが含まれる。

ITによるグリーン化

また、業務のIT化による効率向上やITシステムによる機器や設備の高度な電力制御などにより、従前よりも環境への負荷を低減する取り組みのことをグリーンITと呼ぶ場合もある。

これには、文書の作成・管理にIT機器を導入して紙の使用量を減らすペーパーレス化や、テレビ会議などの活用による出張の削減やテレワーク化、通信ネットワークで遠隔地を結んで行う遠隔授業や遠隔医療、住宅やオフィスのエネルギー利用の最適化(HEMS/BEMS等)などの取り組みが含まれる。