» 【第83号】LSVの目的と進め方

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

DRI通信83号「LSVの目的と進め方」   2003.8.1
長い梅雨ですね。皆様お元気ですか。私は大学4年の夏(1958)梅雨明けが待ちきれなくて、友達と二人でテントかついで北アルプスに出かけましたが、毎日雨、雲の平で往生したことを思い出します。ビールやクーラーも大変でしょうが、東北は地震もあって気の毒ですね。
会員の方にはすでにお知らせしましたが、8月26日(火)「企業情報システム部門の役割、これまでとこれから」という題でK2W勉強会を開きます。参加されたい方は弊社CRMグループまでご連絡ください。
■レガシーシステム
我が家の付近は昭和40年ころ開拓された住宅地ですが、世代交代の時期にあたり、更地にして売りに出される物件を良く見ます。この場合、建物はマイナスの評価とされているわけです。同様に、かつては資産であったソフトウエアが、もはや維持費のかかる負債であると評価されたりします。これは、高度成長期、短期的ニーズに対応して、田舎の温泉旅館の増築さながら、コピー機能を活用して、次々とソフトウエアを増産して作られたレガシーシステムに多いように思われます。
このところ2007年問題という言葉を耳にします。1947年生まれの団塊の世代が2007年に定年引退すると、彼らの作ったシステムのメンテナンスができなくなり、大きなトラブルが発生する、との心配です。度重なる場当たり的メンテナンスによって、ドキュメントとスパゲッティ化したソフトはすでに乖離していて、スーパーマンの暗黙知が頼りとなっている、その彼らがまもなく引退する、ということでの問題提起です。


これはレガシーシステムに関する、きわめて象徴的指摘で、そのまま当てはまる企業はさほど多くはないと思われますが、さりとて万全の企業も多くはないはずです。属人的につくられたソフトウエアを分担してメンテしているが、守備範囲は狭く、業務との関係を理解している人は限られており、ローテーションが難しい。システム間には重複データや重複ロジックがあり、サブシステム独立性は不完全、しかも全貌を把握している人はいない。このため生産性が低いだけでなく、読みきれたメンテナンスが難しい。
■開発とメンテナンス
ところで、開発とメンテナンスは何がどう違うのでしょうか。規模の大きさと無関係ではないでしょうが、ここでは次のように規定します。変更に際し、「必要な項目がすでにあればこれを使うか、これを捨てた上で新設し、不要になったデータ項目はファイルから取り除く」ものを開発と呼び、そうでないものをメンテと呼ぶ。すなわち規模は小さくても、ファイルの劣化をもたらさないものは開発/再構築と呼ぶものとします。ファイルが劣化しなければ、プログラムの劣化は、あったとしてもそこそこに収まるはずです。
メンテを続け、ファイルの劣化が進むと、メンテの生産性が低下し、いよいよファイルの劣化が進み、ドキュメントとの乖離も大きくなります。劣化を抑えるためには、在庫の定期棚卸やプラントの定期修理のような作業が必要なはずですが、再構築まで放置されるのが従来のやり方です。情報システムの歴史が浅く、またITの変化が激しいためでしょうか。
■LSV
したがって、劣化をもたらさない、「毎日が再構築」が理想ですが、今その体制をつくれるところは例外的です。そこでレガシーのメンテ地獄から脱出するための第一歩として、LSV−Legacy System Visualization−を位置づけます。われわれは、「LSVとは業務モデルを可視化し、物理ファイルと紐付けること」としていますが、これにも2レベル、すなわち浅く広く全体骨格をねらうハイレベルLSV(hLSV)と、個別アプリケーションの詳細をねらう徹底LSV(xLSV)とがあります。xLSVとて、まずはhLSVを先行させますから、一般にはLSVとはhLSVを意味することになります。
LSVの成果物は
(1) 概念データモデル図+物理ファイル紐付け
(2) 業務フロー図
(3) 上記対応のメタデータ定義
(4) 保守マニュアル
などです。ただし大規模システムの(1)概念データモデル図は非常に大きくなり、取り扱いの便を考えて適宜簡略版を作成する場合が多くなります。(3)メタデータ定義も、ROIの観点から品質・目的対応に記述の方法を適宜選択することになります。
素材は物理ファイルフォーマットが主体で、組織図、業務フロー、画面・帳票、コード説明書ほか、業務を説明する資料でこれを補います。業務担当者による適切な説明は、作業効率・品質を大きく左右するので、大切です。
ツールとしては、われわれはTHモデラー(データモデリングツール)、IPFモデラー(業務プロセスモデリングツール)、THeRepository(リポジトリ)を用いています。
なお、(1)としてさらに画面・帳票との紐付けも考えられます。品質の高い業務の可視化という観点で非常に有効ですが、ユーザの参画や工数の制約で敬遠される場合が多いのが実態です。
■LSVの目的
暗黙知の可視化によって、人間の理解やコミュニケーションは格段に前進します。これまで何事にも引っ張り出されて時間の取れなかった生き字引のキーマンが、ドキュメントベースでの説明により、効率的に活躍できる効果は絶大です。こうして可視化の目的・用途は種々展開されます。たとえば
(1) 開発保守管理の品質向上
(2) 他システムとのデータ連携・統合
(3) 再構築/ERP導入の準備
(4) 保守スピードアップ・品質向上
(5) アウトソース契約でのSLAのリスク低減
(6) 要件定義の品質向上
(7) 人材育成
などです。
hLSVは(1)−(7)すべてに効果があります。また「(3)−(5)のためにxLSVが望ましい」とされる場合もあります。また一般に(2)、(3)ではリソースデータ(コード)の整備が課題となります。なお当然(7)のためにはユーザや作り手の担当者の積極的な参加が必須です。
■LSVの進め方
一般にレガシーシステムはボリュームが大きいので、期間・コストのリスクが大きくなります。レガシーといっても企業によって劣化の程度、様相が大きく異なりますので、まずはアセスメントを兼ねて、パイロットプロジェクトを走らせるのが、お奨めです。その結果を踏まえて、LSVの目的、範囲、順序を決める。これによって最小のリスクで、自社にとって有効な最大の効果を得ることができます。
パイロットの対象としては、ユーザの多い代表的な小ぶりなシステムを選びます。大きすぎるときは、ケースを限定して小さくします。そして工程は初めから終わりまでトレースする。下手なやり方は、初めから間口を大きくとり、各所で類似の試行錯誤を発生させ、期間・コストの制限から挫折することです。パイロットプロジェクトで得られたイメージや合理化策は非常に有効で、類似システムなら1/5で処理できるようになることすらあります。
また物理ファイルにデータ項目が100あっても、当初は代表的なもの5−10項目に絞って分析すると言った工夫も有効です。パイロットの対象、物理ファイル、データ項目などの選定には、業務知識が必要ですが、当初から余り神経質になる必要はありません。進捗するほどに視界が開けてくるからです。ハイレベルLSVのときは、受注、発注、生産指図、出荷、請求など、システム間をまたがるハイレベルメッセージを分析することになりますが、初めは明らかにハイレベルと思われるものの分析からはじめます。
■業務モデルからソフト部品へのリンケージ
こうして物理ファイル対応のエンティティがどの工程で発生するか、その粒度や他のエンティティとの関係がどうなっているかが可視化され、さらに加工データの導出過程を追跡することによって業務モデルが明らかになってきます。一方、物理ファイル、物理項目、プログラム、JCLなどソフト部品間の関係は、機械的に分析するツールが進歩しつつあるので、物理ファイルや画面・帳票経由で、業務モデルとソフト部品のリンクがとれる日も近いと思われます。
■ データインフラの構築
情報システムは、メインフレーム、C/S、Web、モバイルなどへテロな環境に実装され、M&A、分社化、SCM、CRMなど、ビジネスニーズの変化に翻弄されています。アプリケーションは、レガシー、パッケージ、自作が入り混じることになりますが、もはや孤島システムは許されず、緊密な連携が要求されます。それぞれ精度は違っても同じコンセプトで一元的に管理したい。したがって、まずはシステム内というより、システム間でやり取りされるデータ、すなわちハイレベルメッセージに焦点を当てたhLSVにより、効率的に全体を抑え、新たなシステムとの連携要求などに迅速に対応できる体制をつくる必要があります。
すなわち、データインフラ−?メタデータ、?リソースデータ、?オペレーショナルDW−構築に当たっては、まずハイレベルメッセージを素材として、特に共用性の高い部分を対象にhLSVを実行する。次に緊急なニーズを持つ、あるいは劣化の激しい個別アプリケーションについてのxLSVや再構築などを手掛けながら、データインフラをレベルアップする。このような戦略的配慮が、大規模システムに対して、効果を実証しながら進めるために欠かせないものと思われます。