情報化投資の費用対効果のうち費用を考えます。ハードは比較的把握しやすいのですが,それでも情報特有なむずかしさがあります。さらに情報システム開発にかかる費用については,経営者にとって不可解なことが多くあります。
ハードウェアは実際に見えるモノですから,比較的評価しやすいはずですが,それでも多くの難しい事項があります。
1000キロリットルのタンクには2000キロリットルのガソリンは入れられないし,時速160キロが定格の自動車を時速300キロで走らせたらエンジンが壊れてしまいます。ところがコンピュータでは,「現在はコンピュータの能力ぎりぎりで処理しているが,近い将来,データ量が増大するのでパンクしてしまう。増強させてほしい」との情報システム部門からの要求を無視しても,コンピュータがネックになり業務ができずに倒産した例を私は知りません。
これは,情報システム部門が,プログラムを直したり運用を工夫することにより,処理効率をあげたからです。特定のプログラムがネックになっているとき,システムやプログラムを工夫すれば,数十倍の処理をさせることも可能です。しかしそのためには,ファイルをその処理に特化した工夫をしたり,プログラムに特殊な細工をするなどが必要ですから,標準からはほど遠い複雑なシステムになってしまいます。そのようなシステムの保守改訂は非常に困難でコストがかかりますから,長期的に見れば,非常に金のかかるシステムになります。
経営者がそのような事情を知らないと,「なぜ増強を要求する前にそうしなかったのか。情報システム部門は工夫もしないで,安易に増強したがっているのではないか」という批判になります。
パソコンは急激に発展しています。それで実務的には「パソコンの寿命は3年」(「日経コンピュータ」2002年11月11日号)だともいわれています。ところが,経営者に「古い機種では計画中の○○システムの入力や出力ができなくなるのか」とか「来年になれば価格はもっと下がるだろう」と指摘されると答えようがないのですね。しかも,パソコンのOSを変えるには再教育が必要ですし,Officeソフトのバージョンアップでは新旧機種でのデータ互換性の問題も生じます。それで「バージョンアップはもうやめた」(「日経コンピュータ」1998年11月09日号)としたいのですが,社外との情報交換を考えるとそれもできません。
ハードという見えるモノでもわかりにくいのですから,見えないソフトはもっとわかりにくいことになります。経営者は次のようなことに疑念を持ちますが,明快に答えられるでしょうか?
会計システムを構築するとしましょう。秋葉原へ行けばパソコンの会計ソフトは5万円以下で売っています。本格的なERPパッケージを導入しようとすれば,ソフトだけでも数億円するし,システムを構築するにはコンサルタントやERP技術者などの費用はそれの数倍かかります。独自に開発する場合でも,A社では数百万円で済んだというしB社では数千万円かかったといいます。規模の違いや機能の違いはあるでしょうが,あまりにも価格差があり過ぎます。当社にとって,どれが適切なのでしょうか?
自動車を購入するときは実物がありますし試乗することもできます。注文住宅でもその場で簡単な間取り図や見取り図を描いてくれます。ちょっと気の利いた工務店ならCADでの実演をしたり模型を作ってくれるでしょう。ところが情報システムでは,見本を見せてくれないのですね。それをするだけでも要求分析や概要設計が必要だといって,かなりの時間と費用を請求します。それどころか,そのシステムを検討するのに経営戦略がどうのシステムの目的はどうのなど,痛くない腹を探られるようなことまでいわれます。
概要設計が終わった頃に,システムの説明があるのですが,これも実物見本ではなく分厚い仕様書です。専門家でなければ,こんなものを見る気がしないし,読んでも実物を描くことはできません。しかも,松・竹・梅のような代替案はなく1品だけの提示です。それの出力帳票が10表あるので,それを5表にしたら半額になるのかといえば,データベースがどうのこうのといって1割程度しか安くならないのですね。YesかNoか二者択一を迫られるので,どう考えてよいかわかりません。
しかも,さらに代替案を求めると「そういうことは要求分析の段階で明確にしてもらわなければ困ります」といわれ,追加費用を要求されます。家を建てるのにおカネのことは何も示さずに「交通の便がよいほうがいいですか」「部屋は広いほうがよういですか」「ご主人の書斎も必要でしょうね」などと聞き出して,最後になって3億円になるといわれたような感じです。
情報システムの規模や開発費用を推定することは,自社で構築する場合も必要ですし,他社からの提案見積りを検討するのにも必要です。ましてベンダーではこれが収益に直接に関係するのですから精度のよい推定が必要になります。そのために,多くの算出方法が研究されていますが,どれも経営者にとってあまりわかりやすいものではありません。
私たちは商品やサービスを購入するのに,いちいち原価を調べることはしません。それを購入することによる効果と購入費用を比較しているのです。システム開発でも,その効果から費用を考えて,その費用内で開発すればよいという考え方です。これは理屈に合った方法ですし,ベンダとの取引では理想的ですが,それでも適正な価格なのかどうか気になります。また,社内での開発では,このような方法ではむしろ管理がいい加減になる危険もあります。
過去に経験した事例により費用を類推する方法です。経験が豊富であり,今回のシステムが特別な事情がないならば,比較的よく類推できます。しかし,あまりにも主観的であり人によって値が大きく異なることもありますし,状況把握が不十分だと大きな見積り誤りを生じる危険もあります。
LOCとはライン・オブ・コードすなわちプログラムの行数のことです。システムをいくつかの細かいモジュールに分解して,そのモジュールについてLOCを想定して合計を求めるとか,過去に経験した類似のシステムから類推したりします。
わかりやすいのですが,肝心のLOCをどう類推するのかが問題になります。下手なSEが設計して下手なプログラマがプログラムを作るとLOCが非常に大きくなります。出来高払いとすると,下手なSEやプログラマを使うほうが売上が増大するという矛盾が発生します。また,簡単なロジックと複雑なロジックでは,出来上がったプログラムの行数にはあまり違いがないにしても,それを考える手間は非常に違います。LOC法は手仕事に価値があり,頭脳にはカネを払わないということになります。
このようにLOC法は意味がないだけでなく,これがソフトウェア産業を堕落させ,優秀な技術者の育成を阻害しているのです。それでLOC法を追放しようという動きになっているのですが,素人の経営者にわかりやすいので現在でも人月実績やLOC法がのさばっているのは嘆かわしいことです。
現在ではファンクション・ポイント法が最も合理的な方法であるとされています。しかしこの方法も基本的な問題があります。
さらに基本的なこととして,LOC,COCOMO,ファンクション・ポイントのどれもが,かなり要求事項を分析した後でないと算出できない欠点があります。経営者としては,それを待っていられないことも多いでしょう。それに当然ながら,情報検索系システムやコミュニケーション系システムへの適用やインフラ投資への適用は非常に困難です。
従来の日本的な商慣習に染まっている経営者には,情報業界の慣習には理解できないことがいろいろあります。しかも,いつでも当社側がカネを払うような仕組みになっているのは,なんだか騙されているような気になります。