あれから見積方法について色々考えてみて試験項目数見積もりというのを思いついた。話は簡単で試験 1項目あたりの単価を決めておいて，単純に全試験項目数を掛け算したものをシステム構築費用とするのだ。
これはシステムの価値はソースコードの量ではなく提供している機能の量によって測られるべき，という考え方を基本にしている。じゃあ機能の量はどうやって測るの？これは開発工程における試験項目数とほぼリンクするだろうから，試験項目数をもって機能量とすればいい(ここまで書いて，あれもしかしてこれって FP法と同じ？とか思ったけど FP法を良く知らないのでとりあえず先に進む)。
普通，多機能，高機能なシステムは少機能，低機能なシステムに比べて試験項目数は多くなると考えていいよね。機能が多くなり，複雑になれば試験パターンが増えるのは明らかだと思うからだ。つまり前者のほうが構築費用が高くなる訳だが，これはより多機能，高機能な前者のほうが顧客にとっての価値が高いであろう，という感覚ともあっていると思う。またここで言う試験項目数には単体テストは含まない。なぜなら関数やメソッド云々の話は内部実装の話であって，そんなの顧客にとっては何の意味もなさないから。だって顧客にとっては機能の提供が重要であって，極論すれば動きさえすれば中はどうだっていいということでしょ。
これは開発側にとってはけっこうメリットがあると思う。まず機能追加が発生したとき費用の追加要求がしやすくなる。機能追加で試験項目が増えるからその分費用がかかります，というのはわかりやすい話だ。
次に頑張れば頑張るほど利益が増えることになる。ものを作る場合，一般的にはより少ない人数，より短期間で作ったところがより大きな利益を手にすることができる。ところがソフトウェア産業だけが例外でこれまではより多くの人数，より長期間で作ったほうが利益が大きかった。つまり仕事を早く仕上げるほど利益が低くなるということ。人月換算の弊害を語るときに必ず出てくる話だ。試験項目数見積にしてしまえばこれも解消される。
顧客にとってのメリットはぼったくられる可能性が低くなるということかな。これまではちょっと既存機能変更するだけなのに，プログラムの作りが悪いせいで必要以上の修正費用を取られたところもあるかもしれないけど，それもなくなる。
デメリットは何かあるかな。今のところ思いつかないな。いいことずくめの見積方法だと思うのだけどだめかな。