見出し画像

第172回: 「統計の実務」32 EVM その3(EVM 使用上の注意点-前編)

◀前の記事へ   次の記事へ▶

≡ はじめに

前回は、「EVM その2(EVM とは)」でした。

プロジェクトの進捗について「PV/EV/ACの値を計測する方法」と、「測定した値を使ってEVMグラフ(PV、EV、ACの推移グラフ)を描く方法」(ggplot2を使う方法とExcelを使う方法)についてでした。

EVMについて、一通りの進め方はわかったものの、実際にデータを取ろうとすると「どうするんだっけ?」と思うことがたくさん出てくるはずです。(私がそうでした)

さらに、前回のnoteに、

EVMによって分かることは、
  1. 現時点でプロジェクトがどれだけ進行したのか
  2. 計画と実績との乖離の大きさ
  3. このまま推移するとどうなるのか
の3点です。

と書いたのですが、『具体的にどこを見たらわかるの?』と疑問に思われると思います。(私がそうでした。ふたたび)

ということで、今回は、上記の2点、すなわち、「データのとり方」と「解釈のしかた」について書こうと思います。

文字数が増えてしまったので「解釈のしかた」については一部次回に回します。



≡ データのとり方

まずは、PV(出来高計画)です。前回「プロジェクトの計画資料にある、開始日と終了日と各工程ごとの工数見積もり値から作ります」と書きました。

実は、ACでも同じなのですが、「工数」を「お金」に換算する必要があります。

EVもお金に換算するのですが、EVは、
  (PVで金額換算済みの中間成果物)×進捗率
の総和で求めます。そのため、EVでは、あまり、お金のことを考える必要がありません。

「お金 = 工数 × 要員単価」ですから、「要員単価」の情報が必要となります。
ところが、前回の最後の方に書いたとおり、

要員単価はマネージャーしか知りません。

といった問題が発生しがちです。

さらに、「自分の分は給与明細の残業代から【残業代 ÷ 残業時間 ÷ 1.25】(1.25で割っているのは、法律で残業勤務の対価は通常勤務の25%増しと決まっているから)でわかるとしても、他の人の分がわかりません」だとか、「そもそも、給与のみから算出してよいのでしょうか? 会社は給与のほかにオフィスの賃料や光熱費ほかを負担しているはずです」という人もいます。

多くの会社では、マネージャーしか要員単価の額を把握していないはずです。
しかし、納税を正しく行うための財務会計処理をしようということではありません。
EVMは、管理会計処理だと割り切って、それほど厳密でなくて良いのです。前回は、5,000円/時として計算しましたが、まずは、これで計算すればよいです。人月80万円の派遣社員の方も月に160時間勤務(20日×8時間/日=160時間)なら5,000円/時です。結局、縦軸のスケールが若干変わるだけで、PV/EV/ACの比較や納期にはあまり影響がないからです。

ここまで読んで、「縦軸のスケールが変わるだけなら金額換算せずに工数のままで良いのでは!?」と思われたかもしれません。
はい。それでも進捗管理には十分です。実際、アジャイルでよく使われている「バーンダウンチャート」は金額換算していません。バーンダウンチャートは、縦軸を反転しているだけで、「ACがないEVMグラフ」という見方もできます。

EVMとバーンダウンチャートは「目的」が違うので使い方も違います。「目的」とは、そのままの意味で、「的」、すなわち、進捗管理をおこなうことで、当てようとしている“まと”が違います。

話がそれました。EVMに戻ります。
次に考える必要があるのは、工程と工数の情報をどこから入手するかです。
結論を先に言えば、工程と工数は、EVMで独自に持つのではなくWBSと対応付ける情報はWBSに集中して管理して、EVMはWBSのビューのひとつと位置付けるとうまくいきます。そういう意味で、前回、

WBSと連携したEVMを描けるプロジェクトマネジメントツールを使うべき

と書きました。

ただし、現実問題として、日本ではエクセル方眼紙を使ってWBSを作っている組織が多いです。
その場合は、エクセルの情報をEVMに連携させるほうが大変です。(使っているうちに勝手にExcelに行や列を追加削除する人が現れるのです)
したがってExcelでWBSを管理している場合には、PVを作るときにだけWBSを参照するのが良いです。せめて、ライチ(Lychee Redmine)を導入してくれるとよいのですが……。
(なお、自分でライチを立ち上げるのはちょっと大変です)

実績値のEV(出来高実績)とAC(コスト実績)も厳密でなくて大丈夫です。

EVの方ですが、WBSのタスクが十分に細かく、たとえば、20行あれば、一つのタスクは全体の1/20の5%しかありません。
仕掛中のタスクの進捗率を0%, 30%, 70%, 90%あたりの粗い粒度で測っても、全体としては数パーセントの誤差に収まります。
それに、進捗管理で気を付けるべきは、EVの絶対値ではなく、前回報告時のEV値との差です。90%が3週も続いたら何か問題があると気付くほうが大切と思います。

もう一つの実績値である、ACは勤怠管理データをそのまま突っ込めばOKです。こちらも「会議時間を引いたほうが良いのですか?」と悩む人が多いのですが、半日(4時間)単位で十分です。残業時間も入力します(残業単価にしなくて良いです)。

PVを作成するときにも、残業をあてにしているなら計画に入れるようにします。実態を管理することが大切です。

ところで、システム開発の場合、顧客から「EVMで進捗報告をしてください」と言われることがあります。

その際に、AC(コスト実績値)を顧客に提示したくないことがある(ほとんど?)と思います。
社内用と顧客用の2つのEVMを作るのは無駄なので、社内用のEVMのみを作成し、そちらは週次で管理して、顧客に提示するときには縦軸を1.5倍にするなどして、PVの最終金額と顧客への請求額(利益込みの額)のズレが無いように加工します。



≡ EVMの解釈のしかた

再びの引用となります。

EVMによって分かることは、
  1. 現時点でプロジェクトがどれだけ進行したのか
  2. 計画と実績との乖離の大さ
  3. このまま推移するとどうなるのか
の3点です。

今回のデータとRのスクリプトは以下の通りです。

# install.packages("tidyverse")
# install.packages("patchwork")

library(ggplot2)
library(patchwork)
library(tidyr)


EVM <- Dataset

EVM$day <- as.Date(EVM$day,"%Y/%m/%d")

EVM$SPI <- EVM$EV / EVM$PV
EVM$CPI <- EVM$EV / EVM$AC

EVM$SPI2 <- EVM$SPI -1
EVM$CPI2 <- EVM$CPI -1

g1 <- ggplot(EVM, aes(x = SPI2, y = CPI2)) +
     geom_path(aes(colour = t), arrow = arrow(), size = 1, colour= "red",lineend = "round")+
     scale_x_continuous(limits=c(-0.5,0.5))+
     scale_y_continuous(limits=c(-0.5,0.5))+
     xlab("SPI - 1") + #x軸の軸ラベルを指定
     ylab("CPI - 1") + #y軸の軸ラベルを指定
     geom_hline(yintercept = 0, linetype = "dashed", colour = "darkred")+
     geom_vline(xintercept = 0, linetype = "dashed", colour = "darkred")+
theme(
  axis.text.x = element_text(angle = 0, hjust = 1),
  axis.text.y = element_text(size = 10),
  axis.title = element_text(size = 10),
  legend.text = element_text(size = 10),
  legend.title = element_text(size = 10)
 )


EVM <- gather(EVM, key = "TypeC", value = "Cost", PV, EV, AC)
EVM <- gather(EVM, key = "TypePI", value = "PI", CPI, SPI)


g2 <- ggplot(EVM, aes(x = day, y = Cost, color = TypeC, group = TypeC)) +
     geom_line(size = 2) +
     scale_x_date(date_breaks = "1 week",
     date_labels = "%m/%d")+
     xlab("Date") + #x軸の軸ラベルを指定
     ylab("金額") + #y軸の軸ラベルを指定
 theme(
  axis.text.x = element_text(angle = 30, hjust = 1),
  axis.text.y = element_text(size = 10),
  axis.title = element_text(size = 10),
  legend.text = element_text(size = 10),
  legend.title = element_text(size = 10)
 )





g3 <- ggplot(EVM, aes(x = day, y = PI, color = TypePI, group = TypePI)) +
     geom_line(size = 2) +
     scale_x_date(date_breaks = "4 week",
     date_labels = "%m/%d")+
     xlab("Date") + #x軸の軸ラベルを指定
     ylab("率") + #y軸の軸ラベルを指定
 theme(
  axis.text.x = element_text(angle = 90, hjust = 1),
  axis.text.y = element_text(size = 10),
  axis.title = element_text(size = 10),
  legend.text = element_text(size = 10),
  legend.title = element_text(size = 10)
 )

g2 / (g3 + g1)

ggsave(plot = g2, file = "EVM1.png", w = 6, h = 3, dpi = 600#pngでグラフを保存
ggsave(plot = g3, file = "EVM2.png", w = 6, h = 3, dpi = 600#pngでグラフを保存
ggsave(plot = g1, file = "EVM3.png", w = 6, h = 3, dpi = 600#pngでグラフを保存

こちらですが、データ(EVM-2.csv)をRコマンダーで読み込んで、パッケージを2つ(スクリプトの1行目と2行目)をインストールして、あとは、このスクリプトを実行するだけです。実行すると、画像ファイルをドキュメントの下に残します。

出来上がったグラフはこんな感じです。
(3つのグラフが1枚にまとまっています)

以下、この3つのグラフの読み方を説明します。

■ EVMグラフ(PV、EV、ACの推移グラフ)

最初のグラフはこちらです。

EVMグラフ(PV、EV、ACの推移グラフ)

EVMのグラフと聞くと思い浮かぶグラフです。
前回は、X軸についてカレンダースケールに対応していませんでしたが、今回は対応しました。(笑)

     scale_x_date(date_breaks = "1 week",
     date_labels = "%m/%d")+

上の箇所です。あと、日付関係の処理を簡略化するため、CSVの日付を2022/4/22(デフォルトの形式)にして、

     EVM$day <- as.Date(EVM$day,"%Y/%m/%d")

で、Rにこの変数(ベクトル)のデータ型は、日付だよって教えるようにしました。(前回は文字型でした)

ggplotが好きになるには、こういう呪文を増やしていくしかありません。

それでグラフの見方ですが、過去は雰囲気だけ見ます。肝心なのは最新データの箇所です。

最新データ

凡例が見えなくなってしまいましたが、PV(出来高計画:青)、EV(出来高実績:緑)、AC(コスト実績:赤)にしています。(好みで好きな色で構いません。今回のスクリプトでは指定していません。「TypeCの値毎に適当にお願い!」ってggplotに頼んでいる感じです)

それで、現時点のグラフの値から「PV > EV」(開発遅れ)、「PV < AC」(コスト超過)、「PV ≒ EV」(計画と同じ)の3点をチェックします。上のグラフでは、計画よりも開発が進んでいて、コストも抑えられていますので、初めの二つは問題ありません。

つまり、3点のうち、「PV ≒ EV」だけが引っ掛かりました。
PVとEVが、厳密に同じ値になることは滅多にありませんので、だいたい同じ(≒)で見てください。

「計画どおりに成果物ができて何の文句があるんだ」と思われた人が多いのではないかと思います。ところが、実は、EVMを導入すると、「PV ≒ EV」という報告が届く場合がほとんどです。

計画があるとそれを守ろうとする意識が強く働く」からです。

計画と実績に差があると叱られたり、余計な仕事が増える」と心配してのことかもしれません。計画と実績との差は担当者の問題ではなく、マネージャーが解決すべき問題と割り切って、ある意味堂々と?報告するほうが良いです。

計画と実績がほとんど同じ場合は、
  1. もともとの計画が甘かったケース
  2. 実績計上において、十分な精度で集計されていないケース
  3. 無理をしているケース
の可能性があります。

1と2は心配無用です。計画についてレビューして合意したわけですから。

気にしてほしいのは3です。

3のときに、ACがいつもよりも増えていたら残業時間による過労を心配します。でも、EVをPVに合わせてくる人はACをごまかすことも多いものです。
進捗会では何も言わずに、普段の様子をよく観察してアドバイスをしたり、フォローをつけたりします。



≡  おわりに

今回は、「EVM 使用上の注意点-前編」でした。長くなったので、残りの2つのグラフの解釈のしかたは次回にします。

次回は、EVMの使用上の注意点の残りについて書きます。

◀前の記事へ   次の記事へ▶

この記事が気に入ったらサポートをしてみませんか?