アーンドバリューだけではどうしようもない

アーンドバリュー(Earned Value) ってありますよね。多分エンジニアが100人いたら120人くらい面倒くさいと思うやつです。
おさらいでアーンドバリューの意味を確認しておきましょう。

EVM 【 Earned Value Management 】アーンドバリューマネジメント / EVMS　引用　e-words
プロジェクトマネジメントにおいて進捗状況の把握・管理を行う手法の一つ。作業の到達度を金銭などの価値に換算したEV(Earned Value：出来高)という概念で把握する。

作業をお金に換算して計画値と実績値を比較して進度をみるわけですが、なんでエンジニアが面倒くさいと感じるかと言うと、

作業の見積自体自分で作っていない、又は、合意していない

作業時間なんて計っていない

そもそも単価は誰の単価なんですか

そんなところじゃないでしょうか。とは言え、工程の締め切りまで、はたまた納期までに間に合うのか間に合わないのかを知りたいのは人情だし、そんなことは結局「納期までに『間に合わせる』だけなんだから同じなんだよ」なんて言われちゃうと後はもう「祈る」か「鬼軍曹」になって「早くコードをコミットしやがれ！マヨネーズ野郎ども！！」なんてセリフを吐かなければならないのかとか、もうどっちもダメだよなぁと思うわけです。

現実問題、アーンドバリューだけでは本来のアーンドバリューの意図するところの「未来を期待通りに迎えられるかを予測する」には足らんのです。全然足らない。何が足らないというかと言えば、

作業の標準化と品質

です。

作業の標準化と言うと引かれるかもしれないけれど、ココでの意図は、例えば設計なら「仕様検討/執筆/セルフレビュー/内部レビュー/外部レビュー/指摘反映/コミット」などの作業手順を共通化、統一化するということです。こんなことは複数のエンジニアが一緒にプロジェクトで働いているなら「初めから合わせてやっているのは当たり前じゃん？」って思うかもしれないけれど、現実はどう？とりあえずやってみて、その場で適当にやっている方が多いんじゃない？ワタシ的はそういったやりかたは最初に粗方決めておいて、微修正くらいで運用する程度にイニシャルコストを掛けてでもやった方が、行き当たりばったりでアウトプットの状態もレベルもバラバラで後から揃えるコストを払うよりどれだけ安価か、と思うけど。

作業手順を揃える他に、どこからどこの作業を計測するかというのと実績を把握する単位を揃えておくのも必要です。それもアーンドバリューを本当にやるなら最初からプロセスとして埋め込んでおかないとエンジニアに刷り込むことは「無理！」ですから。

品質は「この条件をクリアしないと先に進ませないよ」という意思表示だと思うのです。それも作業の標準化に組み入れらるモノであって、あとから検証して足らないから足すようなものではないのです。それをバグが出たら直せばいいんだろうなんて言う輩をみると「処す」と思うのは仕方がないことだと思うのですが。

で、アーンドバリューは出来高、つまり実績と計画値を比較するわけで、その出来高は作業のプロセスが統一されていないといくら実績値を報告してもらっても確からしさには？が付くわけです。同じように幾ら作業が終わった、プログラムをコミットしたと言われてもその出来具合が酷かったら将来、と言っても次のテスト工程での手戻りを先送りしているだけなんですね。だから共通的に決めてある品質の作り込みのレベルをクリアしていないと先々危なくてどうしようもないです。と言うかそんなの受けれられないです。

纏めると、アーンドバリューをするにしてもWBSを定義する前の作業の標準化や品質の考え方を含めて揃えてやらないとアーンドバリューに期待していることは得られないということです。