はじめに
これから話す内容は目新しい話ではないのですが、驚くほど理解されていないことが多いと感じています。特にSierではその傾向が顕著であるように感じます。
一人でも多くの方に気付きを得てもらえれば、と思い書いています。特にマネージャークラスの方に読んでいただきたいと思っています。
エンジニアは何かと生産性向上を求められる
「プロジェクト原価が悪化してしまったが、なんとか予定原価内でプロジェクトを完了させろ」「決算まであと１ヶ月。生産性をあげて利益を捻出しろ」。こういう話をきくたびに、本当にウンザリしてしまいます。
気合と根性で生産性はあがりません。「売上をあげろ」と叫ぶだけでは売上は上がらないですよね。それと同じなんですね。
そもそも生産性の定義が曖昧です。
一般的には、生産性＝生産量÷投入量（時間や金）です。昔から耳にする「エンジニアの生産性」は、
・生産量＝書いたコードの量（step数）
・投入量＝人月
です。
生産性＝○kstp/月 といった感じで表現されます。
でもソフトウェアってstep数だけで測れるものじゃありません。極端な話、ダメなコードを大量生産し、それを「生産性が高い」と言うのか？という事です。
何故、このような考え方が普及してしまっているのか？
かつては、プログラミングが単なる翻訳作業だった（私は実際には知らないのですが）ことが原因の一つのようです。
プログラミングは「システム仕様をコードに翻訳する作業（コーディング）であり、単純な作業」である。誰がコードを書いても同じモノができあがる。書くスピードが早ければ早いほど良い（生産性が高い）。こうい考えだと思います。
プログラミングは設計です
ところがどっこい、プログラミングは明らかに「設計」を含む行為であり、単なる翻訳作業でありません。「１人月あたりのステップ数」で生産性を測るというのは、どうしてもフィットしません。
「設計工程の生産性を測る」ということを考えてみればわかると思います。「１人月あたりの設計書のページ数」で生産性を測るとしたら、それは「なんか変だな」と思うはずです。
（余談ですが）
大真面目に、設計工程の生産性を「設計書のページ数」で測ろうとしていた企業がありました。更に悪いことに、その生産性をエンジニアの評価に結びつけたものですから、エンジニアの中には、設計書のフォントサイズを大きくしたり、画面のキャプチャを多様したりしてページ数を稼いでいる人もいました。やたら文字がでかい設計書が何枚もできあがっていました。
ソフトウェア開発における「製造」とは「ビルド」だと思っています。ですが、一般的にはプログラミングを行う工程を「製造工程」と呼んでいます。これもよろしくないことだと思います。
ちなみに「上流工程」「下流工程」という言い方もあまりいいとは思いません。いかにも「流れ作業」「ライン」という感じです。ソフトウェアって流れ作業でてきるものでしょうか？
生産性の測り方
ステップ数で測る生産性もラインの考え方も、かつてSierが目指したソフトウェアファクトリーの考え方の名残りです。かつては機能した考え方かもしれませんが、現在の情報システム開発にフィットするとは思えません。
計画に役に立つ生産性の見積もり方について、現実的で具体的だな、と思える書籍がありました。是非、こちらを読んでいただきたいと思います。アジャイルであろうがウォーターフォールであろうが役に立つと思います。
どれくらいつくるかではなく何をつくるかに着目する
最後になりますが、私は、これからのIT企業は、どれくらいアウトプットするか（できるか）を考えるのではなく、何をアウトプットするのか、何故それをアウトプットするのかを、もっと考えるべきだと思います。
生産性を高めて量を増やすのではなく、質を高める、ということです。そうでないとIT業界はどんどん沈んでいきます。
（参考）
日本のSierにおけるソフトウェアファクトリーの思想についての記述があります。少し古い本ですが、興味深い内容でした。