ソフトウェア開発で見積もりのための定量化はできないんじゃない？

素人がそう思ったよ。間違っていると思うよ？入門しようと片足つっこんでいるときの独り言だよ？的な。でも、こう思っているよ？的な。

メトリクスとかをふくむ定量的なデータは傾向を測るものであって、特定チームの特定期間にしか使えないというもとに活用出来ると思った。

根底にあるのは「僕は1年前と同じようなコードは今では書かない。」のような「以前よりもっと綺麗な設計/実装ができる」というのがあります。
だから、例えば行数でも相対値でも違うものになる。

行数：コードの行数。コピペがないコードだとしても設計方針でまるで違ってくる。
ストーリーポイント：実現するための相対的なコスト見積もり。

他にもいろいろあると思うんですけど、きっとどれもが他人(成長する前の自分含む)と比較しにくいものだと思うのです。常に変化していく。
例としては(経験による感覚)、5,6人以下固定チームで2ヶ月目から9ヶ月以内くらいのチームでのみある程度の一定値を使えるんじゃないかなぁと思っています。
9ヶ月過ぎたらさすがに基準を見直さないとやばい気がしています。
（アジャイルではそもそも基準のベロシティが流動的かもしれないけれど。

「長期間使い続けられる一定値の定量化できています！」っていうチームは次の2パターンくらいはありそうだと思っています。
「(技術革新や個人のスキル上達が激しい世界なのに、メンバーや組織が成長を諦めたり、阻害しているので)長期間定量化できてしまう」
「長期間定量化できるプロジェクトしかやっていない(例として規模が小さいとか)」

個人的には「6ヶ月くらいで技術的にしろプロセス的にしろ変化がない」のはよくないかなーって思うし、それが起きているなら「そこまでずっと使えるような定量化っていうのは難しいでしょう」
っていう感じです。

ビジネス価値をいくら生み出したかというのは出来ると思うし、チームの評価には使えても、見積もりには使えないんじゃないかなぁと。
届けられなかったコストにどんなことがあったとか、どういったパスでその価値を届けたとかいろいろ難しいですしね。

個人的には、見積もりのための定量化を頑張るよりは、「いかに早く届けられるか」と「いかに今やっている事が正しいか」を洗練させるほうがいいかなぁとか。
そのために定量化が必要になるのが政治的な要因以外で、定量化がベストなら選択せざるを得ないかもしれませんが。