redmineの作業分類から工数集計～活動基準原価計算

Redmineによる工数集計について考えたことをメモ。

【1】工数集計の問題点

チーム運営する現場リーダーではなく、売上責任を持つマネージャがRedmineに期待する機能は工数集計だろう。
マネージャにとって、プロジェクトの成功とは、品質の良いシステムを確実に納品できるだけでなく、売上がコストよりも高くて利益が出ることだ。

ITプロジェクトは殆どが受託プロジェクトであるから、SEやPGの人月計算、つまり工数集計が重要になる。
特に運用保守のように、一定の金額で契約している場合、当初の予定工数よりも大幅に実績工数がオーバーしたら、ビジネスでない単なるサービスに過ぎない。
だから、予定工数よりも実績工数が上回らないように、もし上回ったとしても、多少の赤字に抑えるようにマネジメントしなくてはならない。

しかし、工数集計の作業は面倒極まりない。
従来のExcelの場合、メンバーに月末に指定のExcelフォーマットで集計報告させて、そこから活動別に集計しなおす必要がある。
何故なら、本来の契約範囲内の作業もあれば、自社の作業で契約外の作業の場合もありうるから、それらを厳密に区別しなくてはならないからだ。

更に、改善要望別に予定・実績工数を集計する必要もある。
何故なら、改善要望ごとにどれだけのコストがかったのかを顧客へフィードバックして、コストに見合った改善が行われたのか、評価するデータを提供しなくてはならないからだ。
しかし、改善要望別に実績工数を把握するには、メンバーにテーマ別に毎日、工数入力を強制しなければならない。
特に、複数のタスクを掛け持ちで作業しているメンバーにとって、毎日の工数入力はかなりの手間がかかるから、とても嫌がる。

また、開発チームとしては、サブシステム単位あるいは機能単位に、問合せ調査や障害対応、改善要望の実績工数を把握しておきたいものだ。
何故なら、どの機能で顧客から問い合わせが多いのか、本番環境で障害が多いのか、どれくらいの対応工数がかかるのか、をまとめて、今後の是正対策や予防対策に役立てたいからだ。

しかし、実際のタスクは複数機能にわたるタスクもあるし、ドキュメント作成のように特に機能に依存しない管理工数の範疇もある。
すると、それらの工数は、各機能へ均等に配分(按分)する必要があり、その計算はとてもややこしい。
その計算はExcelだけでは役不足で、Accessを使って一つのプログラムを作るぐらいの手間がかかってしまう。

【2】活動基準原価計算(ABC：Active Based Costing)とは

工数集計の考え方は最終的には活動基準原価計算、つまり原価計算の考え方に通じる。
渡辺さんの「生産管理・原価管理システムのためのデータモデリング」の最終章に、SEの立場から活動基準原価計算について優れた解説があり、とても分かりやすい。
また、下記のITProの記事も分かりやすい。

ABC（Activity Based Costing：活動基準原価計算）／ABM（Activity Based Management：活動基準原価管理）：ITpro

製造間接費の予定配賦と原価計算表: 簿記２級　工業簿記の考え方

第7章直接原価計算

ABC（活動基準原価計算） - Q-BPM

レポート：＜役に立つ管理会計＞活動基準原価計算（ＡＢＣ）

活動基準原価計算の発端は、多額の間接費をいかに按分するか、本来の原価とは何か、という問題に対して生まれたようだ。
詳しくは、簿記2級の工業簿記、簿記1級の原価計算を勉強すると良い。

活動基準原価計算では、一つのサービス(製品、システム)のコストをどんぶり勘定で原価を収集するのではなく、活動(アクティビティ)単位で細かく原価を集計して、それらを分析することに利点がある。
上記のITProの例では、コールセンターのオペレータの人件費を、サービス単位ではなく、電話対応や資料作成、会議などの活動単位で労働時間を記録し、そこから原価を計算する。

そうすれば、本来の活動でどれだけの価値創出があったのか、を厳密に計算できるようになる。
ITProの例では、電話対応よりも資料作成や会議に多くのコストがかかっているならば、コールセンターの仕事の生産性は実はあまり高くなかったのではないか、という評価を出すこともできる。

【3】Redmineの工数集計機能は使い物になるか？

Redmineの場合、チケットに予定工数と実績工数はデフォルトで付いている。
Redmineの工数集計のViewは、何通りもある。

例えば、バージョン単位で工数集計したいならば、バーンダウンチャートが相当するだろう。
Chartsプラグインや@daipresentsさん作成のバーンダウンチャートプラグインを使えばよいだろう。

redmine_chartsプラグインでバーンダウンチャートは表示可能: プログラマの思索

Redmineに入れたプラグイン一覧part2: プログラマの思索

理想ラインが加わったredmine_version_burndown_charts画面: プログラマの思索

メンバー別に工数集計したいならば、WorkTimeプラグインを使えば良い。
WorkTimeプラグインは、実績工数の入力のUIもとても優れているので、日々の実績工数の確認もしやすい。

RedmineのWorkTimeプラグイン: プログラマの思索

あるいは、テーマ別に工数集計したいならば、チケットの親子関係(Subtasking)を使えばいいだろう。
つまり、親チケットはテーマ(改善要望)ごとの集計用チケットとして、子チケットに各メンバーのタスクを登録しておけば、親チケットへ予定・実績工数や進捗率を自動集計してくれる。

また、プライベートチケットを使って、顧客へ見せる必要がないタスクはプライベートチケットにして、工数集計から外す運用もしてもいい。

但し、Redmineのデフォルトの工数表示機能であるレポート機能は正直UIが弱い。
せめてCSV出力できるようにして欲しい。

【4】RedmineにあってTracにない機能は「作業分類」という項目だ。
「作業分類」は日々の実績工数をラベル付けする属性であり、これがまさに活動基準原価計算の「活動(Activity)」に相当する。
すなわち、Redmineの作業分類をうまく使えば、活動基準原価計算に応用することもできるだろう。

僕は以前、作業分類を「設計」「開発」「テスト」「リリース」などのように工程別に入れていたが、あまり役立たなかった。
活動基準原価計算の考え方に従うと、原価計算の観点から活動単位を作業分類に割り当てるべきだろう。

すると、Redmineの作業分類には、「会議」「レビュー」「本来の開発」「リリース」などのように、1人だけの作業時間と、複数人で行う作業に分けた方が良いと思う。
例えば、「本来の開発」よりも「会議」「レビュー」に時間がかかりすぎている場合、そのタスクはかなりの無駄が含まれている事が分かる。

この考え方を発展させると、Redmineの作業分類は、新規開発プロジェクトよりも運用保守、ITプロジェクトよりも営業チームのタスク管理やインフラチームのタスク管理の方に向いていると思う。
何故なら、営業チームやインフラチームのタスク管理では、ITSとSCMを連携する機能よりも、タスクの工数集計と原価計算を組み合わせる方がはるかに価値があるからだ。
特に、ITILをRedmineで運用した場合、インシデント管理・問題管理・変更管理・リリース管理の各プロセスでどれだけの工数がかかったのか、を集計して分析する方が、その後の改善に役立つ。

【5】Redmineの工数集計は、バージョン別・人別・テーマ別・作業分類(活動)別の観点で、集計して分析することが可能だ。
そこから原価計算という考え方を取り入れることも可能。
色々試してみる。