ソフトウェア開発生産性についてのあれやこれや

最近、ソフトウェア開発生産性についてあれやこれや考えている。IBMがOS360を作った40数年前から活発に議論されていて、ソフトウェア工学という学問分野があるけど、物理学や化学や電気工学あるいは数学のような分野と違って多くの人が認める公理系のようなものは存在しない。コンピュータサイエンスの大学の先生は、物理の大御所の先生に、「ところで、きみ、コンピュータサイエンスというのはどこがサイエンスなんだね」とか言われちゃうそうで、そーだよなーとは思ったりもする。

サイエンスではないとしてもエンジニアリングとして、再現可能な原理原則を発見したいと思うのだけれどもなかなかそれも遅々として進まない。20数年前に大学を卒業してこの業界にはいり、それなりに、ソフトウェア工学のいろはも学んだし、ソフトウェア品質保証のなにがしかについても現場で経験を積んできたりもした。会社や業界のベストプラクティスや成功のパターンあるいは失敗のパターンを見聞きしつつ少しでも自分の出来る範囲を広げていく努力も微力ながら行ってきたつもりだ。

そこで、ソフトウェア開発生産性について、原点に立ち返って考えてみた。

　　　　　出力
生産性＝−−−−−−
　　　　　入力

生産性の定義は上記のとおりだ。経営者にとっての興味は投資に対する利益だから、

　　　　　利益
生産性＝−−−−−−
　　　　　投資

になる。ソフトウェア開発を個人が趣味で行うのではなく企業が行う場合は、どれだけ利益をあげたかがその評価尺度になる。ただこれだと、ソフトウェア開発の指標としては、ちょっと使いにくいので、いろいろ分解していく。
ソフトウェアは機械が自動的に作ってくれるものではなく、ヒトがコンピュータやネットワークなどの設備を利用しながら作る。最近ではコンピュータもネットワークも非常に安くなってきているが、投資の部分は人件費、設備費そのたもろもろとなる。それを費用と呼ぶことにする。利益の部分は（売上ー費用）。

　　　　　売上ー費用
生産性＝−−−−−−−−−−
　　　　　費用

右辺を整理して下記になる。

　　　　　売上
生産性＝−−−−−　- 1
　　　　　費用

生産性がマイナスだと、企業の活動としてやっている価値がないのでここでは、生産性の定義を売上を費用で割ったものと考える。

　　　　　売上
生産性＝−−−−−
　　　　　費用

　　　　　売上　　生産物
生産性＝−−−−−−＊−−−−−
　　　　　生産物　費用

ソフトウェアの場合、ある機能を実装する生産物はソースコードなどになる。費用はこの場合、人件費が大半を占めるので、仮に工数などで近似する。

　　　　　売上　　機能数　生産物
生産性＝−−−−−−＊−−−−−＊−−−−−
　　　　　機能数　生産物　工数
　　　　　（１）　（２）　（３）

ソフトウェアが持つべき各種の品質要件、保守性、拡張性、性能などなどは機能数に反映出来ないが、単純化のために、機能数で近似している。

この式は、
（１）ある価値（売上）を上げるために、ある機能を提供する
（２）ある機能を実装するために、なんらかの生産物（ソースコード）を作る
（３）生産物を作るために工数を投入する
という活動を表現していることになる。

ソースコードもCのような低レベルな言語で書く場合と、RubyやPerlでちゃちゃちゃと書く場合では生産される量が違うし、プログラマによっても雲泥の差がある。ソフトウェアメトリックスと言う分野に批判があるのはソースコードの分量を測定したところで何がわかるのか、何もわからないのではないだろうかという指摘だと思う。

（２）＊（３）は下記のようになり、生産物（ソースコードの種類とか）の差を考慮しなくて、単純に実装した機能数の差で評価できるようになる。

機能数　生産物　機能数
−−−−−＊−−−−−=−−−−−
生産物　工数　　工数
（２）　（３）

生産性の評価の問題は機能数をどう測定するかということになる。ソフトウェアの価値は、機能以外にも先にあげた各種の非機能要件あるいは、言葉にできない質（無名の質 - QWAN: Quality Without A Name）もあり、その評価もすっぽり抜け落ちている。

計測できないものは管理できないという考え方があるが、下記のように因数分解し、（１）をソフトウェア開発の価値生産性と呼び、（４）をソフトウェア開発の機能生産性と呼ぶことにしたらどうか。

　　　　　売上　　機能数　生産物
生産性＝−−−−−−＊−−−−−＊−−−−−
　　　　　機能数　生産物　工数
　　　　　（１）　（２）　（３）

　　　　　売上　　機能数
生産性＝−−−−−−＊−−−−−
　　　　　機能数　工数
　　　　　（１）　（４）

従来のソフトウェア開発生産性の議論は主に機能生産性の向上を目指していた。単位工数あたり実現できる機能数をどう増やすか、あるいは、単位機能を実現する工数をどれだけ減らすか。

企業活動の観点から言えば、それ以上に（１）が重要で、そのサービスとかソフトウェアでどれだけ価値を提供できるか、そして売上を上げられるかにかかっている。品質機能要件をどう向上させるか、顧客満足度をどう最大化するかという活動にほかならない。売上を上げるためにあれやこれや機能を追加することは生産性を上げることにはならなくて、むしろ無駄な機能は作らないという方向で生産性をあげるという戦略が見えてくる。

企業が提供する価値はもちろん売上だけではないが、計測が容易なので近似値として使う。

Martin Fowlerさんは「生産性の計測不能」と言ってるが、機能数というのは計測が可能だし、売上、費用についても、精度の差はあったっとしても計測できると思う。
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CannotMeasureProductivity

「測定できないものは制御できない」は誤りだった。-- by Tom Demarco/Agile Way, 平鍋　健児さんのブログ
http://blogs.itmedia.co.jp/hiranabe/2009/07/---by-tom-demar.html

ちょっと衝撃的な記事だが、実際には、「ソフトウェア工学は誤りだった」、というよりも、「ポイントを外しつつある」というのが正しい。ソフトウェア開発にもっとも大切なのは、そこには無かったのだ。現実のソフトウェア開発は、「計測と制御」で語れる部分の「外側」に徐々にフォーカスを移動しつつある。

計測できないところに価値の源泉が移りつつあるとしたら、それはそれで、そーなんだろうなあと思ったりもする。

とは言うものの、皆が同じ物差し、言葉の定義を使えば、情報共有がしやすくなるし、いろいろなベストプラクティスが流通しやすくなると思うので、私見を述べさせて頂いた。コメント、ご意見ご質問を頂ければ幸いである。