本日は、私が元々、生産技術畑の人間なので、業務系ソフトウェア開発の生産性についての話をしたいと思います。

＜アウトライン＞

1. 生産性に関する前提情報
2. 生産性は、どの程度、向上し得るか？
3. 大きな生産性低下の要因は何か？

---

＜1. 生産性に関する前提情報＞

　「業務系ソフトウェア開発の一般的なWBS（Work Breakdown Structure）」における「ウォーターフォール・モデルでの工程別工数比率」は、一般的に、「設計：開発：テスト＝３：４：３」などと言われています。

　これを、もう少し細かく分けると、


　などと言う感じになり、生産性は、「X KS/人月や、Y FP/人月」などと定義されます（KS：㌔ステップ、FP：ファンクション・ポイント）。これが、先ず生産性を考える上での前提情報となります。

＜2. 生産性は、どの程度、向上し得るか？＞

　よく「コーディング・レスの開発ツールで生産性が上がる。」という話がありますが、この手のツールも、デザイナ・ツールなどを用いて定義自体は作るので、



　全体１０割のうちの、プログラミング・単体テスト工程の４割の工数がどれだけ圧縮されるか？という話になり、「仮に」ココの生産性が倍になったとしても、工数は、全体の２割程度しか削減されないことになります。

　「IDE＋テンプレート＋パッケージ方式」を採用した某弊プロダクトでも、



　下記ページに書いたぐらいの謳いはしていますが（削減工数の算出式を参照）、

＜参考１＞

　実際は、１～２割程度の削減工数を稼いだとしても、慢性的に激務なシステム開発プロジェクトのバッファに埋もれていく気がしますし（これを「パーキンソンの法則」と言うらしい）、一括外注側の生産性が上がっているケースではこれを観測できないこともあります。なので、残念なことに、これが見積時の「X KS/人月や、Y FP/人月」と言った数字に直接的に跳ねてくることは感覚的に殆ど無いと思っています。

　しかし、代わりに


　するケースは実際に観測できています。これは、更なる研鑽によって、更に伸び得ると思いますので、引き続き、某弊プロジェクトに、ご期待頂きたいと考えています。

＜参考２＞

＜3. 大きな生産性低下の要因は何か？＞

　反対に、１つ１つの生産性向上を帳消しにしてしまいかねない、大きな生産性低下（所謂、大赤字・デスマ プロジェクトの発生）の要因は何でしょうか？これには、ズバリ、以下の２つがあると思います。

1. 上流から要求仕様が出てこないなど要件・仕様取り纏め能力の問題。
2. 最新技術の導入や高度な性能要求に対しエンジニアリング観点で失敗。

　これらの要因は、上記の地道な生産性向上施策にあまり関係なく、プロジェクト・マネジメントにおけるリスク・コントロールに失敗していると言う事かと思います。殆どのケースは、「１」で、暫く「２」が目立たない時期が続いていましたが、昨今、また技術の多様化によって、このケースも目立ってきたように思います。

　また、これらのリスクが発生した場合、「1.」については、基本設計以降の全ソフトウェア開発工程を遅延させる影響があります。「2.」については、膨大な工数を掛けて対策するか、最悪、作り直し等の話になります。

　ここで、「IDE＋テンプレート＋パッケージ方式」があれば、動員した応援の開発要員の立ち上がりを容易にできるため、「1.」のリカバリに対してサポートは可能です。また、「2.」の問題もテンプレートの品質次第で抑止できますが、最新技術と言う事で、テンプレートの開発・導入が間に合っていないケースも増えてきています。