2016年11月18日金曜日

お知らせ:ブログの移転

当ブログをご覧いただき、誠にありがとうございます。

 この度、当ブログを以下のURL(ユニリタホームページ)に移転しました!

 移転先でも引き続きご覧いただければ幸いです。

 ↓↓
http://www.unirita.co.jp/blog/digital-business/digital-business-person/

2016年10月27日木曜日

デジタルビジネスの競争力に直結する変更管理のポイント(前編)

こんにちは、デジタルビジネスのシステム運営に関するコンサルティングを担当している河村です。
今回は変更管理プロセスをとりあげて書きます。


デジタルビジネスにおける変更対応の重要性:
変更対応は、デジタルビジネスの競争力に直結する特に重要な領域です。他社サービスとの競争に勝つため、カットオーバー後も継続的にサービスのアップデートやインフラの増強が行われ、その頻度と求められるスピードは基幹系システムとは比べられません。

一方で、変更対応に起因するシステム障害が多いのも特徴です。変更管理では、こうしたビジネスにとって有益な変更対応を、トラブルなく実施できるようにコントロールするのですが、ここで基幹系システムに取り入れられている変更管理プロセスをそのままデジタルビジネスのシステム運営に適用してしまうと、ビジネスのスピードや柔軟性が損なわれる可能性が高いです。ビジネスの競争力を損ねるようでは本末転倒ですので、工夫が必要となります。


変更管理とは:
変更管理についてはITIL®で目的や達成目標、活動内容がまとめられていますが、それ以外にもISO20000の要求事項(ITSMS)や、監査対応時の主なチェックポイントなども参考になります。以下にその概要をまとめます。


ITIL®における変更管理
  • 変更とは、ITサービスに影響を及ぼす可能性のあるものを、追加、修正、または削除することを指す
  • 変更管理の目的は、すべての変更のライフサイクルをコントロールし、ITサービスの中断を最小限に抑えながら、有益な変更を実施できるようにすることである
  • 変化する事業要件に対応すると同時に、価値を最大化し、インシデント、中断、手直しを削減する
  • 変更要求の記録から評価、優先度付け、計画、テスト、実施、文書化、レビューまでをコントロールする


ISO20000における変更管理の要求事項の例
  • 変更管理方針を確立し、変更管理が制御している構成アイテムと、サービス又は顧客に重大な影響を及ぼす可能性のある変更を判断する基準を定義しなければならない
  • 変更要求を記録し、分類し、評価し、承認する文書化された手順をもたなければならない
  • サービス提供者は、緊急変更の定義について文書化し、顧客と合意しなければならない
  • 緊急変更を管理する文書化された手順をもたなければなならない
  • サービス又はサービスコンポーネントへのすべての変更は、変更要求を用いて提起しなければならない
  • 承認された変更は、開発し試験しなければならない
  • 承認された変更の詳細及びその展開の期日案を含む変更スケジュールを策定し、利害関係者に周知しなければならない
  • 失敗した変更を元に戻す、又は修正するために必要案活動を計画し、可能な場合に試験しなければならない
  • CMDBの記録は、変更の展開の成功後に更新しなければならい


監査対応時のチェックポイントの例(内部統制におけるIT全般統制、ITガバナンスにおけるシステム監査)
  • 規程・手順書・マニュアルなどが策定されているか、CIOIT部門長による正式な承認を受けているか
  • 規程やマニュアルが関係部門に周知・徹底されているか
  • 変更依頼書が作成されているか(変更ログはあるが変更作業依頼書がないものはないか)
  • 変更依頼書は、依頼部門の承認を受けているか
  • 変更依頼書は、IT部門の責任者の承認を受けているか
  • 要件定義書と設計書の整合が取れているか。設計書とプログラム機能書の整合性がとれているか
  • 変更作業に作業工数や期間が異常にかかっているものがないか
  • 本来の担当者以外の者が変更作業を行っていないか
  • 変更作業を行っている場所の情報セキュリティが確保されているか
  • 変更作業の件数・作業工数・コストなどについて、アプリケーションシステム間で比較して、異常値がないか
  • テストや変更内容の事後確認が行われているか
  • 変更作業完了報告書は、依頼部門に送付され、依頼部門の責任者の承認を受けているか
  • 変更依頼書と変更作業完了報告書の整合性がとれているか


後編に続きます。

2016年10月25日火曜日

デジタルビジネスのサービス品質改善のための問題管理のポイント(後編)

前回に続き、問題管理プロセスを実施する際のポイントについて書きます。

前編はこちら


根本原因を深く掘り下げ、開発フェーズの対策にまでつなげる:
問題管理では、インシデントおよび問題の事業に対するインパクトを最小限に抑え、インシデントの再発をプロアクティブに防止することを目指します。その際に特に重要なのが、根本原因の特定です。

例えばプログラムの不具合に起因するインシデントを例にとると、プログラムを修正すれば、そのシステムにおいて同様のインシデントが発生することを防ぐことはできます。ここでもう一歩掘り下げて、不具合を発生させたそもそもの原因が、開発工程やプロジェクトマネジメントになかったかどうかを分析すると、より効果的です。システムアーキテクチャへの対応だけでなく、システムの開発から運用に至るプロセス、ルール、ツール、各種基準や文書に修正すべき点がないかまでを分析することで、本質的な根本原因への対策が可能となります。このような活動が定着すると、運用から開発へのフィードバックサイクルが回り、トラブルを未然に防ぐ仕事の仕方に変わっていきます。


サービス横断で対策を行い、対岸の家事を防ぐ:
根本原因を特定したら、変更要求を起票して恒久対応を行います。その際に重要なのが、直接の影響を受けたサービスやシステムだけでなく、似たような根本原因がほかのサービスやシステムにも内在していないかを洗い出し、横断的に対策を行うことです。

特にデジタルビジネスでは、サービスやシステムごとに担当者が縦割りな事例をよく見ます。その場合、担当者間での情報共有が行われず、以前あるサービスで発生したトラブルと似たようなケースがあちこちで再発しがちです。こうした「対岸の火事」を防ぎ、組織としての品質向上に取り組むためには、問題管理を特定のサービスや担当者でクローズさせず、組織横断・サービス横断で取り組む必要があります。


ワークアラウンドを発見し、既知のエラーとして登録・活用する:
ワークアラウンドとは、問題によって発生したインシデントの困難を克服する、一時的な方法のことです。問題の中には恒久対応が困難なものがあります、そのような防止できないインシデントについては、発生時の事業へのインパクトを最小化できるよう、ワークアラウンドを見つけ、ナレッジとして残しておくと効果的です。ITIL®では、根本原因とワークアラウンドを文書化したものを、既知のエラーと定義しています。


KPIでパフォーマンスチェック:
定義したプロセスフローや基準が有効的・効率的に機能しているかどうかを評価し、改善を推進することが、継続的なプロセスの強化につながります。例えば以下のKPIを設定し、ツールから実績データをとれるようにするとよいでしょう。
  • ITサービスごとの未処理の問題の数(品質改善の指標)
  • ITサービスごとの再発インシデント数(多いようなら、根本原因の特定および対策が不十分)
  • 登録された既知のエラーの数(防止できないインシデントの事業インパクトを最小化する)

2016年9月29日木曜日

デジタルビジネスのサービス品質改善のための問題管理のポイント(前編)

こんにちは、デジタルビジネスのシステム運営に関するコンサルティングを担当している河村です。
今回は問題管理プロセスをとりあげて書きます。


デジタルビジネスにおけるシステム障害削減の重要性:
先日も書きましたが、デジタルビジネスは売り上げや利益に直結するケースが多く、システム障害が発生した際のインパクトは膨大です。システムが停止すればユーザーがサービスを利用できなくなり、利用料・課金額の減少や、顧客満足度の低下、リピート率の低下といったことが起こります。中には1つのインシデントが1000万の機会損失につながると見積もられているケースもあり、障害を起こさないこと、起こしてしまった際にはなるべく早く解決することは、経営視点で見ても重要な課題です。

こうしたトラブルを極力減らし、ビジネスへのダメージを最小化するための組織的な改善活動を行うには、発生したトラブルに対して再発防止のための恒久対応を行い、また傾向分析により障害につながりそうな事象をとらえて未然防止のための予防保守を行う、標準的な手法と手順が必要です。これに該当するのが、問題管理です。


問題管理とは:
問題管理についてはITIL®で目的や達成目標、活動内容がまとめられていますが、それ以外にもISO20000の要求事項(ITSMS)や、監査対応時の主なチェックポイントなども参考になります。以下にその概要をまとめます。


ITIL®における問題管理
  • 問題とは、1つまたは複数のインシデントを引き起こす根本原因をさす
  • 問題管理の目的は、ITシステムに内在するエラーによって引き起こされるインシデントおよび問題の事業に対するインパクトを最小限に抑え、インシデントの再発をプロアクティブに防止することである
  • インシデント発生の未然防止、発生したインシデントの再発防止、防止できないインシデントのインパクト最小化を行う
  • 問題の識別から、さらなる調査、文書化、最終的な除去までを管理するための、標準化された手法と手順を使用されるようにする

ISO20000における問題管理の要求事項の例
  • 問題を特定し、インシデント及び問題の影響を最小化又は回避するための、文書化された手順をもたなければならない
  • 手順には、識別方法、記録方法、優先度基準、分類、エスカレーションルート、解決・終了を定義しなければならない
  • 問題は上記手順に従って管理しなければならない
  • サービス提供者は、根本原因及び潜在的な予防処置を特定するため、インシデント及び問題のデータ及び傾向を分析しなければならない
  • CIの変更を必要とする問題は、変更要求を提起することによって解決しなければならない
  • 根本原因が特定されたが、問題が恒久的に解決されていない場合、サービス提供者はその問題がサービスに及ぼす影響を低減又は除去するための処置を特定しなければならない
  • 既知の誤り及び問題解決に関する最新の情報を、インシデント及びサービス要求管理プロセスに提供しなければならない

監査対応時のチェックポイントの例
(内部統制におけるIT全般統制、ITガバナンスにおけるシステム監査)
  • 規程・手順書・マニュアルなどが策定されているか、CIOIT部門長による正式な承認を受けているか
  • 規程やマニュアルが関係部門に周知・徹底されているか
  • 応急対応だけでなく、本格対応まで行い、再発防止策が確実に講じられているか
  • 本格対応まで確実に実施されるような障害報告書の書式になっているか
  • 根本原因の調査を行っているか(発生した事象としては異なる障害であっても、その根本的な原因が同じ場合がある)
  • 根本原因の究明が行われやすい仕組みになっているか
  • 障害報告書をレビューし、同様の障害が発生していないか
  • 障害管理がシステム化されている場合には、障害管理データを分析して同様の障害が発生していないか

後編に続きます。

2016年9月16日金曜日

デジタルビジネスのサービス品質改善の入り口となるインシデント管理のポイント(後編)

こんにちは、デジタルビジネスのシステム運営に関するコンサルティングを担当している河村です。
前回に続き、インシデント管理プロセスを実施する際のポイントについて書きます。


重大インシデントと通常インシデントでプロセスフローを分ける:
インシデントには、サービス中断に至るクリティカルなもの(重大なインシデント)もあれば、冗長化しているサーバの一つが壊れただけでサービス品質にあまり影響のないもの(通常のインシデント)もあります。これらの対応に同じプロセスフローを適用すると、重大インシデント発生時のサービスレベル要件に引きずられて非効率になったり、通常インシデント発生時のサービスレベル要件に対応がとどまりユーザーの満足度が下がったり、といった問題が起こります。

重大インシデントと通常インシデントの分類基準を明確化したうえで、これらの対応プロセスフローを分けて標準化することがポイントです。重大インシデント発生時の対応には、通常インシデント発生時の手順に加え、以下を定義するとよいでしょう。
  • 影響範囲や復旧時間に関するユーザーアナウンスの手順、頻度、実行責任者、承認者
  • 社内関係者への状況報告の実施手順、頻度、範囲
  • 事後のお詫び対応の実行有無を判断する手順、実行責任者、承認者


サービスレベル要件との整合性を確保する:
デジタルビジネスのITシステムでは多くの場合、高いサービスレベルが求められます。しかし、本来求められるサービスレベルに対して実態があっておらず、求められるサービスレベルを満たせなかったり、過剰なコストを払っていたり、といったことがよく見られます。以下に、その例を記載します。
  • 本来は24時間365日のサポートが求められるにもかかわらず、一部の作業を社員が実施しているため、夜間や休日は十分な対応ができない(ストレスもたまる)
  • 本来求められるサービスレベル以上のサポート体制でベンダーと契約しており、過剰なコストを支払い続けている
  • 24時間365日のサポート体制でベンダーと契約しているが、休日夜間問わず復旧作業の承認を必ず社員が行う手順になっているため、そこがボトルネックとなり実態はベストエフォート対応にとどまっている

こういったことを起こさないためには、求められるサービスレベル要件を定義したうえで、それに準じた契約をベンダーと結ぶ、社内の体制がボトルネックとならないよう手順化や権限移譲を進める、といった対応を行うことが有効です。


問題管理へのエスカレーション基準を定義する:
インシデント管理だけをいくら頑張っても、品質は上がりません。問題管理へとつなげ、恒久対応・再発防止を徹底しなければ、いつまでたっても楽になりません。担当者の意識に左右されないよう、どういう場合に問題管理へとエスカレーションするのかを明確化したうえで、それが徹底されているかどうかをモニタリングできるようなプロセスフローとツールを整備する必要があります。また、徹底状況を常に確認し、指導や是正処置を推進することに責任を持つ問題管理マネージャーを任命することも有効です。


KPIでパフォーマンスチェック:
定義したプロセスフローや基準が有効的・効率的に機能しているかどうかを評価し、改善を推進することが、継続的なプロセスの強化につながります。例えば以下のKPIを設定し、ツールから実績データをとれるようにするとよいでしょう。
  • インシデント発生から初動までのリードタイム(早いほどビジネス影響を小さくできる、ベンダーのパフォーマンス指標の一つ)
  • インシデントの一次解決率(同じようなものが何度もエスカレーションされるようなら、ナレッジ共有が不十分)
  • 復旧までの時間(短いほど、ビジネス影響を小さくできる)
  • 再発インシデント数(再発しているようなら、問題管理が不十分)

2016年8月31日水曜日

デジタルビジネスのサービス品質改善の入り口となるインシデント管理のポイント(前編)

こんにちは、デジタルビジネスのシステム運営に関するコンサルティングを担当している河村です。
前回はITサービスマネジメントの概要をご説明しましたが、今回はその中のインシデント管理プロセスをとりあげて書きます。


デジタルビジネスにおけるシステム障害発生のインパクト:
デジタルビジネスは売り上げや利益に直結するケースが多く、システム障害が発生した際のインパクトは膨大です。システムが停止すればユーザーがサービスを利用できなくなり、利用料・課金額の減少や、顧客満足度の低下、リピート率の低下といったことが起こります。中には1つのインシデントが1000万の機会損失につながると見積もられているケースもあり、障害を起こさないこと、起こしてしまった際にはなるべく早く解決することは、経営視点で見ても重要な課題です。

こうしたトラブルを極力減らし、ビジネスへのダメージを最小化するための組織的な改善活動を行うには、発生したトラブルに対して効率的かつ迅速に検出・分析・復旧対応を行い、きちんと記録を残して恒久対応(再発防止、未然防止)につなげる標準的な手法と手順が必要です。これに該当するのが、インシデント管理です。


インシデント管理とは:
インシデント管理についてはITIL®で目的や達成目標、活動内容がまとめられていますが、それ以外にもISO20000の要求事項(ITSMS)や、監査対応時の主なチェックポイントなども参考になります。以下にその概要をまとめます。


ITIL®におけるインシデント管理
  • インシデントとは、ITサービスに対する計画外の中断やITサービスの品質の低下、またはサービスにまだインパクトを与えていない構成アイテムの障害をさす
  • インシデント管理の目的は、通常のサービス運用を可能な限り迅速に回復させ、事業運営へのマイナスのインパクトを最小限に抑え、合意したレベルのサービスレベルを維持することである
  • 「通常のサービス運用」とは、サービスと構成アイテムが、合意済のサービスレベルおよび運用レベルの枠内で機能している運用状態として定義されている
  • インシデントに対する効率的かつ迅速な応答、分析、文書化、継続的な管理と報告のために、標準化された手法と手順を使用されるようにする 

ISO20000におけるインシデント管理の要求事項の例
  • 記録方法、優先度基準、分類、エスカレーションルート、解決・終了基準を定義した、すべてのインシデントに対する文書化された手順をもたなければならない
  • インシデントは上記手順に従って管理しなければならない
  • インシデント管理プロセスに関与する要員が、関連する情報(手順、既知の誤り、問題解決、CMDB)にアクセスし使用できることを確実にしなければならない
  • サービス提供者は、報告されたインシデントの進捗状況について、継続的に顧客に情報を提供しなければならない
  • サービス提供者は、重大なインシデントの定義について文書化し、顧客と合意しなければならない
  • 経営陣は、重大なインシデントについて通知されなければならない
  • 合意されたサービスの回復後、改善の機会を特定するために、重大なインシデントをレビューしなければならない

監査対応時のチェックポイントの例
(内部統制におけるIT全般統制、ITガバナンスにおけるシステム監査)
  • 規程・手順書・マニュアルなどが策定されているか、CIOIT部門長による正式な承認を受けているか
  • 規程やマニュアルが関係部門に周知・徹底されているか
  • 障害が発生してから対応が完了するまでの時間は適切か、対応作業に必要以上に時間がかかっていないか
  • 担当者のスキルに問題はないか、管理者の管理に問題はないか、手順書やマニュアルの内容に不足はないか
  • 障害発生時に適時・的確にIT部門長、システムオーナ部門長などに報告されているか、連絡の遅延が発生してないか
  • 重大な障害の場合には経営者への報告が適時に行われているか
  • 恒久対応まで確実に実施されるように障害報告書の書式になっているか
  • 委託先からの障害報告が適切・適時に提出されているか、障害報告の内容は適切か、障害報告の内容をチェックしているか
  • 障害の原因が委託先に起因している場合の対応について、定められているか


後編に続きます。

2016年8月23日火曜日

デジタルビジネスのシステム運営効率化に有効な「ITサービスマネジメント」とは?

こんにちは、デジタルビジネスのシステム運営に関するコンサルティングを担当している河村です。
今日は、デジタルビジネスのシステム運営効率化に有効である「ITサービスマネジメント」とは何かについて書きます。

ITサービスマネジメントの定義:
ITサービスマネジメントとは、事業のニーズを満たす良質のITサービスを実施および管理することを指します。ITサービスとは、顧客や利用者の視点から見たITを指し、その中には利用するITシステムに加え、それらを稼働させて利用可能にするためのあらゆるプロセスやそれを行う人・組織も含まれます。












デジタルビジネスの場合、ITサービスはデジタルビジネスそのものであり、事業のニーズとしてはビジネスの売上・利益目標の達成や、ユーザー満足度の向上などが当てはまります。


ITサービスマネジメントを実施する効果:
デジタルビジネスにおいてITサービスマネジメントを実践することで、体系立てられた手法に基づき、組織は以下の項目を実現することが可能となります。
  • サービスのユーザー満足度を向上させる(リピート率の向上)
  • デジタルビジネスのIT戦略を経営戦略と整合させる
  • デジタルビジネスのシステム運営の品質向上、スピードアップ、工数削減を継続的に推進する
  • デジタルビジネスのシステム運営のパフォーマンスを測定、モニタ、および最適化する
  • ITの投資と予算を管理する
  • リスクを管理する、IT統制やITガバナンスに対応する
  • ナレッジを管理する
  • ITコストを最適化/削減する

など


ITサービスマネジメントのベストプラクティス「ITIL®」:
デジタルビジネスにおいてITサービスマネジメントを実践する際には、業界で広く利用されているベストプラクティスである「ITIL®」を活用することが有効です。実際のシステム運営業務をITIL®に照らし合わせてギャップを分析することで、どこに問題があるのかを効果的・効率的に洗い出し、標準化に向けた対策をうつことができます。

ITIL®
ITサービスマネジメントの分野において、最も広く認知され、信頼されている、ベストプラクティス(成功事例)のこと。ITサービスマネジメントのための各種標準プロセスが記述されている。ITIL®の出所は英国商務局(OGC : Office of Government Commerce)である。日本におけるITIL®の普及促進を目的として、itSMF ジャパンが20035月に設立されている。


ITIL®の構成:
ITIL®は、サービス・ライフサイクルの5つの段階(ストラテジ、デザイン、トランジション、オペレーション、継続的サービス改善)で構成されており、それぞれに標準プロセスや機能が定義されています。


















次回からは、これらのプロセスや機能についていくつかピックアップし、デジタルビジネスで実践する際のポイントを解説したいと思います。