Redmineを使ったITIL的な運用プロセス管理

に続き、日常の運用にまつわる課題をRedmineで解決できるかの検証備忘録。

目次

背景など

所属する会社（一応システム会社の情シス）では、 日々ヘルプデスク業務や問合せ業務が頻繁に発生するが、 概ね、どこにでもあるような以下の課題が発生している。

• 当事者同士の口頭・メールベースでやり取りが可視化・蓄積化されずらい。 （しかも、個人に割り当てされるメール容量が少ないため、メールを最終的には削除せざるを得ない。)

• 問い合わせに端を発し、課題管理・ 変更管理といった形でプロセス遷移していった場合、その遷移が事後的に追いづらい。 （あの件どうだったっけ？が頻発する。）

以下の参考書籍には、顧客サポート業務をRedmineを使用して行っている好例があっため、先述の課題をRedmineで改善できないかと考えたのがそもそもの発端。

入門Redmine 第5版

やりたいこと

概ね以下のような感じでやりたいことは、とてもシンプルなもの。

• 問合せ履歴の蓄積　

• ITILをイメージしたプロセス遷移

Redmineでの設定方針について

• ITILのプロセスを「トラッカー」で表現し、それぞれステータス更新させる。

• ITILにでてくるようなプロセスをすべて表現せずに、必要最小限のプロセスを実装するため、問合せ管理・インシデント管理、課題管理・変更管理プロセスをベースとする。

• 変更管理では、マネージャー承認が行われるように、ワークフロー承認（もどき）を入れる。

設定するプロセスのイメージ図

一つのチケットを様々なプロセス（Redmine上はトラッカーとして表現）遷移させる システム変更が必要な対応においては、変更管理プロセスに基づく、ワークフロー承認後、システム変更対応を実施し、完了させる。

プロセスのイメージは、下記ような感じ。

登場人物

ここで、検証するために以下のユーザーを用意する。

ユーザーID	ユーザー名称	権限
manager	管理者　太郎	承認者
staff	担当者　次郎	申請者
oahelp	OAヘルプ隆司	ヘルプデスク

ユースケース

検証を行うにあたり、以下のユースケースを前提とする。

①ヘルプデスク(oahelp)にエンドユーザーからあるアプリケーションが利用できないとの問い合わせが入る。

②ヘルプデスク(oahelp)は、問合せ内容をインフラ部門担当（staff）にエスカレーションするため、Redmineの「問合せ管理トラッカー」に問合せ内容を登録する。

③インフラ部門担当（staff）は、当該問い合わせを「インシデント管理トラッカー」にプロセス遷移させ、一次切り分けを実施する。

④インフラ部門担当（staff）は、原因をアプリケーションのメーカに問い合わせるとともに、当該チケットを「課題管理トラッカー」にプロセス遷移させ、課題管理する。

⑤インフラ部門担当（staff）は、本事象の原因がメーカ問い合わせにてわかったため、変更計画をたて、管理者（manager）の承認を得るために、「変更管理トラッカー」にプロセス遷移させ、承認依頼を行う。

⑥管理者（manager）は、変更内容を承認し、対応日を指示する。

⑦インフラ部門担当（staff）は、管理者（manager）から指示を受けた期日に対応を行う。予定通り作業を完了したため、チケットを「完了」させる。

ヘルプデスク(oahelp)の問合せ登録

①ヘルプデスク(oahelp)にエンドユーザーからあるアプリケーションが利用できないとの問い合わせが入る。

②ヘルプデスク(oahelp)は、問合せ内容をインフラ部門担当（staff）にエスカレーションするため、Redmineの「問合せ管理トラッカー」に問合せ内容を登録する。

問合せ登録を行うプロジェクトは「ITILプロセス」として、 トラッカーはこんな感じで、ITILプロセスをイメージしたもの。

ここでは、ヘルプデスク(oahelp)でログインし、「問合せ管理トラッカー」上に問合せ内容をエスカレーションのために登録する。

登録されると、下記の感じで、チケット登録される。

インフラ部門担当(staff)の「インシデント管理」

③インフラ部門担当（staff）でログインし、当該問い合わせを「インシデント管理トラッカー」にプロセス遷移させ、一次切り分けを実施する。

登録されたチケットを確認し、

ヘルプデスクからエスカレーションされたチケットを「問合せ管理」⇒「インシデント管理」トラッカーにプロセス遷移させ調査を開始する。

登録後、プロセス遷移の履歴とコメントが履歴化される。

インフラ部門担当(staff)の「課題管理」

調査が難航したため、メーカーに問合せを行うとともに、 「インシデント管理」トラッカーに登録されたチケットを 「課題管理」トラッカーにプロセス遷移し、課題管理を行う。

登録後、プロセス遷移の履歴とコメントがさらに履歴化される。

インフラ部門担当(staff)の「変更管理（承認依頼）」

メーカーからの回答を受領し、事象の原因が分かったため、 「変更管理」トラッカーにプロセス遷移させ、管理者 太郎(manager)に 変更の承認依頼を行う。

「変更管理」トラッカーに変更すると、ステータス制限のため、 承認が完了しないと、ステータス変更できない。

登録後、プロセス遷移の履歴とコメントがさらに履歴化される。

管理者 太郎(manager)の「変更管理（承認）」

管理者 太郎(manager)がログインし、インフラ部門担当(staff)からの承認依頼を承認するため チケットをクリックする。

管理者 太郎(manager)は、「変更管理」トラッカーのステータスを「承認」できるので、 承認する。さらに、対応日を3/10として指示する。

登録後、プロセス遷移の履歴とコメントがさらに履歴化される。ステータスも「承認」となる。

プロジェクトのカレンダーに対応予定日（3/10)が登録される。

インフラ部門担当(staff)の「変更管理（対応待ち）」

改めて、インフラ部門担当(staff)でログインし、承認が行われたので、 「対応待ち」ステータスに変更できるようになる。

インフラ部門担当(staff)の「変更管理（完了）」

最終的に、対応が完了したら、ステータスを「完了」に変更し、 チケットもクローズさせる。

チケットがクローズし、

いままでの登録内容が履歴化される。

以上の感じで、問合せに端を発した１つのチケットが様々なプロセス（ここではトラッカー）遷移を経ながら、 最終的には、クローズされ、その経緯もバッチリ履歴化されるため、 内容をよりシャープにさせていけば、より高精度な業務が実現できそう。

※こんな高機能のソフトウェアを無償で利用できるようにしてくれた 　開発者・コミュニティの人たちに唯々感謝するばかり。