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

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

DRI通信75号「情報システム部門の役割その2」 2002.12.2
短い秋が過ぎて、早めの冬がやってきました。12月の声を聞くと、時の過ぎるのが速く「老年老いやすし」の感ひとしおです。
今年のK2W(Know What are the problems and Who know them)勉強会はアプリケーション・アーキテクチャを主題としてやっていますが、11月12日は東洋ビジネスエンジニアリング中村尚志(一世)さんの「ERP・レガシー共存のアーキテクチャ」に関する熱演で、参加の皆様方には十分ご満足いただけたようでした。次回は1月30日の予定です。ご興味のある方は是非会員登録(会費無料)していただきたいと思います。
73号でユーザ企業の情報システム部門の役割を論じ、74号で開発・保守を請けるSI業の対応について考察いたしました。本格的な調査を行ったわけではなく、日頃見聞きしたことを整理しただけで、皆様の認識とどの程度一致しているか、若干の不安もありましたが、かなり当たっているとの評価をいただきました。
■各氏の声を整理して
そこで今月は、コメント頂きました皆様方−峯岸輝明(住友金属)、新藤一豊(日揮情報)、油谷泉(SCS)、堀越雅朗(DRI)、小西了(NSRI)、長谷川泰司(DRI)、丸山則夫()、小松昭英(名商大)、長谷川兆秀(大和総研) 、上野則男(システム企画研修)、戸田忠良(戸田ソフトウエア事務所)ら各氏(敬称略)−の声を整理しながら、情報システムのありかたを考えてみたいと思います。


■情報システム部門の実態 
情報システム部門(情報子会社を含む)の実態については、「確かに弱体化しているが、そもそも強い時代があったのだろうか」、「差別化するというより、差別化されないための最小限でよい」として、「リストラされ、そのため丸投げ化の傾向があり、システム導入も情報システム部門バイパスで、直接ユーザになるケースがある」、「縦割りのユーザ部門に対応していて、業務知識も部分化し、全体を見る力が弱い」、「昔はそのシステムについて熟知した神様のような人がいたが、今は少なくなったし、度重なるメンテでスパゲッティ化して神通力がなくなってきている」、「増改築専門の大工や左官ばかりで、図面が書けない」、「付加価値のある情報を提供できていない」、「経営を支えていない」、「お荷物になっている」などの声が寄せられました。
■責務は重大
しかし、「経営に情報は不可欠であり」、「情報戦略立案と実行」は情報システム部門の役割であるはず。「業務モデルは事業・業務の意思決定の結果で、アウトソースはできない」から、「全社の業務モデルを総合的に把握し経営に役立つべくプロデューサ役を務めるべき」で、今は「役立たず」のきらいはあるが、「事業改革、業務改革は任さざるを得ない」。
「ニーズにフィットした情報システムを提供すべきではあるが、開発・保守は必須ではない。今までは作ることが自己目的化する傾向があった。調達のためのきちんとしたRFPを造るべきである」。また「コード値を含めた情報資源管理を行うべきである」と。
■経営の責任
このようなあるべき姿との乖離のひとつの原因は、「CIOがいない」ためであるが、これは「情報活用のすべを知らない経営の責任である」。このため、情報システム部門は「ビジネスと情報システムのグランドデザインを示す図の作成・維持の意義をTOPに理解させる」べきであるとのこと。
■業務モデル図が鍵
問題の鍵はやはり業務モデルであるが、「日本ではその責任の所在が明確でない」。「業務モデル図なしでよくやれているなと思うが、標準化がなぜないかは不明である、本当に必要でないのかとも思う」という声と、反対に「可視化のため概念データモデル図は必須だ、業務を知らないSEに書かせるのは無理がある、THモデル図は算数の九九のようなもの、これを業務ユーザに教育すべきだ」といった弊社としては有難いお言葉もありました。また「概念データモデルをDBの形式に表現したリポジトリを公開すべき」、「業務フロー図はデータ項目の更新に焦点を絞ったものとすべき」との指摘をいただきました。
業務モデルは、プラントエンジニアリングでは、P&ID(配管計装線図)、機器リストを中心にしたものとなりますが、「パッケージ・プロセスベンダーが、テンプレートを提供しており」、また建築では「設計事務所が設計図を作っている」、「SI業がいまだ情報エンジニアリング会社になっていないのが問題だ」、「大手SI業はファンクショナル化もプラットフォーム関係やビジネスコンサルだけで、多くは外注をたたいて利益を上げている。エンジニアリング合理化への取組みは、気づいてはいるが、まだまだである」とのことでした。
■DRIの認識
プラントや建築の成果物はハードであり、設計図は直感的に理解しやすいもの、基礎学問は物理や化学ですが、情報システムの成果物は「大規模、変化する、目に見えにくい」業務モデルやソフトであり、歴史が浅いこともあって基礎学問は未熟で、人間が関与するため心理学や政治学の動員も必要になるというハンディキャップを抱えています。
しかしわれわれは、解決の方法はあるし、その糸口がかなりはっきり見えてきたと思っています。各社によって作成担当は違うかもしれませんが、業務モデルは情報システム部門(またはこれに相当する部門)が押さえ、これを介してビジネスユーザと開発担当が疑義の発生しないコミュニケーションを行うべきですが、これがさほど遠くない将来、可能かつ不可欠になると思うからです。
われわれは以前から「経営が欲しいのは企業の実態であり、鍵はこれを十分詳しく広く忠実に表現したDWHである。各部門が欲しいのは、その業務をスムーズに支援できるアプリケーションシステムであり、ネットワークとDBが鍵である。これらを繋ぐため統一コードの整備が、また全体を統制し索引となるメタデータリポジトリおよびこれを可視化した業務モデル図−弊社では概念DB構造図、IPFチャートなど−が不可欠である」と考え、方法論やツールの開発を進めて参りましたが、これらの提供のめどがはっきりしてきたからです。