読者です 読者をやめる 読者になる 読者になる

Always All Ways Archive

Archive Imported from Always All Ways on Plala

開発生産性について

システム保守・改訂の生産性について、ちょっと考えてみたことを、まとまりのないまま記述してみる。

まず、「生産性」という言葉をWikipediaで見てみよう。

「生産性(せいさんせい:productivity)とは、経済学で、生産活動に対する生産要素(労働・資本など)の寄与度のこと。あるいは資源から付加価値を生み出す際の効率の程度のこと。

一定の資源からどれだけ多くの付加価値を生み出せるかという測定法と、一定の付加価値をどれだけ少ない資源で生み出せるかという測定法がある。」

乱暴に言い換えれば、「生産性=アウトプット/インプット」。

そして、アウトプットやインプットをどう考えるかで、生産性というものがいろんな形で定義できるわけである。(資本生産性、労働生産性、…。)従って、生産性の議論をするときには、まずそこの認識を合せておかないと、話が噛み合わなくなる。

上のWikipediaの定義にもあるように、アウトプットを「付加価値」と定義すると、システムやソフトウェアの開発生産性は、その開発規模やプログラムコードのSTEP数などではなく、そのシステムやソフトウェアの付加価値で測定することとなる。これは、パッケージ会社が開発するパッケージソフトとか、いわゆるモノに組み込まれる組込ソフトなどではない、いわゆる事業会社がインハウスで使う業務システムの場合には、それが生み出すビジネス上の価値(バリュー)ということになる。

ここで、大きく2つの問題が出てくる。

一つは、このビジネス上の価値(バリュー)というものをどうやって測定すればよいのか?という話。

そしてもう一つは、(いろいろ異論はあるかも知れないが)「システムは、その開発が完了した時点では何らの付加価値も生み出していない」ということ。(なぜならば、業務システムはそれが使われる過程において、付加価値を生み出すものだから♪)

#ついでに言うと、ビジネス上の価値を考えると「時間」という概念も非常に重要で、早くシステムが完成して使い始めることができれば、それだけ早く価値が享受できるわけだし、逆にそれが遅れると機会損失も生まれるわけで…。

う〜ん。深い…。この辺から私の頭の中はループを始める。(w。

で、無理やり整理すると、

●開発生産性を考えるには、あくまでもそれが生み出すビジネス上の価値をアウトプットとして位置づけなければならない。

●インプットは、とりあえずは、労働力(工数)でいいのかな?

●「時間」って大事。

ということか。

つまり、開発生産性を考えるときに、開発規模というのは付加価値とは関係ないので、分子ではなく分母(投入工数として)に来るわけだ!分子はあくまで、事業価値!

ここまできちんと理解して、やっと、保守・改訂の開発生産性を上げる方策が語れることとなる。