» 【第103号】SI業の方法論再建のシナリオ(前編)

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第103号】SI業の方法論再建のシナリオ(前編)

DRI通信103号「SI業の方法論再建のシナリオ(前編)」 2005.4.1
3月後半の冷え込みで、桜は遅れているようですが、木蓮や雪柳があざ
やかに咲き、鶯が「どうだ、うまいだろう」というように、鳴き始めています。
2005年度のスタートです。花粉症のマスクが目立ちますが、あと少しの
辛抱です。がんばりましょう。
DOA+第1分科会(第3回)は3月23日、定義域をテーマに行いました。
私が定義域と属性の違いとその関係、とくに属性定義の品質を効率的に
上げるための定義域のあり方について述べた後、弊社堀越が過去のIRM
における実体験、また住友電工の中村氏が楽々フレームワークの適用に
際して採用しておられる定義域活用事例について話されました。また堀内
教授(東京国際大学)からは定義域やコードの標準化についての紹介と、
DOA+として定義域の標準を作成すべきとの提案がありました。
■ 解決策を考える前に
90年代初め、バブルがはじけた頃からでしょうか、「情報システムはコア
コンピタンスでない」との判断のもとに、ユーザ企業の情報部門のスリム化
が進みました。その結果、開発・保守要員の多くがSIerに移っていったよう
です。そしてそのSIerが先号に述べたような質的な問題を抱え、またユー
ザ企業も要件を正しく切り出せなくなって、トラブル発生を招いているようで
す。SIerだけで解決できる性質の問題ではないようです。そこで本号では、
ユーザ企業とSIer全体の問題として捉え、まず本来あるべき理想像を考え
てみることにします。


■ システム開発・保守の理想像
ユーザ、SIer、DOA屋、OO屋など立場によって、理想像は違ってくるもの
かと思われます。そこでここでは、私の個人的な理想像を描いてみることに
いたします。
(1) 成熟した方法論
情報システムは、一旦実装独立の、個人差の出ない図と表によって、業務
モデルとして表現(可視化)される。これによって、ユーザと開発・保守担当
が、情報システムのWHY・WHATを共有し、コミュニケーションが正しく効
率的におこなわれ、ユーザによるガバナンスに問題が発生しない。
(2) 業務モデル
業務モデルは、属性を最小部品とする各種粒度のデータ部品から成るデー
タモデルと、IO上のデータ項目を最小部品とする各種粒度のプロセス部品
から成るプロセスモデルから構成される(プロセスの階層は上から、L5:業
務ドメイン、L4:システム、L3:業務プロセス、L2:IO、L1:IOデータと考え
る)。部品の漏れ・重複・不整合は図と表を活用してほぼ完全に防止される。
(3) 部品リポジトリ
これらの部品仕様はリポジトリ(メタデータDB)にストアされ、ビジネス環境
の変化には、これら部品の追加・削除・変更によって迅速に対応できる(情
報資源管理指向)。このため、システムの劣化による保守コスト増大は発生
せず、劣化対応の大規模再構築はもはや必要がなくなる。
(4) ソフトウエアへの連携
データ部品1個にはこれを生成するプロセス部品が高々1個対応し、ソフト
ウエアはこれを基に設計・開発される。その対応事例はつぎのようになろう
(注1)。
 [データ部品]   [プロセス部品]        [部品粒度]
 出荷一覧出力   出荷一覧出力プロセス    2(属性群)
 出荷数量      (プロセスなし)         1(属性)
 出荷金額      出荷金額加工プロセス    1
 商品在庫数     商品在庫数更新プロセス   1
 発注レコード    発注入力プロセス       2
(5) データインフラ前提のアーキテクチャ
個々のアプリケーションを統合するDBと、アプリケーション横断にこれらを
統合するDB(EDW)(注2)の2レベルのDBを前提としたアーキテクチャを
前提とする。このためこれらが共用するリソースを定めるリソースDBとこれ
らのメタ構造を統制するリポジトリが、このアーキテクチャに含まれる。なお、
共用のリソースDBとEDWおよび統制のリポジトリをデータインフラと呼ぶ
ものとする。
(6) DMOによる管轄
業務モデルを記述するリポジトリおよびリソースDBのコンテンツは、DMO
(Data Management Office)が管轄する。この要員は、企業規模/同時に
走るプロジェクトの数にもよるが、10人内外を想定する。彼らは開発・保守
時に、業務モデル開発・保守を担当させて育成する。またアプリケーション
開発要員やユーザも極力業務モデル開発に参画し、その理解、コミュニケ
ーションの円滑化に協力するものとする。
(注1)このデータとプロセスの対応は正統派オブジェクト指向からすると、
違和感を持たれるものかと思われるが、管理対象(オブジェクト)を一旦記
号化しデータの世界に写像してから扱うTHモデルの考え方に起因するも
のである。ビジネスシステムの成果物は画面・帳票であり、これに立脚して
管理対象を考えるため、その識別に客観性が出て、人によるブレが最小限
になる利点があるものかと思われる。
(注2)EDW(Enterprise Data Warehouse)はRTDW(Right Time DWH)
などとも呼ばれる、各種アプリケーションから参照される共用メッセージを
ストアするDBであって、いわゆる孤島システム問題を一挙に解決すること
ができる。したがって、この中でERPを用いるときは、その統合機能ではなく、
アプリケーションパッケージ機能を利用することになる。
■ 理想と現実の乖離およびその原因
多くのユーザ企業・SIerにおいて、上記(1)−(6)のいずれにおいても現
実は理想と大幅に乖離しているのではないかと思われます。
(1) 「実装独立でない」からITが変化すると変更が多発する、また「個人
差の出ない図と表」でないから、抜け・重複・不整合の除ききれない、設計
者の個人的メモに近い属人的ドキュメントを作っている。
(2) 業務モデルによる部品化ができていないので、不整合がとりきれず、
テストの負荷が大きい。
(3) リポジトリによる部品管理は、一般にまだ、極めて未熟である。ユーザ
のメタデータに対する理解が不十分、かつ扱いなれていないこともあるが、
ツールベンダーのメタモデルに関する研究も未熟で、加工データ・チェック
データは自然言語で記述する段階である。さらに業務仕様を実装仕様へ
変換する標準も未整備で、MDAへの課題も多く残されている。
(4) オブジェクト指向が騒がれているが、オブジェクトを如何に客観的に
識別すべきか、したがってデータ部品とプロセス部品をどう関係づけるか
など、結論の出ていない課題が多々残されている。
(5) 「孤島システムではまずい。したがって全社をどのようなアーキテク
チャによって統合すべきか」が、重要な課題となっているが、今は種々の
案が提出されている段階と言える。このため「データインフラとは何か」は
十分認識されておらず、インフラ不在のまま「安く速く」が求められ、混乱
を招くケースが多々ある。現行システムとの差が少ない場合は、Copy &
Pasteによる差分メンテナンスの方が速くかつ安いということでこれに走り、
田舎の温泉旅館のような迷路が発生し、人間リポジトリもその限界に到達
しつつあるケースが増えている。
(6) DMOは言うに及ばず、データ管理機能を認識している企業すらきわ
めて例外的というのが、現状である。「管理者なくして標準なし。標準なくし
て共用なし」である。同じプロジェクト内ですら共用が不十分、プロジェクト
横断の共用など非現実的、と言うのが一般ではないだろうか。こうして孤島
システムが乱立する。情報システムの基礎となっているデータ定義やリソ\nースデータ値(コード値)の整備に立ち戻るべきと気付いても、プロジェクト
の制約条件に収まらない、ということから場当たり対応となり、悪循環から
抜け出せないということになっているのではないだろうか。
多くのユーザ企業では、自らの業務モデルをガバナンスすべき要員が、質
的にも量的にも不足し、丸投げ購買事務しかできなくなっているようにみえ
ます。一方SIerは与えられたスコープの中でのQCDの達成に追われ、孤
島システムのカットオーバーが無事できれば成功、として活動することに
なっているように見えます。一般に保守は、開発担当のSIerに任されます
ので、保守に時間やコストのかからない開発は、SIerの売上減につながる、
SIerによっては「望ましくない開発」であり、前向きに取り組みたくない課題
でもあります。
このように理想と現実の乖離は大きく手ごわいわけですが、解決の道を探
らなければなりません。私なりの解を次回述べたいと思いますが、皆様か
らのアイデアも歓迎です。遠慮なくお寄せください。