プログラマの思索

Redmineでリソースヒストグラムを実現するアイデアについて、ラフなメモ書き。

【参考】
情報システム用語事典：リソースヒストグラム（りそーすひすとぐらむ） - ITmedia エンタープライズ

[ThinkIT] 第6回：組織管理 (2/4)

PMBOK（Ｒ）テンプレートの作成　その８ / PMstyleコラム

【1】リソースヒストグラムが必要な背景と問題

【1－1】SIの管理職になれば、彼の仕事の大半は、開発要員の調達管理とシステム提案による営業だ。
システム開発を受注したら、システムを設計し、開発するためのメンバーを一定期間は確保しなければならない。
この時に必要なツールが、リソースヒストグラム。
別名は、山積み表。
あるいは、要員表。

リソースヒストグラムは、縦軸がメンバー、横軸が毎月で、各セルは該当月のメンバーが働く工数を表す。
普通は、1ヶ月働くなら、1.0人月(単位：MM)になる。

【1－2】このリソースヒストグラムを作るのはかなり面倒だ。
その理由はいくつかある。

一つ目は、該当の案件にアサインされた要員が、すべての期間に1人月分働くとは限らないため、調整の手間が発生すること。

例えば、他案件に掛け持ちしているメンバーや、開発・テストなどの特定の工程だけにアサインする派遣の開発要員もいると、リソースヒストグラムはまばらな値になる。
すると、他案件に掛け持ちしているメンバーは、該当案件の稼働工数は0.5MMだったりする。
開発・テスト工程でかき集めた開発者なら、2～3ヶ月だけ1.0MM稼働し、他の月は契約されずにゼロになる。
彼らのようなメンバーや開発者も、考慮したり、契約の手配が必要。

2つ目は、WBSの積み上げ法による見積り工数とリソースヒストグラムで作った見積りが完全に一致しないこと。
WBSの積み上げ法は、システムの機能や成果物ごとに詳細に見積もって積みあげるから、精度は高い。
しかし、システムの機能を誰が作るのか、によって、生産性が違うし、タスクの先行・後続の順序を考えると、工数や納期が当初よりも膨れ上がってしまいがちだ。

だから、リソースヒストグラムを作りながら、実現可能な要員のアサインを考えなければならない。
でも、普通は、積み上げ法とリソースヒストグラムにおける見積り工数は一致せず、多少の誤差が出る。
僕の今まで見てきた案件では、どちらかの見積りのうち、多い見積りを正しいものとして、開発を進めていた。

3つ目は、リソースヒストグラムの保守がとても面倒なこと。
仕様変更や工期の短縮などが発生すると、リソースヒストグラムを保守しないといけないが、この作業がすごく面倒だ。
何も考えずに修正すると、特定のメンバーが1ヶ月で2人月も働く、みたいな非現実的な計画が作られてしまう。

MSProjectには、タスクの先行・後続関係に応じて、リソース(作業負荷)の平準化を行う機能があるので便利だが、最終的には手作業の修正が発生する。

【1－3】そんな面倒な作業が多いリソースヒストグラムが重要なのは、メンバーの作業工数がプロジェクトの原価に直結するからだ。
つまり、リソースヒストグラムの精度が、プロジェクトの利益に大きく依存する。

一括請負案件では、受注した時に契約金額が決まっているから、粗利を確保するためには、メンバーの作業工数の上限は決まっている。
その上限を超えると粗利が減り、損益分岐点を超えれば赤字なる。

SIの受託開発案件では、大規模プロジェクトになるほど、赤字のリスクは大きい。
普通は、当初の計画時点の前提条件がプロジェクト進行中に変わってしまい、リソースヒストグラムも影響を受けて、当初の作業工数よりも増えてしまいがちだからだろうと思う。

「人月の法則」に従うように、開発メンバーの人数が増えるほど、プロジェクトはどんどん遅延していく。
その場合、リソースヒストグラムは、縦軸のメンバーがどんどん増えて、積み上げられた総工数が膨れ上がることになる。

また、リソースヒストグラムは進行中のプロジェクトの原価や利益を見たいだけでなく、今後受注されるであろう提案中の案件に、どれだけの開発要員をアサインできるか、を予測するためにも使われる。
普通は、リソースヒストグラムで3ヶ月先、半年先の見積り中の案件に対し、メンバーがどれだけ必要か、を計算して、システム提案という営業活動を行なっているわけだ。

このように、SIの管理職は常に、リソースヒストグラムをにらめっこしながら、月末に工数締めされる時に、自分の部署の売上や利益が大丈夫か、ハラハラドキドキしているわけだ。

【2】Redmineチケットによるリソースヒストグラムの実現方法

【2－1】そんなリソースヒストグラムもRedmine上で実現することは可能だ。
まず、前提条件として、チケットに開始日・期日・予定工数・実績工数・担当者は入力される運用があるとする。

すると、リソースヒストグラムの仕様は、下記のように、チケットの属性を集計すれば良い。

【例】測定日：6/15

メンバーごとのリソースヒストグラム工数(「RH工数」と略す)
・5月：過去月は、該当月の実績工数の和。
・6月：当月は、当月初めから測定日までの実績工数の和＋測定日の翌日から当月末までの予定工数の和
・7月：未来月は、該当月の予定工数の和

上記の仕様の意味は、実績工数が発生した日までは、該当月のRH工数は実績工数の和で計算できる。
まだ実績工数が発生していない将来の日は、該当月のRH工数は、予定工数の和で計算できる。

また、上記の仕様の実現方式としては、日次または月次に工数集計のバッチ処理を動かし、毎日または毎月のRH工数をサマリしたテーブルに保持すればいい。

【2－2】Redmineチケットで実現するメリット

RedmineチケットをWBSのように見なすならば、プロジェクト計画時に全てのチケットに開始日・期日・予定工数・担当者をあらかじめ登録できる。
Redmineへチケットを一括インポートすれば、プロジェクト計画時点のリソースヒストグラムを立てることができる。
そして、日々の実績工数はチケットに記録されるので、バッチ処理で工数集計してサマリテーブルに保持すれば、簡単にリソースヒストグラムを見ることができる。

つまり、リソースヒストグラムは、EVMと同様にRedmineのチケット管理で簡単に実現できる。

【2－3】Redmineによるリソースヒストグラム作成処理で不足している点

しかし、Redmineはあくまでもチケット集計結果から、リソースヒストグラムを生成しているに過ぎない。

例えば、MSProjectのように、リソースの平準化のような気の利いた機能はない。
従って、現状のリソースヒストグラムで、特定のメンバーに作業負荷が大きく偏っていておかしい場合は、手作業でチケットを逐一修正するしか無い。

また、毎月の実績工数は月末に締められて、修正不可として確定され、工数委託の開発者の会社に毎月の委託費を支払わなければならない。
つまり、Redmineチケットからバッチ処理でリソースヒストグラムを生成する場合、月次締め処理が必ず必要で、一度締められたチケットの実績工数は修正不可になる仕様が必要。

そして、Redmineチケット管理に最も不足している機能は、メンバーの人月単価を保持する機能がない点だ。
そのため、実績工数から毎月の委託費を計算する処理は、別の社内システムで実施するしかない。

すなわち、Redmineによるリソースヒストグラムは、あくまでも工数ベースの原価計算機能と割り切るしか無い。

【3】とは言え、Redmineチケットにすべての作業と工数が記録されているならば、チケット集計機能によって、色んな使い方ができる。

普通のSIでは、リソースヒストグラムの他に、毎月のメンバーごとの稼働率と生産性を必ず計算している。
下記の仕様で計算される。

・稼働率＝該当月の実績工数(ΣAC)/該当月の予定工数(ΣPV)
・生産性＝該当月の出来高工数(ΣEV)/該当月の予定工数(ΣPV)

【3－1】稼働率

「稼働工数」とは、メンバーが、一括請負案件や工数委託案件(つまり準委任または派遣契約の案件)、保守案件など、売上が発生する案件で働いた実績工数の和のこと。
「総工数」とは、メンバーが該当月に働いたすべての実績工数の和。

稼働工数は、売上が発生する案件の実績工数なので、直接人件費になり、仕掛品で計上される。

一方、売上が発生しない案件とは、例えば、社内の研究開発、営業活動、社内会議、教育研修など、売上が０円の活動に相当する。
つまり、これらの実績工数は、間接費として計上され、普通は製造間接費として集計され、すべての部署に按分されて配賦される。
つまり、稼働工数以外の工数は、間接費のため区別しなければならない。

SIの上層部の観点では、稼働率の高いメンバーは、売上への貢献が高い。
逆に、稼働率の低いメンバーが多いという状況は、受注される開発案件が少ない時がほとんどであり、社内の開発者は暇を持て余して、自社のサーバーで作業したり、研究開発したりしていることになる。
だから、SIでは、稼働率が低い社員が多くならないように、常に受注した案件に社員をアサインできるように、注力しているわけだ。

【3－2】生産性

また、生産性は、文字通り、１よりも大きければ、予定された時間よりも短い時間でアウトプットを出せたことを意味する。
つまり、生産性の高い社員が多いほど、数多くの受注した開発案件をこなせることになる。

しかし、SIのソフトウェア開発では、生産性が高いからと言って、開発者のインセンティブが高まる仕組みにはなっていない。
当初の予定工数よりも短い時間で作業が終わったら、見積りが甘いのでは、と逆に詮索されてしまい、次回からの予定工数を減らされてしまう。
あるいは、生産性を高めて、暇な時間ができたとしても、余った時間を別の作業で売上に結びつけるのは難しい。

結局、生産性も稼働率も一つの指標にすぎない。

【3－3】Redmineでは、生産性は、メンバーごとに、「毎月のチケットのPVの和/毎月のチケットのACの和」を計算してバッチ処理でサマリテーブルに保持すればいい。
しかし、稼働率は、稼働工数の対象のプロジェクトかどうか、Redmineプロジェクトにフラグを付けておく必要がある。

【4】リソースヒストグラム、稼働率、生産性などをRedmineで実現することは可能だ。
WF型開発中心に受託案件を回しているSIなら、それらを定期的に集計する仕組みを持つRedmineは一つの有力候補になるかもしれない。