なぜ情報化投資は
初期計画より増えるのか?
――システム部門Q&A 第2回
木暮 仁
2003/12/2
多くの情報化投資では、計画値と実行結果の間に開きが出る。一般に計画値より実際の費用のほうがふくらんでしまう。この理由はなぜなのか。そしてこうした事態にいかに対処すべきなのか。(→記事要約へ)
| 質問 | 中堅企業の経営者です。最近の情報化投資では、起案時の計画と実現結果の間に大きな違いが目立つようになりました。情報化対象が複雑になったからだとは思いますが、理由はそれだけなのでしょうか。経営者としてどのようなことに留意するべきでしょうか。 |
| 「222の法則」と「2423の法則」 |
- - PR -
ご質問の状況は、法則になるくらいに普遍的なものですし、これらは数十年前にも指摘されていたことですので、情報システムの本質的特性だともいえます。……といっても、解決にはなりません。
このような事態に陥るのは「情報システム部門やベンダのSEの能力が低いからだ」と一概にはいえません。昔はそれが原因だったことも多かったのですが、近年は見積もりの技術も整備され、関係者の経験値も高くなってきました。昔のような情報システムを対象にするならば、かなり精度の良い見積もりができるでしょう。
ご指摘のように、情報化対象が複雑になったのが原因ですが、その複雑性とは情報システムの複雑性というよりも、情報システム以外の要因の影響が従来に比べて非常に大きくなったからなのです。例えば、給与計算や請求書発行のシステムでは、その処理ルールは比較的明確ですし、関係者との調整も大したことではありませんでした。しかるべき能力を持つ技術者が適切な行動をすれば、計画とほぼ一致した結果になります。
ところが、近年の情報システムは多くの関係者を持つシステムが多くなっています。クレジットカードや顧客カードなどの発行システム(ここではカードシステムといいます)を例に挙げて説明しましょう。
| 非情報系活動から続出する“要望” |
カード発行システムの目的は明瞭です。顧客志向マーケティングを実現するために、顧客情報の入手・分析を円滑にすることにあります。提案書には、顧客情報の重要性や、その分析による期待などが列挙されており、それに掛かるコンピュータ費用や情報システム開発費用が示されています。その費用は妥当なものであり、効果は定量的にはあいまいさがあるものの、定性的あるいは戦略的な効果は高いでしょう。本件は承認され、情報システムの開発に着手します。情報システムを構築する一連の作業を、ここでは「情報系活動」と呼びます。少なくとも当初は情報系活動は比較的順調に進みます。
カードシステムでは顧客加入数を多くしないと意味がありませんし、そのカードの取扱店も多くする必要があります。このような活動を、ここでは「非情報系活動」といいます。初期の情報系活動によりカードの仕様が固まりますと、これらの非情報系活動が精力的に開始されます。
ところが、カード顧客の獲得をする段になってから、申込書に多くの項目を記入をしたりプライバシーに関する事項の記入を求めるのでは、なかなか加入してくれないので、思い切って決済や通知に必要な項目だけに絞ろうという意見が強くなります。顧客獲得数の増大が目的となり、当初計画していた顧客特性に応じたマーケティングの展開という目的が怪しくなります。
また、取扱店になってもらうために、このシステムから得た情報を、取扱店側に提供することが求められます。これは当初から計画されており、標準的なものが設計されてはいました。ところが取扱店のニーズは多様です。標準以外の要求が続出します。ある店では「紙の帳票がよい」というし、ほかの店では「オンライン検索にしたい」といいます。この担当者にすれば、取扱店確保が最重要目標ですので、それらの要望を実現するよう情報系活動に圧力を掛けます。
| 変更と期日厳守を迫られる情報系活動 |
人間の感覚では、カードの記載項目が変更になったり出力帳票が多くなったりしても、大して影響はないように思いがちですが、情報システムにとっては、当初の設計と異なるということは、データベースの改訂やモジュール体系の改訂など、基本から変更しなければならないことが起こり得るわけです。その場合、時間や費用が掛かるからと“姑息なパッチ当て”で逃げたりすると、情報システムは不必要に複雑なものになってしまいます。
このような変更により開発期間が遅れますが、すでに実施期日を顧客や取扱店に公表しており、営業上も困るし信用問題でもあるとの理由で延期要請は拒否されます。それで、十分なテストもせずに本番突入となりますが、その結果はトラブルの続出となります。
こうした事態になると、情報システムを円滑に稼働させることが唯一の目標となり、初期の目的は忘れられてしまいます。カードの名義人が父親で実際の利用者は母親や息子であると、高齢の男性が婦人下着を購入したり、休みのたびに数千キロのドライブを楽しむといった分析結果になりますが、もはやそれを怪しむこともなくなります。
費用の面でも、非情報系活動は重要です。多くの社員が本来の業務を縮小して顧客や取扱店の獲得キャンペーンに従事します。顧客加入数を増やすために計画よりも多くのサービスが必要かもしれません。取扱店からボーナスや仕切り価格変更の要求もありましょう。このような見えない費用は、提案書での情報系費用を上回ることもありましょう。
| 情報化投資ではなくプロジェクト投資なのだ |
ややもすると経営者は、カード「システム」という言葉により、これが情報系活動であり情報システム部門の仕事だと考えがちです。それで、情報化の費用対効果について情報システム部門を非難したりします。ところが近年の情報化投資では、情報化そのものの投資であるよりも、経営戦略実現のプロジェクト投資の一部分であることが多く、しかもその成否は非情報化活動に懸かっていることが多いのです。
また逆に、非情報系活動を重視するあまり、その要求を迅速に実現するのが情報系活動であり、情報システム部門の任務であると決め付けることもあります。原則的にはそうかもしれませんが、ものには順序があります。システム開発は人間と異なり、融通が利きません。開発途中や実施直前になって基本的な事項に変更が起こると、常識では考えられないほどの労力や費用が掛かります。要求分析段階の5分間の事項が実施後では1年規模の大改造になることすらあるのです。先に「222の法則」や「2423の法則」を紹介しましたが、これらの原因は最初の計画段階での不徹底が元凶であることが多いのです。
しつこいですが、情報化投資ではなくプロジェクト投資であるとの認識を持ってください。先に顧客志向マーケティングを実現するために、顧客情報の入手・分析を円滑にすることが目的だと述べましたが、もっと根本的な目的は顧客満足の実現や顧客の固定客化にあります。その目的のためには、多額の経費を掛けて高齢男性が婦人下着を買うような統計資料を得る以外にも、多くの手段がありましょう。カードシステムの構築は、それらのプロジェクト中の1つの選択肢にすぎません。また、カードシステムが必要だとしても、それを自社開発するのか、ほかのクレジット会社のシステムを利用するのかなど多くの選択肢があります。
また、自社で開発するにしても、情報系活動と非情報系活動の両方をマネジメントすることが重要です。経営者自ら参画してリーダーシップをとることができればよいのですが、そうでなくとも、その両方に責任を持つプロジェクト責任者を明確にするべきです。
| 第1回へ |
第3回へ
|
|
|
この記事に対するご意見をお寄せください |
managemail@atmarkit.co.jp |
■要約
システム開発プロジェクトでは、初期計画値と実際に掛かった費用との間で、かなり開きが出る。一般に、初期計画より実際の費用のほうがふくらむことが多い。こうした現象を端的に表した「222の法則」「2423の法則」というものがある。「222の法則」とは「情報システムの開発では、計画の2倍の費用と2倍の期間がかかり、計画した2分の1の機能しか実現できない」というもので、「2423の法則」とは、「契約時の規模・金額は2だったのに、要求分析の段階で4の規模になってしまった。ベンダが追加費用を要求してもユーザーは2しか払わないという。結果として3の費用で4の規模のシステムを開発したが、ユーザーは費用が2→3になったことに不満を持ち、ベンダは3の費用で4の規模をやらされたことに不満を持つ」というものだ。
こうしたことが起こる理由の1つには、情報化の範囲が広くなりシステムが複雑になったことが挙げられる。しかし現在は見積もり手法や開発手法も上がっているので、しかるべき技術者が適切な行動をとれば、計画値と実費の間でそれほど大きな開きは出てこないと思われる。
そこで何が投資額を上げているかといえば、システム開発そのものではなく、システムを利用する側のビジネス的な活動に起因していることが大きい。クレジットカードシステムを例にとると、「登録顧客数を増やそう」「契約店に情報を渡そう」などといった活動が仕様変更に影響を及ぼし、なかなかシステム要件が固まらず、工数も費用も掛かってしまうことになる。もう1つの問題は、こうした開発以外の作業も「システム部門の責任」として非難する経営者が存在することだ。
この場合、「情報化投資」ではなく「プロジェクト投資」という意識を持つことが必要である。情報化投資=システム開発に掛かる費用ではなく、経営戦略実現や建て直しを図るための「プロジェクト投資」という認識から、実際の開発作業+開発以外の作業も含めて1プロジェクトとして投資を考えること。なぜなら情報化の成否は、開発作業以外のビジネス上の活動に懸かっているからだ。
| profile |
| 木暮
仁(こぐれ ひとし) 東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士(情報工学)、中小企業診断士、ITコーディネータ、システム監査、ISMS審査員補など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」「情報システム部門再入門」(ともに日科技連出版社)など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している |
システム部門Q&A バックナンバー
- 第1回 IT書籍やコンサルタントが“使えない”理由
- 第2回 なぜ情報化投資は初期計画より増えるのか?
- 第3回 社内から必要とされるITスタッフを育成するには
- 第4回 IT投資効果の算出法は本当に役に立つのか?
- 第5回 コンサルタントを賢く活用する秘策
- 第6回 ERPのカスタマイズを最小限に抑えるには
- 第7回 バランスト・スコアカードで業績が上がるか?
- 第8回 システム部門縮小化に打ち勝つ!
- 第9回 情報システム部門の生産性が上がらない理由
- 第10回 情報システム部門を戦略部門化できるか?
- 第11回 セキュリティ対策、社内の協力を仰ぐには?
- 第12回 RFPの作成方法が分からない!
- 第13回 ここまでやればRFP作成工数は削減できる
- 第14回 データウェアハウス中心アプローチで問題解決しよう
- 第15回 パートナーベンダの見直しは慎重に!
- 第16回 システム開発におけるユーザーニーズは絶対か?
- 第17回 健全なEUC推進に適した組織とは?
- 第18回 素人IT部長に望むこと
- 第19回 素人IT部長に望むこと(2)
- 第20回 会計原価を損得計算に使うな!
- 第21回 会計原価を損得計算に使うな!(2)
- 第22回 情報共有化の障壁を突き崩せ!
- 第23回 なぜ、ITコンサルタントに依頼が来ないのか?
- 第24回 企業合併でシステムが止まらない方法教えます!
- 第25回 素人CIOとの上手な付き合い方とは?
- 第26回 ユーザー企業のIT部員育成はどうすればよいのか?
- 第27回 社内用語・概念を整理する「ユーザー辞書」は役立つ
- 第28回 いろいろある基準をどう考えて、どう使うか?
- 第29回 中小企業がERPパッケージを成功させるには?
- 第30回 オープン化とERP導入は今年中に終わらせよう!
- 第31回 部門のエゴによるデータ公開反対運動を回避せよ
- 第32回 新技術ラッシュをいかに乗り切るか?
- 第33回 文系学生はIT関連科目で何を学べばよいのか?
- 第34回 日本版SOX法はIT部門にとって脅威か機会か?
- 第35回 行政のセキュリティ投資はどうするべきか?
- 第36回 オープンシステム移行による弊害を断罪する
- 第37回 IT部門が頼りなくなった原因はなんだ?
- 第38回 ユーザーが満足する提案ができません
- 第39回 経営者が可視化を理解できないのはどうして?
- 最終回 どうしたら、しこりなくローテーションができるのか?
| 「システム部門Q&A」バックナンバー |
|
ホワイトペーパー(TechTargetジャパン)
|
|

