ソフトウェアの生産性について

山本康彦＠BluewaterSoft @biac

結局、(工程ごとの見積額に基づくearnd value)÷(工程ごとの実績工数)として算出される工程別の「生産性」と称する数字は、見積りと実績の比を見ているだけだ。見積りに正当性(たとえば、全国平均を使った見積り等)が無い限りは、他の何とも比較することはできない。

山本康彦＠BluewaterSoft @biac

さて、ソフトウェア開発の生産性は、全体で見るしかないわけで。良くなるだろうと思われることをtryしてみて、それが全体の生産性にどういう影響を及ぼしたかを見るPDCサイクルを地道に続けるしかない、という結論になる。

山本康彦＠BluewaterSoft @biac

もうひとつ、ソフトウェア開発の生産性には困った話がある。それは、出荷額が安定しない、ということ。生産性＝出荷額÷投入工数という、製造業でよく言われる生産性定義を使うと、出荷額、つまりプロジェクトごとの売上額は営業によって大幅に変動するから、開発の真の生産性が同じでも、変動する。

山本康彦＠BluewaterSoft @biac

したがって、開発部門だけの生産性を見るには、生産性＝生産量÷投入工数という数字を使わねばならない。とは言うものの、ソフトウェアの生産量(サイズ、大きさ)ってナニ、どうやって測るの、という問題に当たる。米国では、ソフトウェアのサイズとしてFPを使うことが多いらしい。

山本康彦＠BluewaterSoft @biac

生産性＝出荷額÷投入費用 という値だけが問題だという経営者が居たりするけど、しかしその数字だけでは、儲からない原因が他社より安売りしてるからなのか開発部隊の生産性が低いからなのか、判別することはできない。

山本康彦＠BluewaterSoft @biac

生産性＝サイズ(FP)÷投入工数 を見るならば、日本でも統計データが揃いつつある(例: http://t.co/JJlTnZAh )から、開発部隊の生産性の優劣を判断できる。

山本康彦＠BluewaterSoft @biac

…で、最後の難関。FPを算出する工数が出ないw

山本康彦＠BluewaterSoft @biac

製造業の量産ラインだと、「不良は後工程に流すな!」ってのが相当に徹底してる。精神論じゃなくて、実際にそうするための仕組み・仕掛けをラインに作り込んでる。

山本康彦＠BluewaterSoft @biac

ソフトウェア開発で、工程ごとに「生産性」を上げろ、と号令を掛けるとどうなるか? 手っ取り早いのは、手を抜いて自工程の工数を減らして、次工程以降に押し付けること。「不良は後工程に流したもん勝ち!」になる。なんせ、不良を次工程に流さないようにする仕掛けが無いからね。

山本康彦＠BluewaterSoft @biac

ほんとは、ドキュメントのレビュー、コードのレビューや机上デバッグなどが、不良を次工程に流さないための防波堤だったんだけど。形骸化してしまったか、省略してしまったか、ともあれ機能していないところがほとんどだろう。レビューできる人材も育ててこなかったし。

山本康彦＠BluewaterSoft @biac

ところで。生産性の議論は、商売として競わねばならない以上は避けて通れないものなのだけれど。品質については「出荷できること」以上の話が入ってこないのが、すごく嫌。納品できさえすればOKみたいなのは、勘弁してほしい。(で、そう言うところほど、儲かってないような気がするw)

山本康彦＠BluewaterSoft @biac

あ、それと。ソフトウェアのサイズをFPで測るというのにも、実はかなり懐疑的だったりする。それより良いと思える測り方を知らないだけです。