ISO20000 SKILL

【ISO20000】ISO20000(ITSMS)に関するQ&Aまとめ

投稿日:

ITサービスに特化した国際規格である、ISO20000。
取得企業の少なさから、ネットで調べても全然情報が出てこず、一体どうしたらいいんだと頭を抱えることも少なくありません。
本記事では、私自身がISO20000規格認証を取得した際にいろいろと調べた疑問点をまとめてみます。
これからISO20000取得を目指す方がもし見ていれば、少しでもお力になれればと思います。

スポンサーリンク


Q.SMSとITSMSの違いは何?

SMSとITSMSはそれぞれ以下の用語の略称になっています。
SMS=サービスマネジメントシステム
ITSMS=ITサービスマネジメントシステム

ITがついているかついていないか、の違いですが指している内容は全く同じです。

どういうことかというと、もともと「ITSMS」という言葉が使用されていましたが、IT以外のサービスでも適用できるように、2011年版より「SMS」という言葉に変更になったそうです。

よって、内容は一緒であるものの、今現在正式に使用されている用語は「SMS」ということになります。

ただ、企業によってはSMSだかISMSだか何だか分りづらい、ということであえて「ITSMS」という言葉を使用しているところもあるようです。

Q.ISO20000を取得するのにどれくらい期間が必要?

ISO認証規格を1つあたり1年間運用する為に必要な時間は、平均587時間だそうです。
(ISOコンサル専門の独自統計情報より)

ただし、これはあくまでも「運用するために必要な時間」です。構築するとなると話は別です。
ISO20000規格認証取得時、8割くらいの会社は外部コンサルを入れて規格認証取得を行うそうですので、どういった体制で取得を目指すかで大きく話が変わってきます。

前提知識がなく、コンサルにも頼らない、という状態であれば組織の大きさにもよりますが1年は見ておいた方が良いでしょう。
というのも、ISO20000は仕組みを構築しただけでは認証を得ることができません。
ISO20000の認証は実績評価だからです。
構築した仕組みが運用されていることに対する評価制度ですので、仕組みができたら終了!ではなく、仕組みが実際に運用され、そのアウトプットがあることが条件となります。

運用するにしても、導入する前に関連する担当には教育をする必要があります。
この点を意識したうえでのスケジュール策定することを強くお勧めします。

Q.ISO20000を取得するという言い方は正しい?

ISMSだと「ISO27001」を取得、品質管理規格だと「ISO9001」を取得という言い方をします。
では、ISO20000の場合は「ISO20001」の取得というのか? というと答は「No」です。

ISO20000は、正確には「ISO20000-1」の取得という言い方になるそうです。
同じISO規格でもこのあたりの細かい部分が統合されていなかったりするので非常に混乱しますが、基本的にはISO20000については、ISO20000を取得という言い方で問題ありません。
今後、この規格の認証取得の用語等についても統合していく動きがあるそうです。

Q.文書化が求められていない内容は文書化は必要ない?

必要ありません。
ISO20000は仕組みを問う規格ですので、仕組みが出来ていれば問題ありません。

ただし、文書化と実証は別問題(文書化≠仕組みのアウトプット)なので注意が必要です。
ISO20000は仕組みが出来てることの証明は、証拠を示すことによってのみ適合と判断されます。

従って、文書化が求められていなくても仕組みが運用されたことの証拠、例えば議事録、実施記録などは、規格上で文書化を求められているかどうかに関わらず、作成しておく必要があるので注意してください。

Q.文書管理とは?様式管理との違いは何?

文書管理って何?様式管理と違うの?文書と様式の違いは何?とごちゃごちゃになりやすい言葉ですが、規格上での話をすると「様式管理」という言葉は存在しません。

文書管理の対象の一つとして「様式」が存在するだけだと思えば良いです。
文書管理は、最新かつ有効な文書を識別するための「版」管理を行い、古い文書あるいは廃止された文書が利用されないようにすることを目的として実施します。

もう少し詳しく解説すると・・・
文書管理においては、大きく分けて2種類のものを管理することになると思います。
(※規格上「様式」という言葉は使用されませんが、あえてわかりやすくするため「様式」という言葉を使用します)

▼文書
契約書・仕様書など、利用する際に編集を行わない、内容が固定された文書を指します。
記載されている内容も含めて全てを管理しなければならないものです。
▼様式
申込書など、「項目」あるいは「書式」のみが決められており、利用時に項目を埋める形で編集をして使う文書を指します。
項目だけが決められ、中身の記入がされていない状態で保管・管理を行うものです。
上記2種類ともに「文書管理」の中で管理しなければならないものですが、これらの違いは、管理しなければならない内容が異なる ということです。

上記例で例えると・・・

文書の場合、記載された文言、書式、項目、どの修正をする場合においても、「版」を更新する必要があります。
一方、様式の場合は項目や書式に変更があった場合のみに「版」を更新すればよいです。

よくこのあたりがごちゃごちゃになっているケースが見受けられますが、項目だけが決まっている文書はここでいう「様式」です。

文書の「何を」管理しなければならないのか?ということを考えるとどちらの方法で管理しなければならないものかはわかってくるとおもいます。

Q.SLAは全ての顧客に対して締結する必要がある?

必ずしも全ての顧客に対してSLAの締結をする必要はありません。

厳密に言うと、ISO20000の規格では顧客に対し1つ以上のSLA締結が要求しているため、締結は必須です。
しかし、全ての顧客に対してSLAの締結をするのは困難であるケースもあるため、審査においては全ての顧客に対してSLAを締結していなくても、SLAが策定され、一部の顧客でも締結がされていれば問題ありません。

Q.ISO20000に関連するSLAや方針群についてWebで公開しなくてはならない?

ISO27001と異なり、ISO20000は外部へ公開しなくてはならない事項は要求されていません。
よって、特に外部に公開を行う必要はありません。

Q.全ての供給者に対して契約の締結が必要?

規格で言ってる「供給者」がどこまで該当するのか?というのは非常に悩ましい問題ですが、必ずしも全ての供給者との間に契約の締結をする必要はありません。
電力会社からも電力供給受けてるから供給者じゃないのか?という風にもとらえることができますが、実際に電力会社とそんな個別契約を結ぶなんてことは非現実的でしょう。
(よっぽど特殊な電力供給を受けてるとかであれば別かもしれませんが)

こちらについてはSLAと同様の考え方で、厳密には供給者に該当する企業とは契約を締結する必要があります。
ただし、個別にISO20000用の特殊な契約を結ぶことが困難である場合は、審査においてその旨を説明すれば問題ありません。

Q.サービス提供をしていない第三者からの苦情はどう扱う?

ISO20000の規格上求められている内容に限定して考えた場合、第三者からの苦情は原則、管理対象外です。

規格書にも記載されていますが、求められているのは会社としてのサービス品質向上であり、管理しなくてはならないのは顧客からの苦情のみです。

「顧客」とは、ISO20000取得を目指す企業あるいは部門からサービス提供をうける組織または組織の一部を指しますので、そこからサービス提供を受けていない第三者からの苦情は管理していなくても規格認証上は問題ありません。

とはいえ、第三者から苦情がくるということは規格云々の問題ではなく、会社・部署の問題として対応が必要があると考えられます。

Q.どういったものを苦情とする?

苦情の定義は各企業で定めるものであり、ISO20000においては特に定義が存在していません。
会社あるいは部門としてどういったものを苦情として扱うのか?定義をする必要があります。

Q.インシデントとは?

事故や事件などの意味以外に、事故に繋がりかねない(繋がりかねなかった)出来事、状況、異変、危機を意味します。
ポイントとしては、発生してしまった事象の他に、未発生ではあるが、発生した場合において明らかにサービス中断等の影響を及ぼすことが明らかなものもこれに含まれます。

SMSにおいては、通常運用以外の全ての事象を意味します。

Q.インシデント管理と問題管理はどう違う?

インシデント管理と問題管理は、ざっくりと説明すると・・・ 
インシデント管理=現象の解決
問題管理=根本原因の解決

を意味します。

一つの事象を「現象」と「根本原因」に分けて考え、それぞれを別のステージで管理・解決を図るという考え方をすればよいです。

もう少し具体的な例を挙げて説明すると・・・ パソコンが部品の不具合でフリーズしたという事象が発生したとします。
この場合、上記のインシデント管理、問題管理の考えを適用すると、

▼インシデント管理
インシデント管理では、現象の解決のみを行うので、この場合はパソコンの再起動を行いパソコンがフリーズするという「現象」の解決を図ります。

▼問題管理
問題管理では、根本原因の解決を行います。上記の例の場合では、悪い部品を交換し、パソコンのフリーズが再発しないよう根本原因の解決を図ります。

このように、インシデント管理と問題管理では一見同じこと言っているようでも求められる内容が異なりますので、注意してください。

Q.インシデント管理と問題管理を統合してはダメ?

これも考え方が難しいのですが、インシデント管理と問題管理は全く目的が異なるものです。

インシデント管理では、いかなる手段を用いても良いのでとにかくサービスの復旧を最優先として実施・管理されます。
荒っぽい言い方をすると、インシデント対応の中では原因なんてどうでもいいのです。
とにもかくにもサービスが復旧すれば何でもいいという考え方をします。

一方、問題管理は時間をかけて根本原因を追究し、その原因を排除することを目的としています。
原因を取り除くことによって、同じインシデントの再発を防ぐほか、あらかじめ発生しうるインシデントを予防するなどを目的とします。

つまり、両者は全くスピード感が異なるものです。

インシデント管理は可及的速やかに対処しなければならないもの、問題管理はじっくり時間をかけて「確実に」実施するものということになります。
サービス提供者側からみると、結局どっちも障害対応の延長線上なのだから、一緒でいいじゃないか と思うかもしれませんが、サービスを受ける側からしてみるとどうでしょう?

根本原因が特定されるまで復旧が遅れてしまったりするのは望ましくありません。
利用者からしてみれば原因はともかく直してくれというのが正直なところではないでしょうか。

また、インシデントと問題が同じステージで管理されてしまうと、現在発生中のインシデントを特定づらくなるという問題も出てきてしまいます。
インシデント管理が別のステージで存在することによって、現在進行形で発生しているインシデントが何で、どのインシデントから対応すべきか?といったことも把握しやすくなります。

といったところで、まったく目的も求められるスピード感も異なるものなので、別で管理したほうが良いでしょう。

Q.審査段階で、一部プロセスが運用されていなかった場合は不適合になる?

審査の段階で、仕組みはあるものの重大変更が無かった、インシデントが無かったなどの理由により、運用実績が取れなかった場合でも、審査上は不適合とはならないはずです。
(ここは審査員の捉え方、説明の仕方にもよるところがあるかもしれません)

基本的には仕組みがあり、運用が出来る体制になっていれば大丈夫と思います。
逆に言うと、実際に運用できない仕組みで実績が取れていない場合や、仕組みそのものが無い場合は、不適合となる可能性が出てくると考えられます。

Q.審査で重大不適合となった場合は認定をもらえない?認定がはく奪される?

審査で不適合(重大)となるのは、規格で要求されている内容が「全く」実施されていない場合です。
PDCAサイクルが回っていない、仕組みが全く機能していない場合に判定されます。

従って、ルールはあるけど一部やれていない場合などは重大不適合となる可能性は少ないでしょう。
万が一、重大不適合を食らった場合でも、即認定はく奪にはなりません。
基本的には再審査となるはずです。とはいえ、そんなリスクを冒す必要なんてないのでしっかりやっとくに越したことはないです。

-ISO20000, SKILL
-, ,

Copyright© SCRAMBLE , 2019 All Rights Reserved.