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