スタートページ＞ 主張・講演＞ 経営者・利用部門のためのＩＴ入門＞ 第４章 個別システムの調達（２）
経営者にとってＩＴの費用対効果がわかりにくい原因の一つに、システム開発、特にプログラム作成などの費用算定がわからないことがあります。
情報システムの開発費用については、一般の取引とは異なる特徴があります。
通常の商品では、原価を算出して価格を決めるのではなく、利用者がその商品価値から支払ってもよい金額により価格を設定しています。ＥＲＰパッケージやＳａａＳなどではこの方法になっています。
本来ならば、個別仕様による情報システム開発もそうあるべきです。これならば、生産性の高い技術者をもっているベンダや部品や開発環境の整備などの努力をしているベンダは、開発コストが低減され利益が増大します。このようなベンダの努力は、結果として利用者のメリットにもなります。
しかし、未だこのような取引をすることは稀です。その理由として、情報システムの要件定義が明確にできないので効用を適切に把握できないこと、利用者とベンダの相互信頼が不十分なことなどがあります。
過去の類似した実績から類推する方法です。カンに頼ったドンブリ勘定になりがちですが、他に適切な方法がない場合や大雑把に把握したい場合に広く用いられます。それに、経験のあるＩＴ技術者は、かなり適切な見積もりをするものです。
しかし、一般の商品購入などと比べると、情報システム開発での類推法には限界があります。一般の商品では、実際に購入した経験はなくても、常識的な価格を知っています。情報システム開発では、その常識がまだ不十分なのです。
類推法を用いるには、規模、信頼性への要求度、開発環境などが類似した実績が多く存在することが前提になります。実際には、同じ情報システムを構築する場合でも、多様なアプローチがあるので、類推法に耐えるだけの情報をもっている企業は稀です。
個々の情報システムは多様だとしても、開発工程を詳細に分割すれば、工程レベルでは共通するので、類推法を用いることができます。しかし、そのためには、実績を多様な切り口に分解して詳しく分析した記録を残すことが求められます。
このような分析記録をすることは、将来の見積りに役立つだけではありません。計画と実績の分析を行うことにより、情報システム開発プロジェクトの評価のためにも必要ですし、プロジェクトマネジメント能力を向上させることができます。
素人は「開発費用＝プログラミング費用」だと思っています。情報システムの内容が単純で、プログラム開発環境が劣悪な時代では、プログラミングが費用の大部分を占めていました。ところが現在では、部品再利用やプログラム作成環境の発展により、プログラミングにかかる作業の割合は低下しています。
反面、複雑なシステムになり、要求分析から内部仕様書作成までのプロセスに多くの作業がかかります。データベースやネットワークなど、プログラミング以外の作業が多くなりました。しかも、これらの作業のほうが、情報システムの成否に大きな影響を与えます。
そのため、技術者の数ではなく質が重要なファクタになるのです。
通常の商品やサービスならば大量取引の場合はコストが低減します。ところが、情報システムの場合には、逆になるのがむしろ一般的なのです。
情報システムに要求する機能がｎ個あると、ｎ(ｎ－１)／２個の相互関係があります。規模が大きくなると複雑度が増大します。それだけリスクも大きくなります。また、規模が大きくなると、要員の都合により多段階に下請を起用しますが、中間での管理費が多くなります。
それで、開発にかかる工数あるいは費用はシステム規模の指数倍になります。これをブルックスの法則といいます。
このような理由により、情報システム開発では独自の工数見積り技術が発展してきました。これらは、ベンダが原価見積りをするためと、発注者に見積金額を説明するための目的があります。ここでは、発注側の経営者の立場で考察します。
開発費用の根拠として、ベンダが示す最も典型的なものは、開発するシステムのプログラムステップ数でしょう。「このシステムでは○○ステップのプログラムになる。１人月での開発ステップ数は△△などで、□□人月必要になる。１人月の人件費が▽▽万円なので、開発費用は◇◇万円になる」というものです。このように、工数をプログラムステップ数で表す方法をＬＯＣ（Lines Of Code）法といい、人月を尺度として費用算出する方法を人月法といいます。
ところが、経営者にとっては、プログラムステップ数を示されても、どうしてその数値になるのかわかりません。また、プログラミング以外の作業もある（しかもその割合が増大している）ので、プログラムステップ数を費用算出の根拠にしている場合には、他の作業もプールして単価を設定することになります。そのため、単価が大きく変動します。これでは、費用が適切なのかどうかわかりません。
●人月ベースの弊害
人月ベースは労働提供型の特徴です。能力の高い技術者を配置したり、部品や開発環境の整備をしたりすることにより人月はかなり減少しますが、利益を得るには人月当たりの単価を高くすることになります。ところが、単価は格好な値引き交渉の項目になり、能力の高いベンダほど受注できなくなるという矛盾が生じるのです。
ベンダの能力が低いことがよくいわれますが、その大きな原因が人月法にあります。品質の良いシステムを安価に短期間に調達するためにも、発注者が人月法と決別することが望まれます。
プログラムにかかる作業量は、プログラムの対象、信頼性の重要度、開発言語、プログラマの経験など多様な要因により変化します。ＣＯＣＯＭＯはこのような影響要因について、多くの実例から標準的な係数を設定し、ＬＯＣ法を修正するものです。ＣＯＣＯＭＯでは、かなりシステムの仕様が明確になってからでないと、工数算定ができません。また、経営者にとっては、ＬＯＣ法と同様にその値の根拠がわかりません。
なお、ＣＯＣＯＭＯⅡでは、それを改善して、次のファンクションポイント法の考え方も取り入れています。
ファンクションとはデータ入力画面数、出力帳票数、使われるファイル数などのことで、それぞれに複雑度などによりポイントが与えられています。このポイントは多くの実例から統計的に得られたもので公表されています。
複雑さの程度
低 中 高
外部入力 ３ ４ ６
外部出力 ４ ５ ７
内部論理ファイル ７ １０ １５
外部インタフェース ５ ７ １０
外部照会 ３ ４ ６
対象システムが必要するファンクションの個数にそれぞれのポイントを乗じたものをファンクションポイントといい、その値によってシステムの規模や工数の尺度とします。
この方法は、システム開発の比較的初期の段階で把握することができること、経営者にもわかりやすいことの特徴があります。