アーンドバリューとベロシティは共存できるか

ソフトウェア開発者は、アジャイルで柔軟なアプローチが顧客の問題を解決し、ビジネス価値を生み、高品質なフィーチャーを開発するのにベストな方法だと確信を深めています。その一方で、PMO はプロセスばかり作って、非IT 分野でうまくいっていたという伝統的な手法をプロジェクト・マネジャーに教え続けています。

これら2 つの流派（開発者とPMO）の報告を組み合わせて、上位マネジメントが両方のメトリックスの整合性をとる方法はあるのでしょうか？

はい、あります。万全ではありませんが。

アーンドバリューになじみのない人もいるでしょう。これは毎週、毎月、四半期ごとに、進捗と達成したビジネス価値を数値的に追跡したものです。少々乱暴な言い方かもしれませんが、プロジェクト・マネジャー（および他のステークホルダー）はコスト要因を無視して、要求事項を定義します。そして、プロジェクト作業にかかる作業時間を見積もり、その時間見積りをスケジュールに変換します。

さて、報告期間を1 週間として、プロジェクトチームはその週に事前に定義した40 時間分のタスクを完了できると見積もったとしましょう。金曜日の午後、チームは実際の進捗を報告します。すべてのタスクを40 時間で完了できていれば、40 時間の価値を稼いだことになります（EV：Earned Value、アーンドバリュー）。これは40 時間の作業相当の価値だと見積もられ、計画されたものです（PV：PlannedValue、計画価値）。EV－PV がSV（Schedule Variance、スケジュール差異）となります。このケースでは、チームのスケジュール差異はゼロになります。

しかし、もしチームの進捗が遅れるとスケジュールは遅れます。下流工程にいる作業者はそのことを連絡してもらう必要があるかもしれません。もしチームが早く完了したのなら、もともとの見積りが過大だったのかもしれません。資材受け入れや他のプロジェクト参加者は、予想よりも早くタスクに着手する可能性があることを知っておく必要があります。思い出してください。プロジェクトのスコープ（作業）はすでに決まっているのです。

アジャイルのベロシティという用語は、開発者の生産性を評価したものを意味しています。開発者は先週の作業能率に基づいて（先週完了した作業量を超えないように）見積もった作業量を今週引き受けます。しかしながら、開発者は自分自身、そして先週選んだ仕事と比較されるだけです。長期スケジュールと比較されることはありませんし、他人の作業との関係からスケジュールし直すことはありません。その上、今週のタスクはもっと簡単かもしれませんし、ほとんどバグがないかもしれませんし、プログラマにとってはなじみ深いものかもしれません。

ソフトウェア開発プロジェクトでは、最終製品の機能は確定しているわけではありません。したがって、実際のベロシティが見積りほど大きくなければ、スコープ（実現するフィーチャーの量）を縮小することもできます。

マーケット上、製造上、トレーニング上の問題にまみれたソフトウェア開発プロジェクトからの報告をまとめているプロジェクト・マネジャーには、報告基準が必要です。一番シンプルな方法は、IT 部門にソフトウェアに取り組むためのまとまった時間（そして相応の給料）を与えることです。報告では、例えば5 週分を見せましょう。IT チームがソフトウェアの週次報告をあなたに出すときには、完成したフィーチャーやストーリーも一緒に提出させます。そのあとあなたはそれをタスク名に変換して、報告に追加してください。これで、これらのタスクが計画通り100％完了していることを示せます。これによって、従来のスタイルの報告でもアジャイルの進捗を示すことが可能になります。