» 【第79号】システムの可視化

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

DRI通信79号「システムの可視化」           2003.4.1
イラク戦争の最中ですが、桜が咲き始めました。厳しい2002年度でしたが、
おかげさまでなんとか2003年度を迎えることができました。皆様はいかがでしたでしょうか。
インフラというとハードやネットワークを想定される方も多いようですが、われわれはメタやコードを中心にしたデータインフラを対象としています。標準化という縁の下の力持ちのような仕事なので、地味で即効性に欠け、それゆえにビジネス的に難しいのかと理解しています。しかしこれがあってはじめて、変化に即応する情報システムが構築できると、今年度もがんばって行きたいと考えています。どうぞよろしくお願いします。
■ いろいろなシステム
システムというと、コンピュータを用いて実装された情報システムを想定される方も少なくないかと思われますが、ここでは一旦、交通システム、社会システム、生態系システム、さらには化学プラントや建物などを含めて、もっと広義に捉えるものとします。一般に大規模かつ複雑なため、要素とその相互関係に分解して取り扱われるといった共通点を持ちます。


これらシステムには見えにくいものと、比較的見えやすいものとがあります。ハードウエアで静的なシステムは見えやすい。建物やプラントが設計図どおりできているかどうかは素人にも結構分かる。そうでないシステムは見えにくいため、不備があっても当事者以外がこれを認識するのは簡単ではありません。大規模システムでは、当事者は部分しか担当できませんから、全体を把握している人がいない、といった事態が発生しがちです。
■ 図と表\nシステムは要素とその関係から構成されますから、そのドキュメンテーションには、図と表が用いられます。関係を表現するのに、図に勝るものはないでしょう。人間の目の能力を最大限に活用してこれをつくり、また検証することができます。表は要素の性質を記述するのに用いられます。要素が同質ですと同じ形式の表が適用できますが、異質ですとその種類の数だけの形式の表が必要になります。
システムはまた階層的になっている場合が多々あります。たとえば全社情報システムは、販売、生産、経理などの要素から構成されますが、販売、生産、経理などがさらに1ランク下のシステムとなっているわけで、これに対応した図(データモデル図など)と表(データ定義書など)で表現することができます。
図示の場合大切なことはその文法(図法)、とくにレイアウトです。プラントや建物などハードウエアの場合は、目に見える形が基本になりますので、その文法に個人差が出にくく、素人にも比較的容易に読みこなすことができます。しかしソフトに近い目に見えないものは要注意です。レイアウト規則をうまく作っておくと、同じシステムは誰が書いても同じ表現になります。また類似したシステムは、類似した表現になり、過去の経験の蓄積や活用が容易になります。
情報システムは、ドキュメンテーションの最も難しい分野かと思われます。ソフトウエア、とくにコンピュータへの命令を記述するプログラムは、可視化の困難かつ効果の期待できないものとして対象外としましょう。そのベースとなる業務モデル、すなわちデータモデルと業務プロセスモデルが可視化の対象となります。これが客観的に−同じシステムは誰が書いても同じに、また類似システムは類似に−表現される文法を導入し、ユーザ、SE、データ管理者など、関係者間のスムーズなコミュニケーションを実現することが課題となります。
■ 2つの書き方
業務モデルでは、業務をデータ(IO、トランザクション、エンティティレコードなど)とその変換過程(処理プロセス)として捉えますが、その書き方には、
A.データをノード(箱)とし、変換を線で書く
B.変換をノードとし、データを線で書く
の2つがあります。
業務モデルのうちのデータモデル図にはもっぱらA方式が使われています。すなわちAによって、KEYに対応するノードでエンティティレコードを表現し、RKEYに対応する線で1:nや、1:1の関係、およびこの上で結合、要約、抽出などの処理−残念ながらデータモデル図上で処理をトレースすべきと提案する方法論は、PLAN−DB以外に見たことがありません−が行われることを表現します。
他方、業務プロセスモデル図にはAとB、両方の表現が用いられています。われわれはAの表現、すなわちIOをノードするIPF(Information Process flow)チャートの表現をとっています。利点はノードについての共通認識がとりやすく、個人差がでにくいことです。Bの表現によって、処理プロセスをノードとすると、大きさがまちまちになったり、レイアウト規則が作りにくいため、個人差がでやすくなります。
■ Agilityを求めて
システムは大規模化を求めて変化するもののようです。Monolithicなシステムで、1箇所の変更が全体に影響するものであると、全面再構築のような対応を迫られ、スピードやコストの点でついていけなくなります。このため独立性の高いサブシステムから構成し、これをリプレースしながら追随できるものでなければなりません。このためにはまずインターフェースを標準化して安定化させる必要があります。
情報システムのインターフェースは、データですから、この標準化を先行して決める、これがDOAということになります。インターフェースの標準化を容易にするためにXMLが提案され、またITの変化から守るために概念モデルと物理モデルの分離が行われます。
IT独立は、業務ユーザによる理解の容易化、寿命の延長とともに、IT環境の異なる企業間での業務モデルの使いまわしを可能にするものですが、ユーザ企業の短期的ROIの観点から、取り組みは遅れ勝ちとなっています。
IT独立は、またSIにとっては必ずしも前向きに取り組みたくない意味があります。ITの変化は新しいビジネスチャンスでもあるからです。ERP、OOなど新しいIT技術をいち早く習得し、「次はこれ、次はこれ」と市場を開拓する方が、ビジネスとしてうまみがあるとも言えます。手のかかるレガシーシステムがあっても、事故なくメンテしていれば、収益は確実に見込め、また顧客も満足し、Win-Winの関係となるからです。保守費用が不当に高いかどうかを検証する方法が見つかっていませんので、誰も責任を問われることはありません。
■ レガシーシステム可視化の試み
80年代にメインフレーム上に、また90年代にC/Sを使って、プロセス中心のコンセプトで、もりもりとプログラムを作り、そのときは自動化のメリットを享受したけれど、今になってそのメンテナンスが問題になっているという企業がたくさんあります。ドキュメントはなかったり、あっても正確でなく、また設計開発に携わったベテランは退職したり、異動になったりで、「ソフトは資産でなく、負債である」とか言う声が聞かれます。
業務は厳しい経済環境に対応するために、変えなければならず、システムへの種々の変更要求が発生します。システム管理者は変更の方針を評価し、優先度をつけますが、可視化ドキュメントがありませんから、丸投げに近い形で担当者に任せるほかはありません。後に問題を残す場当たりメンテを行っても、これに気づく人はいませんし、ユーザとシステム担当も、不完全な自然言語によるコミュニケーションしかできませんから、行き違いによるトラブルが発生しがちです。
そんなことから、顧客の要請にもとづいて、われわれは最近何件か、LSV(Legacy System Visualization)と称する、DOA技法を適用したレガシーシステムの可視化プロジェクトに取り組んでいます。素材は物理ファイルレイアウトを中心にし、IOやヒアリングで補強します。投入工数、所用期間、ユーザヒアリングを最小にして、膨大なソフトの関わる業務モデル、とくにデータモデルを復刻しようという狙いです。再構築のための物理設計ではありませんから、SEの気にする「データの漏れ」などは論外とします。まずは業務が可視化され、関係者が共通のドキュメントに基づいて、コミュニケーションできるようになればよいのです。
対象システム、顧客のニーズなど違いますので、種々のやりかたが試みられていますが、顧客からもかなりの評価をいただいております(コマーシャルになってすみません)。LSVでは全体構造はつかめますが、詳細は工数の関係で追及しません。したがって具体的なメンテナンスが入れば、その部分についての詳細がつかめ、精度が上げられるものかと思われます。従来はメンテのたびに品質が劣化したわけですが、「LSVではメンテのたびに品質が向上する」ことを期待したいと思っています。
従来は再構築したときが品質最高、徐々に品質が劣化し、メンテしきれなくなって再構築と繰り返してきましたが、もはやシステムが大きくなりすぎています。保守によって品質が劣化しない、毎日の保守が再構築となる、これが21世紀のシステム運用・保守の考え方ではないでしょうか。