システム開発の生産性をどう計るかというのは、古くからある課題である。
システム開発の生産性とは
システム開発の生産性とは、一般に、「システムの付加価値／投入コスト」で示される。ここから、派生して、人月当たりコーディング行数(LOC)といった指標もあるが、 LOCにて生産性を計ることに対しては、多くの異議が唱えられている。 一つは、開発者の能力は千差万別であり、これを一律単価×人月で計るのはかなり無理がある点。次に、成果物の質にも当然ばらつきがあり、LOCは品質の定義や品質を確保するための時間の定義がやや曖昧である点。最後に、一般に同じ機能を実現するのなら行数の少ないソフトウェアの方が保守性が高い点。または、同じ機能で同じような行数だとしても、保守性や汎用性を熟慮して作成したソフトウェアとそうでないソフトウェアがあるという点。 これも品質の一つかもしれないが、バグのないソフトウェアという意味の品質とは異なる視点である。
そうすると、システム開発の生産性とは、LOCではなく、 「広義の品質を考慮したシステムの付加価値／投入コスト」という定義でしかない。 単価の高い人が、効率良く品質の高いものを作る、 あるいは、単価の低い人が時間がかかっても品質の高いものを作る というパターンがあるが、いずれにしても、投入コストあたりの品質を考慮したシステムの付加価値が、生産性の定義である。
上記のような本質的な意味での生産を考えるとき、 生産性、特に、成果物の広い意味での品質の定量化は難しいことがわかる。 また、成果物の品質をもう少し狭義に捕らえ、バグのないソフトウェアとしても、 今度は、システムの要件は、そのシステムごとに千差万別であり、 生産性を横並びに比較できないない、という問題が残る。
デスマーチ!?
悪い例えとして、システム開発は、デスマーチだといわれる。 とにかく前に行進することが要求される死の行軍という例えである。 ここで、先のLOCをはじめとする開発工数の評価が問題となってくる。 システム開発のコストは、人月で評価されるものではなく、 成果物で評価されるべきであり、同じ機能の同じ品質のシステムであれば、 単価の高い人が短期間で作っても、単価の低い人が長期間（納期内であることが大前提）に作っても、同じ評価をされなければならない。
ソフトウェア開発は、人的要素が強いため、生産設備が整い機械化が進んだ工業製品の生産ラインとは異なり、芸術的あるいは職人的側面が強い、といわれることがある。 確かにそういう部分はあると思う。 では、工業製品と比べたときのソフトウェアの相違はなんだろうか？
- パッケージソフト以外は、受注生産であり、標準規格というものがない。
- 要件定義／成果物の定義の中で、使い勝手等、規格化が難しい要素が含まれる。
- 流通部品が限られている。
- 言語や方法論、つまり生産のための手法のライフサイクルが短い
-
デスマーチからの脱却
これは、さながら、かなり手の込んだ、特殊な部品を使う注文住宅 といったところだろう。 しかも、その建築手法や部材は、時流により変わる。 だから、規格化も標準化も難しいし、生産性も品質も職人のスキル次第 といっていては、永遠にデスマーチが続くことになりかねない。
古くからソフトウェア開発の生産性を向上するための様々な方策が考えられてきた。 例えば、要件定義からプログラムソースのテンプレートやテストプログラムを自動生成する開発ツール。ＧＵＩによる画面設計と画面をコントロールするプログラムソースのテンプレートを自動生成する開発ツール。 共同開発を支援するソースコード管理ツール。 ビジネスオブジェクトや、J2EEなどの部品。 あるいは、データ中心設計、オブジェクト指向設計、ＳＬＣＰなどの設計・開発方法論や開発標準などである。 既に、開発ツールや、開発方法論や、ソフトウェア部品には、その兆候はみられるが、 この状況を解決するひとつの方策は、できるだけ、完成された部品を流通させることではないかと思う。 もう一つは、ＩＴスキルスタンダードなどで行われているように、生産者のスキルを計り、一定以上のレベルに保つ努力をつづけることである。
本文中のリンク・関連リンク：