Redmineのロードマップ画面に表示される進捗率と原価計算の関係

Redmineのロードマップに表示される進捗率の計算方法と原価計算の関係について、考えたことをメモ。
ラフなメモ書き。

【元ネタ】
ロードマップ画面に表示される進捗率の算出方法 | Redmine.JP Blog

脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所

見かけ上の進捗: プログラマの思索

チケット駆動開発にEVMの概念を導入してみる: プログラマの思索

RedmineプラグインRodmapsにEVMの機能を追加する: プログラマの思索

Redmineのロードマップには2種類の進捗率が表示される。
薄い緑色は、チケットの進捗率から得られた見かけ上の進捗。
濃い緑色は、終了チケットから得られた実質の進捗。

Redmineが他のBTSよりも優れている点の一つは、ロードマップを見れば、実質の進捗と見かけ上の進捗の2つの進捗が見れること。
見かけ上の進捗: プログラマの思索にも書いたけれど、実質の進捗と見かけ上の進捗に大きな差がある場合、そのプロジェクトは黄色信号。

例えば、仕掛り中のチケットは多いのに、どのチケットも完了ステータスまで到達しておらず、90％のまま停滞している状態。
こういう状態のプロジェクトは、開発者の単体テストは終わったけれど、レビューでたくさんの指摘を受けては直すことを繰り返していたり、バグ修正したのにデグレしていたり同類バグ調査の分析が漏れていたりして、何度も同じ作業を繰り返している場合があるだろう。
ソフトウェア開発では、進捗率が90％のまま停滞する時がとても多い。
つまり、開発プロセスに問題があり、プロジェクトの生産性が落ちている事実を示している。

この発想はPMBOKのEVMに関係していることは以前書いた。
つまり、終了チケットから得られる進捗はEV(実質の価値)、作業中のチケットから得られる見かけ上の進捗はAC(実際のコスト)を表している。
PV(予定している価値)は、予定している終了チケットの進捗から得られるから、EV・PV・CVの3つを計算することによって、プロジェクトのスケジュールやコストをリアルタイムに把握することは可能。

更にこの発想は原価計算にも関連する。
終了チケットは倉庫にある完成品、作業中の未完了チケットは仕掛品に相当する。
つまり、在庫にある商品の状態とイメージすることもできる。

すると、在庫に仕掛品がたくさん残っている場合ほど、その工場の生産性は低いことになる。
完成品でなければ、すぐに販売して売上に変えることができないからだ。

工業簿記に出てくる原価計算の場合、大量規格品の総合原価計算と少品種少量生産の個別原価計算の2種類があるが、ソフトウェアは後者に相当するだろう。
但し、どちらにせよ、直接材料費と加工費、あるいは直接費と間接費の2種類から製造原価を求める手法に変わりはない。
製造原価が求まれば、どれだけ利益を上乗せして販売すればよいか、利益計画を立てることができる。
つまり、製造原価を知らなければ、本来どれだけの販売単価で顧客に売ればよいのか、分からないから、赤字になりやすい。

ソフトウェア開発では、ソフトウェアは人の頭から作られるから直接材料費は殆どゼロだ。
つまり、製造原価の殆どはPGやSEの労務費、パソコンや電気代の経費などの加工費になる。
実際のソフトウェアの製造原価の殆どは人月計算に示される労務費だから、チケットにある実績工数と人月単価で計算できる。

だが、昨今は原価の殆どが間接費になっているため、各製品に間接費を按分すると、本来の製造原価が歪んでしまって、どの製品が本来コストが高いか、どの製品が本来利益が出ているのか見えにくくなる。
その問題意識から出てきたのが、バランス・スコアカードを作ったキャプラン・ノートンが提唱した活動基準原価計算(ABC：Activity Based Costing)。
下記の記事が分かりやすい。

ABC（Activity Based Costing：活動基準原価計算）とは［ITCサンシャイン・ブレインズ］

上記の記事では、電話オペレーターという活動は本来どれだけの原価なのかを計算するために、電話オペレーターの活動を細かく洗い出して、それぞれの活動時間からコストを計算している。
つまり、活動基準原価計算では、資源(リソース)がどの活動に使われて有効活用されたのか、という発想につながるので、ホワイトカラーの生産性を計算することに使える。
活動基準原価計算の具体例としては、役所やNPOなど公的活動で使われた経費が本来の利益や貢献をもたらしているのか、という評価に使える。

もちろん、ソフトウェア開発の原価計算にも活動基準原価計算の発想は使えるはず。
つまり、時間という限られた資源からどれだけの成果物(実際は動くシステム)が作られたのかを追跡することは可能。
Redmineによるチケット駆動開発ならば、チケットに予定・実績工数と予定・実績の開始・終了日を入力する運用ルールが徹底できれば、活動基準原価計算によって精度の高い製造原価を求めることは可能。

製造原価の計算方法については、TOCのスループット会計という発想もある。
下記の記事が分かりやすい。

簿記２級対策　工業簿記１ - 中小企業診断士 中村俊基 - Yahoo!ブログ

スループット計算

スループット会計では活動基準原価計算とは逆に、細かな原価計算をしても無意味で、ボトルネックになる製品の原価を求めることに注力する。
クリティカルパス上の作業が本来の原価計算の源だからだ。
ソフトウェア開発もクリティカルパスがあるから、スループット会計によって、ボトルネックによる制約条件から原価計算することも可能。
TOCの方が本来の製造原価に近いかもしれない。

Redmineにはたくさんの可能性が秘めている。