Redmineを勤怠管理システムで運用するアイデア

Redmineを勤怠管理システムで運用する記事を見かけたのでメモ。
これは面白いし、Redmineの利用可能性をかなり広げてくれそう。

【参考】
Redmineで勤怠連絡をしてみる

【1】こんな問題が提起されている。
派遣先、常駐先で働くメンバーが多い場合、確かにそういうニーズはありそう。

(引用開始)
・体調不良で休む際、常駐先から現場リーダ/営業/上司/上長…など複数人に報告をしなければならない。
・部下の勤怠管理をしなくてはならなかったが、報告がなかったため月末に出勤簿を提出されたときに初めて高稼働だったと気付く。
・日々、勤務時間を記録しなくてはならないが、月末になってあいまいな記憶で出勤簿を作成している。
・勤怠管理システムを導入したいが、多額の費用を払ってまでやる必要性を感じていない…etc

そこで、オープンソースのRedmineを用いて、簡易的な勤怠申請システムを構築してみる。
(引用終了)

【2】トラッカーやステータスの種類が興味深い。

(引用開始)
トラッカーの分類

・残業申請：残業が発生する場合に報告するチケット
・遅刻・早出：始業時間より遅く出社する場合に報告するチケット
・早退・遅出：終業時間より早く退社する場合に報告するチケット
・休日出勤：法定休日に出社する場合に報告するチケット
・休み：午前半休・午後半休・全休など休暇を取得する場合に報告するチケット
・出社退社の記録：出勤時間と退社時間を日々記録していくチケット(報告者用)
(引用終了)

(引用開始)
ワークフローの設定(ステータス)

・申請中：報告者、開発者、管理者
・承認済み(開発者)：開発者、管理者
・承認済み(管理者)：管理者　※終了したチケットに設定
(引用終了)

(引用開始)
トラッカー＝残業申請(例)

標準フィールド：担当者のみ
カスタムフィールド：申請日(カレンダー)、退社(テキスト)

トラッカー＝休み(例)

標準フィールド：担当者のみ
カスタムフィールド：申請日(カレンダー)、休暇種別(リスト)
(引用終了)

Redmineを簡易なワークフローシステムと見なせば、残業・休日出勤・夜間勤務などの申請フローは簡単に乗せることができる。
出勤時刻のような必要な項目は、「hh:mm」のような書式で設定して、カスタムフィールドで追加すればいい。

チケットの削除機能をOFFにしておけば、申請の記録が残り、消去されることもない。
チケットの実績工数を入力する運用も行えば、毎月の労働時間も記録することもできる。

【3】Redmineの運用ルールは下記で行われているらしい。

(引用開始)
例えば、電車遅刻した際に遅延証明書を添付しないと承認できないというルールを作ると、虚偽の遅刻などが減らせる。
常駐先では自社用でインターネットが利用できない場合が殆どだと思われるが、スマートデバイスがあればブラウザやRedmine専用のアプリから勤怠申請を行うことが可能である。

企業の就業規則や労働基準法に則った運用が必要なため、本格的に使用する場合は管理部門の承認が必要である。
まずは小規模組織内でのトライアル利用を推奨する。
(引用終了)

社外に常駐のメンバーが勤怠管理用Redmineにアクセスできる環境を作れば、気軽にRedmine上でコミュニケーションを取ることができる。
また、電車の事故で遅延証明書が必須になったら、iPhoneでカメラ撮影して、その画像をチケットに添付すればいい。

特に、最新バージョンのRedmineを使うべきメリットは、レスポンシブデザインになったので、スマホのようなクライアントでもRedmineのチケット操作がやりやすくなったことだろう。
もちろん、RedminePMのような専用クライアントを使ってもいい。

セキュアなRedmine環境を用意できれば、勤怠管理システムとして有効に使えるのではないか。

【4】では、勤怠管理システムとしてRedmineを使う場合、課題はあるだろうか？
課題があるとすれば、上記の記事の指摘のように、就業規則や労働基準法に即したルールを全て満たしているか、確認する必要があることだろう。

中小企業なら就業規則もそんなに複雑でないから、問題ないかもしれない。
でも、大企業の場合、労働組合が強かったりして、勤怠管理や労働時間の管理にはすごくうるさかったりする。
また、勤怠管理に付属するイレギュラーな運用フローもあるだろう。

たとえば、勤怠管理の業務では、出張申請は普通、特別な運用ルールになっている。
直行・直帰の場合、みなし労働と見なされるので、勤怠管理システムに特別なルールが埋め込まれている可能性がある。
実際、出張旅費規定にも絡むので、社内の経費精算システムとも連動する必要があるかもしれない。

あるいは、勤怠管理の情報と、実際の各プロジェクトで作業した工数を相互チェックして、整合性を取る必要があるかもしれない。
すると、勤怠管理システムと工数管理システムの二つのシステムに、作業時間を二重入力する手間がかかり、より煩雑になってしまう。
しかも、工数管理システムは普通、社内の原価管理システムや会計システムと連動しているだろうから、勤怠管理システムのデータの精度が高くないといけないし、後から改ざんできるようでは困る。
最終的には、勤怠管理システムは、内部統制システムの一部になるから、データの精度や保管に問題ないことを保証しなければならないだろう。

したがって、勤怠管理の月次締めのような機能が必要になるだろう。
その場合、Redmineの運用では、Redmineのバージョンを年月で指定し、前月度のバージョンは当月月初に「ロック」「完了」ステータスに更新して、チケットを更新不可に運用でカバーする必要があるかもしれない。

【5】そんなことを考えると、課題はいくつかあるだろうが、Redmineを勤怠管理システムとして使う運用は、社内の就業規則などのルールと矛盾がなければ上手くいくだろうと思う。

今まで、Redmineの運用パターンとして、ソフトウェア開発以外に、ヘルプデスク管理、工数管理、PC資産管理、事務処理ワークフローなどを収集してきたが、まだまだ他にも使える利用シーンがあるだろうと思う。
それを考えるのが結構面白い。

そんなことを考えると、Redmineは汎用的な帳票ワークフローシステムであり、一昔前にNotesで社内の事務処理ワークフローを実装して、BPRと称して業務を改善していったと主張した歴史とダブるような気がしている。

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

RedmineをBPMツールとして使うアイデア: プログラマの思索

【公開】SQIP2015講演資料「チケット駆動開発の運用パターン集～問題はチケットに分割して統治せよ」 #Redmine: プログラマの思索

【公開】講演資料「Redmineの運用パターン集～私に聞くな、チケットシステムに聞け」 #tidd: プログラマの思索