残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事

残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事が面白かったので、リンクしておく。

【参考1】
Redmineで残業申請ワークフロー - My Tracking

(引用開始)
勤務管理の厳正化が叫ばれる昨今、所属する会社でも残業申請が行わている。 概ね、以下のような残業申請の形態（一応システム会社）。

基本Excelでの申請台帳形式
申請者が事前にExcelに以下の内容を入力する。
①申請日・②時間・③残業予定時間・④概要・⑤内容。
申請者が上司にメールする。
上司が内容を確認し、承認/却下とその理由も添えてExcelに記載し、回答する。
事後申請の場合は、申請者がその旨記載し、入力する。

いろいろな問題をはらんでいるものの最大の問題が、

「Excelの台帳を誰かが開きっぱなしにすると、申請自体ができない」

という最も単純かつ根本的な問題に行きつき、そのわずらわしさから、申請自体がおざなりになるという事態が頻発。
(引用終了)

システム会社であっても、残業申請はExcel管理台帳に書いて、それを印刷して、警備員に渡す運用フローが回っている所は多い。
Excel管理台帳や印刷した紙は便利だが、大人数の運用には向いていない。
こういう現場はまだまだたくさんあるのではないだろうか？

上記の記事では、そんな問題意識からRedmineを導入したらしい。
興味深い点は二つある。

一つは、最初にBPMN 製品を検討したがRedmineに乗り換えた点。

僕も一時期、汎用ワークフロー基盤を持つパッケージ製品を調べていたので、事情は何となく分かる。
確かに、事務処理のような汎用ワークフローの機能は豊富だが、複雑すぎて使いこなせない。
汎用ワークフロー基盤のメリットは、組織情報を持っているので、組織や役職に応じた複雑な条件をワークフローに入れ込むことができること。
しかし、もっと簡易なワークフロー機能だけで、十分に使える利用シーンは多いから。

Redmineは帳票ワークフローシステムであるというアイデア: プログラマの思索

Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索

Redmineを勤怠管理システムで運用するアイデア: プログラマの思索

オープンソースのBPMツールBonitaのメモ: プログラマの思索

オープンソースのワークフローエンジンActivitiの感想: プログラマの思索

BonitaBPMを動かしてみた感想～BPMツールに必要な必須機能: プログラマの思索

もう一つは、「事前申請」「事後申請」の二つのトラッカーを使っている点。
普通は、事前申請トラッカーだけだろうが、たとえば、本番障害の緊急対応で急遽、休日夜間に出勤して対応した、という事態もあるだろう。
つまり、例外的な残業申請に対して「事後申請」というトラッカーを設けている、と思われる。

この辺りは、現場に応じていろんな状況があるはずなので、例外的な運用をどこまでシステム化するのか、あるいは、手運用でフォローするのか、という天秤をかけることになるのだろう。

個人的には、残業申請のように、特に細かな観点の集計が必要でないワークフローは、IssueTempateプラグインで、説明欄に申請テンプレートを作っておく運用がとてもマッチしていると思う。

Issue Template - Plugins - Redmine

理由は、申請テンプレートを用意しておけば、申請者は空欄に情報を埋めるだけでよく、申請内容を考える労力が減るし、申請内容の記載漏れも減るからだ。
わざわざ、たくさんのカスタムフィールドを設けて、入力が面倒になるようなUIにする必要はない。

事務処理ワークフローでは、IssueTempateプラグインのようなチケットテンプレートを事前準備する機能が重要になってくるだろうと思う。

【参考2】
Redmineを使ったITIL的な運用プロセス管理 - My Tracking

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

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

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

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

システム会社であれ、製造業であれ、小売業であれ、ヘルプデスクや問合せ、カスタマーサポートのような業務は必ずある。
それら業務は普通は、メールや電話などでやり取りされているだろう。
しかし、個人ベースで情報蓄積されてしまいがちで、応援したくても刻一刻と状況が変わるような状況では情報共有しにくく、引き継ぎしにくい。
特に、顧客からの問合せには、即座に対応する緊急性の高いものから、優先度が低いものまで多様なので、それら切り分けも大変。

上記の記事で興味深い点は、「ITILのプロセスを「トラッカー」で表現し、それぞれステータス更新させる」している点。
つまり、インシデント管理、問題管理、変更管理、リリース管理などのプロセスごとにトラッカーを作り、運用方針を定めている。
このやり方の方が上手く回るだろうと思う。

僕も、9年前に、ITILをRedmineのワークフローで回そうと色々試していた時期があった。
当初は、一つのトラッカーで、インシデント管理、問題管理、変更管理、リリース管理のプロセスにステータスを割り当てて運用しようとしていた。
すると、ステータスが10個近くにもなり、チケットは更新されているのに、外部から見るとチケットが滞留しているように見えて、あまり上手く運用できなかった経験がある。

ステータスの多いトラッカーでよく見られるアンチパターン「スタンプラリー」に陥っていたのだと思う。

個人的には、こういうタスクは、親子チケットにすれば良いと思う。
親チケットが進捗報告用、子チケットがそれぞれのプロセスのチケットにすれば、親チケットで進捗率や状況が一目で分かる。
また、各プロセスの子チケットでは普通は担当者がそれぞれ異なるので、担当者も自分のチケットだけに専念しやすい。
こういうたくさんの担当者が関わるチケットは、親子チケットで分割した方が作業しやすいし、プロマネも管理しやすい。

できれば、Redmineで親子チケットのテンプレートを設定できる機能があれば、もっと良いのだが。

最後のコメントもとてもいい。

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

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

Redmineの最大の特徴は、チケットの柔軟な機能だ。
そのおかげで、ソフトウェア開発のタスク管理以外の用途にも適用でき、色んな使い方、色んな利用シーンが生まれている。
Redmineは、先進的なプロジェクト管理の実験ツールなので、今後も改良される余地がたくさんあるだろう。
その可能性を色々調べてみたい。