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

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

はじめに

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

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

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

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

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

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

・生産量=書いたコードの量(step数)
・投入量=人月

です。

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

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

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

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

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

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

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

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

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

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

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

生産性の測り方

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

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

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

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

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

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

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

カテゴリーIT