» 【121号】ユーザ企業とSIerの協業

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

情報システムが、経営ニーズに応えていてほとんど問題がないという企業は、
今日例外的でしょう。そこで今月はこの問題の根本的原因を探り、対策を考え
て見ましょう。

■現状の問題点と原因
自ら見聞し、また報告される問題点は
・保守コストが高い
・ユーザニーズへの対応が遅い
・データはシステム内にあるはずだが活用できない
・手間がかかって使いにくい
・二重入力している
・SVOT(Single Version of Truth)でない
・トラブルが多い
などかと思われますが、これが年々改善されず、むしろ悪化するケースも多い
との声を聞きます。
原因は
・大規模化。作ったときは大きくなくても相互接続しているうちに結果として
大規模になり、自分の担当分以外は十分把握できない。
・見えない。ドキュメントはあってもユーザ要件ではなく、ソフトウエアのド
キュメント。必然的に属人的で、ほかの人とくにユーザには難解。改変が多
いのでメンテ洩れもある。
・人がいない。適切に問題解決できる人が、ユーザ企業にも、またSIerに
も大幅に不足している。
などではないでしょうか。
■解決の前提
難題ですが、放置するわけにはいきません。対策を考えるにあたり、前提を整
理しましょう。それは
・ユーザ企業とSIerが適切な分業・協力を行う。これは「丸投げ不可」と
言う意味です。
・孤島システムを作らない。すなわち他システムとのインターフェースを見通
した上で当該システムのRFPを作る。
・「動いてなんぼ」ではない。動くのは当然、10年―20年稼動させて保守
費用を含めて最低になることを指向する(この場合ゲインは一定として)。
これは業務モデルと実装モデルの分離を要請するはず。短期ROIでは判断
できない。
などでしょう。
■対策
以上の前提の上で、次のように対策を考えます。
・大規模が問題ですから、分割します。分割によってインターフェースができ
ますが、これは安定かつ関係者間での適切な作業分担を決めるものでなくて
はなりません。とくにユーザ企業とSIerの作業分担、および営業、生産、
経理などのアプリケーションシステムの範囲の決定が重要です。このため実
装独立にアプリケーション間インターフェースを調整し、共用リソースDB
―欧米ではMDM(Master Data Management)と呼び今問題になっている−
およびアプリケーション間で交換するメッセージをストアするEDW
(Enterprise DWH)−これもNCRを中心に話題を集めている−を確定する必
要があります。
・ユーザ企業およびSIerの多くの関係者が、正確かつ効率的にコミュニケ
ーションできるために、個人差の出ない図と表によるドキュメンテーション
を行わなければなりません。この情報はコンピュータも共有しなければなり
ませんので、電子化しリポジトリにストアすべきものです。
・これらの対策は、従来技術とかなりのギャップがありますので、教育から入
らなければなりません。マニュアルとツールと座学だけでは難しく、一般に
は適切なテーマを選んでOJTを行う必要があります。
これらの対策は、ユーザ企業にとっても、SIerにとっても、情報システム
への取組みの大きな変革になりますので、CIOまたはCEOの問題としての
取組みが必要になるでしょう。この場合の留意点を以下まとめてみます。
■ユーザ企業の留意点
情報システムのベースは業務モデルであり、これを全社的視野で如何に設計し
運用すべきかが問題になっていますので、ユーザ企業が主導権をもって取り組
まなければなりません。
実装問題、すなわちハードウエアとソフトウエアについては、原則として
SIerに委託できるわけですから、それ以前の全社的ビジネスの組立、個別
アプリケーションの大きさ、これから決まるアプリケーション間のインターフ
ェース、これを標準化して得られる、データインフラ−リポジトリ、リソース、
EDW−の設計・管理の主体はユーザ企業としなけれなりません。SIerと
のインターフェースは実装独立/概念、それもできれば概念詳細とすべきであ
り、従来型のソフトウエアの物理仕様を含む要件定義では受け取れない、とい
った姿勢も必要と考えます。
■SIerの留意点
個別アプリケーションへの分割は、ユーザ企業によって行われており、孤島問
題は解決されているという前提で、SIerは個別アプリケーションの実装お
よび運用を担当します。しかし多くのSIerは長らく保守中心で業務を行っ
てきたため、物理詳細→物理詳細の変換を得意とする要員は多いのですが、概
念概要→概念詳細→物理詳細の変換を得意とする人は少ないように思われます。
後者ができないと、ユーザ企業との連携に支障が発生しますので、まずは概念
と物理の違いを理解し、概念から物理へ変換する技術を体得する必要がありま
す。個別アプリケーションではパッケージという手もありますが、その物理イ
ンターフェースがどのような概念インターフェースの変換であるかを解析し紐
付けなければなりません。このスキルは、パッケージでなくレガシーシステム
へのSOA適用でもほぼ同様に適用されますので、これは応用性の広い将来性
の高い技術と考えます。