基本情報技術者単語帳 - サービスマネジメント

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

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

サービスマネジメントに含まれる業務には、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の分野では、人や組織が提供する役務といった一般の外来語としての意味に追加して、コンピュータなどの機器やソフトウェアが、利用者や他の機器、ソフトウェアなどに対して提供する機能や働きのことをサービスということがある。

Windowsのサービス

Windowsでは、利用者や実行中のソフトウェアの求めに応じて即座に何らかの機能を提供できるよう、起動された状態でシステムに常駐するプログラムのことをサービスという。

システムやデータの管理や監視のための機能や、多くのソフトウェアが共通して必要とする汎用的な機能などを実装したもので、通常は操作画面などを持たず、利用者が直接操作することはほとんどない。

Windowsがオペレーティングシステム(OS)の機能の一部として標準的に提供するもののほかに、個々のアプリケーションソフトが提供するものがある。起動時に自動的に実行されるよう設定されており、コントロールパネルの「サービス」アプリから実行、停止、再起動を行うことができる。起動時の自動実行の有無も切り替えることができる。

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

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

サービスマネジメントに含まれる業務には、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」として生まれ変わった。

人工物について信頼性という場合、定められた条件(製造元の指定する定格値など)下で一定の期間(耐用年数など)、期待される機能を提供し続けることができる性質を表す。

修理不能な製品の場合は故障や破損のしにくさがそのまま信頼性とみなされ、平均故障率(FIT：Failure In Time)や平均故障時間(MTTF：Mean Time To Failure)などの指標が用いられる。修理可能な製品では平均故障間隔(MTBF：Mean Time Between Failures)などで表され、保守性(maintainability/serviceability)を含んだ概念となる。

信頼性にいくつかの性質を加えて、システムが期待された機能・性能を安定して発揮できるか否かを検証するための評価項目として用いる場合がある。よく知られるのは信頼性に可用性(Availability)と保守性(Serviceability)を加えた「RAS」で、これに完全性(Integrity)と機密性(Security)を加えたものは「RASIS」という。

コンピュータや情報システムなどの場合には、要求や入力が終了した時点から、応答や出力が開始される時点までの時間のことを応答時間と呼んでいる。

通信回線やネットワークを介してデータを送受信するようなシステムの場合は、相手方が送信を終えてから受信が始まるまでの時間を指し、信号が伝送路を往復する時間が含まれる。

ディスプレイの応答時間

画面表示装置(ディスプレイ)などの場合、画素の色を変更するのにかかる時間のことを応答時間と呼ぶ。この時間が短いほど高速に画面を切り替えることができ、動きの激しい映像などを精細に表示することができる。

単に応答時間といった場合は黒(消灯)から白(全点灯)に切り替えて再び黒に戻す動作にかかる時間を指すことが多いが、近年では実際の使用時に頻度の高い「中間色から別の中間色に切り替える速度」を表す「GTG」(Gray To Gray/G to G/中間階調応答速度)という指標もよく用いられる。

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

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

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

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

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

ソフトウェア製品などは発売・公開された後に改良や修正を行い、以前とは異なる新版として改めて発行し直す場合がある。その際に、特定の版を他と区別するために番号やアルファベット、付加的な短い固有名などが与えられる。

バージョンをどのように付けるかは開発元によって異なり、統一された厳密な基準や規則などは無いが、よく用いられるのは「バージョン3.14」のように3～4桁程度の実数で表す方法である。上位桁ほど大きな更新を表し、整数部の値が増えると別の製品として再発売、再公開されることが多い。細かな修正や改善が行われると変更の大きさに応じて小数部の値が増加する。

派生版など単純な更新ではない場合は「バージョン3.3D」のように英字などを付加する場合がある。また、正式版の発行前に実質的に同じ内容のものを配布して利用者のもとで試用やテストを行う場合があり、アルファ版の場合は「1.0α」「1.0a」「1.0-alpha」のように、ベータ版の場合は「1.0β」「1.0b」「1.0-beta」のように表記される場合がある。

商用ソフトウェア製品などの場合、ブランディングや消費者にとっての分かりやすさなどのために「Windows 2000」のように発売年をバージョンとしたり、「Windows XP」「Windows Vista」のように短い固有の符号や名称を与えてバージョン名とする場合もある。その場合、技術的なバージョン番号が別に定められ、内部的なシステムの識別・同定などに利用される場合もある。例えば、Windows 2000は内部的にはWindows NT 5.0として扱われる。

バージョンアップ

製品を改良し、バージョンを更新、増加させることをバージョンアップという。和製英語であり、英語では一般的には “upgrade” という。

再発売などを伴う全面的な更新を「メジャーバージョンアップ」、小幅な改良や修正、欠陥の解消などを「マイナーバージョンアップ」という。これらも和製英語で、英語では前者を “upgrade”(アップグレード) 、後者を “update”(アップデート)などと言う。

エディションとの違い

書籍の「第1版」などの版のことは英語で “edision” (エディション)というが、ソフトウェア製品でエディションという場合はバージョンのような新旧の前後関係ではなく、同世代の製品について想定顧客や用途などで分かれたパッケージの区別を意味する。

例えば、同じソフトウェアの同じバージョンについて、家庭や個人利用者向けの「Home Edition」、ビジネス向けの「Business Edition」、大企業向けの「Enterprise Edition」といったように異なるパッケージが並行して提供される場合がある。それぞれの顧客のニーズや用途の違いに応じて、機能や価格、販売方式、サポート方式などが異なっている。

データベースなどを用いて各顧客の詳細な属性情報や購買履歴、問い合わせやクレームの内容などを記録・管理し、問い合わせに速やかに対応したり、買い替えやメンテナンスなどの提案を行なったり、その顧客に合った新製品を紹介したりといった活動が中心となる。

顧客と良好な関係を継続することで、次回の買い替えや追加購入、別の商品の購入などで他社よりも優先的に検討してもらうことが期待でき、また、顧客の周囲の人々や各種の調査などで自社(製品)の評価やイメージの向上を図ることができる。

広義には、見込み顧客に対する売り込み(セールス)活動の管理や支援も含まれる。個々の見込み顧客ごとに接触履歴(担当者との面会履歴、ダイレクトメール等の送付状況、セミナーなどの参加履歴など)や案件や商談の進捗などを記録・管理し、組織的・効率的に成約に向けた販売活動を展開する。そのための情報システムは「SFA」(Sales Force Automation/営業支援システム)とも呼ばれる。

顧客関係を展開するためのシステムは単体のパッケージソフトやネットサービスなどの形で提供されることもあるが、ERPパッケージの一部(SAP CRMやOracle CRM、Microsoft Dynamics 365 CRMなど)やSFAシステムの一部(Salesforce CRMなど)として提供されるものの市場シェアが高い。SugarCRMのようにオープンソースとして無償で利用可能なソフトウェアもある。

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

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

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

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

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

ITの分野では、コンピュータなどの機器やソフトウェア、システムなどの処理性能や実行速度、通信回線・ネットワークなどの伝送速度・回線容量などのことをパフォーマンスという。「コストパフォーマンス」という場合はコスト一単位あたりの性能である価格性能比(費用対効果)を意味する。

一般の外来語としては「歌や踊り、劇などの上演や披露」「スポーツ選手の調子や能力、試合の出来や成績」「注目を集めるための派手な行動」「仕事などの能率、能力」といった意味で用いられることが多い。金融分野では金融商品の運用成績を指す。

委託側は専門的な業務や周辺的な業務などをアウトソーシングすることで、自らの本業や強みを持つ業務や事業、部門に資源を集中できる。また、業務量の変動が大きい場合、仕事があるときだけ必要に応じて外部に発注することで、ピーク時に合わせて設備や人員を固定的に保有する必要がなくなる。

受託側は様々な企業から同種の業務のアウトソーシングを請け負うことで規模を拡大して固定費を節減でき、各企業が内部で行うよりも低コストで業務を遂行することができる。一企業では大きな繁閑差がある場合も、多数の企業から同じ業務を請け負うことで平準化することができる。

特に、コストの低さなどを見込んで海外の事業者へ業務を委託することを「オフショアアウトソーシング」(offshore outsourcing)あるいは「オフショアリング」(offshoring)、近隣国や国内の別の地方の事業者へ委託することを「ニアショアアウトソーシング」(nearshore outsourcing)あるいは「ニアショアリング」(nearshoring)という。一方、アウトソーシングと対比する文脈で、社内で行う業務や社内で抱える人員や部門などを指す場合は「インハウス」(inhouse)という。

従来、ソフトウェアを使用するには利用者がパッケージなどを入手して手元のコンピュータにプログラムを複製、導入し、これを起動して操作する方式が一般的だった。SaaSではソフトウェアの中核部分は事業者の運用するサーバコンピュータ上で実行され、利用者はネットワークを通じてその機能を遠隔から利用する。

利用者側には表示・操作(ユーザーインターフェース)のために最低限必要な機能のみを実装した簡易なクライアントソフトが提供される。専用のクライアントを導入する場合もあるが、一般的には全体をWebアプリケーションとして設計し、利用者はWebブラウザを通じてWebページとして実装されたクライアントを都度ダウンロードして起動する形を取ることが多い。

SaaS方式のソフトウェア提供は2000年代中頃からSFA(営業支援システム)やグループウェアなど業務用ソフトウェアを中心に広まり始め、2010年代以降はERPなどの大規模システム、あるいはオフィスソフト、ゲーム、メッセージソフト(Webメールなど)といった個人向けを含む様々な種類のソフトウェアで一般的になっている。

利用者側の特徴

利用者はサービスへ登録・加入するだけで、ソフトウェアの入手や導入を行わなくてもすぐに使い始めることができる。データも原則としてサーバ側に保管されるため、ソフトウェアやデータの入ったコンピュータを持ち歩かなくても、移動先などで普段とは別の端末からログインして前回の作業の続きを行うことができる。

料金もパッケージソフトのように最初に一度だけ所定の金額を支払う「買い切り」型ではなく、契約期間に基づく月額課金や、何らかの使用実績に応じた従量課金が一般的となっている。登録や利用は原則無料で高度な機能や容量などに課金する方式や、広告を表示するなどして完全に無償で提供されるサービスもある。

ただし、利用のためにはインターネット環境が必須で、回線状況によっては操作に対する応答に時間がかかる場合もある。また、サービスを脱退したりサービスが終了してしまうとソフトウェアを使用できなくなり、サーバ側に保存したデータにもアクセスできなくなる。データについては特定の形式でまとめて利用者側にダウンロードできる機能が提供されている場合もある。

事業者側の特徴

提供者側から見ると、システムの中核部分はサーバ側で実行され、Webブラウザなどをクライアントとするため、機種やオペレーティングシステム(OS)ごとに個別にソフトウェアを開発・提供する場合に比べ様々な環境に対応しやすい。

また、サーバ側でソフトウェアを常に最新の状態に保つことができ、機能追加や不具合の修正などを利用者側へ迅速に反映できる。機能を細かく分けて利用者が自分に必要なものだけを選んで契約するといった柔軟な提供方式にも対応しやすい。

ただし、処理の多くをサーバ側で行う必要があるため、利用者数や利用頻度などに応じてサーバの台数や性能、データ保管容量などを適切に用意し、必要に応じて増強しなければならない。インターネットを通じてサービスを提供するため回線容量なども提供規模に応じて必要で、単にソフトウェアを販売するより事業者側の投資やコストは重くなりがちである。

PaaS/IaaSとの違い

インターネットを通じて様々な資源や機能をサービスとして遠隔の顧客へ提供する事業形態はSaaS以外にも存在し、総称して「XaaS」(X as a Service：サービスとしての○○)と呼ぶ。

このうち、導入・設定済みのOSやサーバソフト、言語処理系など、アプリケーション実行環境一式(プラットフォーム)をサービスとして遠隔から自由に利用できるようにしたものを「PaaS」(Platform as a Service：サービスとしてのプラットフォーム)という。

また、情報システムの稼動に必要な機材や回線などのIT基盤(インフラ)をサービスとして提供するものを「IaaS」(Infrastructure as a Service：サービスとしてのインフラ)という。これらは主に企業などの情報システム部門やネットサービス事業者などが自らのアプリケーションの実行環境として使用するために提供される。

通常の場合、企業などで業務用システムなどを運用するには、コンピュータなどの機器にオペレーティングシステム(OS)、プログラミング言語処理系、ライブラリ、ミドルウェア、フレームワークなどを導入・設定し、実行環境を構築しなければならない。

PaaSは専門の事業者がデータセンターに設置したサーバにこのようなソフトウェア環境を構築したもので、これをインターネットを経由して契約者に貸し出して利用させる。顧客は実行したいアプリケーションを持ち込んで実行するだけですぐにシステムを運用でき、メンテナンスや障害対応なども事業者に任せることができる。

PaaSでは利用者が操作・設定可能なのはOSよりも上の階層であり、ハードウェアや仮想マシンの動作に直に介入することはできないが、逆に、これらの設定や運用などを自ら行う必要がなく、事業者側にすべて任せることができると捉えることもできる。

提供されるコンピュータは仮想化されており、利用者が必要に応じて性能などを指定することができる場合が多い。設備が固定されている自社運用(オンプレミス)とは異なり、突発的な負荷の増大に合わせて一時的に性能や容量を割り当てたり、負荷に応じて柔軟に性能の伸縮や契約の切り替えを行える点が大きな特徴である。

料金は契約期間に応じた月額基本料金にシステムの使用量(CPU実行時間や外部への送信データ量など)に応じた従量課金を加えた課金体系になっていることが多い。契約者は固定的に人員や設備を抱えることなく必要な分だけサービス料を支払って利用する形となる。

よく知られるPaaSとしては、米アマゾンドットコム(Amazon.com)がAmazon Web Services(AWS)の一部として提供している「Amazon Lambda」や「Elastic Beanstalk」などのサービス、米グーグル(Google)社がGoogle Cloud Platform(GCP)の一部として提供している「Google App Engine」(GAE)、米マイクロソフト(Microsoft)社がMicrosoft Azureの一部として提供している「Azure Cloud Services」、米セーフルフォース・ドットコム(Salesforce.com)社の「Force.com」や「Heroku」、などがよく知られる。

一方、仮想化されたハードウェア環境を遠隔からサービスとして操作・利用できるようにしたものを「IaaS」(Infrastructure as a Service)、具体的な特定のアプリケーションをインターネットを通じてサービスとして利用できるようにしたものを「SaaS」(Software as a Service)という。

専門の事業者がデータセンター施設に設置・運用しているコンピュータやネットワーク環境などを契約者が借り受け、遠隔から操作して自分の必要なソフトウェアを組み込んで稼働させることができる。事業者のコンピュータなどを借り受けて使用するレンタルサーバやホスティングサービスは従来からあり、IaaSもその延長にあるが、より柔軟で包括的なサービスを指すことが多い。

IaaSの場合、一台単位で物理的に固定されたコンピュータ自体を貸し出すのではなく、物理コンピュータ上に仮想化技術で作り出された特定の仕様を持つ仮想サーバ(サーバインスタンス)を単位に契約が行われることが多い。これにより、メンテナンスや障害発生時などに速やかに別の機材に移転して稼働を続行したり、処理の負荷の増減に合わせて柔軟に資源の追加・削減(スケーリング)ができるといった利点がある。

料金は月額固定制の場合もあるが、基本料金に加えて一ヶ月の資源の使用量(外部へのデータ送信量など)の実績に応じた従量制を取るサービスが多い。企業などでシステムを運用する場合、自社内設置(オンプレミス)だと固定的に設備(その多くは税法上の資産)や人員を抱えることになるが、金額が同水準でもサービス料の形で支払う方が財務・会計の都合上好ましい場合も多い。

IaaSで提供されるのはコンピュータのハードウェア環境であるため、使用するオペレーティングシステム(OS)やミドルウェア、アプリケーションソフトなどは契約者側で用意して導入・設定する必要がある。OSなど特定の環境がある程度導入済みのコンピュータをサービスとして提供する形態は「PaaS」(Platform as a Service)という。

代表的なサービスとして、米アマゾンドットコム(Amazon.com)がAmazon Web Services(AWS)の一部として提供している「Amazon Elastic Compute Cloud」(Amazon EC2)や、米グーグル(Google)社がGoogle Cloud Platform(GCP)の一部として提供している「Google Compute Engine」(GCE)、米マイクロソフト(Microsoft)社がMicrosoft Azureの一部として提供している「Azure IaaS」などがよく知られる。

機材やソフトウェア、処理性能、記憶領域、ファイル、データなど何らかの計算資源をインターネットなどの通信ネットワークを通じて提供し、利用者がいつでもどこからでも必要なときに必要なだけ資源にアクセスできるようなサービスの総称として用いられる。

どのような資源をサービス化したものかによって大きく3つに分類される。「SaaS」(Software as a Service)あるいは「ASPサービス」(Application Service Provider)は特定の機能を提供するアプリケーションソフトをサービス化したもので、利用者はWebブラウザなどを通じて事業者のサーバにアクセスし、その機能やデータを利用する。

「PaaS」(Platform as a Service)はソフトウェアの実行基盤であるオペレーティングシステム(OS)や言語処理系が導入済みのサーバ環境をサービス化したもので、契約者は自らが必要なソフトウェアを導入し、ネットワークを通じてその機能を利用する。

「IaaS」(Infrastructure as a Service)または「HaaS」(Hardware as a Service)は情報システムの運用基盤となるコンピュータ自体や通信回線などをサービス化したもので、契約者はOSやアプリケーションなど必要なソフトウェアやデータを導入して運用する。

いずれの場合も利用者はパソコンやスマートフォンなど最低限の操作環境(クライアント)さえあれば基本的な機能を利用することができ、ハードウェアやソフトウェア、データなどの資源を固定的に所有したり持ち歩いたりする必要がない。利用者に属するデータや情報も事業者側のコンピュータに保存されるため、使用環境(場所や端末など)が変わっても自らの資格情報(アカウント)を入力することで同じように利用できる。

かかるコストも従来のような個々の資産の購入代金ではなく、利用期間や使用量に応じた都度課金や月額課金などサービス利用料の形となる。個人向けのサービスでは基本的な機能が無料で提供され、追加の機能や記憶容量などにのみ課金される方式も多い。

システムの開発や購入、導入などにかかるイニシャルコスト(初期費用)と、利用期間中の運用や保守、管理などにかかるランニングコスト、利用終了時の撤去や廃棄、後継システムへ引き継ぐための準備などにかかるコストなど、システムに関連する全期間にまたがる費用の総体を意味する。

従来、企業などが導入する製品の選定にあたっては、その購入価格や開発費などのイニシャルコストが重視されてきたが、初期費用が低廉でも運用や管理、廃棄に高額の費用がかかっては全体としては高コストになってしまうため、総所有費用の算出や見積もりを行なって比較するべきであるとする考え方が普及した。

見えにくいコスト

イニシャルコストは製品価格、開発委託料のような「見えやすい」コストが多い一方、ランニングコストには「見えにくい」コストが多くある。

保守契約の費用や消耗品の価格などは見えやすいが、不具合や脆弱性が多い低品質の製品だと、システム障害やサイバー攻撃などによる停止が頻発し、その対応コストに加えて業務が停止することによる逸失利益もコストとなる。

また、使いにくいシステム、分かりにくいシステムでは、利用者の教育・訓練コストやシステム部門のサポート対応コスト、誤操作による生産性の低下などのコスト増を招くことになる。これらは調達コストの安易な引き下げによって生じることも多いため、導入製品の選定や開発にあたっては運用時のコストを十分に見極めて総所有費用を最適化する視点が欠かせないとされる。

具体的な内容は対象の種類によって異なり、記憶装置であれば記録できる最大データ量や管理できる最大要素数、通信回線であれば最高通信速度、マイクロプロセッサであれば単位時間あたりの最大命令実行回数、Webサイトであれば最大同時接続数などのことを指す。

キャパシティプランニング (capacity plannning/キャパプラ)

情報システムを開発・改修する際に、機材の台数や処理性能、記憶容量、回線容量などの計画を立てることを「キャパシティプランニング」という。俗に「キャパプラ」と略されることもある。

利用者数や利用頻度、処理の内容、扱うデータの種類や容量、必要とされる信頼性、予算などからシステムのハードウェアやネットワークの構成を検討し、機材の種類や性能、台数、配置などの具体的な計画を作成する。

具体的な内容は対象の種類によって異なり、記憶装置であれば記録できる最大データ量や管理できる最大要素数、通信回線であれば最高通信速度、マイクロプロセッサであれば単位時間あたりの最大命令実行回数、Webサイトであれば最大同時接続数などのことを指す。

キャパシティプランニング (capacity plannning/キャパプラ)

情報システムを開発・改修する際に、機材の台数や処理性能、記憶容量、回線容量などの計画を立てることを「キャパシティプランニング」という。俗に「キャパプラ」と略されることもある。

利用者数や利用頻度、処理の内容、扱うデータの種類や容量、必要とされる信頼性、予算などからシステムのハードウェアやネットワークの構成を検討し、機材の種類や性能、台数、配置などの具体的な計画を作成する。

もとは生物学や物理学などで、ある現象や反応などが誘起される最低限の量などを指す概念だが、IT分野では「警告を表示する残り容量の閾値を10%に設定する」といったように人為的に設定された境界値などを指す場合もある。

コンピュータはすべての情報を「0」と「1」を組み合わせた2進数で表すが、内部のデジタル回路では電圧の高低を0と1に対応付けて表す。電圧の高低の判断の境目となる値が閾値で、明確に区別できるように「1.5V以下は0、3.5V以上は1」といったように中間に幅を持たせることが多い。

なお、「閾値」の「閾」の文字は音読みが「イキ」、訓読みが「しきい」とされ、心理学や生理学などでは「いきち」、物理学や工学などでは「しきいち」と読むことが多いようである。工学系では「しきい値」というひらがな表記が定着している。

ある単位時間のうち、オペレーティングシステム(OS)やアプリケーションソフトが何らかの処理を実行している時間の割合を意味し、実行状態にある個々のプログラム(プロセス)について言う場合と、すべてのプログラムの使用率の合計を指す場合がある。

使用率が0%の場合は何も実行されず待機状態となっており、100%の場合はCPUがフル稼働して何らかの処理を行い続けていることを意味する。

100%になったまま下がらない場合は、処理能力を超えた膨大な処理要求が溜まっているか、脱出できない無限ループが実行されているなど、不正常な状態に陥っている可能性があり、最悪の場合は利用者の操作や外部からの呼びかけに応答しなくなることもある。

ただし、近年のCPUとOSのほとんどはプリエンプティブマルチタスクを採用しているため、見かけ上100%になっても強制的にプログラムの実行を中断して他に切り替えることができ、応答に反応しなくなる事態は稀である。また、サーバ向けのソフトウェアなどでは使用率の上限を設定してそれ以上は使わせないようにする機能を持ったものもある。

コンピュータの処理装置(CPU)がプログラムを実行し、データを処理するには、プログラムを構成する命令コードや処理対象のデータをメインメモリ上に記録しておく必要がある。そのために現在実行状態にあるプログラムが占有しているメモリの容量をメモリ使用率という。

コンピュータに搭載されているメモリ装置の合計容量を超えてプログラムやデータを置くことはできないが、現代のコンピュータやオペレーティングシステム(OS)の多くは「仮想メモリ」方式を採用しており、ストレージ容量の一部も一定の制約のもと、メモリ装置の延長として利用できるようになっている。

このため、OSがメモリ容量として認識するデータ量は物理的なメモリ装置の容量より多くなることがあり、その分多くのプログラムやデータを記録することができる。ただし、ストレージ上の領域に実際にアクセスするためには物理メモリ装置との間で内容の交換(スワップあるいはページング)を行う必要があるため、容量いっぱいにプログラムを配置すると頻繁に入れ替え処理が起こり極端に性能が低下することがある(スラッシング現象)。

メモリはOSによって管理されるため、OSには現在のメモリ使用率を表示する機能が用意されていることが多い。Windowsでは「Windowsタスクマネージャ」などで、macOSでは「アクティビティモニタ」(Activity Monitor)などで、LinuxなどのUNIX系OSでは「freeコマンド」「topコマンド」「psコマンド」などでメモリ使用率や各プログラムの占有容量を知ることができる。

コンピュータではソフトウェアの動作に伴ってストレージへのデータの読み込みや書き込みが行われるが、ある時間幅のうちにストレージ装置が駆動して読み書き動作を行っている時間の割合をディスク使用率と呼び、パーセンテージで表す。

Windowsではタスクマネージャーでディスク使用率の現在値や直近の変遷を確かめることができる。ディスク使用率が継続的に100%になる場合は、ソフトウェア側からのアクセス要求に対して装置側の処理がまったく追いついておらず、ソフトウェア側の処理が停滞して待たされる状態に陥っている可能性が高い。

特に、仮想メモリのスワップ処理が原因で100%になっている場合は、ソフトウェアが特にファイルの処理などをしなくても継続的にディスクアクセスが発生し続けるため、いくつかのソフトウェアを終了して占有していたメモリを解放するなどの措置を取らなければいつまでも使用率100%状態が継続してしまう。

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

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

ある時点の正常な状態のデータやプログラム、設定などを複製してまとめて保管しておき、障害などが発生した時にこれをシステムに書き戻してその時点の状態に戻す処理をロールバックという。

トランザクション処理のロールバック

特にデータベースシステムのトランザクション処理でよく用いられる概念である。トランザクション開始前の状態を保存しておき、コミットする前に途中で中断された場合に完了済みの処理をすべてキャンセルし、開始前のデータを書き戻して復旧する。トランザクションは途中で終了すると結果に矛盾が生じることがあるため、このような制御が行われる。

一方、障害発生時にすでにコミットされたトランザクションの場合には、ある時点(チェックポイント)で複製したデータを書き戻し、これにトランザクションログに記録された処理を適用していき、コミット時の状態に戻す。この復帰方式を「ロールフォワード」(roll forward)という。

冗長化されたシステムの切り戻し

二重化やクラスタ構成により冗長化されたシステムで、障害により停止した系を修理・交換し、他の系から処理を引き継いで稼働を再開することを切り戻しという。

冗長化されたシステムで稼働系に障害が発生すると、これを切り離して残りの稼働系で処理を続行(アクティブ/アクティブ構成の場合)したり、即座に待機系が稼働を開始して処理を引き継ぐ(アクティブ/パッシブ構成の場合)「フェイルオーバー」(failover)が行われ、システム全体が停止することを防ぐ。

その後、障害から復旧したシステムを稼働系に戻し、元通りに処理を再開する作業のことを切り戻しという。フェイルオーバーの逆であるため「フェイルバック」(failback)とも呼ばれる。

システム移行などの切り戻し

古いシステムから新しいシステムへの移行などで、切り替え作業中に重大なトラブルが発生して新しい系の稼働が見込めなくなったとき、切り替えを中止して元の状態に戻すことを切り戻しという。

切り戻し後は、移行を妨げる不具合が解消され再び切り替えの準備が整うまで旧システムでの運用が継続される。この状態は新システムで期待された機能や性能を制限していると見ることもできるため、一種の「フォールバック」(fallback：縮退運転)であるとみなされる場合もある。

システム開発における要求分析や要件定義などの工程で主に検討されるのはシステムの機能や動作、振る舞いを定義する機能要件で、システムが何を扱うのか、何を行うのか、利用者や外部システムに対してどのように振る舞うのかといったことを定める。

しかし、機能要件だけでは求めるシステムの定義としては不完全であり、システムに求められる特性や動作の前提条件などを非機能要件として定義する。例えば、可用性について何の要件も定めなければ、要求された機能は確かに動作するが装置の一部が故障すると即座にシステム全体が停止してしまう脆弱なシステムが納品される事態が起こりうる。

情報処理推進機構(IPA)の発行している「非機能要求グレード」では、大項目として「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つを定義し、それぞれについてさらに詳細な項目とレベルを定義している。

また、日本情報システム・ユーザー協会(JUAS)が発行した「非機能要求仕様定義ガイドライン」では、非機能要件を「機能性」「信頼性」「使用性」(操作性や習得の容易さなど)「効率性」(計算資源・時間を効率よく使っているか)「保守性」「移植性」「障害抑制性」(障害の発生・拡大のしにくさなど)「効果性」(投資対効果など)「運用性」「技術要件」(システム構成や開発手法など)の10種類に分類して定義している。

システム開発の最終段階で行われるテストの一つで、システムテストなどが終わり導入可能となった新システムを旧システムから切り替える前に行われる。テストに先立って移行計画の策定、移行ツールなどの開発や準備が必要となる。

移行リハーサルでは移行手順の確認、課題や問題点の発見、移行ツールの稼働確認、データの複製・移転の試行などが行われる。問題が発見された場合は移行計画の見直しやツールの修正などが行われ、正常に移行が完了できることが確認できるまでテストが繰り返される。

システム移行は深夜や連休など業務でシステムを利用しない時間を利用して行うことが多いため、業務が再開されるまでの制限時間に完了するかの確認や、移行に失敗したときの旧環境への切り戻し手順の確認や試行も重要となる。

一般的には業務上そのシステムを実際に利用することになる発注元の最終利用者(業務担当者)が行なうもので、実際のデータや業務手順に沿ってテスト計画を組み立てて実施する。

納品を受諾するかどうかを判定する受け入れテスト(承認テスト/検収テスト)を兼ねる場合や、ある程度の期間を費やし、担当者がシステムの操作に習熟する研修を兼ねる場合もある。

運用テストでは、仕様書通りの機能が実装されていることを確認するだけではなく、操作に対する応答時間や処理性能を計測したり、高負荷時の反応や耐久性を調べたり、入力ミスや誤操作、ハードウェア障害などを故意に発生させてエラー処理や復旧などの手順を確認したりすることもある。

システムが発注した仕様を満たしているか、マニュアルなどの文書に誤りが無いか、障害発生時など運用上の様々な状況に対して想定通りに対処できるかなどを利用者側がチェックする。実務を想定して実際に使用してみる実地試験(ベータテスト)を行うこともある。

開発側の瑕疵による不具合などが見つかった場合は、工程を差し戻して修正などを行い、改めて受入れテストを行う。発注側の想定漏れなどで導入できないことが発覚し、改修の必要が生じた場合は追加作業の発注となることが多い。

第三者によるUAT

受入れテストの実施は受け入れ側の情報システム部門やその要員によって実施されるのが一般的だが、開発側との専門知識の格差やテストの実施に必要な人員・コストなどの問題、情報システムのテストに関する経験や知見の不足などから十分なテストの実施が困難なことがある。

そのような場合に、開発を請け負った事業者とは別の外部の事業者からテストに関する支援を受けたり、テスト自体を一部またはすべて委託する場合もある。システム開発関連企業の中には受入れテストを請け負うサービスメニューを用意している事業者もある。

ベンダーテスト

官公庁などの公的機関向けに開発したシステムに対して行う、品質を保証するためのテストを「ベンダーテスト」という。システムの開発側(ベンダー)で行うテストという意味。

テスト内容とテスト結果を合わせて報告することで、要求された仕様を満たしていることを保証するために行う。典型的には、単体テスト(ユニットテスト)、システムテスト、統合テスト、負荷テストなどの工程からなる。

一般の外来語としては、新しい作品や製品などを公開、発表、発売することをリリースということが多い。公開・発売された新しい製品や作品自体のことを指す場合もある。音楽作品や映像作品、ゲーム作品の発売などでよく用いられる言い回しである。

「ニュースリリース」「プレスリリース」などのように、新しい情報や宣伝を告知・発表すること(および、発表文そのもの)をリリースということもある。球技でボールを手から離すことや、釣りで魚をすぐに水に戻すこと(キャッチアンドリリース)など、「放す」という意味で用いられることもある。

ソフトウェアのリリース

ITの分野では、一般の外来語と同じように新製品の発売などの意味で用いられるほか、ソフトウェア開発などで新バージョンの公開や頒布、提供開始などをリリースということが多い。

ソフトウェアを提供可能なパッケージなどにまとめ、利用者が導入・使用できるように提供することを指す。一方、開発環境上で実行ファイルなどを作成して導入可能なパッケージを作成する工程は「ビルド」(build)、提供されたソフトウェアを実行環境上に展開して利用に供する工程は「デプロイ」(deploy)という。

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

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

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

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

情報セキュリティ上のインシデント

情報セキュリティの分野では、情報管理やシステム運用に関して保安上の脅威となる人為的な事象を「セキュリティインシデント」(security incident)と呼び、これを略して単にインシデントと呼ぶことが多い。

当該組織が運用するコンピュータシステムや管理下にある情報の機密性、完全性、可用性を脅かす(危険性のある)何らかの人為的な事象を指し、マルウェア感染や不正アクセス、パスワード漏洩、Webサイト改竄、機密情報流出、フィッシング、サービス拒否攻撃(DoS攻撃)などが含まれる。

インシデントが発生した際に行われる被害把握や原因特定、正常な状態への復旧、利害関係者への報告や連絡といった対応業務を「インシデントレスポンス」(incident response)という。これを行うために組織内に設置された部署を「CSIRT」(Computer Security Incident Response Team/シーサート)という。

ITサービスにおけるインシデント

企業の情報システム運用などの分野では、利用者がITシステムによって本来できるはずの業務、行為を正常に遂行できない状態や事象のことをインシデントという。「できない状態」そのものを指す概念で、それが機器やソフトウェアの不具合や障害、故障に由来する場合、不具合等は「インシデントの原因」であると考える。

例えば、利用者から「コンピュータを使おうとしたら画面が真っ暗で表示されない」という報告を受けた場合、「ディスプレイ装置が壊れていた」というハードウェア障害が原因の場合もあるが、「ディスプレイの電源コンセントが外れていた(ことに利用者が気付かなかった)」といった原因によって起こっている場合もある。

このため、インシデントはそれ自体を故障や障害とは区別して登録・管理する必要があり、ITシステムにおけるインシデントを情報システム部門が記録して対応する業務を「インシデント管理」という。

アクシデントとの違い

英語の “accident” (アクシデント)は事故、災難、偶然、運、巡り合わせ、偶発的な出来事、予期せぬ失敗といった意味の英単語で、故意や必然ではなく偶然に起こった悪い出来事、あるいは予期せず不意に生じた事態という意味合いがある。

通常、アクシデントは何らかの被害や損害、不利益が生じてしまった事故や事件そのものを指す一方、インシデントはその一歩手前の予兆や異変、逸脱や違反行為、危機的な状況や現象などのことを指すという違いがある。

他分野におけるインシデント

IT分野以外でも、重大な事故に繋がりかねない、いわゆる「ヒヤリハット」事象や逸脱事例などを指してインシデントという用語を用いることがある。特に、医療など事故が人命に直結する分野でインシデントの概念を用いることが多い。日本では航空法や鉄道事業法において、事故に繋がりかねない危険な事象の報告義務などを定めており、これを「重大インシデント」という。

上位者への引き継ぎ

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

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

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

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

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

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

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

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

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

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

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

人工物について信頼性という場合、定められた条件(製造元の指定する定格値など)下で一定の期間(耐用年数など)、期待される機能を提供し続けることができる性質を表す。

修理不能な製品の場合は故障や破損のしにくさがそのまま信頼性とみなされ、平均故障率(FIT：Failure In Time)や平均故障時間(MTTF：Mean Time To Failure)などの指標が用いられる。修理可能な製品では平均故障間隔(MTBF：Mean Time Between Failures)などで表され、保守性(maintainability/serviceability)を含んだ概念となる。

信頼性にいくつかの性質を加えて、システムが期待された機能・性能を安定して発揮できるか否かを検証するための評価項目として用いる場合がある。よく知られるのは信頼性に可用性(Availability)と保守性(Serviceability)を加えた「RAS」で、これに完全性(Integrity)と機密性(Security)を加えたものは「RASIS」という。

機器やシステムなどの場合には、一定の水準の機能や性能を保つ上で、日常的にどのくらいの作業が必要になるかといった点や、一部が老朽化したり故障した際に、いかに容易に発見や修理、交換を行えるかといった点が中心となる。

ソフトウェアの場合には、誤りや不具合の発見・修正のしやすさや、事前に予定されていなかった仕様変更や機能追加などの行いやすさ、ソースコードの読みやすさといった点が中心となる。

ある期間における(あるいは複数の同じ機器における)機器の稼働時間の和を、その間に発生した故障の回数で除して求められる。例えば、あるシステムの運用状況を1年間調べた結果、総稼働時間が8000時間で故障による停止が4回起こっていた場合、MTBFは8000/4で2000時間となる。

一般にMTBFが大きいほど故障から次の故障までの間隔が長く、長期間安定的に利用できる。MTBFは何度も繰り返し修理して使用する前提の指標であり、故障、破損したら修理できず破棄・交換される機器の場合には、同様の指標のことを「MTTF」(Mean Time To Failure：平均故障時間)と呼ぶ。

機器やシステムの種類や用途によっては、始動してから停止せず稼働させ続ける連続動作時のMTBFと、始動・停止を繰り返す間欠動作時のMTBFを別に求めて表示することもある。多くの機器では連続動作の方が使用環境としては過酷なためMTBFが短くなるが、始動時や停止時に大きな負荷のかかる機器(蛍光灯やハードディスクなど)では間欠動作時の方がMTBFが短くなることもある。

MTBFが数か月から数年以上に及ぶ機器などの場合、実際にそれより長い期間、同じ機器を試験し続けることは現実的でないため、大量の(新品の)機器を用意して並列に試験し、稼働時間と故障回数を合算して算出することが多い。この場合、いずれの機器も新品状態から短い期間しか観察されないため、長年使用し続けた時に生じる摩耗や劣化による故障を正しく反映しない場合もある。

MTTR・稼働率との関係

これに対し、一回の故障・修理にかかる平均時間のことは「MTTR」(Mean Time To Repair)という。MTBFを、MTBFとMTTRの和で除したものは全時間に対する稼働時間の割合、すなわち稼働率(operating ratio)となる。

例えば、ある装置のMTBFが999時間、MTTRが1時間であれば「平均999時間稼働するごとにトラブルで停止し、平均1時間の復旧時間を挟んで稼働を再開する」ことを意味するため、稼働率は999/(999+1)で0.999(99.9%)となる。

ある期間のうち、故障などで停止してから稼働を再開するまでにかかった時間(ダウンタイム)の和を停止回数で除して求められる。例えば、あるシステムが調査期間中に10回停止し、停止時間の合計が100時間だった場合、MTTRは100/10で10時間となる。

MTTRが小さいほど復旧までの時間が短いことを表し、機器やシステム自体の保守性(serviceability)や運用組織の即応性や熟練度が高いことを意味する。MTTRの算出には稼働時間の長さは考慮されないため、対象の信頼性の高さ、堅牢性などは別の指標で測る必要がある。

MTBF・稼働率との関係

これに対し、故障(後の再始動)から次の故障までの平均稼働時間を「MTBF」(Mean Time Between Failure)という。MTBFを、MTBFとMTTRの和で除したものは全時間に対する稼働時間の割合、すなわち稼働率(operating ratio)となる。

例えば、ある装置のMTBFが999時間、MTTRが1時間であれば「平均999時間稼働するごとにトラブルで停止し、平均1時間の復旧時間を挟んで稼働を再開する」ことを意味するため、稼働率は999/(999+1)で0.999(99.9%)となる。

事業継続計画を策定するにはまず、大災害や大事故、疫病、テロ、犯罪被害、社会的混乱など、自社の業務継続に致命的な影響を及ぼす緊急事態を洗い出し、それぞれについて具体的な影響を分析する。

そして、中核事業や中枢的な業務を継続あるいは早期に復旧するために優先的に維持・復旧すべき拠点や機能を定め、目標復旧時間(RTO：)や最低限のサービスレベルを定める。これに基づき各人員や部署が取るべき行動をマニュアル化したり、代替設備などを用意する。

作成された事業継続計画は危機管理部門だけでなく全社的に周知・共有し、定期的にテストや訓練を行ない、いざという時に滞りなく実践できるようにしておくことが必要となる。このような事業継続計画策定や改訂、日常からの備えなどを含む活動全体を「BCM」(Business Continuity Management：事業継続マネジメント)と呼ぶこともある。

ストレージ(外部記憶装置)について言う場合は、媒体の破損などでデータが正常に読み出せなくなった機器から可能な限りデータを取り出して保全したり、故障した装置を新しいものと交換して残りの装置からデータを復元する作業(RAID等の場合)などを表す。

ソフトウェアについて言う場合は、プログラムや設定の不具合で正常に動作しなくなったオペレーティングシステム(OS)などを消去し、再び導入(インストール)し直して初期状態に戻すことなどを指す。この場合、導入済みのソフトウェアや保存された設定情報、データなどは消去されるため、必要であれば利用者が別の装置への保全などを行わなければならない。

事業継承計画(BCP：Business Continuity Plan)などを策定する際に定められるもので、業務を停止させる事態(インシデント)の発生から、目標復旧レベル(RLO：Recovery Level Objective)で定められた重要な業務を再開できるようになるまでの目標時間を意味する。

RTOは対象事業の重要性やRLOの水準によって異なり、また、短ければ短いほど対策にかかるコストは高騰する。内閣府の事業継続ガイドラインでは「影響度評価の結果や、取引先や行政との関係、社会的使命等を踏まえ、企業にとってその重要業務の停止が許されると考える目標時間」と定義している。

情報システムの場合、データのバックアップなどがどの時点まで遡ることを許容するかを「RPO」(Recovery Point Objective：目標復旧時点)として設定することもある。RPOが1日ならば、障害でデータが失われた場合にバックアップが前日まで遡ることを許容する。

情報システムでストレージ(外部記憶装置)に保存されたデータは、災害や機器の故障、ソフトウェアの誤動作、操作ミスなどによって失われることがある。これに備えてデータを他の装置や施設へ複製することをデータバックアップという。

RPOはデータをバックアップから復元したときに、最も古いデータがどの程度古いかを表した値で、例えばRPOが7日間に設定されている場合には、どのバックアップデータも常に現在から7日前よりは新しい状態が維持されるように複製が行われる。

RPOを小さな値に設定すれば、最後の複製から現在までの時間が短くなり失われるデータは少なくて済むが、その分バックアップ処理にかかる負荷やコストは大きくなる。データの種類によって、重要性とコストを比較してそれぞれに適切なRPOを設定することが重要である。

一方、障害発生時点からどの程度の時間でデータを復旧できるようにするかを表す目標値のことは「RTO」(Recovery Time Objective：目標復旧時間)という。

事業継承計画(BCP：Business Continuity Plan)などを策定する際に定められるもので、業務を停止させる事態(インシデント)の発生から、目標復旧時間(RTO：Recovery Time Objective)で定められた期限までに再開させる重要な業務やその復旧水準を意味する。

RLOは対象事業の重要性やRTOの長さによって異なり、また、高ければ高いほど対策にかかるコストは高騰する。経済産業省のITサービス継続ガイドラインでは「事故後、業務をどのレベルまで復旧させるか、あるいは、どのレベルで継続させるかの指標をいう」と定義している。

システムを構成する機材が故障などで停止する場合に備え、同じ機材を複数用意しておく手法を「冗長化」あるいは「多重化」(2つの場合は二重化)という。平時に使用する機材を「本番系」「稼動系」「主系」、緊急時に使用する機材を「待機系」「予備系」「副系」「従系」という。

コールドスタンバイでは、同じ構成のシステムを複数用意しておき、通常時に本番系を稼働させておくが、待機系は起動せず停止した状態で保管されている。普段は他の用途で使用している機材を待機系とすることもある。

障害発生時には待機系を起動し、必要な場合は設定作業や移行作業などを行い本番系からの切り替えを行う。数分から数時間で切り替えが完了する場合もあるが、システムの種類や構成によっては数日から数週間を要することもある。障害時に処理途上だったデータなども引き継がれないことが多い。

これに対し、待機系の機器本体やオペレーティングシステム(OS)などは起動状態にしておくが、本番系と同期などは取らず、障害時にシステムを本格稼働させて切り替えを行う方式を「ウォームスタンバイ」(warm standby)、待機系を常に稼動状態にして本番系と同期を取り、障害時に即座に引き継ぐ方式を「ホットスタンバイ」(hot standby)という。コールドスタンバイはこれらの中で最も運用が容易で低コストだが、障害時の停止時間や損失は最も大きい。

システムを構成する機材が故障などで停止する場合に備え、同じ機材を複数用意しておく手法を「冗長化」あるいは「多重化」(2つの場合は二重化)という。平時に使用する機材を「本番系」「稼動系」「主系」、緊急時に使用する機材を「待機系」「予備系」「副系」「従系」という。

ホットスタンバイでは同じ構成のシステムを複数用意しておき、通常時に稼働している本番系に対して待機系を同期して常に同じ状態で稼働させ続けておく。本番系に障害が発生して停止すると、即座に待機系に切り替わり、実行途上だった処理なども引き継いで続行される。システムの種類にもよるが、切り替えに要する時間は数ミリ秒から数分程度であることが多い。

これに対し、待機系の機器本体やオペレーティングシステム(OS)などは起動状態にしておくが本番系と同期などは取らず、障害時にシステムを起動して切り替えを行う方式を「ウォームスタンバイ」(warm standby)という。

また、待機系の機材などは用意しておくが普段は停止しており、障害時にシステムの起動や設定などから行う方式を「コールドスタンバイ」(cold standby)という。ホットスタンバイはこれらの中で構成や運用が難しく最もコストがかかるが、最も障害時の損害が少なく対障害性の高い方式である。

システムを構成する機材が故障などで停止する場合に備え、同じ機材を複数用意しておく手法を「冗長化」あるいは「多重化」(2つの場合は二重化)という。平時に使用する機材を「本番系」「稼動系」「主系」、緊急時に使用する機材を「待機系」「予備系」「副系」「従系」という。

ウォームスタンバイでは同じ構成のシステムを複数用意しておき、通常時は本番系を稼働させるが、待機系は機器本体やオペレーティングシステム(OS)などは起動しておくが本番系と処理やデータの同期などは行わず、切り離された状態で待機する。

障害発生時には本番系と同じシステムを立ち上げ、本番系から処理を引き継ぐ。データベースシステムの場合は、主系からトランザクションログを一定間隔で従系に送信し、従系で非同期にバックアップを取って待機することをウォームスタンバイという。

これに対し、待機系を常に稼動状態にして本番系と同期を取り、障害時に即座に引き継ぐ方式を「ホットスタンバイ」(hot standby)、待機系の機材などは用意しておくが普段は停止しており、障害時にシステムの起動や設定などから行う方式を「コールドスタンバイ」(cold standby)という。ウォームスタンバイは両者の中間的な方式で、運用の難易度やコスト、障害時の損害の大きさや切り替えに要する時間なども両者の中間程度となる。

ISOとIECの合同作業部会(JTC1)が策定した規格群で、企業などの組織が情報セキュリティ管理を行う際のベストプラクティスやガイドラインを提供する。日本では同等の内容が日本産業規格(JIS規格)「JIS Q 27000シリーズ」として発行されている。

「ISO/IEC 27000」は「ISO/IEC 27001」「ISO/IEC 27002」などの一連の規格群(ISMSファミリ規格)の総称であると共に、「ISO/IEC 27000」という個別の規格も設けられている。この規格ではISMSファミリ規格群の目的や概要を示し、共通する用語の定義を列挙している。

ISO/IEC 27001

2005年に初版が発行された規格で、組織の情報セキュリティ管理が一定の水準を満たしていることを認定する「ISMS認証」の要求事項を定義している。日本では2006年に「JIS Q 27001」として同等の国内規格が発行されている。

ISMS認証制度は各国の認定機関が対象組織を審査し、ISO/IEC 27001の要求する事項を達成している場合にこれを認証するもので、日本では「ISMS適合性評価制度」の名称で一般社団法人情報マネジメントシステム認定センター(ISMS-AC)が制度を運用している。

ISO/IEC 27002

情報セキュリティ管理を実践するためのベストプラクティス(実践規範)をまとめた規格。英国規格の「BS 7799」を元に2000年に策定された「ISO/IEC 17799」が2005年に改訂され、規格番号が改められISO/IEC 27000シリーズに編入された。日本では2006年に同等の内容が「JIS Q 27002」として発行されている。

組織が情報セキュリティ管理を実践するための指針として、基本方針、組織、資産管理、人的セキュリティ、物理セキュリティ、通信ネットワーク、アクセス制御、システム開発・保守、セキュリティインシデント管理、事業継続、コンプライアンスの12章に分けて規範が紹介されている。

組織の管理の一環として、取り扱う情報の種類などから確保すべきセキュリティの水準を定め、計画や規約を整備して情報システムの運用などに反映させる取り組みの総体を指す。具体的には、国際規格であるISO/IEC 27001および同等の国内規格JIS Q 27001に定められた要求事項を満たし、体制を整備して継続的に実施することが求められる。

組織がどのような情報をどのように取り扱うかを特定し、情報の適切な保護・管理についての基本方針や対策基準(情報セキュリティポリシー)、実施手順などを定め、担当部門だけでなく全社的な取り組みとして周知・実施を図る。

また、情報セキュリティ上のリスクについて、アセスメント(特定・分析・評価)を行って対応方針を決め、実際に現場で起きる様々なリスクへ対応し、一定期間状況を監視・記録(モニタリング)して検証(レビュー)し、結果を元に再度アセスメントから一連のプロセスを繰り返すというサイクルを継続的に実施することが求められる。

情報セキュリティマネジメントシステムの起源はBSI(イギリス規格協会)が1995年に策定したイギリス国内規格であるBS 7799で、これを元に2000年に国際規格のISO/IEC 17799が策定され、2005年にISO/IEC 27001および27002に改番された。日本ではほぼ同様の内容が国内規格として2006年にJIS Q 27001/27002として標準化された。

日本ではJIPDEC(日本情報経済社会推進協会)の情報マネジメントシステム認定センターが主導して情報セキュリティマネジメントシステム適合性評価制度を運用しており、審査を経て認定を受けることにより情報セキュリティマネジメントシステムが適切に整備されていることを内外に示すことができる。

ITの分野では、コンピュータなどの機器やソフトウェア、システムなどの処理性能や実行速度、通信回線・ネットワークなどの伝送速度・回線容量などのことをパフォーマンスという。「コストパフォーマンス」という場合はコスト一単位あたりの性能である価格性能比(費用対効果)を意味する。

一般の外来語としては「歌や踊り、劇などの上演や披露」「スポーツ選手の調子や能力、試合の出来や成績」「注目を集めるための派手な行動」「仕事などの能率、能力」といった意味で用いられることが多い。金融分野では金融商品の運用成績を指す。

組織や個人が目標達成に向けて行動するにあたり、限られた資源を最も効率よく活用するために設定するもので、目標の成否を左右する様々な要因や活動の中からCSFとして選択されたものには優先的・集中的に資源が投下される。

一般的には、まず組織や事業の長期的あるいは最終的な目標を表す「KGI」(Key Goal Indicator：重要目標達成指標)と呼ばれる尺度が設定され、これに決定的な影響を及ぼすと想定される要因や活動、施策などを見定め、これをCSFとして選択する。

CSFに基づく施策の進捗状況を継続的に計測・監視するため「KPI」(Key Performance Indicator：重要業績評価指標)と呼ばれる定量的な指標が設定されることもある。

すでに定義されている具体的な目標を達成するために、現在の状況を表す様々な数値などの中から進捗を表現するのに最も適していると思われるものが選択される。短い周期で繰り返し計測・記録され、時系列の推移から現況や進捗を把握したり、問題解決や活動の改善点を検討するための最も重要な材料の一つとして扱われる。

なるべく具体的で、努力や改善によって直接的に働きかけて変化させられる値であることが望ましく、抽象的だったり、活動と結果に因果関係が薄かったり、制御不能な要因によって大きく変化するような指標は好ましくないとされる。

一般的には「顧客への訪問回数」「受注件数」のように指標そのもののことを意味するが、これを「3月末までに顧客を30回訪問」「月に10件受注」のように、ある期限や期間に達成すべき目標の形で示し、これをKPIと呼ぶ場合もある。

組織の規模や業務の内容などによっても異なるが、あまりに指標が多いと集中すべき点がぼやけて形骸化しまうため、一つあるいは数個程度が設定されることが多い。全社KPI、営業部KPIといったように組織階層ごとに異なるKPIを設定する場合もある。

KGI・KSFとの関係

これに対し、組織や事業の長期的あるいは最終的な目標を表す尺度は「KGI」(Key Goal Indicator：重要目標達成指標)と呼ばれる。KPIはKGIで示された目標を達成するために、これを日々の活動のレベルに分解したものと解することができる。

また、KGIやKPIに決定的な影響を及ぼす重要な要因や活動、施策などのことを「KSF」(Key Success Factor：主要成功要因)あるいは「CSF」(Critical Success Factor：重要成功要因)という。KPI向上のために最も影響があるとみなされたKSFには最優先で資源が投入される。

企業などの組織が事業やプロジェクトなどの最終的な目標を設定するために用いる物差しの役割を果たす指標を意味する。「年間売上高」のように単に指標自体のことを指すこともあるが、一般的には「3年後の年間売上高を今年度比+50%にする」といったように、期限と具体的な目標値を合わせて設定したものを指すことが多い。

KGIを決定したら、そのために日々の業務や活動で何を目指すべきかを表す指標としてKPI(Key Performance Indicator)を定義する。例えば、「売上を50%増やす」というKGIに対して、「営業課員一人あたり毎月20件以上顧客を訪問する」といったKPIを設定する。一つのKGIに複数のKPIを定める場合もある。

KGIは一つの組織やプロジェクトについて原則として一つを設定するが、全社のKGIとは別にそれぞれの部門やチームが個別にKGIを定める場合もある。その場合は両者の目指す方向が矛盾しないよう、全体のKGIに資する部門別KGIを検討する必要がある。

「ジョブ」(job)は主に大型汎用機(メインフレーム)系のシステムにおいて用いられる処理単位で、人間側から見て業務上の特定の目的を達成するために、関連する複数の(単一でもよい)プログラムをまとめて連続して実行する一つのかたまりにしたものを指す。

ジョブスケジューリングは業務上の要請に従って必要なプログラムやデータを揃え、オペレーティングシステム(OS)付属のジョブ管理システム(ジョブスケジューラ)や他の専門的なシステムに登録する。実行するプログラム名やその所在、実行時の設定などを管理画面上の操作で指定するか、専用の「ジョブ制御言語」などで設定ファイルとして記述する。

一定期間ごとなど何らか条件に基づいて自動的に特定のジョブを起動する処理方式を特に「バッチ処理」という。複数のジョブを結び付けて実行順を指定したり、条件分岐などを含む複雑な実行条件を指定した「ジョブネット」などの単位で管理することができるシステムもある。

メインフレームではOS標準の機能としてジョブスケジューリングのためのシステムが付属しており、これを用いることが多い。LinuxなどのUNIX系OSではatコマンドやcron、anacronなどのツールを、Windowsでは標準のタスクスケジューラを用いることが多い。「Hinemos」や「A-AUTO」「JP1/AJS」などの運用管理ソフトウェアを導入してジョブスケジューリングを行うこともある。

単にバックアップといった場合は、データの破損や損失に備えてデータの写しを取って保管する「データバックアップ」のことを指す場合が多い。データをコピーする作業や工程のことをバックアップという場合と、作成されたデータの複製(を記録した装置など)のことをバックアップという場合がある。

コンピュータの記憶装置に保存されたデータを別の装置や記憶媒体へ複製して別に保管するもので、機器の故障や破損、人為ミス、不正行為などによってデータの消失や改変などが起こった場合に、複製した時点のデータに復旧させることができる。

また、「バックアップ回線」「バックアップサーバ」などのように、通常時に使用している機器などが何らかの原因で正常に稼働できなくなった時に、その機能を肩代わりするための機器や設備、施設などのことをバックアップということもある。

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

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

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

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

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

一般消費者と直に取引する事業者によく設けられる部門で、大きな部屋に電話機や電話機能を内蔵したパソコンなどを並べ、オペレータがこれを操作して顧客や消費者などと電話によるやり取りを行う。

電話により主にどのような業務を行うかは業種や個々の企業により異なるが、大きく分けて、電話営業や顧客への案内など企業側から電話を発信する「アウトバウンド」業務と、外部からの着信を受けて注文や修理、返品などの手続きをしたり、問い合わせ、苦情、顧客サポートなどの対応を行う「インバウンド」業務に分かれる。

一般的なコールセンターは「ACD」(Automatic Call Distribution：自動着信呼分配装置)や「CTI」(Computer Telephony Integration)などのシステムによって構築されており、多数のパソコンと電話回線を取りまとめ、着信を空いているオペレータに割り振ったり、現在のオペレータが対応できない場合に上位のスタッフに通話を転送するといった制御を行う。

また、その企業のCRMシステムやSFAシステムなどと連動し、画面上に現在の通話相手に関連する情報(プロフィールや個人情報、製品の購入履歴、過去の対応履歴、進行中の案件の進捗など)を表示したり、通話しながらシステムに新しい情報を入力したりできる。また、着信時にまず自動音声応答(IVR：Interactive Voice Response)システムで要件などを把握し、適切な部署へ繋ぐといった処理を行う場合もある。

コールセンター業務は設備の構築や人員の確保、オペレーションにかかる負担が大きい一方、企業ごとの違いが少なく共通化や集約を行いやすいため、これを専門に請け負う事業者も存在する。コストの大半が人件費となるため、国内の平均賃金の低い地域に立地したり、英語圏では人件費の安い国へのアウトソーシングも盛んに行われている。

CTIシステムは電話回線網とコンピュータネットワークを中継し、コンピュータに電話機の機能を統合する。オペレータは端末を操作して発着信を制御し、ヘッドセット(ヘッドホン一体型マイク)を用いて通話する。企業などが顧客や見込み客などと電話でやり取りするコールセンターでよく利用される仕組みである。

顧客管理システム(CRM)や営業支援システム(SFA)などと連動し、画面上に現在の通話相手に関連する情報(プロフィールや個人情報、製品の購入履歴、過去の対応履歴、進行中の案件の進捗など)を表示したり、通話しながらシステムに新しい情報を入力したりできる。通話内容を記録・蓄積し、トラブルの際の証拠としたり、オペレータの評価やトレーニングに活用することができる。

多数の端末と回線を取りまとめて一括管理することができ、オペレータの稼働状況の把握、空いているオペレータへの着信の自動割り振り、オペレータで対応できない場合の上役への自動引き継ぎ(エスカレーション)、音声案内による受付や取次(IVR：自動音声応答)などの機能もある。

従来は施設内に設置して運用するオンプレミス型の製品しかなかったが、近年ではCTIシステムを事業者の管理するデータセンターで運用し、インターネットを介してサービスとして提供するクラウド型CTIが増えている。少ない導入コストで迅速に使用開始でき、在宅スタッフへの遠隔割り当てなどにも対応できる。

製品や分野についての初心者向けの手引きや、サービスの加入者向け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はそれに限らず想定問答などを含む」といった違いについての説明を見かけるが、少なくとも現在そのような違いが広く浸透して適切に使い分けられているとは言い難く、実質的にはほぼ同義語として扱われていると見るべきであろう。

企業などの組織で各個人が日々の業務や活動の中で得る経験や知見、資料、データ、ノウハウ、コツ、トラブル解決法といった有用な情報をITシステムに記録し、他のメンバーが検索したり参照できるようにデータベース化したものを指す。

従来は暗黙知として個人の中に溜め込まれていたような情報を形式知として共有することで、業務の効率化や均質化、技能や知識の属人性の排除、組織全体として能力の底上げ、引き継ぎや新メンバーへの知識移転の効率化などが期待できる。知識ベースなどを用いて組織内の知識を管理を行うことを「ナレッジマネジメント」(knowledge management)という。

具体的な構築手法として、専用のナレッジベースツールやFAQシステム、社内Wikiなどを導入して独立したシステムとする手法のほか、グループウェアに業務システムに記録された情報を利用する手法、文書ファイル群に対するエンタープライズサーチやデータベースシステムに対するデータマイニングなどができる環境を整える手法などがある。

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

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

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

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

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

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

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

送電線や通信回線には、雷やスイッチ素子の開閉動作など様々な原因により瞬間的に定格を超える大きな電圧や電流を生じることがあり、これを「サージ」(surge)という。サージがコンピュータなどの機器内部の回路にそのまま流れ込むと誤作動や故障の原因となり、物理的に破損して使用不能になったり火災の原因となる場合もある。

アレスタはサージから電気系統を保護するため、サージの発生源と保護したい機器の中間に設置する。普段は回路を流れる電気に何の作用も及ぼさないが、内部に意図的に絶縁を弱くした箇所などが設けられており、ある電圧を超えると内部が短絡して流入したサージ電流をそのまま出口側の配線へ放出する。アレスタより内側にある機器へサージが流れ込むのを阻止する。

アレスタは回路や回線の種類や特性、保護対象の機器、サージの想定規模などに応じて様々な種類があり、多くは送配電設備や電源設備などの中に組み込まれている。身近なところでは、建物の分電盤やOAタップ、UPS(無停電電源装置)に組み込まれたものがよく知られる。

送電線や通信回線には、雷やスイッチ素子の開閉動作など様々な原因により瞬間的に定格を超える大きな電圧や電流を生じることがあり、これを「サージ」(surge)という。サージがコンピュータなどの機器内部の回路にそのまま流れ込むと誤作動や故障の原因となり、物理的に破損して使用不能になったり火災の原因となる場合もある。

サージ防護デバイスはサージから電気系統を保護するため、サージの発生源と保護したい機器の中間に設置する。普段は回路を流れる電気に何の作用も及ぼさないが、内部に意図的に絶縁を弱くした箇所などが設けられており、ある電圧を超えると内部が短絡して流入したサージ電流をそのまま出口側の配線へ放出する。サージ防護デバイスより内側にある機器へサージが流れ込むのを阻止する。

サージ防護デバイスは回路や回線の種類や特性、保護対象の機器、サージの想定規模などに応じて様々な種類があり、多くは送配電設備や電源設備などの中に組み込まれている。身近なところでは、建物の分電盤やOAタップ、UPS(無停電電源装置)に組み込まれたものがよく知られる。

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

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

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

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

CVCFとの違い

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

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

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

データセンターなどではコンピュータや通信機器などを収納した棚(ラック)が一列に並んでおり、列と列の間が通路や作業用の空間になっていることが多い。棚の前面側同士、背面側同士が向かい合うように配置した際、前面側が面する通路や空間をコールドアイルという。

機器内部の空冷装置は筐体の前面側から吸気して背面側に排気する構造が一般的なため、コールドアイルには冷房機器の送風口を集中させ、できるだけ冷たい空気を機器に供給できるようにする。背面側との仕切りにはラック自体を活用するが、棚上面と天井の間に隙間が生じないよう断熱材などで厳密に仕切っている施設もある。

一方、コールドアイルの裏側で機器の背面側が並んでいる通路や空間のことは「ホットアイル」(hot aisle)という。機器の排熱が集まる空間で、強力な換気扇などで効率的に屋外などに排気するようになっている。大規模なサーバルームはコールドアイルとホットアイルが交互に並んだ配置になっている。

データセンターなどではコンピュータや通信機器などを収納した棚(ラック)が一列に並んでおり、列と列の間が通路や作業用の空間になっていることが多い。棚の前面側同士、背面側同士が向かい合うように配置した際、背面側が面する通路や空間をホットアイルという。

機器内部の空冷装置は筐体の前面側から吸気して背面側に排気する構造が一般的なため、ホットアイル側には機器から排出された熱気のこもった空気が集まることになる。強力な換気扇の吸気口などを設けて効率的に屋外に空気を排出するようになっている。

一方、ホットアイルの裏側で機器の前面側が並んでいる通路や空間のことは「コールドアイル」(cold aisle)という。機器が冷却用の空気を吸い込む空間であるため、冷房の送風口などを集中させて常に冷たい空気を供給する。大規模なサーバルームはホットアイルとコールドアイルが交互に並んだ配置になっている。

マンションやオフィスビルなどのMDFは共用部に設置され、内外を繋ぐ電話回線や光ファイバー回線、CATVなどの加入者回線はすべてここを経由して各部屋、各フロアへ配線される。外から各部屋に個別に配線する場合に比べ、接続状態の変更などを一か所で集中的に管理することができる。

高層マンションや大規模な商業ビルなど大きな建物では、各階ごとなどの単位で「中間配線盤」(IDF：Intermediate Distribution Frame)と呼ばれる中継機器を設置し、MDFからこれを経由して各加入者宅へ配線する場合もある。

将来の通信需要を見越して、あらかじめ電話局からMDFまである程度まとまった数の回線を敷設しておくことがあり、入居者が契約する際に迅速に配線を済ませることができる。保安器などを設け、回線を落雷などからまとめて保護する仕組みになっていることもある。

電話局のMDFはNTT東日本やNTT西日本の局舎などに設置され、外部からの通信回線を交換機に繋ぐ前に集配線して整理する役割を果たす。NTT地域会社以外の通信事業者のサービスに加入する利用者の回線はMDFを経由して局内に設置された当該事業者の交換機などへ接続される。

光ファイバー回線では、MDFと似た役割を果たす建物全体の集配線設備を「PT盤」(Premise Termination cabinet)、IDFと同様に各階ごとに設置される集配線設備を「PD盤」(Premise Distribution cabinet)という。ADSL回線が主流の時代にMDFの呼称が広く定着したため、現在でも慣用的にPT盤を指してMDFと呼ぶこともある。

集合住宅やビルなどで外部に通じる通信回線をすべて収容し、集中的に管理する集線装置を主配電盤(MDF：Main Distribution Frame)という。内外を繋ぐ電話回線や光ファイバー回線、CATVなどの加入者回線はすべてここを経由して各部屋、各フロアへ配線される。

小規模な建物ではMDFから各戸へ直に配線されるが、高層のマンションやオフィスビルなど、大きな建物に多数の回線契約者がいるような場合には、各階ごとなどの単位でIDFが設置されている。回線の増設などの際にいちいち各戸から建物全体の主配線盤まで配線しなくても済むようになる。

ITのグリーン化

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

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

ITによるグリーン化

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

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