» 【第73号】情報システム部門の役割

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第73号】情報システム部門の役割

DRI通信73号「情報システム部門の役割」 2002.10.1
彼岸花の赤と金木犀の香りがお彼岸を送ると、急に涼しくなってまいりました。
世界不況の中、皆様の02年上期はいかがでしたでしょうか。
暗黒大陸化したレガシーシステムの重圧は、増大する地球の炭酸ガスと同様なか
なか手ごわいもののようですが、解決の道を求めてがんばっていきたいと思います。
■弱体化する情報システム部門
成長を当たり前とする時代が終わって、M&A、カンパニー制、組織の再編や統合が日常
茶飯事として行われるようになってきました。リストラと称する人員削減が、情報システ
ム部門にも一律に行われたりします。経営にとっての情報の重要性は、低くなるはずもあ
りませんが、情報システム部門−親会社の仕事しかしないシステム子会社を含む−への評
価は、むしろ低くなることすらあるかに見えます。そこで今回は情報システム部門の役割
について考察いたします。


クライアント/サーバーが実用化され、ちょっとしたシステムならユーザが作ってしまう。
メンテが出来なくなって、システム部門がこれを引き継いでいるうちに、新規ニーズに対
応する余力を失ってしまった。ERPパッケージが出てきて、ユーザ主導でこれを入れて
しまうこともある。ITは高度化し、システム規模が大型化し、もはやシステム部門の手
に負えなくなってしまった。
情報システム部門は、強化すべきなのか、それともアウトソーシングすべきなのか。その
条件は。など難しい問題を前に、人減らしの総論から、とりあえずアウトソーシングを選
択した、という会社も少なくないかに見えます。
■プラント建設におけるアウトソーシング
この問題を考えるとき、いつも念頭に浮かぶのは、1960年ごろのプラント業界におけ
るエンジニアリング産業の確立です。それまで化学・石油会社は、プラントの設計を自ら
行い、工務部門が建設を担当していました。しかしコンビナートの中に工場一式を建設す
るといった大型プロジェクトが生まれて、手に負えなくなり、プラント建設のプロ、千代
田化工・日揮・TECなどが育っていきました。プラント建設におけるアウトソーシング
の確立です。
このときのアウトソーシングにおけるインターフェース−RFP(Request for Proposal)
−は、プロセス・フローシート、P&ID(配管計装線図)、機器図面などで、ドキュメン
トの作成はたしかにアウトソーサーが行いましたが、発注側(発展途上国の場合は例外)も
これをしっかり読みこなし、必要な注文をつけることが実行されていました。対象がハー
ドウエアで、図面の読み方にさほど訓練を要さなかったことはありますが、化学工学など
の基礎学問を修めており、アウトソーシングはRFPに関する共通の理解の上に成り立っ
ていたと言えます。
■情報システムにおけるアウトソーシング
40年後になって、情報の世界に同じような状況が生まれているわけですが、いくつか違
った点があるようです。たとえば
・RFPが不完全

・市場ニーズやITの進歩によってRFPの内容が激しく変化・拡大する
・建設だけでなく運用を含めたアウトソーシングもあるが、このときは人も含めてとなる
など。
RFPが不完全とは、きちんとした形式知になっていない、端的に言えば業務モデルを記
述した図面がないと言うことです。図面のないプラントを受け取って運転しなければなら
ないようなものです。画面や帳票を見て、システムを覗き見ることは出来ますが、図面の
上で、変化・拡大するシステムをトレースし確認することが出来ません。人とソフトを抱
き合わせでアウトソーシングするというのもこの対策かと思われますが、時とともにソフ
トは、暗黙大陸となってしまい、一時しのぎに過ぎないように思われます。
■RFP
RFPは、基本的には実装独立の業務仕様ということになりますが、ハードウエアと違っ
て、その記述法が確定していません。予算をとるための、トップに対する「漫画+箇条書
き」−WHYが中心ですからWHATは不十分−でRFPの代用とする場合も少なくない
ように思われます。この場合は、本来アウトソーサーが確認のためのRFPを書くべきと
思われますが、実装従属の膨大なソフトウエア仕様書を納入して、RFPの代わりとする
場合が多いようです。発注側にとって、これはITがらみの詳細が多くて読むに耐えず、
大量のごみと化する、という結果になり勝ちです。
業務仕様とは、「人/組織がどのような情報を利用しているか、これを誰−人/組織/コ
ンピュータシステム−がいつ作っているか、その情報−IOやメッセージ−はどのような
データを含むか」であると考えますが、いろいろな表記法が提案されているものの、標準
はなく、「漫画+不完全な自然言語」を用いた属人的な表記となっているのが実態です。
しかもデータモデリングが科学として認知されていないため、たとえばAさんの言う画面
上の取引先と、Bさんの言う帳票上の顧客が同じと扱えるものか否かを判定するのに、フ
ィーリング以外の手段持たない関係者がほとんどです。こうしてアウトソーシングにおけ
るRFPは、プラントなどに比較すると、暗黙知を含むきわめて曖昧なものとなっていま
す。
■業務モデルを形式知として守れ
システム部門といえば、昔はひたすらプログラムを作り、処理の自動化により業務の効率
化を実現し、それなりに経営に貢献していました。今はパッケージを導入したり、アウト
ソーシングを行って、情報化を推進しています。これは、昔、東京から京都まで東海道5
3次をひたすら歩いて行ったのに、いまは新幹線、さらに必要なら地下鉄やバスを乗り継
いで目的地に到着するようなものかと思います。
新幹線がどのように動いているのかを理解する必要はありませんが、どこで乗ってどこで
降りるか、降りてどう乗り継ぐかは、本人が知らなければなりません。このため、必要に
応じた詳細度の地図が必要なはずです。同様に、パッケージを使う場合も、これを使いこ
なすための機能を表す概要図や、他とのインターフェースをとるための詳細図が必要にな
りますし、アウトソーシングの場合も、業務担当者のわきまえるべき業務モデル、および
アウトソーシング対象外部分とインターフェースをとるためのドキュメントが必要になり
ます。
これらを、業務ユーザが作る、情報システム部門が作る、アウトソーサーに作らせる、コ
ンサルティング会社など第3者に作らせる、など作り方はいろいろあるかと思われますが
、業務担当者はこれをわきまえレビューしなければならないはずです。作成担当者は状況
によって変わるが、「業務モデルを形式知として守る」、これが情報システム部門の必須
の役割ではないでしょうか。人数が減った、だから情報システム部門はシステム購買部門
になり下がり、業務モデルは暗黙知になってしまった、一体これで5年後、10年後、要
員が入れ替わっていったとき、システムは企業活動を支えられるのだろうかと心配になり
ます。
聞くと「私は業務は分かってます」と答えますが、個人差の出ない明快なドキュメントを
書いて説明できる人はめったにありません。これでは、自宅までの道を知っていると言う
犬と同じ知り方に過ぎないのではないでしょうか。