プロジェクト終了後の実績把握

見積りを行って、そのままにしていては、見積りが正しかったのかどうかわかりません。
また、不幸にして、見積りと大きくかけ離れた結果となった場合は、なぜ、そのような結果になったのかを事後評価する必要があります。

n評価（計測）されないものは、改善されない！ 　のです・・・

n

結果としての規模を計測すれば、生産性や品質が向上するかということであれば、答えはNOです。（それだけでは向上しません。）
しかし、規模（結果）を評価せずに、生産性や品質を向上できるかといえば、それも答えはNOです。
評価されない（できない）ものは、たとえ問題がそこに存在していたとしても、認識できないし、結果的に改善もされないからです。

プロジェクト終了後に、プロジェクトの内容を評価し、今後に生かせる教訓・ノウハウを蓄積していくべきです。

その一環として、見積りを実施する上でのベースラインの見直しを行う必要があります。
ここで言っているベースラインとは、見積り内容をどの程度補正すればいいのかとか、係数の見直しのことです。

例えば、ツールを使用して類推法で見積りを実施した場合、ある一定の傾向がでてきます。（実際よりも多めに出るとか、少なめに出るとか・・・）
その傾向はどういう傾向なのかということと、どの程度の誤差が出るのかということを分析しておきます。
次回のプロジェクトで同じツールを使用する場合は、その内容で補正をしていけばいいわけです。

あるいは、ある係数を乗じて見積もりを実施した、という場合もその係数が本当に妥当であったのかを事後的に評価する必要があります。
場合によっては、当該係数を変更し次回の見積りに適用する必要があります。

ただし、上記の見直しはある程度の実績（件数）を基に行う必要があります。
そうでなければ、ある特異な事例に基づいてベースラインを設定してしまう可能性があり、結果的により精度が落ちる結果になるかもしれません。

実績としてはＬＯＣ（Line of Code）を求めることが多いと思います。

しかし、開発ツールや言語によっては、LOCで実績を把握することが困難な場合があります。

例えば、ソースを自動生成するようなツールを適用していた場合、冗長（無駄）なソースを生成しているかもしれません。（同じ仕様の処理を異なるツールで自動生成して、LOCが１０倍程度違うということもありました。）

あるいは、共通部品等を使用したり継承を行うことで、結果的に少ないソースで実現することが可能となるかもしれません。

ただし、継続的に同じツールや言語を使用して開発するというい場合は、結果としてのＬＯＣを管理すればいいと考えます。

しかし、プロジェクトによって使用する開発ツールや言語が異なるという場合は、実績についてもＦＰで把握することを推奨しています。
といっても、外部仕様決定段階でＦＰを算出していれば、その時点での見積もり結果が最終的な規模ということになりますので、プロジェクトが終了後に再度見積もりを実施する必要はないと思います。
ただし、内部設計や実装段階で外部仕様まで大幅に変更が必要になったという場合は、再度、見積りを実施する必要があるかもしれません。

で、どのような指標を収集するかということですが・・・
これは、プロジェクト評価に必要な指標を収集するとしかいえないのですが、例えば、以下のような指標を収集することがあります。

n①ソフトウェア開発の生産性指標の設定
開発ＦＰ／投入人月
n②ソフトウェアの品質指標の設定
欠陥数／対象ソフトのＦＰ
③ソフトウェア開発の見積り指標の設定
開発金額／開発ＦＰ（ソフトウェア単価を開発環境毎に設定）
n④維持管理部門の生産性指標の設定
維持管理対象ソフトのＦＰ／維持管理人月
n④運用部門の生産性指標の設定
運用対象ソフトのＦＰ／運用部門人月

（なんですが・・・・）

やはり、プロジェクトが終了すると担当者も一段落というかホッとしてしまって、事後評価にはそれほど真剣に取り組まない傾向にあります。（気持ちはよくわかるのですが・・・）

なので、ＰＭやＰＭＯという立場の人が色んな観点から独自に指標を集めているようです。
といっても、それぞれ仕事で忙しいので、やはり後手後手に回って、何ヶ月も前に終わったプロジェクトの実績を分析しているような状態ではないでしょうか？
そうこうしているうちに、当該プロジェクトの担当者は別のプロジェクトにアサインされ、そちらの業務に忙殺されることから、意味のある分析・評価を実施することができていない、というのが現状かと思います。

べき論でいえば、プロジェクト評価・プロジェクト結果報告が終了して、初めてプロジェクト終了と考えるべきなのでしょうが・・・

現実的な対策としては、

①プロジェクト完了報告のフォーマットを規定する（どのような指標を計測・評価するのかを事前に決めておく）
②指標の計測をできるだけ簡単にできるようにする（指標を自動的に集計できる仕組みを考える）

といったことを行っているようです。

①については、もうすでに実施しているところが多いと思いますが、②についてはなかなか整備されていないと思います。
Excelベースでマクロを組んで実績報告やバグ票（一覧）から情報を集計するというものが多いと思いますが、それでも十分目的は達成できると思います。

また、別の機会（記事）で②については記述していきたいと思っています。