Re: 開発プロセスは導入するものじゃない

あきひろ氏がコメントして曰く、

数値化が難しいですよね。何を指標にすればいいんでしょうか。意味無い数字出しても、ろくなことにならないし。

ろくなことにならない数値の例w
・ コード行数 ÷ 実装工程の工数
・ 結合テストでのバグ発見数 ÷ コード行数
※ コード行数を使うと、 コピペしまくりダラダラコードの方が良くなる。 出荷前のバグ発見数を使うと、 テストを手抜きしたほうが良くなる。

役に立つと思う指標の例

・ 生産性 ＝ 完成したソフトウェアの規模(FP) ÷ トータル工数
※ 補助的に 「工程」 ごとの生産性

・ バグ率 ＝ ユーザ受け入れテスト以降のバグ数 ÷ 完成したソフトウェアの規模(FP)
※ バグ数ではなく、 バグの深刻度の集計もいいかもしれない。

・ コード品質: 凝集度、 結合度、 複雑度、 継承数、 メソッド当たりの行数 etc.
※ 安定して、 しかも自動的に計測できる指標を優先したほうが得策だとおもうので、 JIS X 0129-1 (ISO/IEC 9126) の品質モデルとは一致しなくてもしょうがない。

基本は、 完成品に対してのトータルの数値を優先すること、 でしょう。
いわゆる 「工程」 ごとの数値を優先すると、 部分最適の罠に陥ります。 自分の 「工程」 の数字だけを良くしようとしてしまい、 トータルの数字が悪化しようとも気に掛けない、 ということになってしまいます。

ソフトウェアの規模をどう計るか、 ですが。 今は FP ( Function Point ) を見るのが主流だと思います。
FP がベストの指標だとは思わないのですが、 代わるものが無いというのが現状ですね。 オブジェクトポイントだとか幾つか提案されていますが、 FP に代わるまでは広まっていません。
日本のビジネスアプリ開発だけに絞れば、 画面数でもいけるかもしれないです f(^^;

ちなみに、 コード品質の計測値 ( コードメトリックス ) の幾つかは、 Visual Studio Team System でも取得できます。 → MSDN ライブラリ: Visual Studio Team System コード メトリックスの概要