システム関連コストの削減は、情報システム部門にとっては大きなミッションだ。今回は効果的なシステム投資を実現するための見積もりの方法について考えていこう
皆さんは業者の提示する見積もりが妥当だと判断して契約をしているだろうか。「一式いくら」で金額を提示され、こんなものだといわれて十分納得できないまま契約していないだろうか。前回述べたように、質の良い仕様書を作成したなら、それに値するだけの見積書の提示を求めることができ、その妥当性について業者と納得いくまで交渉・商談することが可能だ。
単に「もっと安く」という水掛け論や不当な値引き要求は、結局、見えないところで手抜きされ品質が悪化する。「安かろう、悪かろう」では、最小の投資で最大の効果を生むシステムにならない。
ハードウェアにしろソフトウェアにしろ、見積もりは決して専門家にしか理解できないものであってはならず、利用者の視点でもなされるべきである。もし、業者の見積もりが理解できないのであれば、理解できるように作成してもらうべきだろう。 ハードウェアにおいて利用者の視点とは、要求応答時間、同時利用人数、利用回数、データ量、故障時の復旧時間などである。CPU処理能力がどうとか、ストレージの性能がどうだとかそういった専門的な説明を聞かされても、それらが直接、利用者にどのような影響を及ぼすのか分からなければ意味がない。
この場合、利用者視点の要求とハードウェアの具体的な要件の対応が明らかにされていることが理想的だ。例えば要求応答時間がxx秒、同時利用人数がyy人だから、CPUは1GHzのもの2個とメモリ2GBが必要という具合である。このように見積もりを作成してもらうと、相見積もりを取る場合も、比較がしやすく、また同時利用人数が増えた場合、どれくらい追加の費用が必要になるか、ある程度想定することができる。もし、見積もりに予算が合わない場合、仕事のやり方を工夫し、同時利用人数を半分にできれば、投資額を半減できる可能性がある。
ソフトウェアにおいて利用者の視点とは、画面・帳票・ファイルなどの外部インターフェイスである。これらの要素それぞれに難易度で重み付けをした機能数(FP:ファンクションポイント)をベースにシステムの全体規模を算出し、これに単位FP当たりの単価を乗じて金額を算定するのがファンクションポイント法と呼ばれる見積もり方法だ。利点はまさに“利用者の視点で見積もりができる”ということにある。さらに、画面・帳票・ファイルを数え上げるので、成果物の漏れや忘れを発注者・受注者の双方でチェックでき、合意のうえで発注できるので、納品時に「画面が足りない!」というようなトラブルも未然に防止できる。
このようにして見積もりを数社から取った後、比較表を作成して検討してみるとよい。賢い買い物をするためには、相見積もりは必須だ。
簡単な入力画面を1画面、新規にCOBOLで開発する場合の計算例
FP数:入出力などの要素種類と難易度によって決まる
調整係数:言語生産性やその他のシステム特性などにより決まる
以下より、最新の言語別生産性一覧表を購入することができる。http://www.spr.com/products/programming.shtm
生産性:FP当たりの作業時間(総作業時間÷FP数)
レート:単位時間当たりの作業費用(作業費用÷作業時間)
FP数が5、調整係数が1.0、生産性が10(FP当たり10時間)、レートが5000円の場合、
5×1.0×10×5000円=25万円
という具合になる。
【参考図書】
「ソフトウェア開発の定量化手法」(ケイパー・ジョーンズ著/構造計画研究所)
【参照ファイル】(システム構築駆け込み寺サイトより)
システム構成・ベンダ比較表の例(Excelファイル)(ケイパー・ジョーンズ著/構造計画研究所)
ところで、ファンクションポイント法は、画面・帳票・ファイルなどをベースとするため、これがある程度判明しないと見積もりができない。本来は、仕様書までを作成し見積もりを取るべきであるが、どうしても不可能な場合は、まず仕様書作成までを委任契約するのがよい。その後、画面・帳票・ファイルが明確になった時点で、ソフトウェア開発を請負契約するとよいだろう。
画面・帳票も分からない段階で、「一式いくら」とか「何人月」とかで一括契約してしまうのは、非常に危険である。このような見積もりでは、その妥当性を検査することも交渉することもできない。「一切信じてお任せする」ならそれでよいが、最小の投資で最大の効果を生むシステムを構築するなら、このような契約は避けたい。 そもそも請負契約とは、最終成果物が明確になっており、それに対して対価を支払うものなので、成果物が不明な場合は契約の履行/不履行さえもあいまいになってしまう恐れがある。一方、委任契約というのは、成果物ではなく知識や労働力を対象とした契約であり、必ずしも成果物を必要としない。住宅建築で設計図の作成を建築士と委任契約し、その設計図に基づいて実際に工事するのを工務店と請負契約するのと同じだ。
最近では、コンサルタントを使うこともあるが、そのアウトプットとして成果物(画面・帳票・ファイル)が明確に規定されていなければならない。これは、建築設計図に値するものである。
さもなければ、その図面を用いて実際に工事することもできず、検査することもできない。このように考えておけば、コンサルタントを頼んだのはよいが、いざ業者にシステム開発を発注しようとしたら、残されたドキュメントでは何を作ればよいか分からず、使い物にならなかったなどというトラブルも避けられる。近年、UMLという統一された設計図の書き方が提唱されている。
なお、建築士に設計図の作成を依頼しても、建材や内装など1つ1つを自分で決めなければならないのと同様、システム構築も同じでコンサルタントに任せっきりにすることはできない。他人任せでは、自分の思うようなものはできないということを肝に銘じておこう。
【関連記事】
【“建築”と“システム構築”の類似点・相違点】“街づくり”で理解するシステム構築入門(1)(@IT情報マネジメント > 企業システム構築)
Copyright © ITmedia, Inc. All Rights Reserved.