Redmine
時としてインシデント管理と問題管理は混同されることがあります。
インシデントをとりあえずできるだけ早く解決するのがインシデント管理、そのインシデントを二度と起こさないように再発防止まで行うのが問題管理です。
ちなみにITILでは「問題」のことを「1つまたは複数のインシデントを引き起こす未知の根本原因」と定義しています。何だかピンと来ない定義ですが、要は「放っておいたら同じ厄介ごとを起こしてしまう原因」ということです。
問題管理には、再発防止を行う「リアクティブな問題管理」と、そもそもインシデントが発生しないように予防する「プロアクティブな問題管理」があります。これにはインシデントの予防も含まれるわけです。
例えるなら、ハードディスクが反応しなくなり困っていたが、叩いたら一時的に復旧した。これはインシデント管理です。しかし、いつまた動かなくなるかわからないので、他のハードディスクにデータを移して交換したり、SSDなどを採用したりする。これは問題管理になります。インシデント管理が応急処置なら、問題管理は根治と予防と言い換えても良いでしょう。
問題管理では根本原因を詳細に検討するため、時間がかかります。また、原因を解決するためにサービスの内容等も変えなければならないことがあるので、他の管理プロセスと連携することもあります。
インシデント管理（Incident Management）とは、なんらかの理由でユーザーのシステムが正常に利用できなくなったときに、その原因やトラブルを解決し、再びシステムを正常に利用できるようにするためのサポート体制です。
一時的な回避策、対応策を使い、ビジネスへの影響を少なくすることが求められます。
可能な限り迅速なサービスの復旧を行い、ビジネスへの影響を最小限に抑えるために必要です。
あくまでも一時的な解決策ではありますが、根本的な解決をするためには必要なことになります。
インシデント（incident）は日本語では「あまりよくないできごと」「ちょっとした事件」という意味になります。
ちょっとしたバグや短時間の障害、ユーザーの操作ミス、システムの一時的な停止など、本当に些細で様々なことが含まれています。
迅速に対応しなければ被害が大きくなる、広がるような状態発生をインシデントと呼びます。
インシデント管理の目的は、ビジネスへの影響を最小限にすること、迅速なサービスの復旧をすることが目的です。
ですがインシデント管理ができていないと、問題管理にまでつながらない、根本的な問題解決にならない、などの可能性が出ます。
またインシデント管理はインシデントについて即時的に対応し、その記録を残していくことが大事になります。
同じインシデントが繰り返されている、似たようなインシデントばかりがある、そのような時は、インシデント管理が問題管理にまで到達していない可能性があるでしょう。
根本的な解決をするために、インシデント管理は必須です。
インシデントが繰り替えされる場合、根本的な原因の解決ではなく、インシデントの解決ばかりがされているのではないでしょうか。
インシデント管理とワークアラウンド、問題管理の違いを説明します。
似ているため混同されがちではありますが、違いを理解していきましょう。
このような違いがあります。
ワークアラウンドとは、根本的な解決にはなっていないものの、応急処置的にその場のトラブルを解決する動きを指します。
またワークアラウンドは応急処置的に動くので、インシデント管理と思われがちですが、実際には問題解決を行っているので問題管理の部類です。
どのようなワークアラウンドを行い、その後どうなっていったのか、根本的原因の解決の妨げになっていないように、確認する必要性があるでしょう。
問題管理とは、発生したインシデントを解消することだけでなく、そのインシデントの再発や予防するための対策を考えること、実際に対策をすることを指します。
この場合の問題はインシデントを引き起こす、根本的なトラブルのことです。
発見された課題や問題を、インシデント管理し、ワークアラウンドで即時的に解決します。問題管理は、その結果や経過をシステムやサービスに反映させるのです。
品質やサービスを安定させ、また向上させたり改良していきます。
インシデント管理、ワークアラウンド、問題管理の違いはこのようになっています。
| インシデント管理 | ワークアラウンド | 問題管理 |
| 迅速な対応を考えるサポート体制一時的な解決、回避策を行い、ビジネスへの影響を少なくする | 迅速な対応を行う復旧作業を実際に行う | インシデント後再発や予防の対策を行う体制品質やサービスを安定させ、向上や改良していく |
このように、対処をするタイミング、実際に対処をする内容などで違いがあります。
インシデント管理はインシデントが発生してから迅速に対応することであり、問題管理はその後の再発や予防を行うことが大切です。
そうすることで、同じインシデントを繰り返すことなく、逆にサービスの質や安定、向上や改良にまでつながります。
問題管理に関してはこちらの「ITILにおける問題管理」で詳しく解説していますので合わせてお読みください。
ここでは、インシデント管理の各段階について説明します。
インシデント管理にも各段階があり、何が行われているのか、担当者は誰なのか、理解した上で対応を行いましょう。
また担当者を明らかにしておくことで、メリットもあります。
ナレッジベースの記録から、似ているインシデントを把握し、ユーザー担当者でも対応できるものにすることができるからです。
それでも分からない場合や、難しいと判断された時には上位者が対応すればよい状態になります。
この判断が的確にできる状態になると、エスカレーションの回数や、対応する時間の短縮ができ、業務の効率化が望めるでしょう。
ここでは
この6つの流れで説明していきます。
発生したインシデントを早期に検知して、それに記録します。
ユーザーからの連絡であったり、システムのアラートであったり、と検出される場所は様々です。
どこで発生したのか、何が起きたのかをしっかりと記録することで、今後のインシデント管理につながります。
インシデントを分類することは、問題管理につながり、根本的な解決へつながる一歩です。
またインシデントの分類は、ナレッジベースから過去によく似たものがないかを検索し、その内容や状況などから分類します。
そのデータから対応の優先度や難易度を決定するのです。
緊急度や優先度、難易度などが違うため、ユーザーサポート担当者で対応が可能なのか判断します。
難しい場合は、上位の管理者などに意見を聞いたり、指示を仰いだり、など対応を引き継ぐことをしましょう。
担当者で対応が可能であると判断されたインシデントは、ユーザーサポートの担当者が解決します。
ナレッジベースから過去に似ているものや優先度、難易度を判断しているので、担当者でも解消できるインシデントです。
担当者だけでは対応できないインシデントの場合は、エスカレーションにより、マネージャーや責任者が問題を解決します。
エスカレーションとは、ユーザーサポート担当者では対応できなかった場合にその上位者へ指示を仰いだり、対応を引き継ぐことです。
インシデントが解決したあとは、その記録をナレッジベースに登録します。
状況や経過観察、顧客のフォロー、再発していないかなどを確認することは、重要なことです。
対応が必要な場合は、対応が終了するまで継続します。
インシデントが解消され、作業が再開することができたら報告をして、対応を終了します。
この時、再発していないか、顧客は満足しているか、など様々なことに配慮しましょう。
問題管理プロセスでは、主に次の9つの活動を行います。
前半部分はインシデント管理とほぼ同じです。ワークアラウンドの実施はインシデント管理とも重なりますね。
変更要求はRFC（Request for Change）とも呼ばれ、サービスの内容や構成要素を変更する必要がある場合に行われます。
Redmineを活用すれば、インシデント管理だけでなく、問題管理にも応用することができます。また、変更管理にも対応できます。変更管理については、次回解説致します。
Remineが得意とするチケットというシステムは、変化に強いと言われます。ステータスの変化などにも柔軟に対応できるので、インシデント管理→問題管理→変更管理のプロセスをカバーすることが可能なのです。
より詳しくRedmineについて知りたい方はこちらの「Redmineとは？基本機能とおすすめの使い方をわかりやすく解説」をご覧ください。
インシデント管理をしっかりと行うことで、様々な各担当者にメリットがあります。
現在は様々なサポートがありますので、そういったものを活用しながら、インシデント管理のメリットにつなげていく必要性があるでしょう。
インシデント管理のメリットは、ナレッジベースが適切に管理されていなければ効果が期待できません。そのため、データに漏れや抜け、ミスがないかなどを注意する必要性があります。
「サービス担当者とマネージャー」だけでなく、「ユーザー」にとっても有益であり、迅速な対応が求められる重要な業務の1つが、インシデント管理です。
サービス担当者とマネージャーは、過去のデータを管理することで、迅速で効率的な対応ができるようになります。
また業務改善、顧客の満足度の向上にもつながるので、わかりやすいメリットではないでしょうか。
またユーザーのメリットは、インシデントが発生しても迅速な対応をしてもらえる結果、システムやサポートを信頼することができます。
信頼のあるサポートは愛用され、リピーターもできるでしょう。
それぞれにどのようなメリットがあるのか、ここで説明します。
ユーザーサポート担当のメリットは、過去のデータを一元管理することでインシデント管理を効率化できることです。
迅速な対応ができるようになり、業務改善や顧客の満足度の向上にもつながるでしょう。
ナレッジベースの情報が分類されているので、無駄なエスカレーションも減らすことができます。
マネージャーのメリットは、日常的な対応をユーザーサポート担当者に任せられます。
毎回マネージャーがエスカレーションする必要性がなくなり、業務が効率的になるのです。
そのため、マネージャーはインシデントの分析をする時間が確保でき、問題管理へつなげることができるでしょう。
それによりシステムやサービスの品質を向上させることにもなります。
インシデントが発生した時に正確で的確なサポートを受けることができます。
それによってスムーズに業務を再開できるでしょう。
またシステムやサポートを信頼でき、安心感を持つことができます。そのようなユーザーは長く愛用したり、リピーター顧客になる可能性が高くなるのです。
インシデントの管理に関して、よくある悩みをこちらにまとめています。
様々なインシデントの発生だけでなく、複雑化したシステムの導入による予期せぬトラブル、外注することでのコスト増加、どのように改善していくのかわからない、など誰もが感じる悩みではないでしょうか。
似たような悩みを持っている人は、参考にしてみてください。
ITシステム運用では、複数事業者のクラウドシステムを混在させて利用していたり、利用するサービスそのものが多岐に渡っており、把握するのも難しい、などの傾向があります。
複雑化してしまったことで、予期せぬトラブルが増えたり、様々なアラートに対応しなくてはいけなくなりました。
そうなった時、大量の情報の中に緊急性の高いものや、重要なものが埋もれてしまい、インシデントを見落とす可能性もあります。
顧客の期待値も高まっており、迅速なレスポンスを希望するのが当たり前、24時間365日が当たり前に求められているのです。
その中でどれだけ迅速に対応できるか、インシデントの解決ができるかは難易度が上がっています。
システム運用と保守について詳しく知りたい方は「システム運用・保守と管理の違いや業務内容、課題点と解決策を解説」の記事をご覧ください。
外注する場合、インシデント対応を請け負う業者の計算によって、コストが下がりにくい状態があります。
必要サーバー台数など多く所持している会社は、特にコストがかかるでしょう。
外注の場合、サーバー台数だけではなく、そこにいる人員の数も関係します。
ですが、人員が少なくなるとインシデントの対応可能人数や時間が減ってしまいます。
人員不足によってインシデントの対応ができなかった、となると会社の信用を失う可能性にもつながってしまうのです。
それらを解決するために、運用システムには多くの人数を確保しておかなければいけません。
まず運用プロセスを改善するために、このような情報が必要になります。
など細かい時間の測定をした上での、情報収集が必要です。
様々な情報を駆使して運用プロセスの改善を行うためには、自社の運用プロセスを定義した上で仕組みを整備し、自社で必要な測定をする必要性があります。
そこで出た測定時間などの情報をもとに、改善する必要性があるのです。
現場によって程度は違いますが、抱えている問題はどこも似通っています。これらの悩みを解決できる手段があればいいと思いませんか？
現場が抱えているさまざまな悩みを自動化し、システム運用担当者の手を介することなくある一定の処理まで行います。
今まで担当者が手動で行っていた業務の一部を自動化することで正確で確実な処理を実行し、担当者がより優先順位の高い業務に集中できる環境を整えていきます。
結果的に、システム運用が安定し、安定した運用が継続的に行えることでコストの低減も図っていくことが可能です。
SHERPA SUITEのSHERPA-IRとSHERPA-SMは、どちらも現場のシステム運用を支えるシステムで課題解決の手段の一つとなります。
インシデントの対応は時間勝負です。一般的な現場では手順書の見直しなど、操作に関する改善は行われていても、運用を含めて改善されていません。
インシデント発生から完了までは様々なステップがあり、担当者に頼った運用をしているのが実情ですが、作業が煩雑で多くなり時間がかなりかかってしまいます。ミスも誘発しやすい環境となり、リスクも増大してしまっているのが現実です。
1次的な運用対応プロセス業務をSHERPA-IRで自動化することで時間と労力を大幅に簡略化し、担当者が迅速で確実な復旧に取り組むことができます。
担当者が迅速に復旧作業できることで、結果的に安定したシステム運用にも繋がります。
他にも、問合せメールから情報を拾い、フィルタリングしてRPA(ロボットプロセスオートメーション)と連携するなどのカスタマイズも可能。オペレーションの自動化で、効率化・高品質化・コスト削減を実現します。
SHERPA-SMはインシデント管理から問合せ管理までを担当します。SHERPA-SMには3つのメリットがあります。
インシデントの通知が来ると、SHERPA-SMはチケットとして自動登録します（アラートメールなどの集約はSHERPA-IRが行います）。人手による入力の手間を大幅に削減し、登録漏れやヒューマンエラーを未然に防ぐことができます。
チケットには独自のIDが割り振られるので、対応するスタッフが替わっても素早く応答することができます。すべての記録はSHERPA-SMに残るので、履歴やノウハウをチームで共有することができ、業務改善と生産性向上に活用することも可能です。
チケットには担当者情報が割り当てられ、担当者はリストボックスを設定することで自動で通知メールを送れます。これは、担当者間の“お見合い遅延”防止に効果を発揮します。アサインされた担当者は、通知メールに記載されたURLをクリックすればチケットにダイレクトに接続できます。チケットは一括で管理されるため、漏れも生じにくくなります。
他にも問合せ管理機能、インシデントの進捗状況を視覚化できるガントチャート、定期業務をチケットによって指示してくれる機能など、SHERPA-SMにはインシデント管理を効率化する機能が満載されています。
