ソフトウェア開発の生産性をステップ数で測るのはやめよう

はじめに

これから話す内容は目新しい話ではないのですが、驚くほど理解されていないことが多いと感じています。特にSierではその傾向が顕著であるように感じます。

一人でも多くの方に気付きを得てもらえれば、と思い書いています。特にマネージャークラスの方に読んでいただきたいと思っています。

エンジニアは何かと生産性向上を求められる

「プロジェクト原価が悪化してしまったが、なんとか予定原価内でプロジェクトを完了させろ」「決算まであと１ヶ月。生産性をあげて利益を捻出しろ」。こういう話をきくたびに、本当にウンザリしてしまいます。

気合と根性で生産性はあがりません。「売上をあげろ」と叫ぶだけでは売上は上がらないですよね。それと同じなんですね。

そもそも生産性の定義が曖昧です。
一般的には、生産性＝生産量÷投入量（時間や金）です。昔から耳にする「エンジニアの生産性」は、

・生産量＝書いたコードの量（step数）
・投入量＝人月

です。

生産性＝○kstp/月 といった感じで表現されます。

でもソフトウェアってstep数だけで測れるものじゃありません。極端な話、ダメなコードを大量生産し、それを「生産性が高い」と言うのか？という事です。

何故、このような考え方が普及してしまっているのか？

かつては、プログラミングが単なる翻訳作業だった（私は実際には知らないのですが）ことが原因の一つのようです。

プログラミングは「システム仕様をコードに翻訳する作業（コーディング）であり、単純な作業」である。誰がコードを書いても同じモノができあがる。書くスピードが早ければ早いほど良い（生産性が高い）。こうい考えだと思います。

プログラミングは設計です

ところがどっこい、プログラミングは明らかに「設計」を含む行為であり、単なる翻訳作業でありません。「１人月あたりのステップ数」で生産性を測るというのは、どうしてもフィットしません。

「設計工程の生産性を測る」ということを考えてみればわかると思います。「１人月あたりの設計書のページ数」で生産性を測るとしたら、それは「なんか変だな」と思うはずです。

（余談ですが）
大真面目に、設計工程の生産性を「設計書のページ数」で測ろうとしていた企業がありました。更に悪いことに、その生産性をエンジニアの評価に結びつけたものですから、エンジニアの中には、設計書のフォントサイズを大きくしたり、画面のキャプチャを多様したりしてページ数を稼いでいる人もいました。やたら文字がでかい設計書が何枚もできあがっていました。

ソフトウェア開発における「製造」とは「ビルド」だと思っています。ですが、一般的にはプログラミングを行う工程を「製造工程」と呼んでいます。これもよろしくないことだと思います。

ちなみに「上流工程」「下流工程」という言い方もあまりいいとは思いません。いかにも「流れ作業」「ライン」という感じです。ソフトウェアって流れ作業でてきるものでしょうか？

生産性の測り方

ステップ数で測る生産性もラインの考え方も、かつてSierが目指したソフトウェアファクトリーの考え方の名残りです。かつては機能した考え方かもしれませんが、現在の情報システム開発にフィットするとは思えません。

計画に役に立つ生産性の見積もり方について、現実的で具体的だな、と思える書籍がありました。是非、こちらを読んでいただきたいと思います。アジャイルであろうがウォーターフォールであろうが役に立つと思います。

どれくらいつくるかではなく何をつくるかに着目する

最後になりますが、私は、これからのIT企業は、どれくらいアウトプットするか（できるか）を考えるのではなく、何をアウトプットするのか、何故それをアウトプットするのかを、もっと考えるべきだと思います。

生産性を高めて量を増やすのではなく、質を高める、ということです。そうでないとIT業界はどんどん沈んでいきます。

（参考）
日本のSierにおけるソフトウェアファクトリーの思想についての記述があります。少し古い本ですが、興味深い内容でした。