Reading Time: 1 minutes
当連載記事について
当連載記事では、ITIL®の研修を多く手掛ける専門家が、分かり易い口語体でより実際的な観点からITIL®を解説しています。サラッと読みながらもITIL®に基づいた考え方をより実践的なレベルへ落とし込むことができます。また、ITIL®に準拠するための機能を備えたITサービスマネジメントツール「ManageEngine ServiceDesk Plus」を提供するゾーホージャパンより、欄外コラムとしてツールの詳細や関連機能の説明を行います。ITIL®の概念を把握しつつ、ツールを活用した場合のイメージを広げる際の一助となりましたら幸いです。※ITIL® is a Registered Trade Mark of AXELOS Limited. |
はじめに
第七回では保証と開発についてお話したいと思います。
保証とは
突然、「保証」という単語が出てくるので何のことかわからないと思います。そこで、まずITIL®が言う保証というものが何かを説明します。
ITIL®に出てくる「保証」とは、「可用性（ITサービスが使いたいときに使えること）が確保されている状態」、「求められているキャパシティ（処理速度などの性能）が満たされている状態」、「被災したときでも継続的にITサービスを使用できる状態」、「ITサービスのセキュリティが確保されている状態」という4つが確保されていることを意味します。
そして、これらの状態を作るためにITIL®では、サービスデザインというフェーズにそれぞれの状態を作り出すための活動（プロセス）が用意されています。そのプロセスの名前が、「可用性管理プロセス」、「キャパシティ管理プロセス」、「ITサービス継続性管理プロセス」、「情報セキュリティ管理プロセス」というものになります。
可用性管理プロセスとは
では、先に紹介した4つのプロセスとは、それぞれどんなプロセスなのでしょうか？可用性管理プロセスから説明します。
まず、プロセスの名前にもなっている「可用性」について。可用性とは、「使いたいときにITサービスを使える状態」のことです。可用性が高いというのは使いたいときにいつでも使える。可用性が低いというのは使いたいときに使えないという状態のことです。ただし、ITIL®が言う「使いたいとき」というのは、「SLAで顧客とサービス・プロバイダが合意した時間内で使いたいとき」という意味になります。そうしないと、どのITサービスも24時間365日で使える状態にしないとなりませんから。
そして可用性管理プロセスとは、このSLAで合意された範囲内で「使いたいときに使える状態を維持できるように設計する活動」ということになります。具体的に言えば、ネットワーク機器が1台故障し、それによりITサービスが止まってしまっては困るので、ネットワーク機器を冗長化する（1台が壊れてももう1台でITサービスが使えるようにしておく）とかですね。それを設計するのが可用性管理プロセスです。
キャパシティ管理プロセスとは
次にキャパシティ管理プロセス。キャパシティ管理プロセスの名前にある「キャパシティ」が何かといえば、「器」だと思ってください。コップがあって、そのコップに水が180ml入れられるとします。そうしたら、コップのキャパシティは180ml（分の水を入れられる）ということになります。これをITサービスに当てはめ、1秒間に1万個のタスクが処理できるCPUがあったとしたら、そのCPUのキャパシティは「1秒間で1万個のタスク処理量」ということになります。
他にもサーバであれば、HDD容量もサーバのキャパシティといえるでしょう。ネットワークであれば、「HTTPによる1000アクセスに対して1秒以内にレスポンスを返す」などのレスポンスタイムも、処理速度という観点ではキャパシティの一つといえます。そして、このキャパシティを設計しているプロセスがキャパシティ管理プロセスということになります。
ITサービス継続性管理プロセスとは
3つ目がITサービス継続性管理プロセス。「継続性」とは、被災してもITサービスを止めないという意味があります。一方で、止まってしまったら復旧させるということも含まれています。とはいえ、地震、台風、津波、竜巻などの自然災害や、最近ではハッキングによるシステム破壊など、サービスを停止する災害はいろいろあります。国や地域によっても異なるでしょう。
なので、最初に自分の企業にとって、何が災害なのかを決めないといけません。これを決めるところからITサービス継続性管理プロセスはスタートします。そして何が災害なのかを決めたら、その災害が発生する頻度を考え、発生した場合に及ぼされる影響も考える。例えば地震が起きても建物が耐震構造になっているから被害は発生しないということもあるでしょうし、被災してITサービスが止まり、経済的な損失が発生する場合もあるでしょう。よって、一口に影響を考えると言っても、かなり複雑になります。
とはいえ、影響を明らかにできれば、会社として対策をしなければならない災害が明確になります。あとはその災害が発生した際の対応策（耐震構造にするとか、電源が落ちたときの復旧手順を用意しておくとか）を考えておき、訓練によってその手順が問題ないかをチェックします。これがITサービス継続性管理プロセスです。
情報セキュリティ管理プロセスとは
最後に情報セキュリティ管理プロセス。「情報セキュリティ」とは、内外からの不正アクセスを防ぐことで、情報漏洩やデータの改ざんを防ぎ、ITサービスの停止や破壊から守ることなどを指します。そしてこれらの情報セキュリティを脅かす事態からITサービスを保護するための設計プロセスが、情報セキュリティ管理プロセスです。ただ、ITで情報セキュリティの設計をするというと、ネットワーク経由での不正アクセスに対応するためにファイアウォールを設置するとか、認証システムを導入するなどの話になりがちです。
もちろんこれらも対策しなければなりませんが、情報セキュリティとしては一部にすぎません。なぜなら、個人情報が保存されているHDDを社員が引っこ抜いて持ち出してしまえば、ファイアウォールなど意味がありませんから。
なので、情報セキュリティ管理プロセスでは、ITシステムだけではなく人の教育も含めて、どうすれば情報が漏洩せず（機密性が保たれて）、必要なときに利用できて（可用性を維持して）、いかに正確な状態に保っておけるか（完全性の確保）を考えて設計していくプロセスとなります。よって、情報セキュリティ管理プロセスの活動を行うと、いわゆる情報セキュリティ管理方針や、情報セキュリティ管理規定・手順といわれるルールや文書が作成されることになります。
これら4つのプロセスが保証のプロセスといわれるものです。
ITIL®にとっての開発
ITIL®には、ライフサイクルとして5つのフェーズがあるという話を第二回の記事でお話しています。が、その5つのフェーズに「開発」という活動がないことはお気づきでしょうか？やはり、世間でITの仕事をしているといえば、まだまだ「プログラムを書いている」とか「ソフトウェアを作っている」というイメージがあり、いわば開発はITの花形のようなものです。しかし、ITIL®にはその花形がない。さみしいですね（笑。
では、なぜ花形がないのか、その理由は明確にはわかりません。少なくとも、AXELOSから出版されているITIL®の用語集にある「開発」の説明にも「（ITIL®の書籍では）詳細に説明されていない」と記載されており、開発についてITIL®は触れていないというのが事実です。その理由として、私が想像するに2つほど挙げられると思っています。
- ITIL®が目指していることの一つは、サービス品質の向上です。開発とは、実際にITを作り込む作業になりますが、品質の向上は実際に作る作業ではなく、作られたものをテストすることで担保されます。よって、テストをITIL®のプロセスで管理していけばよいと思っているのではないでしょうか。ちなみに、テストを管理する具体的なプロセスにはリリース管理および展開管理プロセスと、サービスの妥当性確認およびテストプロセスがあります。
- 設計書がアウトプットされる「開発」を管理するノウハウは、すでにPMBOK®、PRINCE2®などといった形で世の中に存在しています。このことから、ITIL®は「サービス品質を担保すること」を主軸に考え、開発自体は既存のPMBOK®、PRINCE2®といわれるプロジェクト管理手法を使って実施することを前提としているのではないでしょうか。つまり、サービスデザインのプロセスを使ってしっかりと設計し、その設計通りに開発されているかどうかをテストでチェックすることで品質を担保しようと考えていると思われます。
最後に
ということで、ITIL®のサービスデザインのフェーズでは「可用性」「キャパシティ」「継続性」「情報セキュリティ」を確保するという観点で設計をしていきます。次にITIL®のフェーズにはありませんが、その設計を元にITサービスを形作る活動（開発プロセス）が行われます。そして、後は本番環境に移行すればよいのですが・・・。実は、すでにこの時点でお金がかかっているんですよね。ということで、次回は再び私の大好きなお金の話になります（といってもお金を増やす方法ではないので期待しないでください）。
＞＞記事一覧：ITの品質向上とコスト削減からとらえたITIL®
執筆者情報
日本クイント株式会社 コンサルタント 吉村友秀（よしむら ともひで）主要資格：ITIL® エキスパート、公認情報システム監査人（CISA) |
SLA機能について
連載コラムをご一読頂き、ありがとうございます。ManageEngineでは、ITIL®準拠のためのITSM機能を網羅した「ServiceDesk Plus」というツールを提供しています。
今回は、可用性管理プロセスの話で少し出てきた「SLA」機能について、ご紹介します。第4回のコラムで、ServiceDesk Plusのサービス・カタログ機能がリクエストフォームと連動しており、各リクエストフォームにはSLAを設けることができると説明しました。
この時、実際の設定画面は下図のようになります。
図中の「フォームデザイナー」というタブでは、リクエストフォームに追加したい項目や、リクエストフォームを公開したいユーザグループの情報を設定できます。例えば、外出時に営業メンバーがモバイル端末を持ち出す申請をフォーム上で行うのであれば
・「貸出日程」という項目を追加
・「営業メンバーのグループ」のみがフォームを閲覧できるように指定
などが可能です。
そして、赤枠で示している「ワークフロー」というタブでは申請に対する承認フローの設定などを行えるのですが、この他にSLAの指定もできます。このSLAには、下図のようにリクエストが送信されてから「一次回答」が返されるまでの期日と、「最終的な解決」に至るまでの期日が設定できます。
例えば、請求業務システムやお客様への一斉メール配信システムを日常業務で頻繁に活用する企業であれば、これらのシステムが止まることで業務に支障が出てしまいます。
サービスデスク担当者は様々なリクエストに順次対応しているとはいえ、こういったリクエストの優先度を上げて「2時間以内には最初の回答をしてほしい」「2営業日以内には問題を解決してほしい」といった、事業レベルでの取り決めを、SLAとして反映させることができます（※なお、期日を設定する際は、業務時間を「考慮する／しない」が選択できます）。
さらに、各期日が過ぎる前後には通知先を指定してエスカレーションを行うことも可能です。
上図の場合だと、一次回答期日から1時間経過したタイミングで別のサービスデスク担当者（デモ技術者2）へエスカレーションが設定されています。たまたま最初の担当者が気づけなかった場合でも、これでリクエストが放置されるというリスクを低減できます。
さらに、解決期日から1時間経過したタイミングで、グループのリーダー（デモ技術者3）へエスカレーションすることで、「スムーズに解決できていないみたいだけど、何か重度の障害なのかな」といったことを、よりスキルの高い担当者に認識してもらえます。
さらに解決が遅延し、事業レベルの判断が必要となる可能性がある場合は、図中のように「中村部長」へエスカレーションするといった設定が必要かもしれません。
＜ツールを触ってみたくなったら＞
いかがでしょう。ServiceDesk PlusのSLA機能は、対応期日を起点とし、それが守られなかった場合のエスカレーションやアクション設定を行うという、シンプルなものです。しかし上手に活用すると現場の運用やユーザの満足度が大きく改善されるかもしれません。
本日ご紹介した設定は、プログラミングの知識が無くても簡単に試すことができます。検証用に30日間無料で使える評価版（オンプレミス版／クラウド版の両方）もご用意していますが、そこまで真剣に検証できないという方には「体験デモサイト」がお勧めです。
グローバル共用のデモサイトなので、英語のデモデータが登録されていますが、GUIは日本語として表示されますので、ぜひお試しください。
＞＞体験デモサイトにログイン（※クリック後、実際のツール画面が開きます）
ログイン後、管理画面から「SLA（サービスレベル契約）」というリンクをクリックしてください。
その他、下記の情報もぜひご利用ください。
＜製品について情報収集したい方＞
＜製品について質問したい方＞
フィードバックフォーム
当サイトで検証してほしいこと、記事にしてほしい題材などありましたら、以下のフィードバックフォームよりお気軽にお知らせください。