2016年11月18日金曜日

お知らせ:ブログの移転

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

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

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

 ↓↓
http://www.unirita.co.jp/blog/systems-operation/it-service/

2016年11月2日水曜日

業務改善に役立つかもしれないプロセス成熟度フレームワークについての知識

こんにちは。高橋です。

今回は、『プロセス成熟度フレームワーク』について触れてみたいと思います。

プロセス成熟度フレームワークは、COBIT(Control Objectives for Information and related Technology)という組織が提唱する、ITガバナンスのベストプラクティス集で定義されているフレームワークです。

と、これだけ聞くとどんなものかよく分かりませんが、簡単にお伝えすると、現状の業務プロセスがどれだけ適切に定義され、運営されているかを測定するフレームワークです。

では、なぜ業務プロセスを測定することが必要なのでしょうか。
測定することで分かることは以下の2点となります。


  • その業務プロセスがどの程度標準化されているか、また改善がされているかという現在の状態を把握できる。
  • 業務プロセスが目指すべき状態を明確にして、現在の状態とのギャップを明確にする。


初心者の人がいきなり高い目標を設定したり、上級者の人が低すぎる目標を設定しても、なかなかレベルアップできませんよね。
プロセス改善を行うには、まず現状の状態を知り、そのレベルに適した目標を設定することが必要です。

それでは各レベルの概要を見てみましょう。


レベル0:存在しない
認識可能なプロセスが存在していない。
対処すべき問題も認識されていない。

レベル1:初期
対応が必要な問題の存在については認識されている。
ただし、標準化されたプロセスは存在せず、問題の対応は個人的にまたは、場当たり的に行われている。

レベル2:反復可能
同じ仕事を別の人が行っても、同様の手順で行われる程度のプロセスは存在する。
標準的なプロセスを研修、周知は行われていないため、実行は個人の知識に委ねられ、誤りが生じやすい。

レベル3:定義済み
手順が標準化および文書化され、研修を通じて周知されている。
しかし、標準化された手順に従うかどうかは個人に任されており、定義されたとおりでないことが発生しても発見しにくい。
プロセス自体は、既存のものを正式化しただけで、最適化はされていない。

レベル4:管理可能
手順の順守度を監視及び計測することができ、プロセスが効果的に機能していないと判断された場合には対策をとることができる。
プロセスは改善が常に行われ、良好なプロセスへとつながる。自動化及び各種管理ツールは部分的に使用されている。

レベル5:最適化
継続的改善、および他部門や他社との比較による成熟モデルを適用してきた結果として、プロセスがベストプラクティスの域に達している。
IT部門は統合され、ワークフローが自動化されている。これにより品質と有効性を向上させるツールを提供しているので、適応性は高い。


どのレベルに当てはまったでしょうか?
実際に分析する時には、レベルの中でも複数項目に分けて、何ができているのかチェックしてみると分かりやすいと思います。
<例>

完全にどのレベルか当てはまらなくても、下のレベルのものでできていないところがあれば、そこから改善していくと、段々と上のレベルに近づいて行くでしょう。

「とりあえず業務が回っているからいいや…」と問題を放置しておくと、今は問題が起きていなくても、将来的に問題が発生する可能性もあります。
これを機に、業務プロセスを見直してみてはいかがでしょうか。

2016年10月19日水曜日

インシデントクローズでNO残業ライフ

こんにちは佐野です。
10月も下旬になってもまだ暑い日がありますが、いかがお過ごしでしょうか?

私はと言いますと、最近発売しましたPSVRを被って、日々あっちの世界と交信しています。
裏社会のエージェントになったり、殺人鬼と対峙したりと今の最新技術は素晴らしいと直に体感できて、中々刺激を受けたこの頃です。

仕事を早く終わらせてプライベートを充実させたいと思いますが、最近では残業時間がとても深刻な話題として取り上げられていますね。
国でも総出で残業時間を減らそうと取り組んでいますが、過労等の事件も多く出ています。

自分の仕事は定時に終わっていますか?

現状、終わらない人が大半だと思います。
特にサポートデスクや運用に携わっている人はそうだと思います。
日々絶えないインシデントのクローズを目的に格闘している事でしょう。

そこで今回は少しでもインシデントを減らしたり早くクローズできるような運用や行動について私なりにまとめたいと思います。



1.インシデントの受付を電話で行わない
サポートデスクであるとどうしても電話対応が多くなってしまいますね。
インシデントの電話を受けその場で紙に書き留めて、あとで対応を行う。
この場合問題となってくるのが、インシデント内容漏れと受付の絶対数になります。
あとはインシデントをノウハウとしてツールに貯めている場合はインシデント入力工数も問題となります。
この場合一番有効となるのが、電話対応からメールやWebページ受付の一本化にすることです。
インシデント内容は文章にあるので少なくとも聞き逃しはなくなりますし、受付絶対数も気にしなくて良くなります。
ツールにため込んでいる場合もコピペである程度高速化できるようになります。
電話受付のほうがクローズが迅速な場合もありますが、ITサービスになりますと、中々その場というのは難しいものですので、電話受付を極力減らすのはどうでしょうか。




2.プロセスの統一化、属人化の排除
もう一つはプロセスの統一化をする事です。
少なくとも以下のプロセスは確立させると良いと思います。
一つは引き継ぎに対する手順です。対応中のインシデントをその人だけでしかできない事を排除しましょう(属人化の排除)。
対応者がいなくなっても他の人がすぐに引き継げるようなプロセスを確立させておきましょう。
二つ目は誰でもインシデント対応ができるような手順プロセスを確立させることです。
新人でも即戦力になるようにすると人の増員でインシデントをクローズできる確率も増えます。
簡単な手順でもいいので人によって作業がばらつくのだけを無くしましょう。
三つ目に対応できない場合のエスカレーション先をうやむやにしない事です。
エスカレーション先の責任者がいないことで対応する人がいなくなる場合が最悪です。
とりあえずは上記の三つのプロセスは確立させると良いと思います。




以上、2点あげましたが、インシデントの発生を減らすことがやはり長期的に見て重要な課題だと思います。
ITILプロセスで言いますと、インシデント管理から問題管理適切にエスカレーションし恒久対応を行うことです。
中々問題管理に上げるべきインシデントというのは選定する条件が難しいですが、統一されたプロセスでインシデント内容の確実な記録で条件も分かりやすくなるのではないかと思います。

私も良いVRライフをするために残業時間を減らそうと日々精進したいと思います。

2016年10月5日水曜日

ITサービスの品質を向上する問題管理

こんにちは開発の小林です。
 
今回は「問題管理」プロセスの入門編について書こうと思います。
 
問題管理プロセスというのは、インシデント管理プロセスと同じようなもののように思われそうですが、実際にはその内容が大きく異なります。
 
インシデント管理では、サービスで障害が発生してから正常な状態までどれだけ迅速に回復させることができるかということに焦点を当てており、これに対し問題管理では、その障害の根本原因を特定し解決方法を提供して、完全にその障害の原因を取り除くことを目的としています。
 
また、普通はインシデント管理プロセスよりエスカレーションされてから、それが既知のエラーなのかどうか、または、未知の問題であった場合にその根本原因が何なのかを調査することが主な活動(リアクティブ)になりますが、インシデントの傾向を分析して、将来の発生を未然に防ぐという活動(プロアクティブ)も、問題管理の中に含まれています。
 
事後対応の問題管理の活動として、だいたい以下のようなものがあります。
 
1) 情報の収集と記録
ここでは、なるべく詳細な情報を取得する必要があります。これには、以下のような情報が含まれるでしょう。
  ・事象の詳細
  ・ログなどの記録
  ・構成情報
  ・回避策の有無
  ・障害発生前に行った変更
ここで、解決のために有効な情報がどれだけ取得できるかが重要になります。また、インシデント管理プロセスと問題管理プロセスとの連携がうまくいっていないと、問題管理へのエスカレーションも有効に機能しないでしょう。
 
2) 問題の分類と優先度の設定
収集した情報から、問題を分類して優先度を設定します。分類と優先度の設定方法は、インシデント管理プロセスと同様になります。
 
3) 問題の診断と調査
ここでは、収集した情報をもとに問題の切り分けを行い、問題が発生している部分を特定します。また、過去に類似の問題が発生していないか確認を行います。
以下の点について考慮する必要があるでしょう。
  ・解決までの期間の見積もりやタイムリミット
  ・コストはどれくらいか
  ・部署間の連携は必要か(メーカーやパートナーなどとも連携する場合があります)
  ・影響の範囲がどれくらいあるか
  ・システムを復旧できるか、どこまで復旧することが可能か

4) 問題の解決とクローズ
問題の根本原因を取り除くための解決策を確認します。パッチ適用などのプログラムへの変更がある場合には、変更管理プロセスにエスカレーションします。問題が発生した環境で、問題が解決したことを確認したら、問題をクローズします。

その他の問題管理の活動としては、問題解決の進捗の確認や、解決した問題のレビューなどがあります。

そして、問題管理プロセスを導入したときの効果には、以下のようなものがあるでしょう。その結果として、ITサービスの品質向上が期待されるでしょう。
  ・障害の再発防止
  ・ノウハウやFAQの蓄積
  ・サービスデスク内での自己解決率の増加
  ・インシデント件数の減少 
 

2016年9月26日月曜日

サービスデスク担当者が語る!障害対応におけるメール対応アンチパターン

はじめまして。サポートを担当している中倉です。

私は普段サービスデスクを担当しております。
その中で、障害対応の進捗が進まなかったり、中々クローズができない問合せが発生する時があります。
経験上、以下のような内容の報告メールや対応を行った際に発生する可能性が高いと認識しております。

①事実確認を行わない
➾事実関係を認識できていない状態でやり取りを行うと、無駄な工数が発生する可能性があります。
お問合わせがあった際は、まず、画面やログを頂くようにしましょう。

②口頭でのやり取りの記録を残していない
➾お問い合わせ内容によっては、メールだけではなく、途中に電話での対応が発生するケースが存在します。
この際、会話して合意した内容を改めてメールで送ることにより、互いの認識のズレを防ぐことができます。
また、メールで返信をすることで、お客様の方でも過去の問合せを確認することができるようになります。
文面で残すことは双方にとってメリットが出てくることですので、記録に残すようにしましょう。

③期限を設定していない
➾回答に対しての期限を設定しなかったり、受け答えが無い場合のリマインド等を行わない場合、お客さま側での対応の優先度が下がってしまい、回答が帰ってこない場合があります。
いつまでに、何をやってもらいたいのかといった、こちらからの希望を明確に伝えることは、お客様にとっても動きやすい結果となります。
お客様が忙しいかもしれないといった、気遣いをすることによって、要望を伝えないといったことはせずに、きちんと要望を伝えるようにしましょう。


上記のようなものは、アンチパターンの一部ですが、こういったことに気をつけることによって、効率的に障害をクローズすることが出来るようになります。
また、お客様にとっても、障害を早期にクローズすることで、ビジネスへの影響を抑えることが出来るようになります。

2016年8月19日金曜日

インシデント管理で何がしたかったんだっけ?
~ITSM活動の目的とビジョンをもう一度振り返ろう~

こんにちは。流行りのナイトプールが気になって仕方がない志波です。


最近、ITサービスマネジメント(以下、ITSM)に取り組まれている担当者の方とお話させていただく際に、
 ・ITSMの活動を始めたものの、成果に上手く結びついていないな
 ・登録をしているけど次に何をすればいいのかわからない
 ・成果が出ているのか分からないけど成果を報告しないといけなくて困っているよ
という声を少なからず耳にします。

今回は、ITSMの活動を続けてきたみなさんやこれから始めたいみなさんと一緒に、ITSM活動の目的やビジョンを考えていきたいと思います。

1.活動の目的とビジョンを考える                  


さて、みなさんはITSMの活動を始めるにあたり、何を期待していましたか?
また、これから始めるにあたり何を期待していますか?

 ・あの人がいないと対応ができないという状態をなんとかしたい(属人化の解消)
 ・仕事の流れ(プロセス)をわかりやすくシンプルにしたい(業務プロセスの見える化・シンプル化)
 ・監査で、作業証跡やプロセスについて指摘されないようにしたい(監査対策)
 ・ユーザニーズや世間のニーズに応えたい(更なる業績やサービス品質の向上)
 ・トラブルが起こる日常をなんとかしたい(安定した業務の実現)
 ・ベンダ毎に報告内容や対応方法がばらばらでなんとかしたい(ベンダコントロールの実現) ・・・etc

こうした様々な期待が、『ITSMを取り組む目的』(=目指すべきビジョン・将来像)となるわけですが、この目的がしっかりしていないと、取り組みを続ける上に『そもそも何がしたかったのか』がぶれてしまいます。取り組みの目的が後々ぶれてしまわないよう、企画書などに”目的を明文化する”ことをおすすめします。

”目的を明文化する”ことで、目指す目標がわからなくなったときに振り返りができたり、後任へ引き継ぐ際にも主旨や目的が正しく引き継げるため、『活動が形骸化しにくい』などといったメリットがあります。

-前任から引き継いだけど、何を目的にした活動か分からないし、上司にも成果を報告しないといけなくて困っている・・・という話をよく聞きますので、ぜひぜひこの機会に。

また、目的を考える上で大切なことは『どうなりたいか』というビジョン(状態目標)です。

ひとまずは、目先の事態やトラブル解消を目的とした活動で構いませんが、『それらが解消された先に目指すべきビジョン(どうなりたいか、どうなっていたいか)』を考えることが取り組みを続ける上で大切なキーになります。KPIを立てるのが難しいという声もお聞きしますが、困ったときには『どうなりたいか』というビジョンを考えると立てやすいかと思います。

 参考:前回記事「インシデント管理と問題管理のKPI改善に向けた初めの一歩

また、目的を定めることが難しい場合は、『何に困っていてどうしたいか』を考えてみると、分かりやすいかもしれません。

2.活動の妨げとなる要因を押さえ、継続して取り組める活動にする   


では次に、活動を続ける上で成果の妨げとなる要因について考えていきましょう。
しっかりと活動が継続できている場合は問題ありませんが、上手くはいっていないケースの方が上手くいっているケースよりも多いのではないでしょうか。

それでは、何が活動の妨げになっているのでしょう。

 ・活動の継続するためのルールが多く、現実的に守ることが不可能・困難(複雑なルール)
 ・せっかく定めたルールが徹底されない、浸透していない(ルールの不徹底、管理者不在)
 ・経営層に活動を継続する目的を問われ、予算取りや人の確保が大変(経営層への説明不足)
 ・運用ルールにツールがついてこれない(業務に合わないツール)
 ・報告用の資料を作ることに膨大な時間がかかる(時間のかかる報告書作成) ・・・etc

このような話は特によく聞きます。

それぞれ原因が異なるため、一概にこうすべきだと提言することは難しいですが、活動を継続することで大切なことは、
 ・ルール、業務プロセスがシンプルであること(シンプルなルール)
 ・管理プロセス毎の目的が定義され、公開されていること(目的の見える化)
 ・また、目的に則した現状が利用者、管理者に公開されていること(状態の見える化)
 ・少ない管理工数で運営ができること(手のかからない運営)
かと思います。

とはいえ、始めからガッチガチにルールを考えるとなかなか活動が開始できなかったり、スモールスタートという言葉にあやかって『まずは始めてから考えようよ』と始めたけど、結局、最初の状態のまま何年も続けてしまっているということもあるかと思いますので、ぜひ始める際には”活動の振り返りを行うタイミングを定義”してください。

参考までに、上手く運営されている企業様の事例を紹介します。

<A社事例(ヘルプデスクでインシデント管理活動を取り組んでいる)>
 ・日次 :当日の発生インシデント件数・対応状況・困り事項の共有
 ・月次 :当月の発生件数、クローズ件数、オープン件数の集計、発生傾向の分析
 ・年次(or四半期) :1年間(or四半期)の活動を通しての実績、課題の共有、改善点の検討
  →翌年(or次四半期)で、改善点の改善を行う

<B社事例(全国拠点のヘルプデスクでインシデント管理活動を取り組んでいる)>
 ・リアルタイム :全国拠点向けに、拠点毎のKPI遵守率、上位ランキング、下位ランキングの公開
 ・月次 :当月の発生件数、クローズ件数、オープン件数の集計、発生傾向の分析
 ・年次(or四半期) :1年間(or四半期)の活動を通しての実績、課題の共有、改善点の検討
  →翌年(or次四半期)で、改善点の改善を行う

活動の振り返りや情報共有を行う頻度は関係者の人数や活動範囲によって様々かと思いますが、活動を継続的に改善し、よりよい活動とするためにも振り返りは必要です。活動を始める際には、そうした振り返りを”いつ、どのタイミングで行い、改善していくのか”を決めましょう。

・ ・ ・

さてさて、今回は、ITSM活動にフォーカスをあて、活動を運営するための目的やビジョンについて触れました。まだまだお伝えできていないことや、上記の内容よりも良い方法もあるでしょう。
 
ITSM活動に関わらず、業務上何かしら活動を行う上でも、目的やビジョンがしっかりしていないと活動自体が形骸化してし、意味のないものになってしまいます。何がしたかったのか、何がしたいのか分からなくなったときには、今回触れたような原点に帰ってみるのもありだと思います。原点に帰った結果、もう今は必要ない活動であれば、終止符を打つのも手だと思います。

それでは、みなさんの活躍を祈願しまして、今回はお開きにしたいと思います。

 参考:ユニリタが提唱するITSMツール「LMIS on cloud

2016年7月27日水曜日

宝の持ち腐れ、DeepLearningで活かせインシデント大量データ

こんにちは開発の佐野です。


段々と蒸し暑い季節になってきましたね。
これからまだまだ気温が上がると思うと少し憂鬱な毎日です。

さて、今回は今話題に挙がっているDeepLearning(深層学習)について話したいと思います。

今では機械学習でポケモンGO並みに名の知れた学習方法です。
白黒画像をカラー画像にしてしまったり、最近では囲碁のプロに勝ってしまいましたね。

こんな急激にAIの技術が進歩してしまって、
いつか人類は侵略されてしまうのではと思いますが・・・。
使える時には最大限に使っていきましょう。

DeepLearingを使うだけならSaasを使えば簡単ですが、何が凄いのでしょうか?
今回はその凄さを少し分かってもらえた上でITサービスに生かしてもらえればと思います。

本来、機械学習と呼ばれているものとDeepLearning(深層学習)は少し違います。

機械学習と一般的に言われるものは、予め人がプログラミングなどで指示した上で学習を行い、
その学習データをもって色々な結果を返すものです。

ここで人が指示するのは何を特徴として学習するかの特徴です。


ですが、DeepLearningは違います。

元々は人間の脳のシナプスを参考にして作られました。
人間は自分で考えて行動しますよね?
人間と同じでDeepLearningでは自分で与えられたデータの特徴を見つけて学習してしまいます。


一般的な機械学習では与える特徴を間違えると意図しない学習をして
判断を誤ってしまいます。

一方DeepLearningだと誤った特徴を渡すことはないので、
高い精度で判断をしてくれます。
人間に一歩近づいたわけですね。

簡単な説明でしたが、ここまで聞いてDeepLearningの凄さが分かってもらえたでしょうか?

それではそのDeepLeraningをどこで活かせば良いかという話になりますね。
ITサービスマネジメントではインシデント(問い合わせや障害)を管理し
日々そのデータを貯めていっています。

例えば、こんな事にDeepLearningを使うといいでしょう。





溜まっているデータから一つ一つ障害や問い合わせの文章を学習させ、
それぞれ、どのカテゴリーかを分類させます。
分類を行ったので新たなインシデントが来た場合、
そのインシデントがどの分類なのか、また過去にどのような
ワークアラウンドや解決策を提示できたかを
サポートデスクが瞬時に知ることができるわけです。





また、分類したインシデントから
どんな傾向のインシデントが多いかなどを把握することができますね。

ほんの一例をあげましたが、まだまだインシデントデータから色んな活用方法がありそうです。

では、どのようなツールを使えば
DeepLearningができるか紹介したいと思います。

まずはMicrosoftが提供している
Microsoft Azure Machine Learning


こちらはSaas型で、機械学習を詳しく知らなくても簡単にデータ分析を行ことができます。
GUI形式でパズルを組み合わせる感じで構築することができるので初心者でもお勧めです。

まずは試してみようかなという方にはうってつけだと思います。


次にGoogleが提供している
Tensorflow

こちらは多少玄人向けにはなりますが、
Linux系でPython言語でプログラミングをして機械学習を行うOSSになります。
機械学習した結果はあとでグラフで見ることができたり他のOSSより分かりやすくなっています。
OSSなのでお金は一切かからないのも強みです。

ただ、試したいだけならMicrosoft Azure Machine Learningのチュートリアルは無料なのでおすすめです。


大量のデータをただ持っているだけでは宝の持ち腐れです。
それをどう活かすかがこれからの課題になっていくと思います。

上記のようなツールを駆使してこれからのITサービスに活かしてはいかがでしょうか。