ユーザー企業ソフトウェアメトリックス調査2007

先日、「最適な工期は「投入人月の立方根の2.4倍」、JUASが調査」が話題となったが、その元ネタである「ユーザー企業ソフトウェアメトリックス調査2007」が届いたので読んでみた。

傾向がわかってなかなかに面白い。

主開発言語

以前、COBOLが死んだのか否かが論争になったが、この文献を見る限りプロジェクト主言語としての採用率は14.3%でありなかなか検討している。古くからある大企業でホストを使い続けているところは多数あるので、妥当な結果だとは思う。ちなみにJavaは34.2%とのこと(なぜかJSPが別項目になっているので実際の割合は微妙に増えるかも)。ちなみに、rubyは一件もなし。おそらくアンケート結果に含まれているのはほとんどが基幹系システムなので当然の結果なので、これは仕方ない(PHPも入ってないのがそれを物語っている。とはいえ、Perlは結構検討してるんだよなぁ)。

データベース

ORACLEが57.6%で断トツの一位。ライバルと目されるSQL Serverと両方使ってみた個人的な感想としては納得というか。標準から外れているし、運用が大変なので決して好きではないんだけど、あの基幹システム開発にぴったりフィットする機能の数々や、どうにかすればどうにかなってしまうあの懐の深さは他の追随を許さない感じ。

開発ライフサイクルモデル

ウォーターフォールが88.3%という一見驚愕だが、中の人としては当然というか……
基幹系システムの開発はアジャイルその他の社会の仕組みに合わない方法じゃ無理です。はい。
逆に小さいプロジェクトは繰り返すほどのプロセスがないからなぁ〜。

開発方法論

構造化分析設計、オブジェクト指向設計、データ中心アプローチがそれぞれ30%前後で三つ巴の戦いを繰り広げている感じ。微妙な結果だ。

実のところ基幹システム開発って、こういう分析手法外で繰り広げられるAS-ISの業務調査をどれだけしっかりできてるかにかかっている気がするので、実は開発方法論ってほとんど関係ないんじゃないの? とか思ってしまったりするのだが。

PMスキルと欠陥率

ベンダー側のPMスキルは欠陥率に大きな影響を与えるのに対し、ユーザ側PMのスキルはまったく関係ないようだ。言われてみればそりゃそうだという気もするが。

レビュー比率と欠陥率

意外なことにそれらしい相関がでない。

とはいえ、範囲を区切って見てみると、レビュー比率が5%を切ると欠陥率が上がりやすくなる程度の傾向が出てくるようだ。面白いのが反復型開発PJの異常なレビュー比率の高さとそれにまったく見合わない欠陥率である。

理由を考えてみるに、結局レビューでわかるのはいわゆる瑕疵(表記の間違いや伝達ミスなどによる要件漏れ)程度で、プロジェクトに致命的な影響を与えるような問題、すなわち、そもそも要件自体が出てきていないとか間違ってるとかそういうことに対しては、レビュー程度ではどうにもならないということなのかもしれない。

人月単価と品質

明確なデータがでないどころか、品質の良かったプロジェクトの単価が一番よかったりしたそうです。優秀な技術者より十分な人数の方が重要ということなのかなぁ。うーむ、経験的な感覚に反するのだが……。それとも、技術者の能力と人月単価が対応していないということなのか?

適正工期からの乖離と顧客満足度

あまり関係ないようだ。となると、早い安い旨いのうち、早いはあんまり意味がないということか。

テスト工期と顧客満足度

開発規模に対し長すぎると顧客満足度は下がるようです。ほどほどが一番ということね。

工数とファイル・画面・帳票・バッチ数の関係

これは、前述の記事でも書かれていたが「総開発工数(人月)=1.28×画面数+0.10×ファイル数+0.29×バッチ数」とのこと。帳票がないのは、画面と帳票の間の相関が高いことによるそうだ。なるほど。

とはいえ、見積りには帳票を加えた「総開発工数(人月)=0.9×画面数+1.57×帳票数+0.10×ファイル数+0.26×バッチ数」の方が使いやすいような。なお、工数と最も相関が高いのは画面だそうで、画面だけを基準にすると「総開発工数(人月)=1.55×画面数」となる。

昨年度の調査結果を合わせても概ね同じ結果が得られていることから、安定した数字のようだ。

問題は総開発工数の定義が書かれていないことだが……(別の場所にプロジェクト全体工数という名称があるのでおそらく設計+開発+テストの工数のことなのか?)

疲れたので今日はこれくらいにしておこう。