◆見積書
ソフトウェアの原価は、ほとんどが人工費であるので、生産量と生産性の合意が基本となる。ここでは、ファンクションポイント法による見積もりを前提に、チェックポイントを紹介する。従って、仕様書上で要求されている画面・帳票・ファイルに対して過不足が無いこと、各構成要素の難易度や改修率に応じたFP数、単位FP数当たりの生産性や原単位などが妥当かどうかがチェックのポイントとなる。複数の業者から合い見積もりを取る場合も、このような見積もりであれば比較検討しやすい。もっとも、1式いくらでは、比較検討のしようがない。単に安いか高いかだけでは、もしかすると大きな見積もり漏れや、作業範囲などに相違があるかもしれない。見積書は、提案書でもあるので、その内容を見れば実力や誠意を伺い知ることができる。仕様書どおりの言われた事だけやるという見積書と顧客の立場に立って、必要十分な内容での分かりやすい見積書と、どちらの業者を選ぶかは自明だ。
(1)数量(工数)、単価、金額は、明示されており、計算間違いはないか。
(2)見積り有効期限は、明示されているか。
(3)システム仕様書に対し、データ型(機能)は過不足無く定義されているか。
整合性をチェック。
(4)処理方式ではなく、外部機能(帳票、画面、ファイル)に着目してデータ型を定義
しているか。
(5)内部処理の作業用一時ファイルをデータ型として定義していないか。
(6)階層型データベースや表データベースでは、全体ではなく、関連するセグメント
や表のみを対象ファイルとして項目数、難易度を算出しているか。
(7)各データ型(入力、出力、入出力)の区分は、システム仕様書に対し妥当か。
(8)難易度別、データ型(画面、帳票、ファイル)の数は、システム仕様書に対し
妥当か。
(9)難易度の選定(難易度表:データ項目数、処理の複雑さ)は、システム仕様書に
対し妥当か。
(10)修正率の選定は妥当か。
・類似ソフトの流用、プログラム部品の使用を考慮しているか。
・全体に対する、改修部分の規模から見て、妥当な修正率か。
・改修でも、外付け可能な機能追加は、その部分を新規開発とした場合と
比較検討する。
(11)開発言語の生産性は妥当か。
・生産性の良い、適切な開発言語、ツールを選択しているか。
・汎用ソフト、ユーティリティ、開発ツールの使用を考慮しているか。
(12)FP係数(単価/FP又は作業工数/FP)は妥当か。
開発標準により、作業工程と各工程での実施作業及び成果物が明確化されている
ことを確認し、その上で、委託する作業範囲及び成果物及び仕様書の完成度に応
じて妥当かを確認する。
(13)マクロ的に見て、合計金額、合計工数は、システム規模に対し妥当か。
過去に実績のある、同等内容・規模のシステムと比較して見る。
このためにも、システム構築の実績を画面・帳票数、FP数、作業範囲、成果物、
発注金額などで記録しておくと良い。
(14)データ型、難易度、ファンクションポイント数(FP)、金額は、矛盾や計算間違いがないか。
基本的なことであるが、あとで揉めないようにキッチリとチェックし、納得でき
ないところはしっかりと説明を求めるべきである。
(15)別途、導入・移行作業等が必要な場合に、見積りがしてあるか。
見積もりから漏れていることが少なくない。
いざ実用開始直前に追加費用が発生して慌てないようにしたい。
(16)ハードウェア、ソフトウェア、ライセンス等、必要十分な購入品を別途、見積り
してあるか。システム仕様書及び実際の業務要件、運用環境に対して、必要十分
な性能・容量・数量等がサイジングされているか要確認のこと。
コメント