祈祷連歌

「My Definition of 生産性(2)」（OO百韻）

◇ ◀ ▲ ▶

前回のMy Definition of 生産性(1)では、生産性に影響を与えると考えられるパラメーターとして、 ゲイン()、経過時間()、人材数()の三つの変数と、 方法論の選択の仕方によって生産性にインパクトを 与える係数()を一つ考えた。 とりあえず第一歩として作り出した生産性()の定義式は次のようであった。

今後、この式をたたき台としてさらなる改良を加えていきたいわけだが、 その前にこの式を吟味することから始めたい。

ゲインの具体例

まず、ゲイン()であるが、そのままではかなり抽象的な要素である。 しかしこの抽象化は意図したことであり、 一言で生産性といってもかなり意味が広いため、 あえて具体性のないものを定義に使用したのである。 それでは、具体的にはどんなものをゲインに当てはめることができるだろうか。

売上や利益

売上と利益とでは意味が違うが、どちらも商売上得た金額に関係する点で同じである。これらに関してゲインがどのように定義されるか表にしてみた。

売上／費用	投入した費用に対する売上
売上－費用	最終的に得た利益
(売上－固定費用)／可変費用	上記二つを合わせたもの

製造業や経済学などでは一般に生産量や設備投資、原価計算などから計算する産出量／投入量を生産性としているようである。対投資効果とでもいうことなのだろうか。また、売上－費用、つまり利益のことでありあまり一般的ではないが、これでもってゲインとする考え方もある。これは設備投資や固定費など生産量に比例しない値を単純に投入量に含めて考えてしまうと、それで計算される生産性が感覚に一致しなくなってくるという欠点を補うため、単純に比率で考えることができないものはまずは引いてしまえという考えからくる。

機能

ソフトウェア開発においては最終成果物の機能(の数)をベースにして生産性を考えることが非常に多いようである。 しかし、しっかりと原価計算をしたうえで生産性を割だす製造業と、仕入れの概念が全く異なるサービス業としてのソフトウェア開発とでは当然ながら同じ指標を全く同じように使えるわけがない。 機能の数と金額はあまり関係ないことの方が多くためか、この違いからくるすれ違いが「ソフト開発における生産性の議論」において多くの混乱を招きよせているように見受けられる。

品質

ソフトウェア開発において、はっきりと明言しているわけではないが、要約すると品質の向上でもって生産性の向上とするケースが最近増えているように見受けられる。

前提として要求や仕様の機能を全て実現するのは当然であるとする立場をとると仮定する。その仮定において、投入する人員や時間によってそれ以上の生産性を上げるのには限界があるような場合、開発現場においてそこで比較されるものがあるとすればその筆頭には品質が挙げられる。機能は同様、納期も同様、そして開発メンバーも同様であるなら、それらは成果物のでき、つまり品質で比べられるというのはおかしな話ではない。 また、経営の観点からみても限られた資源でよりよい品質を求めるというのは競走力の確保のためにはごく当たりまえの話でもある。しかし、品質についても直接的には金額の多少に関係していないことはままあり、単純に金額ベースで考える生産量とてんびんにかけてしまうと混乱のもととなる。

品質を生産性とみなす場合には、前述の機能の数に着目するのとは対称的に、成果物の質やその機能がどれだけ高度なレベルであるかということを指して品質としている。 しかし、量を表すものと質を表すものを、それらの関連性に関する議論抜きでそのままで同じ土俵に乗せて議論することは危険である。

システムの規模

いまだLOC、ステップ数、もしくはそれらバリエーションによるシステムの比較は健在である。 OSや何かの業務システムでも、新しいバージョンが発表されると、そのニュース記事中に何百万行のコードであったかという話が載り、だれもがその数値を聞き流す。 本気で生産性の判定にLOCをを使う人間はいないはずだと皆が信じながら、 それでも記事にはなり、その数値でシステムの規模を想像する。 また、組み込み機器の開発などではもっと積極的にコードのステップ数が議論され、その結論が仕様になる。

よって、甚だ不本意ながらもLOCなどの統計情報をシステムの規模を比較する要素として認めなければならず、また生産性の議論から外すこともできない。 しかし、LOCなどからさらに踏み込んでメトリックスを考えた場合、 統計量と品質を結びつける橋渡しとして重要な役割を演じる可能性もあり、 なんらかの利用ができるかもしれない。

障害

システムの保守で生じた障害のうち回復したものをベースに考えると保守の生産性ということになる。 MTTRの合計に対して、復旧した障害の数が多くなるほど、「保守の生産性」が上がったのだと考えることは可能だろう。 また、障害発生当たりの時間間隔であるMTBFは、その値が小さければ頻繁に障害を起こしていることになり、つまりそのシステムの品質は低いことを表していると考えられなくもない。 このことから、MTBFも何らかの形でシステムの品質に関係しており、よって生産性とも関係がある。 この様に考えれば、障害の回数やその回復などは保守における生産性と密接に関係していると言える。

定数

ゲインについては考慮せず敢えて定数として扱ったり、時間や人数を機能当たりに換算して考え、単純に経過時間や人員数のみで比較するという意見もあるようである。 これは、実態としてソフトウェア開発における生産性というものが非常に漠然としており客観的な経営判断に利用するには無理がある場合が多いということが背景にあるのだと思われる。 ゲインがなにであるかはっきりしていなかったり、感覚に合わないケースが多いならば、そのような場合にはいっそのこと時間と人数だけで判断してしまったほうが合理的である。 また、このような場合には、生産性の定義式の方法論係数が重要な意味をもってくるものと思われる。

ゲインの例のまとめ

ソフトウェア開発を基点に考え、すぐに思いつくゲインの具体例はだいたいこれぐらいであろうか。 だいたいにおいて、ゲインには量的なものと質的なものの二つの要素が複雑に絡みあっていそうだということが窺える。 よってこの二つの側面の間の相互関連性、 言い換えれば全単射を見い出すことができれば、 ゲインがなにであるかということに関してかなりすっきりしたものが 得られるのではないだろうかと期待したい。 他に、開発が始まる以前から序盤にかけては量的な面が注目され、 中盤から終盤で質的な面、そして終盤以降は両方が重視されるのでは ないかと考えているが、現時点でははっきりとした根拠があるわけではない。

以上、ゲインの具体例について少し掘り下げてみた。 次回以降(続きがあれば)、ゲインの量的な側面と質的な側面の数学的なモデリングや、他の要素の具体例などについて扱ってみたい。