» 【151号】 ユーザ企業の役割、SIerの役割

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【151号】 ユーザ企業の役割、SIerの役割

■情報システムアーキテクチャの進化
情報システムアーキテクチャは、相互に通信すべきメッセージデータ(=トラン
ザクションデータ、イベントデータ)の通信の方式によって、
 G1:ロウレベルPOA(個別プログラムが適宜データを通信する)
 G2:ロウレベルDOA(プログラムはアプリDBを介してデータを通信する)
 G3:ハイレベルPOA(アプリ同士適宜データを通信する)
 G4:ハイレベルDOA(アプリはアプリ間通信場DBを介してデータを通信
する)
のように、進化するかに見えます。

ここで、ロウレベルとは個別アプリに視野を限定するもの、ハイレベルとは全社、
したがってアプリ横断の視野を持つものとします。
これは交通問題に対比するならば、「在来線や一般道路はロウレベル、新幹線
や高速道路はハイレベル」として考えられるかと思われます。

これまで多くの企業は、DBMSを活用してアプリケーションシステムを開発し
てきたわけですが、そのほとんどはG2のレベルにあり、リソースデータ(取引
先コード、製品・部品コードなどのマスターデータ)が個別に作られたこともあっ
て、いわゆるSILO、孤島システムの問題を抱えています。一部先進ユーザは
EAI、ESBなどの技術を用いてG3、あるいはG4に挑戦中ですが、解決済
みという話は聞きません。

ERPは元来全社をカバーすべく設計されたわけですが、例外を除き、ほとんど
の企業ではレガシーとの共存であり、さらに複数個のERPを導入するケースさ
え見られます。ERPベンダーも1個のパッケージで全社をカバーすることはあ
きらめたかに見え、「パッケージ:手作り=7:3」が黄金率だ、などの記事も
見られます。こうなると、ERPも大型のアプリとして位置づけられるので、アー
キテクチャはG2ということになり、G3ないしG4への挑戦が課題として残さ
れます。

G3は、粒度がプログラムからアプリケーションに大きくなっただけで、G1と
相似のアーキテクチャであり、アプリケーションの数が2、3個までは良いとし
ても、10個とか増加するときスパゲッティ構造の欠陥を露呈し、メンテを難し
くします。間に合わせでない限り、やはりG4を指向しなければなりません。

G4の場合は、G2と同様、通信場設計を先行しなければなりません。WHYの
経営目標を確認し、WHATのビジネスプロセスおよびビジネスデータのモデル
をハイレベルで作ります。このため、個別アプリ間でやりとりするメッセージを
収集し、個別アプリの偏見から来るデータ定義の違いを調整する標準化作業を行
います。この場合アプリの大きさが過大ないし過小、あるいは一部重複というこ
ともありますので、その調整を同時に行う必要があります。これらのアウトソー
シングは、個別アプリ開発を請けるSIerには難しく、これは本来ユーザ企業
の役割だと考えます。

■課題と解決の方向
作業内容はほとんど個別アプリでのデータモデリングと変わりません。アプリご
とにITが異なることは通常ですから、実装独立のデータモデリングを行うわけ
ですが、担当者は営業、生産、経理など、種々のアプリケーションの広範なデー
タの意味を理解しなければなりません。データは数万項目になる可能性がありま
すが、安定したレガシーやパッケージの中の詳細データは一旦これに任せ、アプ
リ間でやりとりされる数千項目に絞って作業する方針をとるべきです。

いま、多くの企業が抱えている問題は、このような課題に取組む高度のDOA技
術をもった人材が払底していることかと思われます。個別アプリパッケージに任
せきれない、アプリ間インターフェースの部分は、その企業の強みにかかわる部
分であり、自社で管理すべき、SIerにお任せできないはずのものです。人材
が不足するなら、教育し増強すべきものと考えます。ただし繁閑があります。開
発が一段落したときは、少人数でまかなえます。そこで開発の繁忙期にのみアウ
トソーサーを動員する戦略があるかと思います。

■プラントエンジニアリングとの対比から
このような場合、プラント業界ではどうして来たのでしょうか。昭和20年代前
半までは、プラントのオウナーがWHY→WHATの機能設計を行い、反応器、
蒸留塔、ポンプなどは、WHAT→HOWを担当する機械メーカから調達し、プ
ラントを作っていました(注)。ところが昭和20年代後半から、WHY→WH
ATおよびWHAT→HOWを理解し、正確なWHAT-組立図と部品表-を書
くことによって、オウナーと機械メーカをつなぐプラントエンジニアリング企業
が現れました。千代田化工建設(筆者はここに1979年まで20年間在籍しま
した)、日揮、東洋エンジニアリングです。

(注)
プラントエンジニアリングにおけるWHY、WHAT、HOWを具体的にどう対
応付けるかは異論の出やすいところかと思われますが、ここではEPC
(Engineering, Procurement, Construction)におけるE=WHY→WHAT、
PC=WHAT→HOWと考えています。

情報システム業界においても、このような役割を担う、いわばビジネスエンジニ
アリング企業の出現が待たれるのですが、情報システムはプラントに比べ、かな
り手ごわいと思われます。その主な理由は
(1)WHATの形式が未熟
(2)ビジネス要件やITの変化が激しい
(3)実装独立と実装従属の差が大きい
(4)業務横断のスコープの課題が若手に与えられていない
などかと思われます。

(1)は、WHATを受け止めるHOWがソフトウエアであることに起因します。
プラントの場合はハードウエアであり、目に見えるため組立図や部品表の書き方
に大きな差が出ず、標準化が比較的容易です。情報システムの組立図としては、
データモデル図と業務フロー図が代表的ですが、いろいろな図法が提案されてい
ます。しかし多くは、DBのスコープが個別アプリのためリソース一元化未了、
また加工・加工元データ分析をデータモデリングから除外するため、DI
(Derivation Integrity)のチェック未了など、不整合が残されやすく、HO
Wの実装段階になってこれが検出され、WHATに手直しが発生する場合が多々
あります。また組立図は、同じ意味のものは同じLook&Feelとなるよう
作図すべきですが、そのルールが不十分なため、個人差が出やすく、チェックに
時間がかかり、チェック漏れが発生しやすいものも少なくありません。図は一種
の言語ですから、一度これを使うと、別の図法に切り替えにくく、標準化が進み
ません。

(2)はユーザ企業とSIerの距離を大きくします。プラントなどのハードウエ
アは一旦建設すれば、さほど大きな仕様変更はなく運用されますが、情報システ
ムはビジネス環境の変化に応じて、日々変化しますので、そのフォローは難度の
高いものとなります。ユーザ企業はその対応に追われます。一方ITは日進月歩、
ユーザ企業にとっては過大な負荷、このためSIerに任せる方向かと思われま
すが、ビジネス要件との調和は必要、プラントと比べ大きなハンディがあります。

(3)もユーザ企業とSIerの距離を大きくするものです。ビジネスの変化とI
Tの変化とを分離して対応させるために、実装独立の仕様と、実装従属の仕様と
を分離しかつ対応付ける必要があります。SIerは長らく実装技術からアプロー
チしてきたため、実装独立の発想が苦手です。ユーザ企業も必ずしも実装独立を
得意とするあけではありませんが、そのニーズは本質的に実装独立です。プラン
トの場合はそれらが近いのですが、情報システムの場合は、両者の距離が大きい
ため、それらの技術の内容が大きく異なります。その双方を理解し関連付けるの
が、大変難しくなります。

(4)プラントの場合は、20歳台から30歳台のエンジニアがプラント全体を視
野に入れて最適設計を行っていました。しかし情報システムの場合は、若手は個
別アプリの問題解決に終始し、50歳近くなったCIOやトップがようやくアプ
リ横断の全社問題に気づくのが通常かと思われます。すなわち、担当者不在が、
G4問題に本格的なビジネスエンジニアリングを展開し解決することを、妨げて
いるものと思われます。

こうして、情報システムのWHYからWHATを経てHOWをカバーする、ビジ
ネスエンジニアリング企業の登場が期待されつつも、しかしいぜん実現できてい
ないわけですが、「完成度の高いWHATのドキュメンテーションの確立、これ
を習得したアプリ横断の視野をもつ若手人材-ビジネスエンジニア-の育成」が
鍵を握るものかと考えます。「都庁を造るのに図面が要る、プラントを造るのに
図面が要る、オーケストラの演奏に楽譜が要る。これより複雑なシステムを作り
保守するのに、WHATを表す正しい全体図面が無くてよいはずはない」。そし
て、これを正しく共有する人がいてはじめて、G4が達成できると思われます。

ただ残念なことに、最近こんな声を聞きました。「ユーザ企業には要件を規定で
きる人がいなくなった。画面・帳票レベルであれこれ言えるだけだ。SIer側
でやらなければならないがヒアリングする相手がいない」。また「パッケージを
入れてシステムがブラックボックスとなり、システム要員が不良資産化してしまっ
た」とか。

なおPRになってしまいますが、弊社THモデルおよびPLAN-DBは、(1)
の問題、すなわちソフト生成のベースとなる実装独立の情報システム仕様記述-
ビジネスシステムのWHATの形式-に関しては、ニーズをほぼクリアし、お役
に立てるものと考えています。またこれを活用してG4問題の解決に、また以後
これを維持管理する人材の育成に取組みたいと考えています。ご検討いただけれ
ば幸いです。