
IT化と投資の
“正しい”関係とは?(中編)
――何かがおかしいIT化の進め方 第12回(3/3ページ)
公江 義隆2004/12/2
| 信念の実現や限りない向上を目指すシステムが、 日本企業の真の戦略的テーマ? |
- - PR -
「企業の最終的な目的である経営理念の実現には企業の存続が必要であり、存続のために利潤の追求が必要。そのために必要な適正レベルの投資を行う」「投資と効果のバランスや競争相手との関係など、相対的な対比を基にした合理的な概念が投資問題にも適用される」というのが、一般的な教科書の投資に関する内容である。
しかし、世の中には優れたリーダーの理念に基づく、長年にわたる飽くなき施策の実行と問題追究の結果が、他社にまねのできない企業文化、組織の暗黙知として力の源(コア・コンピタンス)となり、これが結果的に“他の追随を許さない”利潤を生み出す原動力になっているケースがある。
業務とシステムのレベルアップをたゆまず繰り返して積み上げ、これを好業績に結び付けている組織がある。組織全体があるレベルに到達すれば、それを踏み台にして見えてきた次の挑戦レベルをとらえ、その実現への具体策が考えられるようになる。次の行動計画を支えるため、情報システムのレベルアップも必須になる。このプロセスを続けてゆくことが絶対的な“善”という組織文化になっているから、条件の許す限り前へ前へ進める行動が取られる。このような繰り返しの長年の蓄積結果が、圧倒的に秀でた組織の力と価値観を作っている。しかし、このような実例がすべての会社にあるわけではなく、IT分野に存在することは極めてまれである。「人の能力向上に限りはない」と考えるなら、ITの関係ではナレッジマネジメントのかかわる部分にその可能性があるように思う。
このような理念・信念に基づく行動を事前に合理的に説明・評価することは大変難しい。科学的といわれる手法による合理的評価や判断、あるいは通常に使われる“戦略的”などという言葉を超えた、勘と感と肝の世界である。評価の対象になるとすれば、次にやろうとする施策内容の“質の高さの妥当性”だろう。その問題に直接関与するリーダーの見識と、幾多の困難を乗り越えて長年にわたり継続できるか否か、リーダーの気力が成否の決め手になる。
| インフラ投資 |
ここまで述べてきたことは、効果を生み出す業務改革テーマ(アプリケーションシステム構築)に対する投資についての話である。通信ネットワークや、コンピュータのハードや基本ソフトや共用ソフトといった、それ自体では効果を生まない投資に対してはどのように考えればよいだろうか。
「いまやコンピュータやネットワークは企業にとって必須のものである。従って必要コストと考えるべきだ」という意見も一部にはある。しかし、これが「なぜ必要なのか」「内容やコストは妥当なのか」という評価や、意思決定する人の問いに対する答えになるだろうか。「PCの単価が××円で総数が××台、掛け算して……、サーバが××円……」といったことは求めている答えではない。「そのサーバとかいうものは、何のために何に使うのか」に始まり、「なぜ? 何のため?」の疑問がエンドレスに続くことになるだけである。
インフラ費用は受益者となるアプリケーションシステムが負担するべきなのである。各アプリケーションの負担額の総計がインフラの総コストとバランスすることが必要条件である。それ以外にはインフラのためのお金の出所はないし、こうしておかないと、企業内でほかの投資との間で投資配分の公正な比較評価が難しくなる(※3)。
| (※3) 例えば、交通物流体系の問題を考えてみる。土地の取得費用から道路建設・管理費用などのインフラ費用、さらに公害対策費まで税金で賄う高速道路+自動車(トラック)輸送体系と、インフラ費用をはじめすべての費用負担を鉄道会社に負わせる鉄道輸送の体系との、社会システムとしての公正な比較評価はできるであろうか。その結果、将来の方向を見誤ることにはならないのだろうか。 |
この問題の構造を少し掘り下げて考えてみることにする。もし、唯一のアプリケーションシステムしかなく、アプリケーションシステム構築とインフラ整備を同時にやるのなら話は簡単なはずである。インフラへの投資+アプリケーションシステム構築のための投資が投資総計になり、これをベースに投資評価をすることができるので複雑な問題にはならない。
中期計画期間などある期間について、この期間にアプリケーションシステム全体が発現する効果予想と必要とするIT資源と、これに必要なインフラの計画といった見方をすれば、上のシステムのケースと同じ考え方が取れる。大枠の計画をこのような考え方で押さえておくことをお勧めする――図「情報化のグランド・デザイン(中期構想)と検討プロセス」。
![]() |
インフラ投資の問題を複雑にしているのは、以下のような点であろう。
- インフラは、複数のアプリケーションシステムが共用する
- これら複数のアプリケーションシステムは、時期を違えて構築されるため、インフラに求められる機能、性能(容量)が時間的に変化する
- インフラにも追加更新投資が発生するが、引き金となるアプリケーションシステムはあっても、必要となる対象を特定できない(追加投資すべてが引き金システムのためではない)
しかし、こんな問題はIT・情報システム固有の問題だろうか。社内を見渡せばほかの分野にも同じ種類の問題は散在する(※4)。IT・情報システム問題の特異性を主張する(※5)より、既知の類似問題を探して「あの問題と同じことです」といって、その問題の扱い方に便乗する方が、はるかに楽に理解・納得が得やすい。
| (※4) 工場では原材料を加工し、あるいは部品を組み立てて製品を作っている。これらの製造ライン(製造工程・設備)は一般的には製品ごとに作られていて、同じ敷地の中に複数の製造ラインがある場合が多い。 一方、これら製品を作るための製造ラインの設備以外に、製造プロセスの中で必要な加熱用の蒸気を作るボイラー設備、冷却水を作る冷凍機の設備、自家発電設備など、複数の製造ラインのための共通の設備がある。これらの設備投資額や運転費用は結構な額になる場合が多い。これら設備の償却費や運転費用は、用役(ユーティリティ)費の名目で製品原価に算入される。そのうえで製品は利益を出さないといけない。製造のためのインフラ費用は必要経費といって原価算入しなければ、利益率の大変高い製品に見えて判断を間違えることになるし、これら用役設備のための費用の捻出先もなくなる。 これら用役費の負担を各製品にどのように配分するかは、固定費や間接費の配分問題と同様、現実の場ではいろいろ議論のある重要な問題である。製品別の製造費用の比率で、発生する用役コスト全額を振り分けるといった大ざっぱなやり方がされていた時代もあるが、製造部門、用役管理部門のコスト削減の努力結果が反映されるような管理の仕組みが考えられている。 部品表や、製品を1単位作るのに必要な原材料の量を表す原単位表などと同様に、製品1単位作るのに必要な蒸気量や、冷却水量、電力量などを表した用役原単位や、標準単価を設定している会社もある。 |
| (※5) ベンダや特にコンサルタントは、わずかな違いでもこれを強調する傾向が強い。ほかの方法、従来の問題とは異なる新しいモノだという方が商売上有利と考えているのだろうが、私などは「従来ある××と基本的に同じですが、××だけが新しいアイデアの部分です」などといわれた方が、ずっと分かりやすいし安心もできる。訳の分からないものは買わないことにしていた。 |
すでに子会社化などで実態が先行しているケースも多いと思うが、このインフラ投資の問題構造を次のような例から考えてみてはどうであろうか。
○インフラのみを計画・管理運営する(バーチャル)会社を考えてみる
この会社はディスク容量、データ通信量、CPU時間などに、市場価格以下であることを必須の条件とする単価を設定し、各アプリケーションシステムが使用したIT資源の量に応じて、アプリケーションシステムを運営する部門から対価を得る。単価は短期的には赤字・黒字が発生しても、ある期間を通じて見た収入と支出のバランスが取れる値とする運営をする(利益が出るような単価設定をすると、アプリケーションシステム投資の評価が厳しくなり過ぎ、機会損失を生じる。また赤字が出る単価設定はアプリケーション評価が甘くなり、無駄な投資が増えることになる)。
必要なサービスレベルを維持して、市場価格よりどれだけ安い価格でIT資源をアプリケーションシステムに提供できるかが、この(バーチャル)会社の存在価値である。「IT資源の需要と供給のバランスをいかにうまく取るか」「設備の稼働率をいかに高め安定させるか」が計画と管理のポイントになるはずだ。その気になれば、新規のアプリケーション構想をはじめ社内の動きを早期に知ることができるし、利益を出さなくてよい分だけ単価を下げられるという立場にある。外部業者のスケールメリットを生かした価格との競争である。このコスト競争に勝てる見込みが立たないなら、アウトソーシングを考えるべき問題になる。
このような(仮定)条件で、この会社は、何をどうすべきかを考えてみれば、インフラの問題の構造ははっきりする。投資をどう評価すればよいかはおのずと明確になる。これを社内の既存のほかのルールと整合性を取った手順にまとめればよい。インフラの投資評価の扱いは、社内の経費処理のルールや仕組みとワンセットで考えるべき問題だ。「以前からある××の問題、よくご存じの××と同じ考え方です」といえることが鍵になる。最後の仕上げは、総論でのこの考え方・仕組みを、経営層や関係者の理解を求めるための働きかけと、これを踏まえた社内オーソライズ(公式ルール化)である。総論の理解なしに、いきなり各論を出すのでは最初から負け戦になること必至だ。受け身になれば、何をいっても言い訳にしか受け取ってもらえない。
なお、当然のことながら、アプリケーションシステム側(個々のアプリケーションシステムの投資評価)では、このインフラの使用料(インフラ使用の対価)をコストとして計上し、効果はその分だけ差し引いて投資評価をしなければならない。
◇
後編では、評価の難しい再構築やソフト更新の問題、情報セキュリティ投資の考え方、などについて紹介する。
| 3/3 | 第13回へ |
| INDEX | |
| 何かがおかしいIT化の進め方(12) | |
| Page1 結果の不確定性というリスク IT投資評価とBSC、そもそもがITへの投資でなく業務プロセス改革への投資 |
|
| Page2 戦略的システム投資と効率化システム投資という分類は…… 不確定性・リスクの高い問題の構造 |
|
| Page3 信念の実現や限りない向上を目指すシステムが、日本企業の真の戦略的テーマ? インフラ投資 |
|
| profile | ||
|
何かがおかしいIT化の進め方 バックナンバー
- 第1回 世評やベンダの意見に踊らされていませんか?
- 第2回 IT化に対する関係者の不安や不満を取り除くには
- 第3回 プロジェクト・チームの編成で失敗していませんか
- 第4回 IT部門の存在価値は“全社最適”にあり
- 第5回 全社IT最適化のカギは「データ体系の統一」
- 第6回 優秀なスタッフを育てる職場環境とは
- 第7回 仕事への取り組み方は最初の数カ月で決まる!
- 第8回 ブレークタイムに“設計思想”を語り合おう
- 第9回 “誰にでもやさしい”ITは良いことなのか?
- 第10回 ブレークタイムでの話題−製品と情報化のコンセプト
- 第11回 IT化と投資の“正しい”関係とは?(前編)
- 第12回 IT化と投資の“正しい”関係とは?(中編)
- 第13回 IT化と投資の“正しい”関係とは?(後編)
- 第14回 ITの動向や他社の状況を、気にし過ぎていませんか?
- 第15回 いまのIT組織でいつまでやっていきますか?
- 第16回 続・いまのIT組織でいつまでやっていきますか?
- 第17回 理想的な上司と部下の関係とは――部下の育成方法
- 第18回 IT徒然草――コストと利便性を追い求めて失うもの
- 第19回 羽田空港の管制はなぜ止まったのか?
- 第20回 JR脱線事故からマネジメントを学ぶ
- 第21回 “気付き”のコミュニケーション
- 第22回 阪神大震災10年目に考えること、するべきこと(前編)
- 第23回 阪神大震災10年目に考えること、するべきこと(後編)
- 第24回 情報システム部は、もう役割を終えてしまったのか?
- 第25回 リーダーシップを発揮するにはどうすれば?(前編)
- 第26回 リーダーシップを発揮するにはどうすれば?(後編)
- 第27回 SOX法とコンプライアンスとIT
- 第28回 有能なプロジェクトマネージャを育てるには(1)
- 第29回 有能なプロジェクトマネージャを育てるには(2)
- 第30回 有能なプロジェクトマネージャを育てるには(3)
- 第31回 ディスカッションテーマのおもちゃ箱(1)
- 第32回 ディスカッションテーマのおもちゃ箱(2)
- 第33回 ゆでガエルになる前に情報子会社は経営の見直しを
- 第34回 “シックオフィス”で健康を損なっていませんか?
- 第35回 コンプライアンスを語る前に考えてみること
- 第36回 適材適所の人材育成をしよう
- 第37回 事の本質を見極めよう
- 第38回 その考え、本当にあなた自身のものですか?
- 第39回 “変化”は外からやってくる(前編)
- 第40回 “変化”は外からやってくる(後編)
- 第41回 “変化”を模索する世界(前編)
- 第42回 “変化”を模索する世界(後編)
- 第43回 変化の中で、自らを制御できるものが生き残る
- 第44回 新型インフルエンザ対策に学ぶ組織の在り方
- 第45回 持続可能社会とITシステムはどう在るべきか(前編)
- 第46回 持続可能社会とITシステムはどう在るべきか(後編)
- 第47回 いまあらためて確認したい、情シスのイロハ(前編)
- 第48回 いまあらためて確認したい、情シスのイロハ(後編)
- 第49回 失敗は成功のもと、成功は失敗のもと
- 第50回 「想定外」から脱却できる、真の対策を
- 第51回 他山の石――政治を顧みて学ぶマネジメントの在り方
- 第52回 “影”から目を背けてきた原発とIT
- 第53回 優れたシステムを作るための“思考力、人間力”とは?
- 第54回 IT関係者は、原発事故から何を学ぶべきか
| 「何かがおかしいIT化の進め方」インデックス |
|
ホワイトペーパー(TechTargetジャパン)
|
|


