はじめに
企業における情報関連投資は増大しており、そのなかでもアプリケーションシステム開発運用費の占める割合が増大している。ところが、その規模が費用対効果の観点から適切かどうかの判断指標が乏しい。また、利用部門がシステム開発に大きく関与するようになってきたが、情報システム部門と利用部門との責任分担はあまり明確になっていない。
花岡(1995)は、情報システムの導入効果の測定と、両部門の責任を明確にするためのαβモデル（η＝α・βの積形式）を示した。このモデルは、企業単位での考察や企業間比較などのマクロな視点では優れたモデルである。しかし、個々のアプリケーションシステムを対象にしたミクロなレベルでの考察には、むしろη＝α＋βの和モデルのほうが適している。
本稿では、花岡モデルをマクロαβモデルとし、この和モデルをミクロαβモデルとして、ミクロαβモデルによるアプリケーションシステムの最適規模の測定や情報システム部門と利用部門の責任分担について考察した。また、この考え方によるアプリケーションシステム投資への応用や、各種開発技法との関係について考察した。
なお、本研究は関東学院大学経済経営研究所「産業ネットワーク研究プロジェクト」の一環として行ったものである。
１．ミクロαβモデルの必要性
１．１ 問題認識
情報関連投資は、バブル崩壊に伴い一時的に減少したが、最近また増大しつつある。しかし、その投資に関して、従来より一層、費用対効果を明確にすることが求められるようになった。
ハードウェアや通信回線は急速に価格低下してきたが、個々のアプリケーションシステムの開発運営費用は、ほとんどが人件費であり、むしろ増大している。しかも、経営環境の拡大に伴い、アプリケーションシステムは巨大化複雑化し、開発運営費用は増大している。これらの要因により、情報関連投資でのアプリケーション開発運営費用が占める割合が増大してきた。
情報システムの効果は、定量的効果、定性的効果および戦略的効果に区分されるが、次第に定性的効果や戦略的効果の占める割合が大きくなり、効果の把握が困難になってきた。戦略的観点からアプリケーションシステムの費用対効果を判断するのは経営者の責任である。しかし、情報システムの提案では、複数の比較案が示されることは少なく、提案が過剰なのか不足なのかの比較判断が難しい。
アプリケーションシステムの開発では、利用部門が機能要求をするが、まだ利用部門はそのシステムの費用対効果について十分な認識を持っていないので、とかく過剰な機能を要求する。情報システム部門もそれをアセスメントする力がなく、結果として最適規模よりも過大なシステムになってしまうことが多い。
また、情報システム部門も、生産性の向上による経営への寄与という観念が希薄である。そのために、生産性向上ツール導入が遅れて紺屋の白袴になり、その結果、アプリケーションシステムの構築に費用がかかり、最適規模を低く抑えてしまうことも多い。
本稿では、情報システムの費用対効果の改善を、個別アプリケーションシステムを最適規模にするモデルを考察する。また、そのモデルをベースにして、情報システム部門と利用部門の任務を考察する。
１．２ マクロαβモデル（積型モデル）
花岡(1995)は、情報システムの導入効果の測定と情報システム部門／利用部門の責任を明確にするモデルを示した [1]。それを簡単に紹介する。
情報システムへの投資額をｉ、それによる業績をｏとすれば、情報システムの投資効果ηは、
η＝ｏ／ｉ
となるが、ここで、
α＝ｆ／ｉ、β＝ｏ／ｆ
とおけば、上式は、
η＝α・β
となる。
ここで、ｆは情報システム機能である。αは情報システム機能をいかに効率よく提供するかの指標であり、情報システム部門の任務である。βはいかにして情報システム機能を使いこなすかの指標で利用部門の任務である。
花岡は、この指標を用いて、企業での情報システムの効果を分析したり、α主導型・β主導型で情報システム推進の特徴と問題点、ＣＩＯの位置づけの解明などに発展させている。
このモデルは、αとβの積の形式にしたので、規模による相違を吸収できるので、企業レベルでの全体の情報システムを対象にした評価や、企業間の比較のようなマクロな分析に適している。それでここでは、このモデルをマクロαβモデルと呼ぶことにする。
マクロαβモデルでは、η＝ｏ／ｉの関係が基本になっている。そのために、個々のアプリケーションシステムの規模を検討するには不向きである。また、企業での投資意思決定では、比率よりも絶対額のほうが判断基準になる。このような理由により、個々のアプリケーションシステムの評価のようなミクロレベルでは、積型モデルでは不都合な面もある。それで本稿では、η＝ｏ−ｉに基づく和型モデルを考えた。それをミクロαβモデルと呼ぶ。
２ ミクロαβモデル（和型モデル）
ここでは、販売情報システムやか人事情報システムのような個々のアプリケーションシステム（以下、単にシステムという）を対象にする。そして、上述の企業レベルでのマクロなαβモデルに対して、これをミクロαβモデルと呼ぶ。
２．１ 最適システム規模の定式化
ミクロαβモデルを、マクロαβモデルの記号を用いて表すと次のようになる。
η＝ｏ−ｉ
＝α＋β
（ここで、α＝ｆ−ｉ、β＝ｏ−ｆ）
数式上はｆは何でもよい。マクロαβモデルでは、抽象的に情報システム機能としているが、ここでは、ｆは当該システムのシステム規模とし、システム規模の指標としては、ファンクションポイント（注１）を用いる。
Brooksの法則（注２）やＣＯＣＯＭＯモデル（注３）が示すように、システム規模ｆと開発費用ｉの間には、
ｉ＝Ａｆａ （ａ＞１）
の関係があり、システム規模が大きくなると急速に開発費用が増大する。しかも、システムは実施後に環境変化への適応や利用者要求追加などによる保守が多く発生するが、その保守要件は規模が大きくなると急激に増大するので、ａの値はかなり大きいと考えられる [2]。
それに対してシステムによる効果ｏは、ファンクションポイントを効果の高い順にならべると、収益逓減の法則により、システム規模の増加とともに効果の増加分は少なくなる。すなわち、システム規模ｆと効果ｏとの関係は、
ｏ＝Ｂｆｂ （ｂ＜１）
となる。
このシステムによる利益ηは、
η＝ｏ−ｉ
＝Ｂｆｂ−Ａｆａ
で表される。これをｆで微分して０とする操作により、最適システム規模ｆ＊は、
ｆ＊＝（Ａａ／Ｂｂ）１／（ｂ−ａ）
となる（マクロαβモデルでは、
η＝（Ｂ／Ａ）ｆｂ−ａ
となるので、最適システム規模ｆ＊は無限大または０になってしまう）。
これらの関係を図示すると図１のようになる。すなわちシステム規模をｆ＊にしたときが費用対効果が最大になり、システム規模がｆ＊よりも小さい（左側）のときは規模不足であり、大きい（右側）のときは過剰規模である。
それらを考慮して、動的計画法や１／０計画法に帰着したモデルにすることはできる。しかし、肝心の係数（Ａ、ａ、Ｂ、ｂ）があまりにも測定しにくい。たとえば該当システムの維持期間を何年にするかで、これらの値は大きく異なったものになる。
そのために、このモデルは定量的な目的ではなく、考え方を整理するためのものであると理解すべきである。
２．２ αとβの意味づけ
前節では、β＝ｏ−ｆ、α＝ｆ−ｉの関係は不要であった。ここでは、これを導入した理由について述べる。
（１）β≠ｏの認識
システムの規模は上述のｆ＊にするのが最適である。しかし、ややもすると利用部門は開発や保守の費用を考慮せずに、β＝ｏと考えて、ｏを最大化するような要求をしがちである。すると当然ながらｆ＊は無限大になってしまう。
あるいはｆを考慮するとしても、ａ＞１なので、ｆが増大するとｉが急激に増加するのを知らないと、ｆ＊がかなり大きいほうに偏ってしまう。このようなメカニズムを利用部門が認識することが必要である。
（２）α増大（ｉ削減、ａ→１）の効果
最近は、情報システム部門の生産性向上が問題になっている。しかし、その生産性の尺度が明確でないし、その向上が定量的に評価されにくい。そのために、生産性向上に真剣に取り組まないとか、そのための投資が認められないようなケースも発生する。
それを解決する一つの手段として、標準的なシステム開発費用としてｆを設定することが有効である。これにより、情報システム部門は、α＝ｆ−ｉとして、世間一般の標準費用に比べていかに安価にシステムを構築するかに努力することになる。
ｉの減少あるいはａを１に近づけることは、単にαが増大するだけではない。図２のようにｆ＊ が右に移動することにより、より多くの利用部門の要求に応えることができるので、βも増大するのである。
３ ミクロαβモデルの応用
上述のように、ミクロαβモデルは定量的なモデルとして活用するのには不十分である。しかし、この考え方は多くの局面に活用できる。
３．１ システム規模の適正性判断の容易化
グループウェアの効果的な活用のためには、１人１台のパソコン普及が重要だといわれる。そうなっていない環境は、最適システム規模と比較して不足状態にあるといえる。また、最近のワープロソフトは豊富な機能を持ち巨大化しているが、大多数の人はそのうちのわずかな機能しか利用していないであろう。もしこれが社内開発のアプリケーションシステムだとしたら、かなりの過剰規模であるといえる。
上記のような環境整備や市販ソフトウェアとは異なり、社内で提案された個々のシステムの規模が、最適規模であるかどうかの判断は難しい。その理由には、費用対効果が不明確なこともあるが、システム規模での代替案がないことによることも多い。定食メニューの「松」「竹」「梅」のように、いくつかの案を提示し、梅→竹→松において、どのような機能が追加されると費用がどれだけ余計にかかるかが示されれば、よしんば定量的な信頼性は低くても、かなり判断が容易になる。
ミクロαβモデルの考え方を普及することは、自動的に複数案を検討することにつながる。そしてそれは、システム規模が適正かどうかの判断を容易にすることができるのである。
３．２ 過剰規模の抑制
ややもすると利用部門は、情報システム部門にアプリケーションシステムの機能について要求を出すだけであり、その効果についての責任を持つまでにはなっていない。そのため、β＝ｏでの要求になってしまう。また、情報システム部門は、利用部門の要求を無批判に受け入れる傾向がある。「利用部門主導の情報システム」がいわれてから久しいが、それが誤って受け止められていることもある。
ミクロαβモデルの考え方を利用部門が認識することにより、利用部門の責任が明確になる。それで、「なければ困る」要求と「あったほうがよい」要求を区別するようになり、過剰要求を防止することができる。
３．３ システム予算方式の改善
予算制度が不適切な場合は、予算作成時点では要求機能が不明確なままに、予算枠を確保するために予算要求をして、実施されないままに残ることがある。逆に、途中での機能追加が続出して予算オーバーになり問題が発生することも多い。
これを防ぐ一つの方法に、まず簡単なプロトタイプを作成し、その段階でαとβの関係を把握して、システムの機能を確定すればよい。あるいは、当年度では「梅」レベルを実施し、その結果を見て次年度以降に「竹」や「松」に進むようにしてもよい。
また、情報システム部門の生産性向上ツールのどは、利用部門の業務改善そのものに関係がないと見なされて予算での優先順位が低くなる場合もある。ところがこれは、ｉを下げａを１に近づけるのに必要な投資であり、前述のようにβを引き上げる効果を持つものである。ＬＡＮの敷設や１人１台のパソコン普及と同様な基盤整備として認識すべきものである。
４ ミクロαβモデルと各種開発技法との関係
ミクロαβモデルの考え方は、各種のシステム開発技法で取り入れることができる。
４．１ ウォータフォール型開発技法
多くの開発技法が出てきているが、大規模な安定した基幹系システムの開発には、古典的なウォータフォール型開発技法が適している。この開発技法では、要件を確認することが重要である。それは、とりもなおさずｆ＊ を決定することである。ミクロαβモデルが最も有効な分野である。
４．２ プロトタイピングやＲＡＤ開発技法
プロトタイピング開発技法やスパイラル開発技法では、最初の段階でη＝ｏ−ｉの大きいｆが重点的に開発される。ここでミクロαβモデルの利用は、どこで開発を打ち切るかの指標として有効である。
ＲＡＤ（Rapid Application Development）でも、開発期間という制約により、効果の大きいｆから優先的に開発される。とくに情報システム部門と利用部門が協同して開発するＪＲＰ（Joint Requirements Planning）／ＪＡＤ（Joint Application Design）では大きな効果がある[3] 。
４．３ ＥＵＣ、データウェアハウス
一般にシステムは、入力、中核、出力の分野に分かれるが、そのうち出力系は、利用者ニーズが多様であり変化が多く、開発検討時には仕様が固まらず、事後になってからの追加や改訂の要求が多い。しかも、ヒューマンインタフェースの要素が強いので、再利用が比較的困難であり個別開発になることが多い。
データウェアハウス（公開データベース群）を構築して、それ以降の出力（いわゆる情報系システム）を利用部門に任せることにより、基幹系システムでの規模を小さくすることができる。また、これを構築することにより、その後のｆの値が非常に小さくなるので、β＝ｏ−ｆを大きくすることができる。
おわりに
個々のアプリケーションシステムの開発運用において、その規模ｆ、効果ｏ、費用ｉの間には、 η＝ｏ−ｉ＝α＋β （α＝ｆ−ｉ、β＝ｏ−ｆ） の関係がある。ここで、αは情報システム部門の責任、βは利用部門の責任である。これをミクロαβモデルと呼ぶ。本稿ではこのモデルをベースにして、アプリケーションシステムの最適規模や、情報システム部門と利用部門の関係について考察した。
個々のアプリケーションシステムの開発運用において、その規模ｆ、効果ｏ、費用ｉの間には、 η＝ｏ−ｉ＝α＋β （α＝ｆ−ｉ、β＝ｏ−ｆ） の関係がある。ここで、αは情報システム部門の責任、βは利用部門の責任である。これをミクロαβモデルと呼ぶ。本稿ではこのモデルをベースにして、アプリケーションシステムの最適規模や、情報システム部門と利用部門の関係について考察した。
ミクロαβモデルは、利益＝効果−費用の式と、効果や費用がシステム規模により変化することから導き出しただけであり、あたりまえのことではある。それにもかかわらず、ここで提示した考え方は、現実の企業でのアプリケーションシステムを検討するときに有効である。定性的効果や戦略的効果をいかに定量的に把握するかを論じることは重要であるが、それ以前に、ここで示したような考え方を普及しておくことが必要である。
「システム開発は利用部門が主導で」とよくいわれるが、それがかえって過剰なシステムを構築することになる傾向がある。また、「技術先行ではなく業務先行で」ともいわれるが、それが情報システム部門の生産性向上を妨げ、結果として利用部門要求を抑えていることもある。このような副作用を回避するには、情報システム部門の任務αと利用部門の任務βを分離することが必要なのである。
当然ながら、情報システム部門／利用部門がセクショナリズムで自部門最適を図るのではなく、互いに協力し合って全体の最適化ｆ＊を図ることが重要である。しかし、ややもするとなれ合い的になり、改善追求が精神的なものになり、かえって問題が見えなくなることもある。その観点からも、ミクロαβモデルの認識普及は有用である。