プログラマの思索

「Redmineは実績工数管理システムとして使えるか？」という問題に対して、考えたことをラフなメモ書き。
結論は、運用ルールさえきちんと決めれば、実績工数管理システムとして使えると思う。

【参考】
WorkTime - Work Time - r-labs

estimate_timelogの0.1.0を公開しました。 - アルパカDiary

toritori0318/redmine_estimate_timelog ・ GitHub

Redmine で予定/実績レポートを表示するプラグイン(estimate_timelog v0.5.0)を Redmine 2.x に対応させた - suVeneのアレ

suvene/redmine_estimate_timelog ・ GitHub

【1】現状と問題

SIのプロジェクトリーダーは月末月初になると、工数確定・工数照合という重要な作業で繁忙になる。
彼だけの担当である工数確定・工数照合とは何なのか？
それは、顧客へ実費請求するための作業明細書の作成と、委託先会社から届く協力会社社員の作業明細の照合という作業だ。
具体的な利用シーンは下記になるだろう。

【1-1】顧客へ実費請求するための作業明細書の作成

例えば、システム保守案件は普通は、顧客と準委任契約を結んでいる時が多い。
すると、準委任契約は工数委託契約であるのが普通だから、どんな作業にどれだけ工数が発生したのか、を作業明細書として作成し、顧客に提出して、顧客から請求金額を振り込んでもらう必要がある。

顧客の立場では、毎月数人日～数人月分のお金を払っているのに、それだけのアウトプットを出してくれているのか、を疑心暗鬼で見てくる。
だから、プロジェクトリーダーは、作業明細書の信ぴょう性を保つために、誰がどんな作業にどれだけの工数を費やしたか、という作業明細を把握し、そのデータを作業別に集計して顧客へ提出する。
作業内容には、本番障害対応、定形作業、突発的な作業など、数多くの作業があるだろう。

発注側の顧客マネージャが政治上手であれば、作業明細書の不備を指摘して、請求金額を値切ろうとする。
顧客マネージャがたくさんのベンダーを抱えているならば、こういう交渉事はすごく慣れているので、厳しい指摘が多くなりがち。
その分、受注側のSIは損する。
だから、プロジェクトリーダーは、それらの作業内容が本当にそれだけの工数が発生したのか、を顧客に説明する責任があるから、作業明細書を作るのにすごく神経を使う。

【1-2】委託先会社から届く協力会社社員の作業明細の照合

例えば、受託開発案件で自社に常駐する協力会社社員は、準委任契約を結んで作業する時が多い。
すると、工数委託契約であるのが普通だから、SIのプロジェクトリーダーは、自チームの協力会社社員の前月の作業明細を委託先会社から請求書としてもらい、それに判子を押して、委託先会社へ支払う運用を月初に行う。

プロジェクトリーダーの立場では、協力会社社員の前月分の作業実績と請求書を照合して、請求書に書かれた作業工数と金額が本当に正しいのか、チェックする必要がある。
この照合作業を適当にやっていると、委託先会社の言いなりの金額で支払うことになり、コスト超過になってしまうだろう。
実際は、協力会社社員の作業工数を適当に管理する現場は少ないだろうが、金銭に関わるから、こういう照合作業は神経質になりやすい。

普通は、協力会社社員に毎日、社内の工数管理システムに実績工数を登録してもらい、月末にプロジェクトリーダーが作業実績を確認後、工数確定し、その結果を協力会社社員は自社に持ち帰って請求書を送付する運用になるだろう。

【1-3】工数確定・工数照合の作業の問題点は、プロジェクトリーダーはただでさえ忙しいのに、月末月初は更に忙しくなることだ。
大規模受託開発案件なら、大量に常駐した協力会社社員がチームにいるから、プロジェクトリーダーは照合作業にすごく手間がかかる。
また、たくさんのシステム保守案件を抱えているリーダーほど、1システムの保守金額は小さい割には煩雑な照合作業が多くなりがち。

【1-4】上記のような実績工数の照合作業が必要な現場を経験してみると、大手メーカー系のSIが多い気がする。
もちろん、金融系、小売系、その他の独自SIも同じだが、何となく特有の空気がある。

その理由は、親会社が製造業の場合、製造原価報告書を正式な財務諸表として提出しなければならないため、システム子会社も自社社員だけでなく、工数委託社員の労務費もきちんと管理しなければならないからだろうと思う。
つまり、直接労務費だけでなく、間接労務費も明細まできちんと管理しなければならない。

【1-5】上記のような問題点があるため、普通のSIは自社特有の工数管理システムを持っている。
しかし、実際は、案件単位の工数管理しかできていないから、作業明細レベルの実績工数は、結局、ExcelまたはAccessにメンバーへ入力させて、月末月初に集計する運用になっている場合が多いだろう。

では、煩雑な実績工数の照合処理は自動化できないのか？
そこで、Redmineを実績工数管理システムとして使えないだろうか？

【2】解決のアイデア

Redmineのチケット管理では、予定工数・実績工数を記録して集計できる機能がデフォルトで付属している。
この機能を使えば、実績工数管理システムとして運用できるだろう、と普通は簡単に思いつく。
では、Redmineのチケット管理で全ての問題は解決できるだろうか？

【3】実際の運用方法

運用上のポイントは3つあると思う。

【3-1】親チケットはWBSしか許さない

作業管理をチケット管理で実現する場合、PLが事前にWBSをチケット登録し、そこから詳細化していく。
計画通りに進むならば、PLが決めたチケットに従って、メンバーは作業すればいい。
しかし、突発的な作業が多発するのが普通だから、WBSのチケットの2倍以上の枚数が登録されるのが普通だろう。
そもそも、チケット管理は変化に強い作業管理である利点があるからこそ、チケットはメンバーが気軽に登録して運用したい。

すると、チケットに実績工数を入力したとしても、作業明細書として出力した場合、作業の粒度がバラバラになってしまうために、チケットの名寄せのような作業が発生してしまう。

一つの解決案としては、Redmineの親チケットに子チケットをロールアップできる機能を使って、親チケットはPLが定めたWBSとし、その子階層に子チケットをメンバーが自由に更新できるようにする。
そうすれば、月末にチケットを一括出力した時、作業明細書は、日付・ユーザ・親チケットNo・実績工数でグループ化すればいい。

但し、WBS以外のタスクも発生しがちなので、その時もPLがWBSを新規発行する運用が必要になるだろう。

【3-2】工数入力の運用ルールの徹底

実績管理システムとして運用するからには、メンバー全員にRedmineのチケットに、毎日実績工数を入力してもらう必要がある。
しかし、システム保守のように、1日で数個以上のシステムの作業を同時並行でやっていたら、チケット入力のUIだけでは、実績工数を付けるのはかなり煩雑だ。

そこで、実績工数入力用のUIが別途欲しくなる。
一つのアイデアとしては、WorkTimeプラグインを使って、工数入力する運用があるだろう。
WorkTimeプラグインでは、自分が担当のチケットだけフィルタリングして、工数と作業コメントを記入できるので、使いやすい。

WorkTime - Work Time - r-labs

但し、メンバーが実績工数を毎日入力する運用が徹底されなければ、実績工数の精度は上がらない。
たとえば、顧客向けの作業明細書で、特定の作業の工数が多すぎて目立つようなことはしたくないために、月末に、自分の作業を棚卸して、実績工数を作業ごとに按分する作業をやる方法もあるが、正直面倒だ。

【3-3】予定工数、実績工数の集計を自動化する機能を作る

作業明細書を出力する時、Redmineのレポート一覧から、当月・ユーザ・チケット・実績工数ごとに出力する機能がある。
この機能を使って、Excelに詳細データを出力した後、Excelマクロを使って集計し直せばいい。

だが、工数委託メンバーの実績工数に間違いがないか、チェックする作業は結局、リーダーによる手作業しかない問題がある。
メンバーも人間なので、故意ではなく、工数の単純な入力間違いもありがちだ。

一つの解決策としては、予定工数をあらかじめ入力しておき、予定工数と実績工数をチケット単位に比較することで、実績工数の信ぴょう性をチェックするやり方がある。

個人的には、estimate_timelogプラグインを使って、当月・ユーザ・チケット予定工数・実績工数ごとに出力すればいいと思う。
但し、estimate_timelogプラグインはVer2.xまでは使えていたが、Ver3.xで安定運用できるか、まで確認できていない。

estimate_timelogの0.1.0を公開しました。 - アルパカDiary

toritori0318/redmine_estimate_timelog ・ GitHub

Redmine で予定/実績レポートを表示するプラグイン(estimate_timelog v0.5.0)を Redmine 2.x に対応させた - suVeneのアレ

suvene/redmine_estimate_timelog ・ GitHub

あるいは、RedmineのDBを直接叩いて、欲しいデータを抽出すればいいだろう。
手が動くプロジェクトリーダーならば、その方が手っ取り早い。

【4】運用上の課題

上記の運用が回れば、Redmineは実績工数管理システムとして使えるだろう。
しかし、実際の運用では、細々とした課題は残る。
思いついた課題を書いておく。

【4-1】月次締め後は前月の実績工数を修正不可にする

顧客へ前月の作業明細書を提出した後や、委託先会社から前月の請求書が届いた後では、Redmineにある前月度の実績工数は修正不可にすべきだ。
後から勝手に修正されてしまうと、作業明細書や請求書の信ぴょう性がなくなってしまう。
つまり、後からの修正は改ざんと同じだ。

Redmineのデフォルトの機能では、前月の実績工数を入力不可にしたり、後から入力不可を解除する機能がない。
この課題はRedmineをカスマイズしないならば、運用でカバーするしかないだろう。

【4-2】勤怠管理の工数との照合処理を自動化する

工数委託メンバーの実績工数は、本来は、勤怠管理の工数と照合させたいのが普通だ。
普通のSIなら入出のタイムカードが記録されているので、そのデータと自動で照合させて、実績工数の不備がないかをチェックしたい。

すると、勤怠管理システムから、前月度の工数委託メンバーの勤怠工数を取ってきて、照合する処理が欲しくなる。
あるいは、RedmineのREST APIで該当チケットの情報を取ってきて、勤怠管理システムの工数と照合する処理をバッチ処理で作ってもいいかもしれない。

【4-3】顧客向け作業明細書を自動出力する

元ネタの作業明細は、RedmineのDBから直接SQLで出力も可能だ。
だから、顧客向け作業明細書はボタン一つで自動で出力してしまいたい。

【4-4】委託先会社からの請求書の照合を自動化する

この作業も自動化できると、プロジェクトリーダーの作業はすごく楽になる。

【5】結論

上記のように考えてみると、Redmineは実績工数管理システムとして運用は可能だろうと思う。
いくつか課題はあるが、全く使えないレベルではない。

但し、一番の注意点は、作業明細書に出力すべき作業項目とチケットの粒度を合わせる点だろう。
柔軟なチケット管理の利点を活かしながらも、煩雑な作業明細書の集計作業もできるだけ自動化させたい、というトレードオフの問題をクリアできれば、Redmineをより有効に活用できるだろう。

Redmineに日々のタスク、障害、課題などの情報が放り込まれているのだから、RedmineのDBさえあれば、進捗・品質・コストに関する情報は、色んなビューの観点でいくらでも抽出できるはずだ。

このアイデアはまだ考えてみる。

【追記】
Redmine3.2では、チケット一覧に予定工数と作業時間の合計時間が表示されるらしい。
この機能は、プロジェクトリーダーにとっては嬉しい機能だ。

MAEDA, GoさんはTwitterを使っています: "@miminashi チケット一覧での予定工数と作業時間の合計は今後リリースされるRedmine 3.2.0で出るようになります。 http://t.co/zWOxH6Zt1n"