政府IT予算の査定にも使われたノウハウを書籍化!見積書チェック、工数単価の妥当性検証、価格交渉のテクニックを体系的に解説したマニュアル書籍の決定版です
ブログ「ITコスト削減と価格交渉の勘所」

ITコスト削減の考え方

マクロ的なIT経費関連指標の活用方法

 売上げや利益といったマクロ的な企業業績とシステム経費の関係は、会社のビジネスモデルによって大きく異なってきます。このため、まったく関係ない業種の会社や全体の平均値と比較してもあまり有益な情報は得られません。  同じ業種の中でベンチマーキングを行えば、相対的な状況は理解できるかもしれません。ですが、日本ではベンチマーキングを積極的に行う習慣がなく、これを実施できるのは珍しいケースかもしれません。  当社もベンチマーキングを依頼されることがありますが、複数者の同意が得られずなかなかうまくいかないケースも多いのです。 ひどい場合になると、自社の情報は提供しないが、他者のベンチマーク結果を売ってほしいなどという要求もあります。情報を提供しない会社に対してベンチマーク結果を開示してよいという契約に同意する会社などあるはずがないことくらいくらい容易に想像できると思うのですが、実際にあった話です。  米国ではベンチマーキングは比較的メジゃーな手法ですが、コミュニケーションの概念が希薄な日本と、論理的で双方向的な米国の企業風土をよく示す事例といえます。  それはともかく、全社的な経営指標がまったく使い物にならないかというとそうではありません。自社のIT経費の指標がどのように変化したのかを知ることで、隠れたIT経費の基準を明確化することができます。 つまり過去のIT投資の意思決定は、明確な基準がなくても、何らかのマクロ的な指標と関連している可能性が高いのです。  マクロ関連指標には以下の4つの方向性でグループ分けできます。 .  ①資産全体とのバランス ②利益・経費とのバランス ③前年とのバランス ④その他指標とのバランス .  個別指標は以下のようになります。重要なのは絶対値ではなく変化とその理由です。 .

企業は情報システムにどの程度お金をかけているのか?

 企業は情報システムにどのくらいのお金をかけているのだろうか? これまで企業の設備投資の主役は、土地や建物、メーカーであれば生産設備などであった。しかし、最近では企業の設備投資の主役は土地や建物といった従来型の資産ではなく、ITにシフトしつつある。  弊社の調査では、3分の1の企業においてIT資産が従来資産の2割を超えている。なかには証券業のようにIT資産が従来資産を上回っている業界もある。  情報システム関連費用と財務関連指標との関係はどうなっているだろうか?企業の情報システム投資の売上高に対する比率は兵器1.2%(最大6.4% 最低0.02%)、販売管理費に対する比率は平均6.0%(最大11.7% 最低1.4%)であった。経常利益に対しては平均21.8%(最大65.5% 最低0.5%)となっている。  システムへの支出形態はシステムを自社で保有するか、アウトソーシングを多用するのかで大きく変わってくる。 アウトソーシングを行っている企業は徹底的にこれを活用する傾向が強く、資産に対すつ費用の割合は圧倒的に高い。 逆にシステムを自社で保有している企業の場合、資産に対する費用割合の平均値は78.6%であった。大雑把にいうと、システム構築費用に対して80%程度の運用保守費を支出していることになる。 .

情報システムの本質的な役割はほとんど変化していない

 情報システムは時代によってその位置付けが変化してきました。大きく分けると以下の4つのフェーズがあります。◇1970年代  企業経営において本格的に情報システムが使われたのは1960年代以降のことです。金融機関における決済処理や一般企業の各種伝票処理や統計処理など、大量のデータを取り扱う組織が、人海戦術的な作業に代わって大型コンピュータを導入したのがビジネスにおけるシステムの本格活用のはじまりです。当時は汎用機を中心としたホスト・コンピューティングが主流でシステムの価格も高価でした。◇1970年代~80年代 1970年代には企業情報システム(MIS:Management Information System)という言葉が普及し、システム化の対象が特定業務だけでなく全社的なマネジメント業務にも広がってきました。大規模小売店舗におけるPOSシステム、航空機予約システム、メーカーの販売店管理システムなどより戦略性の強いシステムが登場してのもこの頃です。 1980年代に入ると、オフコンやUNIXサーバーの普及が進み、いわゆる「ダウンサイジング」が進められるようになりました。価格性能比の大幅な向上によって、中堅規模以下の企業においても情報システムの導入が容易になりました。在庫管理システムや業務支援システムなど、業務プロセスを最適化するという一歩進んだシステムの活用方法も普及し始めました。◇1990年代 1990年代はパソコンの急速な普及と基幹業務への進出によって、情報システムの導入が当たり前となってきた時代です。ERPやCRMなどの戦略的なシステムの普及が進み、企業価値の向上そのものにITが寄与するとの見解も多く見られるようになってきました。 ◇現在 2000年から市場が急拡大したインターネットによって、システムの通信環境は劇的に変化しました。現在ではほとんどのシステムがインターネットの利用を前提としています。さらにハードウェアの劇的なコストの低下によって、大規模なデータセンターの運用が可能となってきたことから、クラウド・コンピューティングという、これまでのアウトソーシングの概念を大きく超えるコンセプトも登場しました。またネット上に分散する情報を大量処理して新しい情報を引き出す、ビックデータと呼ばれるソリューションも注目されています。  確かに劇的な進化を遂げた情報システムですが、よく見てみると、その本質的な役割はあまり変化していません。かつて情報システムは人工知能的な方向に進化すると思われていましたが、現在でも情報システムが得意としているのは大規模なデータ処理です。扱うデータの量と処理能力の向上によって、より広範囲な問題に対処できるようになりましたが、あくまで広がっているのは横方向であって、質的な変化は起こっていないのです。  このことは情報システムを上手に活用する上で非常に重要な考え方です。情報システムは、今も昔も大規模なデータ処理に向いたツールなのです。情報システムを導入したものの思ったほど効果が得られないと不満を持つ企業は意外と多いのですが、その背景には情報システムに対する根本的な誤解が存在している可能性があるのです。

システムの処理能力は向上していない

 IT(情報技術)はすさまじいペースで進歩しているといわれてきました。この業界にはムーアの法則という有名な理論がありますが、これはCPUの処理能力が指数関数的に増加しいくというものです。90年代初頭と比べると現在のCPUは数千倍の処理能力を持っていますし、価格が安くなっているので並列処理を安価に実現できるようになりました。 ですが、利用者が体感できる業務処理時間はあまり短縮されていないというのが現実ではないでしょうか?少なくともCPUの処理能力のように数千倍も能率が向上したなどということはありえません。  図は弊社が調査した大規模システムの処理能力分布のデータです。横軸がCPU数、縦軸がCPUあたりのトランザクション数を示しています。  CPUの数を増やして並列処理をすれば全体の処理能力は劇的に向上しますが、CPU1個あたりの処理能力が増えるわけではありません。多くのシステムが2~5トランザクション/秒という処理能力の範囲に収まっています。 トランザクションは利用者から見た業務処理の1単位ですから、1秒あたりのトランザクション数は利用者の体感的な処理能力といってよいでしょう。  CPU1個あたりのトランザクション数というのは、実は10年以上前からほとんど変わっていません。CPUの処理能力は何十倍、何百倍にも増加しているのに、CPU1個が処理できるトランザクション数(ユーザーから見た処理の1単位)はほとんど増加していないのです。 利用者から見れば、情報システムが処理できる能力はほとんど向上していないということになります。もちろんCPUのコストは安くなっていますから、CPUの台数を増やすことで全体の処理能力を向上させることはできますが、効率という観点では横ばいといってよいでしょう。  CPUあたりのトランザクション数が伸びないのは、ミドルウェアやOSの高機能化やアーキテクチャの多層化などが背景にあると思われます。 このように考えると、情報システムにできることというのは、実はそれほど進化しているわけではないということが分かります。ITに過大な期待は無用なのです。

信頼性が高いシステムは高価なのか?③

 前回は信頼性を向上させる最大の要素はハードウェアの冗長化であるというお話をしました。コストという観点では、冗長化のために増加したハードウェアの分しかコストは増えないことになります(厳密にいうと冗長化ソフトウェアの購入費が上乗せされます)。  ではソフトウェア(アプリケーション)の部分は信頼性や可用性とは無関係なのでしょうか?そんなことはありません。 信頼性や可用性の指標であるMTBF、稼働率はソフトウェアにも関係してきます。もっとも大きな要因はソフトウェアのバグです。バグがあるとシステム障害が発生し、MTBFや稼働率が低下します。ソフトウェアに存在するバグを除去するためには、テスト工程に時間をかける必要が出てきます。 ソフトウェアに起因する障害をゼロにしたければ、数学的には無限大の時間をテスト工程にかけなければなりません。現実的にはそれは無理ですから、想定されるMTBFや稼働率に合わせて、ある水準で妥協するということになります。 またソフトウェアの品質が低くても、運用の要員を増やし、事前に故障に対処するというやり方を取れば、ソフトウェアの品質に関係なく、MTBFや稼働率を向上させることが可能です。もちろんそのためには運用要員の追加コストが必要となります。  整理すると、信頼性や可用性が高いシステムは高価であるというのは事実なのですが、結局のところ、それらを表す指標であるMTBFや稼働率の数字をいくらにするのかという問題に帰結することがわかります。  MTBFの数値を限りなく無限大にしたければ、あるいは稼働率の数値を限りなく100%にしたければ、それこそ無限大のコストがかかります。逆にある程度の水準で妥協できるのであれば、かなり安く済むわけです。  ベンダーは、想定される信頼性や可用性の数値を複数提示し、どの水準に設定するにはどのような措置を実施するのか?そのためにはどの程度、何にコストがかかるのかを明確にすべきです。発注側はそのような情報を求めていくべきでしょう。  ここでは触れていませんでしたが、一般的に信頼性といわれている概念には、データの保全性というものもあります。これは障害があった時にデータが守られるかどうかという指標です。これは信頼性や可用性と密接に関係しますが、厳密には別の概念になります。保全性を向上させるためには、別な手法とコストがかかります。 高い信頼性と可用性を求める企業の多くは、高い保全性も求めますが、あくまで別の概念であることを理解する必要があります。両者が混同された議論は避けるべきです。

信頼性が高いシステムは高価なのか?②

 前回は、信頼性は通常、MTBF(平均故障間隔)で表現され、可用性は通常、稼働率で表されると説明しました。ではMTBFと稼働率とコストにはどのような関係があるのでしょうか?  システムのMTBFと稼働率を低下させる最大の原因はハードウェアの故障です。ハードが止まってしまうとこれはどうしようもありません。ハードウェアの信頼性を向上させるには2種類の方法があります。ひとつは信頼性の高い製品を使用する。もうひとつは、ハードウェア構成を冗長化して故障しても動作を継続するようにするということです。 最近ではハードのコストは劇的に安くなっていますので、同一のハードウェアをいくつも用意して、ソフトウェア上で共有し、いつ壊れてもいいようにしておくという考え方が主流です。Googleのデータセンターでは何十万台というサーバーをリアルタイムで監視し、故障が発生した、あるいは故障が発生しそうなサーバーのデータは自動的に他のサーバーに移管し、ハード自体は修理などせず放置するという徹底的に合理的な手法が採用されています。  信頼性と可用性を上げようと思った場合には、少なくともハードウェアのコストが増加することは明らかとなりました。ですがハードウェアのコストは全体からみれば大したことはありません。ハードの故障という観点からは、信頼性や可用性とコストはそれほど高い相関性はないということになります。  ではソフトウェアや運用面ではどうでしょうか?これについては次回にお話します。

信頼性が高いシステムは高価なのか?①

 システムの信頼性について議論するためには、まずシステムの信頼性についてきちんと定義しなければなりません。 IT業界は非常に言葉が乱れていることで有名です。「信頼性」という言葉に加えて似たようなニュアンスで「可用性」という言葉も使われています。困ったこ とに、これを使っている技術者がその意味を知らないでしゃべっていることも多いのです。これではまともに議論などできるはずがありません。  このほかにもIT業界には意味不明の外来語が氾濫し、正確な定義がなされないままテキトーに使われています。IT業界が他の科学技術分野に比べて一段低くみなされがちなのは、こういった言葉使いのテキトーさが大きく影響していると思われます。  この件に限ったことではありませんが、システムは「テクノロジー」なので抽象的な表現は必要ありません。システム会社の担当SEに対して何か質問して、抽象的な返答しか帰ってこないようなら、その SEの能力を疑った方がよいでしょう。  話がそれましたが、信頼性は通常、MTBF(平均故障間隔)で表されます。故障する間隔が長ければながいほど信頼性が高いという意味です。可用性は通常、稼働率で表されます。理論的に設定された稼働時間のうち、実際何%稼動させるかという指標です。100%に近い方がよいシステムです。ちなみに可用性という正式な日本語はありません。英語のavailability の当て字です。  信頼性が高いシステム、あるいは可用性が高いシステムが高価なのかという議論は、価格とMTBFに相関があるのか?価格と稼働率に相関があるのか?という論点で検証を進めなければなりません。 具体的には、MTBF性能を向上させるためには何をしなければならず、それがコストにどのように跳ね返ってくるのかを明確にする必要があります。同じように稼働率を高めるためには何をしなければならず、それがコストにどのように跳ね返ってくるのかを明確にしなければなりません。  発注者は必要となるスペックをきちんと要求する権利がありますから「ウチのシステムは信頼性が高いのでコストがかかるんです」などとテキトーなことを言っているシステム会社には、きちっとした科学的、技術的な説明を求めることが大切です。 →次回に続く

システムの規模は土地でいうことろの「坪数」と同じ

 前回は、システムのコストは、システム規模との相関性が高いことを説明しました。規模が大きいシステムはコストが高くなりますし、規模が小さいシステムはコストが安く済みます。これは他の諸条件よりも大きな要因です。規模さえ決まれば、おおよそのコストは決まったようなものなのです。 したがって、情報システムのコストを見積もったり、ベンダーから提出された見積もりを検証したり、さらにはベンダーと価格交渉するような場合には、まずシステムの規模を特定することが重要です。 いってみればシステムの規模は、土地でいうことろの「坪数」や、建築物でいうところの「延床面積」と同じなのです。土地ならば価格を坪数で割って1坪あたりの単価を計算し、高いか安いかという比較を行っているのに、情報システムではなぜかこのような作業が行われてきませんでした。 10坪の土地と1000坪の土地では値段が違って当たり前です。ベンダーに発注するシステムの規模がどの程度なのかを特定できないと、そもそも価格が高いのか安いのか比較することは不可能なのです。 システムの規模をあらかじめ特定しておくことはベンダーにとってもメリットがあります。規模について双方が合意していれば、そもそもの設定条件がブレることがありませんから、ベンダー側も安心して見積もりを行うことができます。 システムの規模を数値で表しておくことは、すべての基本なのです。では次回以降は、具体的な規模の表し方について説明していきます。

システム規模が大きくなるほど、オーバーヘッドも増える

 前回のコラムでは、システムの規模とコストには以下のような関係があると説明しました。   システムのコスト=A×(システム規模)^B  この式の中で、Bの値は通常1以上で2以下の数値になることが知られています。つまり、システムの規模とコストは単純な比例関係ではありません。システムの規模が10倍になると、システムのコストは10倍以上になり、規模が大きくなればなるほど、加速度的にコストが増えてくるのです。  ではなぜそのようなことが起こるのでしょうか?それはシステム開発を担当するエンジニアのコミュニケーションに起因します。 システムの規模が大きくなると、ひとつのチームですべてを担当することはできず、チームごとに担当を分けることになります。あるチームが担当した部分で修正が入った場合には、他のチームに影響する部分を修正するため、修正内容を全員でシェアする必要が出てきます。 数チームであれば問題ありませんが、巨大システムになると、多対多のコミュニケーションが発生することになり、そのオーバーヘッドが無視できない水準になってきます。  また実際にバグが発見された場合の対処についても、規模が大きいプロジェクトの方が手戻りなどのムダが増えてきます。これによって開発効率は大きく下がることになります。  規模が大きいほど作業効率が低下することを示している上記のモデルはこういった現場の状況を反映したものなのです。

システムのコストは規模の累乗に比例する

 システムの規模とコストにはどのような関係があるのかについては、これまで様々な研究が行われきました。現在では、システムのコストは、システム規模の「累乗」に比例することがほぼ明らかになっています。式で書くと以下のようになります。   システムのコスト=A×(システム規模)^B  システムのコストが、システム規模に対して、なぜ累乗の関係になるのかついては、おいおいご説明するとして、ともかく規模とコストには明確な相関があることは科学的に明らかにされているのです。 システムのコストを評価する際には、まず大事なこの事実からスタートすることが大切です。  システムのコストは基本的に規模の累乗に比例します。ただ、システムがどのような環境に置かれているのかによって、AやBの値が変わります。 つまり「システムのコストは条件によっていろいろだ」という話は、実はAとBの値が変化すると言っているに過ぎないのです。根本的なコストの構造は、どんなシステムであっても上記の式から逸脱することはありません。

Copyright © 株式会社ストック・リサーチ All Rights Reserved.
Powerd by WordPress & BizVektor Theme by Vektor,Inc. technology.