情報システム開発の工数把握技法

ベーム（Boehm）は、１９８０年代の中頃に、情報システムの開発費用の大部分がハードウェアからソフトウェアになり、しかも、既存システムの保守改訂に多くの労力が費やされ、新規システム開発が圧迫されていると指摘しました。これをベームの法則といい、ソフトウェア危機の認識が高まりました。

そのような認識から、情報システム開発の工数（費用）見積りや生産性向上の必要性が高まりました。現在では、ＩＴ戦略が経営戦略に密着するので、経営者が情報システム開発費用に多大な関心をもつようになり、「信頼性が高く理解しやすい」工数見積もりの方法がますます求められています。

人月法

システム開発の見積りでは、それに必要な人月（＝人数×月数）を見積り、各人の人件費をかければよいといえます。そのような方法を人月法といいます。
人月法には次のような欠陥があり、これからの脱却が重要だと指摘されています（参照：「情報サービス業の課題と対策」）。

• 人月を見積もることが困難です。単に問題をすりかえただけです。
• システム開発やプログラム作成は、能力により１０倍以上も差がでることがありますが、人件費の差はせいぜい数倍です。能力の低い者を充てるほうが費用が高いという矛盾が起こります。
• 開発方法論や品質向上などのベンダ努力が反映されません。そのため、そのような努力のインセンティブが行われず、ＩＴ業界の能力が向上しません。

類推法

過去の類似システムでの経験から類推する方法です。カンだともいえますが、作業を適切に分解して（ＷＢＳ：Work Breakdown Structure）、適切な記録を蓄積することにより、精度の高い見積りを得ることができます。
　類推するのに、一つの類推値だけにするのを一点見積りといいます。しかしこれでは、どの程度信頼してよいのかわかりません。その対策として、最尤値（最もありそうな値）、楽観値、悲観値の３点を示す方法が採られることがります。それを三点見積りといいます。

標準タスク法

類推法と似ていますが、ＷＢＳの方法と各要素作業に標準を用いることを重視しています。
　このように、小規模なＷＢＳの見積りを累積して大規模なシステムの費用を求める方法をボトムアップ法ともいいます。

パラメトリック法

直接に作業全体の費用を見積もるのではなく、作業を構成する要素に注目し、個々の要素大きさから費用を見積もる方法の総称をパラメトリック法といいます。それには、次のような方法があります。

ＬＯＣ法

パラメトリック法での要素として、最も単純なのはプログラムのサイズです。何らかの方法で、ＬＯＣ（Line Of Code：プログラムのコード数）を算出し、標準的なプログラマの生産性から工数を算出して費用を見積ります。人月法と同じ意味で用いられることもあります。
　しかし、プログラムのコード数を算出すること自体が困難だという矛盾があります。

ブルックスの法則

ブルックスは、豊富な経験から、システムの規模（プログラムのステップ数）が大きくなると、それに要する工数は指数的に増大することを指摘しました。それを補正するために、多くの見積りモデルが提唱されてきました。

Dotyモデル

コード数から開発工数を見積もる方法の一つで、
　　工数（人月）＝a×コード行数^ｂ （ａ，ｂは定数）
として表されます。数万ステップまでの小規模開発の見積もりに適しています。

Putnumモデル

数十万ステップ以上の大規模開発に適したモデルです。次の式で与えています。
　　工数＝コード行数³÷（補正係数³×開発期間⁴）
この式は、開発工数だけでなく、開発から保守までを含むシステムのライフサイクル総工数の算出にも適用されるそうです。

ＣＯＣＯＭＯ法

工数＝Ａ×Ｓ^Ｂの式により工数を算出します。
　ここで、Ｓはシステムの規模、Ｂは定数（＞１）、Ａは次のような要因につき係数が与えられます。
　　製品要因：信頼性要求度、データベースの規模、複雑度、・・・
　　計算機要因：ＣＰＵ制約、メモリ制約、安定性、応答速度、・・・
　　人的要因：プログラマ能力、業務成熟度、言語経験、・・・
　　プロジェクト要因：プログラミング手法、開発ツール、納期、・・・
　　　　：
　現在では、これを改良したＣＯＣＯＭＯⅡが用いられています。

CoBRA法

CoBRA法（Cost estimation, Benchmarking and Risk Assessmen）は、見積り熟練者の経験知識、過去の類似プロジェクトからの類推、統計的方法を組み合わせたコスト見積りおよびリスク検討の技法です。
CoBRA法では、開発費用を次のように定式化します。
　　　費用＝α×規模×(１＋∑CO_i)
　　　　　　α：変動要因がないときの単位規模あたりの必要工数
　　　　　　CO（Cost Overhead）：変動要因、開発コストを増加させる要因のみを列挙

• 数人の見積り熟練者が、経験知識からＣＯを抽出し定義します。
• 実績データから規模と工数の関係を調べ、αを求めます。これには１０件程度の実績データでよいといわれています。これが標準コストになります。
• それぞれのＣＯについて、標準コストから何％増加するかにより、レベル０～レベル３のケースを設定します。そして、各ＣＯの各レベルの発生確率を、経験知識により、最頻値、最小値、最大値の３点で予測します。
• この確率データを用いて、統計的手法（モンテカルロ法によるシミュレーションなど）により、全体費用の確率分布を算出します。

これにより、次のことがわかります。

• 予算との関係：予算内で達成できる確率と超過する確率、悲観的な場合の超過費用などがわかります。
• 重要要因の把握：費用増加に大きな影響を与えるＣＯがわかるので、重点対策の検討ができます。さらに、そのレベル発生確率による影響を調べることにより、対策の効果を推定できます。

ファンクションポイント法

開発する情報システムで必要となる入出力画面やファイルなどの個数と複雑度などからファンクションポイントを求め、その値から工数を求める方法です。
　この方法は、画面やファイルの個数など、検討の早期に把握でき経営者など専門外の人にも理解しやすい変数を用いていること、種々の係数が多くの測定により信頼性の高い数値が公表されていること、ハードウェアやプログラミング言語に依存しないことなどの特徴があります。それで、現在は工数見積技法としてファンクションポイント法が高く評価されています。

　　　　　　　　　　　　　複雑さの程度
　　　　　　　　　　　　　低　　中　　高
　　外部入力　　　　　　　３　　４　　６
　　外部出力　　　　　　　４　　５　　７
　　内部論理ファイル　　　７　１０　１５
　　外部インタフェース　　５　　７　１０
　　外部照会　　　　　　　３　　４　　６