JIP-ITSMS121-1.0

1/26

運用管理のお手本 ISO/IEC 20000

～事例から学ぼう～

変更管理とリリース及び展開管理 編

平成 24 年 4 月 10 日

一般財団法人日本情報経済社会推進協会

JIPDECの許可なく転載することを禁じます

JIP-ITSMS121-1.0

～ はじめに ～

IT サービスマネジメントシステム（以下「ITSMS」）とは、サービス提供者が提供す

る IT サービスのマネジメントを効率的、効果的に管理するための仕組みです。

ISO/IEC 20000 は ITSMS の国際規格として制定されました。

ISO/IEC 20000 を実践することは、運用のあるべき姿の実現に向けて取り組むこ

とに他なりません。ISO/IEC 20000 は運用プロセス群において、必須で対応すべき

項目をプロセス毎に体系的に整理した「仕様」であり、単に“あるべき姿”を紹介す

るものではなく、システム運用管理の“お手本”として利用できるものなのです。

本書は ISO/IEC 20000 の持つ運用管理のお手本としての“エッセンス”を事例を

通じて紹介することで、運用管理のあるべき姿の実践に関心を持って頂く事を目的

に作成しました。

JIP-ITSMS121-1.0

読者としては、IT サービスの提供にかかわるすべての方を意識していますが、と

りわけ、運用管理の実務者・実践者の方々にとって有用でありたいと願っていま

す。

また、本書作成に至った背景には「ISO/IEC 20000 認証を取得しても、発注側が

ISO/IEC 20000 とは何かを全く知らないというケースもあり、結果として“対外的な信

頼性確保の表明”につながっていない」という現状があることを、少しでも改善した

いという意図もあります。

さらに、ISO/IEC 20000 への関心はあるものの、「ISO/IEC 20000 の導入は大

変!!」というイメージを持たれている方にも、本書を通じて ISO/IEC 20000 導入に対

する“しきい”を下げ、ISO/IEC 20000 をもっと身近なものに感じて頂くことも目指し

ています。

本書は「事例から学ぼう ISO/IEC 20000」をコンセプトに、運用の現場でよく出く

わす事柄や失敗事例を題材に、ISO/IEC 20000 導入の効果を知って頂けるよう構

成しており、また、「非常に結びつきの強いプロセス」をセットにして紹介していま

す。

※ 本書における「出典:ISO/IEC 20000-1:2011」の訳は、一般財団法人日本規格協会様

の英和対訳版によります。

JIP-ITSMS121-1.0

～ 目次 ～

1. 変更管理とリリース及び展開管理.......................................................1 2. 失敗から学ぼう変更管理～その変更、だいじょうぶですか？～..............3

2-1 ケース１：さみだれ式の変更.................................................................7 2-2 ケース２：顧客・上層部の知らない変更..........................................10 2-3 ケース３：コストに合わない変更........................................................12 2-4 ケース４：やり直しの多い変更...........................................................15 2-5 ケース５：何でも緊急変更..................................................................17

JIP-ITSMS121-1.0

1

1. 変更管理とリリース及び展開管理

変更管理とリリース及び展開管理の違いについて整理しておきましょう。

変更管理を一言でいうと、“変更をコントロールするプロセス”です。変更には、

ハードウェア・ソフトウェア・文書を含んだシステム全体の変更から、単独のモジュー

ル又は小規模なハードウェアコンポーネントの変更に至るまで、変更の規模の大小

や変更の理由にかかわらず、サービス提供に関係するあらゆる構成品目の変更を

含みます。これらの変更を事前に評価し、変更する・しないを判断し、実装の監視、

実装後のレビューをすることが、変更をコントロールすることであり、すなわち変更

管理となります。

一方、リリース及び展開管理は、“変更管理のコントロール下において変更を実

施・実装するプロセス”です。変更管理のコントロール下でリリース及び展開管理が

行われるという関係になります。そのため、変更管理は承認のプロセス、リリース及

び展開管理は実行のプロセスともいわれます。

変更管理とリリース及び展開管理の関係を、身近な例で置き換えて考えてみま

しょう。航空機のパイロットと航空管制塔の管制官との関係は、変更管理とリリース

及び展開管理の関係に似ています。

管制官は航空機の離着陸等に関する指示を出し、航空機の活動をコントロール

しますが、自らが航空機を操縦することはありません。

一方、航空機のパイロットは操縦しますが、勝手に離陸し、着陸しているわけで

はありません。国際空港では 1 日に何百便という航空機が離着陸を繰り返します。

パイロットは管制官の指示に従い、決められた手順とコントロールの下で、航空機

の操縦をして離着陸を行うのです。そうしなければ 悪の場合、事故が発生するか

もしれません。そうならないためにも運航をコントロールする仕組みが必要であり、

それを管制官が行っているのです。

航空機を操縦するパイロットがリリース及び展開管理、航空機の運航をコントロー

ルする管制官が変更管理と考えてください。管制官とパイロットが協力することによ

JIP-ITSMS121-1.0

2

って初めて安全な航空機の運航が保証されます。同様に、変更管理とリリース及び

展開管理がお互いの役割と責任を認識し、密接に連携することで、プログラムの変

更、実装、ハードウェアの増設、オペレーションの変更等が適切に実施され、安全

で安定したサービス提供が可能になるのです。

ISO/IEC 20000 の要求事項で求められている内容から、変更管理、リリース及び

展開管理の活動として特徴的な点を紹介しておきます。

変更管理では、様々なプロセスからの情報を取得し、変更要求を評価します。そ

して、変更によるリスク、顧客への影響、事業利益、技術的実現可能性、財務的な

影響などを考慮したうえで、変更する・しないの意思決定を行います。承認された

（変更することが決定した）変更は展開期日案を含む変更スケジュールを策定しま

す。この変更スケジュールは、リリース展開計画の基礎となります。

リリース及び展開管理では、リリース計画を策定し、稼働環境への展開について

検討します。リリース計画立案は、変更管理と連携して行います。変更管理と密接

に連携してリリース及び展開管理することで、承認なしにサービスやソフトウェア、

ハードウェア等が稼働環境に投入されてしまい、結果として悪影響を及ぼすことが

ないようにコントロールすることが可能になるのです。

JIP-ITSMS121-1.0

3

2. 失敗から学ぼう変更管理～その変更、だいじょうぶですか？～

A 社は流通業界における中堅企業だ。全国の拠点をオンラインで結び、きめ

細かい IT サービスを提供することで、代理店、利用者からのリクエストに応えて

いる。システムの開発・運用は子会社の B システム社に委託しているが、 近は

トラブル続きで、A 社の IT 企画担当部長の S 氏は代理店、役員からのクレーム

対応に追われている。 昨日も、重要な業務アプリケーションが朝から利用できなかった。B システム

社の運用担当者 H 氏からは、トラブルのたびにレポートを提出してもらっている

が、要領を得ない。 S 氏は 近のトラブルの原因は B システム社が実施しているさまざまな作業に

あるように思えてならないのだが.....

多くの職場では、パソコンに向かって作業することが仕事の一部となっているか

も知れません。IT 化が進んでいる職場においては、IT サービスを利用することで、

たいていの仕事が片付くことはめずらしくありません。私たちは、多くの IT サービス

を、日常的にそこにあるものとして、意識することなく利用しています。

スマートフォンでアプリを利用して楽しみ、携帯メールで気軽に友人や家族と連

絡できるのも、多くのコンピューターシステムがどこかで稼働し続けていて、アプリケ

ーションを実行することによって IT サービスを提供しているからです。

利用者の立場からすれば、いつでも、どこでも、IT サービスを使えることが当たり

前のように思いがちですが、実際に IT サービスをいつでも利用できるようにするこ

とは、けっこう大変なことなのです。

IT サービスを常に使えるようにするためには、IT サービスを支えているコンピュ

ーターシステムとその上で実行するソフトウェアを動かし続けなければなりません。

しかし、コンピューターシステムは数多くの弱点も併せ持っています。ソフトウェアの

バグ、ハードウェアの故障、悪意のあるウィルスへの感染などの脆弱性は良く知ら

れている弱みと言えるでしょう。

人間であれば、体調不良になると医者に行き、薬を処方してもらったり、休息を

JIP-ITSMS121-1.0

4

取ることで回復に努めます。人間は不調から立ち直るのは、自己の回復力に負うと

ころが大きいですが、コンピューターシステムではそうはいきません。IT サービスが

使えなくなった時には、必ず、何らかの是正措置をしないと回復しません。

IT サービスの提供者が、コンピューターシステムのどこに原因があるかを探り当

て、その原因を取り去るか、修復しない限り、元の状態には戻らないのです。コンピ

ューターシステムの運用管理の世界では、元の状態から別の状態に変えることを

「変更」として扱います。

例えば、ハードウェアの故障修理は、結果としては交換作業なのですが、運用

管理の立場から見ると変更に相当します。今回は、IT サービスの変更にまつわる

話題、すなわち変更管理について取り上げます。

完璧なシステムなど存在しません。 初に決めた仕様どおりに、約束した納期で

開発が終わり、気持ちよくカットオーバーを迎え、アプリケーションのバグも無く、順

調に IT サービスが提供されているとしても、やはり完璧ではないのです。何故なら、

現実の世界においては、コンピューターシステムをまったく同じ状態のまま使い続

けてゆくことは、非常に難しいからです。今日のコンピューターシステムはさまざま

な要求に応じて、常に変化することを強いられています。IT サービスをビジネスとし

て提供している部門からは、競合他社との差別化をするために、IT インフラあるい

は IT サービスへの変更を要求します。また、一見、完璧そうに思えるコンピュータ

ーも、多くの修正点、潜在的な問題を内包している可能性があるのです。

利用ユーザー数の急激な増加によるリソース不足解消のための変更、新種ウィ

ルスへの対策のための変更、追加仕様によるアプリケーション変更、データベース

のバージョンアップ 等々、コンピューターへの変更を引き起こす要因は数多くあり

ます。コンピューターへの変更要因の代表例はハードウェア変更（ネットワーク機器

も含む）であり、ソフトウェア変更でしょう。（表 1 参照）

JIP-ITSMS121-1.0

5

HW の変更 SW の変更 その他の変更

交換、追加

構成変更

修理

新規インストール

バージョンアップ

バグ修正処置

プロセスの変更

役割の追加

要員交替

表 1：変更の代表例

変更の目的は、堅苦しい表現をすると、次のようになります。

「すべての変更を、制御された方法で、アセスメント、評価、実装及びレビューす

ることを確実にすること。」

では、どうやって変更の目的を達成するかという話になりますが、ここに、変更管

理プロセスが登場します。

変更管理プロセスは、すべての変更を管理し、制御するプロセスです。そのため

に、すべての変更に対して標準のやり方（手順）を用います。変更はうまくいって当

たり前なのですが、あまりに多くの対象から変更が惹起されることで、予期せぬ副

産物を産んでしまうことも少なくありません。いつも利用している IT サービスが、“な

んか調子悪いなぁ”と思ったら、数日前に IT サービスを取り巻く環境のどこかに変

更が加えられていたという経験はないでしょうか。

IT の世界では、変更の実装が IT サービスを阻害する原因となりうる因子（インシ

デントと呼びます）を引き起こすことはめずらしくないのです。出来の良い変更管理

プロセスは、変更によって引き起こされるかもしれないインシデントを、未然に防止

できます。そして、もしかしたら、IT サービスに悪影響を与えかねないほどのインシ

デントの発生をも、抑制してくれるのです。

変更が失敗する要因として次のような項目が考えられます。（表 2 参照）

JIP-ITSMS121-1.0

6

よくある変更の失敗要因 • さみだれ式の変更 • 顧客・上層部の知らない変更 • コストに合わない変更 • やり直しの多い変更 • 何でも緊急変更

表 2：よくある変更の失敗要因

変更管理プロセスをどのように構築すれば、これらの失敗要因を抑制し、避ける

事が出来るのでしょうか？

変更管理プロセスが行うべき標準的な手順は、すでに国際的な共通理解のレベ

ルになっています。コンピューターシステムを利用して提供するサービスに必要とさ

れるプロセス群は ISO/IEC 20000 という IT サービスマネジメントの国際規格によっ

て規定されているのです。もちろん、変更管理プロセスもその中のひとつです。

つまり、IT サービスマネジメントのプロセス群が適切に構築されていることを、規

格への順守という形で確認できるのです。ISO/IEC 20000 の変更管理における要

求事項を実践することで、上記の失敗要因を未然に防ぐ事が可能となるのです。

本書では、いくつかの失敗要因ケース例を解説し、ISO/IEC 20000 の変更管理

の要求事項に沿えば、どのように対処することが出来るかを検証してゆくことにしま

しょう。

JIP-ITSMS121-1.0

7

2-1 ケース１：さみだれ式の変更

S 部長： どうして、1 ヶ月に何度も基幹システムの改修をしないといけな

いんだね？

運用担当者： 申し訳ありません。予定していた変更に加えて、システム基盤

部とアプリケーション開発部から変更を依頼され、変更数が増

えてしまいました。

利用者の急激な増加に伴い、ビジネス部から基幹システムへの

細かなシステム変更を毎月のように指示されています。今回

は、システム基盤部からの要請で CPU 基板をアップグレードし

ました。その直後に一部のアプリが対応できていないことが判

明し、アプリの改修も実施しなければなりませんでした。

S 部長： 事前に部門間で調整していないのかね？

運用担当者： はい、現状では各部門からの要求に応えて、対応することで手

いっぱいの状態です。システム基盤部とアプリケーション開発

部では、変更前にそれぞれ部門内でテストしていますが、今回

の事態を予想することができませんでした。

S 部長： 24 時間稼働を約束している基幹システムを、変更のたびに止

めていたのでは、事業への影響も出かねない。しっかりと対応

してくれないと困るよ。

変更の提起は IT サービスの運用関係者であれば、誰でも可能です。組織によ

っては IT の運用を機能ごとに分化することで効率化をはかります。ハードウェアを

専門とする基盤部、ソフトウェア開発部、ネットワーク部等々です。運用担当者は各

部門からの要望に応えて、変更時の手順にしたがって変更を実施します。各部門

からの要求を受け付けた順番に変更を実施してゆくことは非効率につながり、時と

して、思わぬインシデントを引き起こすことさえあります。

JIP-ITSMS121-1.0

8

ISO/IEC 20000 の変更管理プロセスにおける、次の要求事項を実践することで、

さみだれ式変更の発生を抑制できます。

全ての変更要求は記録し、分類しなければならない。

出典:ISO/IEC 20000-1:2011

ケース１でもわかるように、IT サービスを提供している組織には変更要求を提起

する部門が複数存在します。変更管理プロセスは変更要求の受付から始まります

が、記録するだけではさみだれ式変更を抑制することは出来ません。ここで重要な

のはすべての変更要求を扱うという事です。抜け漏れのないように変更要求を把

握することが重要なのです。

変更管理プロセスでは、すべての変更を扱いますが、IT サービスに重大な影響

を与える可能性のある変更もあれば、ほとんど影響を与えることのない変更もある

でしょう。すべての変更要求を平等かつ受け付け順に扱っていたのでは、効率の

良い変更管理とならないことは明白です。

変更管理プロセスでは、分類という表現で、変更要求の処理の順番を決定する

必要があるとしています。分類の方法は、変更要求が持っている緊急度と事業の

要求により決定します。こうして優先度を付けられた変更要求は、他の変更要求と

比較され、どの順番で実施するかを判断してゆくことになります。

JIP-ITSMS121-1.0

9

分類のメリットはそれだけではありません。複数の変更をまとめて実施することも

検討できますし、どの変更をいつ優先的にやればビジネスにとって効果的なのかと

いった判断さえも可能にしてくれます。

承認された変更の詳細及びその展開の期日案を含む変更スケジュールを策定

し、利害関係者に周知しなければならない。

変更スケジュールは、リリース展開の計画立案の基礎として使用しなければなら

ない。

出典:ISO/IEC 20000-1:2011

変更管理プロセスでは、承認された変更を実装する時期について、すべての変

更の詳細と実装日を含んだ実装予定スケジュールのような文書を作成します。この

スケジュールには、変更を現場で実施する役割（リリース及び展開管理）に関する

情報も含むようにします。この文書は何らかの方法で、関連する顧客、ユーザー、

IT サービスのスタッフ、関連部署に周知します。

複数の変更要求をあげている部門があったとしても、変更スケジュールに実施

日が掲載されていれば安心でしょう。

スケジュールを周知しておくことで、関連部署の協力を期待できますし、変更後

にインシデントが発生したとしても、解決の手助けになるかも知れません。

JIP-ITSMS121-1.0

10

2-2 ケース２：顧客・上層部の知らない変更

S 部長：

近、代理店から「在庫管理システムの画面や操作が変わって

わかりづらい。事前案内や説明会はないのか」というクレームが

多いんだが、何か変更があったのかね。

運用担当者： はい。アプリケーション開発部からの提案で、システムを使いや

すくする変更を実施したそうです。

S 部長： 私に連絡は無かったし、代理店営業部にも連絡がなかったと聞

いてるが。

運用担当者： えぇ～、そうなんですか。アプリケーション開発部から連絡が入

っていると思ったんですが・・・

S 部長：

いや、なかった。システム変更は君たちが管理しているのだか

ら、関係のありそうな変更は報告してくれないと困るよ。私の立

場で「知りませんでした」とは言えないだろ・・・

コンピューターシステムに加える変更の内容によっては、顧客や利用者に大きな

影響を及ぼす可能性があります。顧客や利用者は、自分たちの業務に影響がある

変更をあらかじめ知っておき、場合によっては業務のスケジュールを調整しようとい

う要望を持っています。そのため、業務に影響がある変更の事前連絡などがないと、

クレームにつながる可能性が高まります。

JIP-ITSMS121-1.0

11

また、顧客や利用者に重大な影響を及ぼす変更がどのようなものなのか事前に

評価し、重大な影響を及ぼす変更である場合には、十分に事前準備を行い、慎重

に計画した変更の実装を行うことが重要となります。

ISO/IEC 20000 の変更管理プロセスには、次のような要求事項があります。ケー

ス２の変更は、サービスや顧客に重大な影響を及ぼす可能性のある変更として、事

前に識別されていれば、クレームの発生をおさえられたはずです。

変更管理方針を確立し、次を定義しなければならない。 a) 変更管理が制御しているCI b)サービス又は顧客に重大な影響を及ぼす可能性のある変更を判断する基

準

出典:ISO/IEC 20000-1:2011

そして、関係者へ連絡する内容は、ケース１で紹介した変更スケジュールなどを

含めることで利用者、顧客は、より安心するかもしれません。

JIP-ITSMS121-1.0

12

2-3 ケース３：コストに合わない変更

運用担当者：

S 部長、物流システムのパフォーマンスとユーザビリティ向上の

ために、ハードウェアの増強と追加開発の要望が入っていま

す。

S 部長：

そうか。物流システムはカットオーバーしてから期間が経ってい

るからな。それで、内容はどのようなものだね。

運用担当者：

はい。利用者から、物流システムのレスポンスが悪いとのクレー

ムが入っていまして、CPU とメモリを増強する要望が 1 つと、他

のシステムとの連携を高めるためにシングルサインオンにして

ほしいとの要望が 1 つです。

S 部長： 確かに必要かもしれないな。変更にはどのくらいのコストがかか

るんだ。

運用担当者： まだ詳細には見積りをしていませんが、ざっと 1000 万円にはな

りそうです。

S 部長：

・・・それでどの程度のメリットが見込めるんだね？そもそも、

CPU とメモリを増強すれば解決するのかね？それから、その要

望は多くの利用者から出てきているのか。

運用担当者： それは・・・

S 部長： もう少し詳しく調査してからでないと判断できないな。

変更には、簡単な設定変更で済むものから、大規模なソフトウェア開発を伴うも

の、ハードウェアの増強などコストがかかるものなど、様々な種類があります。また、

変更によって得られるメリットは、必ずしも変更にかかるコストに比例するものではな

い場合もあります。顧客や利用者からの変更要求をすべて受け入れることは、シス

テム運用・保守にかかるコストを際限なく増加させることにもつながります。

したがって、変更要求があった場合には、その変更にかかるコストや他のサービ

ス・システムに与える影響（その影響をおさえるためにコストがかかるかもしれませ

ん）、変更によってもたらされるメリットなどを踏まえて、変更要求を受け入れるかどう

JIP-ITSMS121-1.0

13

かを決定することが重要となります。

ISO/IEC 20000 の変更管理プロセスには、次のような要求事項があります。この

要求事項にしたがってあらかじめ変更要求を精査していれば、ケース３のように S

部長から追加調査を指示されることもなかったかもしれません。

サービス提供者及び利害関係者は、変更要求の受入れについて決定しなけれ

ばならない。意思決定では、リスク、サービス及び顧客への潜在的影響、サービ

スの要求事項、事業利益、技術的実現可能性及び財務的な影響を考慮しなけ

ればならない。

出典:ISO/IEC 20000-1:2011

変更要求のきっかけは、顧客や利用者からの要望、障害への対応など様々です。

そこで留意しなければならないことは、すべての変更要求が、その要求の背景にあ

る要望や問題を解決できるかどうかわからないことです。ケース３の事例でいえば、

物流システムのレスポンスが悪いことが、本当に物流システムの CPU とメモリの性能

によるものなのか、クライアント PC との相性なのか、ネットワークの問題なのか、それ

とも他の原因によるものなのか、ということです。

変更を実装するためには、ほとんどの場合コストがかかります。変更するならば、

変更要求のきっかけとなった要望や問題をクリアできないと意味がありません。その

JIP-ITSMS121-1.0

14

ためには、変更要求の内容や解決したいことなどをはっきりさせて、あらかじめ評価

することが重要となります。

ISO/IEC 20000 の変更管理プロセスには、次のような要求事項があります。ここ

での「他のプロセス」とは、ISO/IEC 20000 で定義されている構成管理、インシデン

ト管理、問題管理などの各プロセスを指しています。この要求事項は、それらのプ

ロセスにより把握する情報や、アウトプットとなる情報に基づき、変更要求を評価す

ることが重要であることを示唆しています。

変更要求は、変更管理プロセス及びその他のプロセスからの情報を用いて評価

しなければならない。

出典:ISO/IEC 20000-1:2011

JIP-ITSMS121-1.0

15

2-4 ケース４：やり直しの多い変更

S 部長： システムが止まったままだが、どうなってるんだね？

運用担当者： あの～、それが、ちょっと・・・・・。

S 部長： ちょっと、どうした？

運用担当者：

今、変更を実装しているところなのですが、なかなか上手くいか

ず、何度もやり直しているため、システムを再開することができま

せん。

S 部長： きちんと試験をすることになっているはずだろ？

運用担当者： はい、そうだと思っていたのですが、やっていなかったようです。

S 部長： 中止するならすると早く決断しなさい。とにかく、できるかぎり早く

システムを再開してくれないと、業務に支障をきたすことになりか

ねない。

変更を実環境に実装するには、システムを計画停止する必要があります。実装

の間は、システムの停止に伴い業務も停止することになります。そのため、計画通り

に変更の実装を完了させ、システムを再開させる必要があります。しかしながら、い

つも計画通りに実装が完了するとは限りません。事前にきちんとテストをしていても、

実環境に変更を実装しようとしたら、不具合が発生したり、予期しない事態が発生

したりすることも多々あります。不幸にして、そのようなことが起こらないように十分に

テスト環境で変更の試験をしておく必要があります。

これは、ISO/IEC 20000 の変更管理プロセスにおける、次の要求事項を実践す

ることになります。

承認された変更は、開発し試験しなければならない。

出典:ISO/IEC 20000-1:2011

あらかじめ、テスト環境で変更のテストを行っていても、テスト環境と実環境はまっ

たく同じであることの方がまれでしょう。テスト環境で問題なしでも、予期せぬ事態

JIP-ITSMS121-1.0

16

が発生して、実環境への実装が失敗することもあるのです。

したがって、実環境への実装に失敗する場合を想定しておく必要があります。業

務を必要以上に停止させないためには、変更の実装が成功した時はもちろん、失

敗した時でも計画した時間内にシステムを再開させることが求められます。そのた

めには、実装が上手くいかない場合に、途中で実装作業を中止するかどうかの判

断をすることになります。そして、中止と判断した場合、そのままではシステムを再

開できませんので、きちんと変更を元に戻しておく必要があります。

つまり、変更を実環境に実装する場合、途中で中止した変更を元に戻したり、何

度も修正したりしなければならない場合を想定し、あらかじめ計画を立て、できれば

そのための試験も実施しておくことで、実装作業中の想定外の事態に対処すること

が可能になります。

これは、ISO/IEC 20000 の変更管理プロセスにおける、次の要求事項を実践す

ることになります。

失敗した変更を元に戻す、又は修正するために必要な活動を計画し、可能な場

合は試験しなければならない。

出典:ISO/IEC 20000-1:2011

JIP-ITSMS121-1.0

17

2-5 ケース５：何でも緊急変更

S 部長： 近、やたらと緊急の変更が多いような気がするが、どうなん

だ？

運用担当者：

はい、そうなんです。実はそのことで困っています。緊急の変更

が増えたせいで、通常時の変更が後回しになるケースが増えて

しまい、変更要求の提出者からクレームが出ています。

S 部長：

そもそも緊急の変更に関して、きちんとした決まりを作っていなか

ったのか？

運用担当者：

はい、緊急の変更について、定義はしていたのですが、きちんと

文書化していませんでした。そのため、緊急時は通常時の変更

のときの手順を省略して、 優先で処理して良いという暗黙の了

解がいつのまにか出来てしまっていたようです。

S 部長：

それはまずいよ。緊急時の変更についても、通常時の変更と同じ

ように、きちんと文書化し、関係者に周知徹底しなさい。なんでも

かんでも緊急の変更では、本当に緊急の対応が必要な変更が

発生しても、優先して対応できないかも知れないじゃないか。

変更には、通常時の変更と緊急時の変更があります。緊急時の変更とは、通常

時の変更手順にしたがって変更していては時間的に間に合わないような変更です。

したがって、優先度が高く、例えそのとき他の通常時の変更に割り当てられていた

リソースであっても、緊急時の変更に割り当てられることになります。

本来、通常時の変更であるにもかかわらず、変更の処理スピードを速めたり、手

順を簡素化したりすることを目的に、緊急時の変更を多用すると、変更作業が無秩

序になり、変更管理プロセスの取り決め自体が意味のないものになってしまいます。

通常時の変更と緊急時の変更の定義と違いを明確にしておく必要があります。特

に、どのような変更を緊急時の変更とするかは、サービス提供者だけでなく、通常

時の変更の優先度付けと同じように、サービスの利用者や顧客と認識を合わせて

おく必要があります。サービス提供者側の勝手な思い込みで、緊急の変更として作

JIP-ITSMS121-1.0

18

業を進めた結果、本来優先すべき変更が後回しになり、結果として利用者の業務

や顧客の事業に多大な悪影響を及ぼすことにならないように注意する必要がありま

す。

IT サービスを提供している組織では、利用部門も含め複数の組織から変更要求

が提起されます。変更要求を提起する人は、できる限り早く自分の変更要求を処

理して欲しいと思うものです。どの変更を優先するのか、どの変更を緊急時の変更

とし、緊急の手順にしたがって処理するかは、各自が勝手に決めて良いわけでは

ありません。

緊急時の変更が多発すると、通常時の変更作業にも支障をきたすことになりま

す。通常時の変更が、予定のスケジュール通りに完了しなかったり、変更作業が正

しく行われなくなったりすることのないように、緊急時の変更についても、きちんとし

た管理を行うことが求められます。

ISO/IEC 20000 の変更管理プロセスにおける、次の要求事項を実践することで、

緊急時の変更を多発させ、変更作業に支障をきたすことを防ぐことができます。

サービス提供者は、緊急変更の定義について文書化し、顧客と合意しなければ

ならない。 緊急変更を管理する文書化された手順をもたなければならない。

出典:ISO/IEC 20000-1:2011

JIP-ITSMS121-1.0

19

～ まとめ ～

今回は、ISO/IEC 20000 の統合的制御プロセスの変更管理とリリース及び展開

管理を取り上げました。

重大なトラブルに至った原因を調査してみると、適切でない変更管理に端を発し

ていたということはめずらしい話ではありません。変更はインシデントの生みの親と

まで言い切る皮肉な表現もあります。

変更を適切に管理し、変更を安全に実環境に実装する事が「変更管理」と「リリ

ース及び展開管理」の共通の目的です。

変更管理の要求事項を理解し、自社の組織に合った導入をすることは、トラブル

の未然防止への 初の一歩と言えるでしょう。

次回は構成管理プロセスをお届けする予定です。ご期待ください。

ITSMS 適合性評価制度技術専門部会

一般財団法人日本情報経済社会推進協会

JIP-ITSMS121-1.0

本書及び ITSMS ユーザーズガイドのダウンロード提供及び ITSMS 適合性評価制

度に関する FAQ、認証機関/認証取得組織情報の参照などを次のサイトからご利

用いただけます。

URL http://www.isms.jipdec.or.jp/itsms.html

JIP-ITSMS121-1.0

―禁 無 断 転 載―

2012 年 4 月発行

発行者：一般財団法人日本情報経済社会推進協会

〒106-0032 東京都港区六本木 1-9-9 六本木ファーストビル

TEL 03-5860-7570 FAX 03-5573-0564

URL http://www.isms.jipdec.or.jp/

JIP-ITSMS121-1.0

一般財団法人日本情報経済社会推進協会 〒106-0032 東京都港区六本木１丁目９番９号 六本木ファーストビル内

TEL 03-5860-7570 FAX 03-5573-0564

URL http://www.isms.jipdec.or.jp/