» 【第81号】ハイレベルLSVの提案

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第81号】ハイレベルLSVの提案

DRI通信81号「ハイレベルLSVの提案」   2003.6.1
梅雨のはしりの涼しい雨、風邪を引いたりする人が目立ちますが、皆様お元気ですか。
今年度も厳しいスタート、そして今は地球の限定された場所、限定された期間と思われているマスク姿が、100年後には「あちこち、いばしば」となったら悲しいなと思ったりする日々です。
今月は、聞いたこともない「ハイレベルLSV」をテーマとしました。LSVとはLegacy System Visualization すなわち「レガシーシステム可視化」という意味です。ハイレベルとは、「アプリケーション間で共通の」といった意味で、ロウレベルの「アプリケーション内固有の」という意味に対比するものです。したがって「アプリケーションの骨格構造の可視化」と理解していただいて良いかとも思います。
■成熟期に入った情報システム
企業による差はありますが、多くの企業において1990年ころまでに業務アプリケーションのシステム化と称するコンピュータ化が大幅に進められました。コンピューティングコストの低下とRDBMSの実用化が、これに大きく寄与したものと思われます。「白地」の未コンピュータ化業務は非常に少なくなり、処理の自動化による合理化が進んだわけですが、開発時期・スポンサー・開発担当者が違っていて、できたのは多くの場合、相互データ流通の難しい、いわゆる孤島システムでした。90年代に入っても、ユーザ主導のC/Sシステム開発など、この延長線上でたくさんの分散バラバラシステムがつくられました。


この不備を解消しようとして登場したのがERPパッケージと言うことになりますが、1個のERPで置き換えてすべてが解決できる企業は皆無に近く、多くの企業はレガシーを残し、またアドオンやSCM・CRM・B2Bなど新機能のためのシステムを付加することになり、これらとのデータ流通という新たな課題を抱えることになったように見受けられます。
「白地」の残っていた発展期は、開発、それも既開発部分を取り込む拡大再開発が多かったわけですが、それは必ず採算の約束されるものでした。しかしいまや「白地」のない成熟期となり、システムは大型化し、1箇所の変更は数箇所に波及するが、それが読みきれない。そのため「変更はペイしない、再構築の体力もなければ技術もない、できるだけソーットしておくに限る」と言った考え方が支配的となっていったように思われます。
■システム部門のレベルが低下
これが大型レガシーシステムを抱え、ERPやアウトソーシングに解を求めている企業の実態かと思われますが、ここでの最大の問題は、システムというよりも、これを支える人材が育っていないことではないかと思われます。このところ多くの方から聞きますが、「システム部門のレベルが20年前と比べて大きく低下している。リーダークラスの人が正規化の意義すら知らないし、知ろうともしない。いわんや部下のSEは、VBやJAVAは書けても、RDB上に移行されたCOBOLファイル構造のDBシステムをメンテして何の疑いを持っていない」という。
いまや情報と経営は一体だといわれる。経営ニーズを理解し、これを強力に支援すべき情報システム要員が不可欠とされる時代に、情報システム部門のレベルがこのように下がってしまってよいのだろうか。第3次・4次産業で生きていかなければならない日本の、情報システム要員のレベルがこのように下がっていて、10年後はどうなるのだろうか。
初めは「本当だろうか」と疑っていましたが、何人もの方がうなずかれるのでその理由を考えてみました。やはり開発がなくなったためではないか。「人は25歳から35歳までの間に、正しい方法論に基づいた開発に携わって育つ」というのが、私の持論ですが、「先人の手がけたシステムのメンテナンスとパッケージ導入だけやっていた、一からシステム構築を考える機会が与えられなかった」と考えると納得がいく。
また「ITの高度化とシステムの大規模化によって、ユーザ企業は丸投げ化し、元請のSIは手配師化し、下請けは部分の実装に特化するという分業が進んで、空洞化が進んだのだ」という声も聞かれます。方法論の標準化のない暗黙知のままでの分業の帰結ということでしょうか。先人はシステムを残しましたが、それは形骸であって、「魂」は暗黙知であるため、時とともに消えていってしまう。引き継いだ後輩たちは、形骸のメンテナンスやパッケージ導入に追われ、モラルダウン、スキルダウンを招いてしまった。そんなシナリオが見えてまいります。
■悪循環
コアコンピタンスの追求ということから、アウトソーシングが適用されますが、暗黙知文化ですから、情報要求の形式知化ができないまま、要員ごとの丸投げが主流となってしまいます。ビジネスユーザとの距離はいよいよ拡大しますから、経営ニーズへの迅速かつ的確な対応が促進されるとは考えにくい。大規模レガシーシステムは、暗黙知のまま、アウトソーサーに移管されても、担当責任は変わりますが、問題は未解決のまま残っています。情報システムとともに経営を丸投げするわけにもいかない。「人が育たない」→「丸投げやパッケージ依存」→「人が育たない」の悪循環はどう断ち切ればよいのでしょうか。
私は今のレガシーシステムは多くの場合「きちんと作れば1/5にはなる、メンテコストは1/10にはなる」と思っています。しかしこれを預かるSI側に、これを推進するインセンティブはないでしょう。ユーザ企業側になければなりませんが、これを指示できる技術力も体力も意欲もなくなっているかに見えます。最大の原因は、この悪循環を断ち切る筋道が見えず、またこの暗黙知の巨大レガシーシステムが、どれだけの先行投資を要求するかが見えないことだと思います。
90年代以降の成熟期の開発は、開発というより保守に近い。従来のデータ構造をベースに若干追加修正を施すものが主流になったためでしょうか、本格的なデータモデリングの教育ニーズが減りました。ツールやデータモデリング技術は進化しましたが、これを普及するチャンスがめっきり減ってしまいました。これと期を一にして、システム部門のレベルが下がったかに見えます。ユーザ企業にとって有効な方法論普及のチャンスはどうすればつくれるのでしょうか。
■ハイレベルLSV
そこで考えたのが、ハイレベルLSVです。期間・コストを最小化するために、「詳細はさておき、レガシーシステムの全貌を骨格レベルで可視化しよう」、「アプリケーション間でやり取りされる、発注・入庫・生産完成・出荷・請求・入金などのハイレベルメッセージに限定してデータモデリングを行い、まずはグローバルなデータ流通を確保しよう」と言うものです。「プライベイトな世界は各自に任せ、公共の世界にルールを設定しよう」、「今後の作戦を立てるための、共通認識すべき概略の地図を作ろう」というアプローチです。これはSCM・CRM・B2Bなどの広域統合を実現するための不可欠の第一歩となるはずです。
対象範囲、詳細度、ヒアリング対応の量や質にもよりますが、多くは、期間は3−6ヶ月、素材は物理ファイルフォーマット+主要画面・帳票を想定しております。開発案件が減少している中、要員教育の貴重なチャンスなので、ユーザ企業の若手に成果物作成を担当していただきたいのですが、目下のところ、弊社コンサルタントが作成し、ユーザ殿にはヒアリング対応により読めるようになっていただく進め方が主流となっております。
このプロジェクトで難しいのは、ハイレベルメッセージとロウレベルメッセージの区分け、言い換えると個別アプリケーションの単位を如何に定めるかです。しかしこの議論の過程で、全社システムの構造が形式知化され、メンバーの理解が共有化され深まります。また商品・部品や組織・顧客など主要なリソース系データの標準化ニーズが整理され、情報流通問題への解決が進展します。
勿論保守問題へのプラス効果が期待されます。私は、保守は次のような手順
1.ビジネスユーザ :改善・改造要件まとめ(RFP:Request For Proposal)
2.SE(DA)  :改造設計
3.SE(DA)  :影響度分析
4.SE      :予算・期間・体制立案
5.システム管理者 :保守案件評価、優先順序付け
6.SE・プログラマ:改造実施
7.ビジネスユーザ :検収
で行われると想定していますが、1−5、特に5の合理化が進められるのが大きいと期待しています。従来はシステムが暗黙知だったため、問題を後に残す保守や、2度手間になるような保守が計画されても、システム管理者は担当者一任により見逃さざるを得なかったのではないでしょうか。
私はデータ流通を実現するための最重要のデータインフラは、ハイレベルメッセージに関する、メタデータ、リソースデータ(コード類)、およびDWHと考えていますが、ここに述べたハイレベルLSVによってそのきっかけができるはず、範囲をハイレベルに限定していますので、期間やコストが最小限になり実現性が高いと考えています。どうぞご検討の上、皆様からのご意見がいただければと思います。