仕事のねた

ずーっと前に 「なんで皆ステップ数で規模とか品質はかるんだ！そんなのシステムによって変わるから今の時代はFPで計測してくれー！」 と書いたら２０１０年に経済調査会なるところが使えそうなネタを公開していました。 経済調査会　経済調査研究所 研究レポート｢ソフトウェア開発データリポジトリの分析｣(2010年7月） ここに上がっている中でビットがたったのが８章「FP生産性に関する分析」です。 この中では、工期とFP生産性の関係、ウォーターフォールと繰り返し型開発のFP生産性などが公開されてたりします。 なかでも興味深かったのは８章最後の「最大開発要員規模比とFP生産性」です。 最大開発要員規模比＝最大開発要員数／実績FP規模 で算出するため、最大５人で５００FPのシステムを開発すると０．０１となります。 この資料ではいくつかの分析でFP規模を１０００未満と１０００以上で分類しているものがあり、最大開発要員規模比の場合も分類されています。 先ほどの５００FPの例を考えると、最大開発要員規模比は０．０１未満、あるいは０．０１〜０．１５未満だとFP生産性はそれ以上に比べて１．５倍以上良くなるようです。  （なお、７人で５００FPだと０．０１４。） 普通のプロジェクトでは、人員は最初少なく、途中で最大になって、最後は少なくなると思うので、３→５→３とか、４→７→４てな感じで５００FPのシステムを作りきれたら「普通にこなせた」と言えるという事でしょう。 ただ、注意しなければらないのは工期の関係でどうしても最大開発要員数が高くなる場合もあると思います。また、このデータ自体「火を吹いて人員を大量投入されたプロジェクト」も入っているのではと思います。 従って、あくまで「どっちのほうが生産性が良いか」という傾向をつかむ為に使えるとは思いますが、実際の「どれくらいの生産性なのか」「何倍の生産性なのか」という値は参考程度にとどめて実際の見積もりに使うのは避けた方が良いのではないか、と思ったのでした。

FP、UCPを使ってみたところ最近テスト密度についての報告を求められた。 そこで、ふと思ったのはこれ。「なんでSTEPなんだ？」 そもそもSTEPなどという単位は会社に入るまで使わなかったし聞いたこともなかった。聞いても「そんなのコーディングする人のセンスでいくらでも変わるじゃん…」と思い、特にJavaについては使いどころはないだろうと思っていた。 しかしながら、いまだにどのプロジェクトも品質指標、とくにテスト密度とバグ密度に対しては「xxxテストケース/KSTEP（キロSTEP）」とか「バグxxx件/KSTEP」などという目標をあげている様子。 STEPを規模のつもりで使っているのであれば、まったく時代遅れだと思う（言葉が悪いが）。 Javaについて言えば、コーディングする人のセンスもあるが、StrutsやHibernateを使うことによってコード量は大幅に減り、そのかわり設定ファイル（xmlなど）が増える。Servlet/JSP＋JDBCで作ったものと、Struts＋hibernateのSTEPは相当違うはずだが、実施すべきテストの量は変わらないはず。（単体テストを除いて） また、まったく腑に落ちない点として、昨今はFPで見積もる機会が多い（少なくともSTEPで見積もったことがない）が、開発規模をFPで出すのに品質指標をSTEP基準にする意味がわからない。しいて言えば「後から測りやすい」ということぐらいだろうか。 あるべき論としては見積もりで使った規模を使って品質指標の基準を考えるべきではなかろうか。FPで見積もりしたらFPで品質指標を考える。 そうしないと見積もり時点で品質指標を考慮に入れたテストスケジュールが立てられるわけがない。 逆に、見積もり時点でそうした指標も考慮したスケジュールを作れれば説得力もまずはず。 それが「後から測りやすい」ということが主な理由で実行されていないのであれば、なんともったいない。 各種I/Fの設計書があればFPなんて簡単に出せるのに…。 今後、IT業界に入ってくる人は変わらず「STEP」を知らないだろう。ならば、今のうちにSTEP基準の指標から、「次のやつ」基準の指標を模索しておこうと思う今日この頃なのでした。

COCOMO自体はプログラムステップから工数を出す見積もり手法だが、COCOMOには工数から工期を算出する計算式があるので、そいつについて。 式は 工期（月）＝α×（工数（人月）の３乗根） だそうな。 なお、このの工数と工期はプロジェクト全体（要件定義からシステムテストまで）が入るので注意。 この式のαについては「日本情報システムユーザ協会（JUAS）」が収集・計測したところ、「2.7」が妥当らしい。 本来、αの部分は「プロジェクトのメンバの能力による適当な係数」と「正規分布を想定した時間経過ごとの要員割り当て」をもとに割り出という手順になっている。 （要員割り当てはαだけではなく式全体に影響がある、と思う） とはいえ、JUASでは実際のプロジェクトをいくつも収集したというのだから、「2.7」は日本のプロジェクトには使ってもよいと思う。 αを2.7としたときの各人月に対する工期は以下のとおり。 1人月　2.7ヶ月 2人月　約3.4ヵ月 5人月　約4.6ヶ月 10人月　約5.8ヶ月 20人月　約7.3ヶ月 50人月　約9.9ヶ月 100人月　約12.5ヶ月 うーむ、工程が要件定義からシステムテストまで入ってると・・・。 10人月以下あたりはちょっと長い印象。 20人月以上になるとこれくらいで適当かなぁという印象。 思うに10人月以下の場合は一人が担当する範囲が広い（プログラム設計者が実装もして、単体テストもして、結合テストもしてetc）な場合が多い、というか実際自分のところではそうなので、感覚と違うのだと思われる。 要員が少なければ各工程ごとの要員割り当てが正規分布どころか、一直線になるんだからこの式に当てはめるて違和感がでるのは、納得感あり。 うーん、大きな工数になることがない限り使う機会が少ない、かな？ ■参考 ThinkIT 日本情報システムユーザ協会

見積もりにおける手法の１つ。 有名なFP法はデータ項目数（DBのテーブルやファイルの項目数）と入出力の数を手がかりにシステムの規模を見積もるが、UCPはUMLでいうクラス図を元に規模を見積もる方法。 分析クラス図までを作れれば、UCP法で見積もりしやすいだろう。 分析クラス図をベースにしたポイントを「未補正UCP」とし、さらに技術的な複雑度、環境的な複雑度をもとにした係数をかけることで「補正後UCP」ができあがる。 あとはFP法と同じように「１ポイントは何時間（または人月）かければ消化できるか」＝生産性係数をかけることで工数の見積もりにすることができる。 UMLを主に開発するプロジェクトでは非常に重宝されそうなこの手法だが、問題点を感じないわけではない。 この手法で感じる問題点は、FPと同じように「生産性係数をいくつにするんじゃい？」という点なのだが、UCP法を考えたGeri Schneiderさんによると普通のプロジェクトならば生産性係数は２０時間らしい。 （つまり１UCPの機能あるいはシステムであれば２０時間で作れるであろう、と。） しかしながらこのUCP法はまだ日が浅いためか、Geriさんの考えるプロジェクトが私の周りと一致しずらいのか、２０時間で本当に大丈夫か？という不安がいつもある・・・。 （事実、２０時間で工数に変換すると「大丈夫かなぁ・・・」という工数が出てくる） また、技術要因はさることながら、環境要因が曲者と思う。 なぜならば、環境要因は「採用するプロセスの習熟度」「モチベーションの有無」「プログラミング言語の難しさ」などなど、非機能要件的な要素を先に係数として含めてしまう仕組みになっており、これをどう扱うかが実際に使おうとすると非常に悩ましい。 とはいえ、個人的に分析クラス図は頭のなかで思い浮かびやすいUMLであり、これからもお世話になるはずなので、まずはUCP法の生産性係数はいくつが望ましいのか、周りからデータ収集を地道にがんばるしかないか。 ■参考 ■オブジェクト倶楽部 http://www.objectclub.jp/ ■ITpro http://itpro.nikkeibp.co.jp/article/COLUMN/20060811/245759/