［技術講座］
ビジネスプロセスモデリング部
明神 知
最近のビジネス環境は、規制緩和で競合会社の製品を販売したり、競争の激化で合併が相次いだりと変化が激しい。一方、ビジネスを支える情報システムはビジネスの変化に応じて迅速に変更せねばならない。この情報技術の進歩はドッグイヤーと言われるほど早い。これらに対応すべく既存の情報システムを変化に強く、ビジネスと整合性を持ったものに再構築・再構造化しようというレガシーマイグレーションが注目を集めている(*1)。どこからどこへ移行するかによってレガシーマイグレーションはいくつかのパターンに分けられるが、概ね「メインフレーム中心のレガシー・システムをオープンでスタンダードな環境に移植・再構築することにより拡張性ある柔軟な情報システムに移行すること」と言える。
オープンシステムに比べてミッションクリティカルな基幹系システムに利用されることを前提としているメインフレームにはスケーラビリティ、可用性、セキュリティに関する優位な技術がある。一般的には、多様なトランザクションの負荷が混在する現実のビジネス環境において高性能と高可用性を実現するためにはメインフレームが確実なソリューションと言える場合も多い。
問題はコスト（製品と要員スキル）とソフトウェアの自由度（品揃え、アーキテクチャ）と技術革新スピードに関する懸念である。局所的には最適化されコストダウンが図れているところもあるかもしれないが、大きな流れとしては１メーカー、１ベンダーがすべてのハード、ソフトを独自に賄うことは不可能になってきており、オープンシステムへの流れは否定できない。
ここで事実として理解しておいて欲しいのは、過去に開発されたプログラム資産は大いにビジネス価値があり、現在も大部分の基幹系アプリケーションはメインフレーム上で稼動していることである。また、基幹系システムに利用されている代表的な COBOL プログラムの全プログラム生産量に占める割合は日本国内において 2002 年で 60-70 %、2007 年度でも 50 % 前後と大きな生産量が維持されると予測されている。一方 Java や VB は現在の経済状況で推移したとすると 2007 年度でもともに 20-30 % 程度と予想されている(*2)。このことはメインフレームからの単純な全面移行を考えるのではなく、ビジネス上の価値とコストを考慮した移行のタイミングを計画する必要があることを意味している。
レガシーマイグレーションはビジネスの観点からも重要な経営課題であるが、本稿では情報システムの企業全体における最適化を目指すエンタープライズアーキテクチャによる移行パスを紹介するに止める。
Java 技術者にとって COBOL というと、メインフレームの古い言語というイメージであろう。ところが堅牢なビジネス情報システムの構築という観点から見ると、高品質、耐障害性、保守性といったアプリケーション運用面の「強さ」について学ぶべきことが多いのである。こういった利用技術に関心が高まっているのは技術としての優劣というよりもオープンシステムの OS や言語、ミドルウェアといったテクノロジ分野の群雄割拠状態がいくつかの有力な環境に収束することによって、より開発者寄りのサービス提供機能に焦点が移りつつあると言える。その点、歴史のあるメインフレームの世界には情報資源管理やデータ管理、運用管理や構成管理といった長年の利用技術と利用者の蓄積がある。さらにメインフレームでは運用機能も含めてメーカーから調達できたが、オープン環境では多様な製品を個別に組み合わせて運用ツールなどを使って開発者が運用の仕組みを作る必要があるのである。
まず、問題の背景を理解していただくために 2007 年問題を考えてみよう。2007 年はメインフレーム上の情報システムを担ってきた団塊の世代が一斉に定年を迎える年である。すなわちベテランの COBOL プログラマがいなくなるのである。多くのレガシー・システムはこのベテラン COBOL プログラマが設計、コーディングしたものが多く、メンテナンスが不可能になるという問題が懸念されている。
この問題に取り組むにあたり、Java 技術者に必要とされるものは次のような項目であろう。
ここで「文化」という言葉を使ったが、従来のメインフレーム・システムはビジネスに直結した基幹システムとして利用されることを前提として整備されてきたので品質、コスト、納期、安全性といった要求はビジネスのニーズでもあり厳しく管理されてきた。その結果メインフレームでのシステム開発において高品質／高対障害性／高保守性は暗黙的に対策が打たれていたのである。一方、オープンシステムでは明示的に要求しなければこれらの品質レベルは実現されない。要は、「きっちりと作り」「しっかりと変更管理を行い」「上位互換性を保つように拡張する」ということが前提の「使い続けるメインフレーム文化」と、「その時々の最先端技術と品質のレベルを開発者が選択できる自由度の高いオープンシステム文化」の違いを言っているのである。
オープンシステムは選択の自由度が高い結果、開発者が決定すべき品質レベルの規定項目が多い。特に設計フェーズ以降の開発姿勢を規定するシステム・ポリシーが重要で利用者と合意しておくことが必須となる。表1
にシステム・ポリシーの一例を検討すべきフェーズと決定項目とともに示した。運用に関しても、運用の基本方針を定めた「システム運用ポリシー」、セキュリティについても「セキュリティ・ポリシー」を定める必要がある。これらはメインフレームではメーカーが作りこんできた技術や製品を前提とする方針が決まっているので、制約をそのまま製品として購入すればよかった。しかし、オープン・システムでは、これらをマルチベンダーからの調達で組み合わせて、ベストミックスを実現できるという自由度を得た代償として開発者自ら決定する必要があるのである。
| 表1 システム・ポリシーの例 | |||||||||||||||||
|
*1) オブジェクト技術の標準化団体 OMG でも Legacy Transformation WG が 2003 年 6 月に発足し、9 月の技術委員会で SIG に昇格決定した。
*2) これらの数字は、『実践 COBOL 資産 移行ガイド』（著者：COBOL コンソーシアム、日経システム構築／発行：日経 BP, 2003 年）掲載の言語別プログラマー人口推移などを参考に、大手 SIer などのビジネス状況を加味して試算した。
ソフトウェアの品質は国際規格 ISO/IEC 9126 によれば「機能性」、「信頼性」、「使用性」、「効率性」、「保守性」、「移植性」があげられている。メインフレームにおける開発では、これらの品質を向上させる施策として「レビュー」、「再利用」、「構成管理」、「変更管理」、「文書管理」、「教育」、「外注管理」、「標準化」、「テスト管理」、「保守管理」といった活動を開発プロセスに組み込み、その計画と結果を管理文書として残し、承認を受けることで品質を確保してきた。さきに述べたシステム・ポリシーによってどこまで品質を確保するのか開発者と利用者が合意して開発プロセスで規定することになる。
障害への対応を考える場合には、障害が起こらない様に高信頼性にすることと、障害発生時に影響を最小限に止める耐障害性がある。一般に高信頼性の実現は多重化など高価になる場合が多いので、費用対効果を考えながら複数の対策によって耐障害性を実現することが現実的である。
耐障害性に最も関連の深い活動が運用障害設計である。これは障害発生時の対応を検討するもので、障害時の代替手段、回復手段を検討し、対策をあらかじめ設計しておき信頼性の向上を図るものである。サーバー、クライアント、ネットワークの運用要件項目を明らかにした上で運用手順、データベースを含めたリカバリ手順などの障害対策一覧の作成を行う。
運用マニュアルについても「通常」「定期」「特別」「障害時」「移行中」の運用体制を明確にして、想定されるトラブル発生時にもマニュアルに従った対処を原則とする。システム異常時の業務対応方法もあらかじめ業務処理マニュアルに記載しておく。またオープンシステムでは、サーバーやデータが分散しているので、特に利用者を含めた運用組織、業務体制など責任範囲を明確にする必要性がある。
大規模、クリティカルなアプリケーション開発におけるリスクの管理についても Java 技術者が学ぶべき文化がある。リスク管理とは、リスクを識別し、評価し、回避策を作ってリスクを抑制することである。インクリメンタルな開発ではリスクの大きいものから開発して影響の波及を回避する手法が取られるが、開発規模の大きさとクリティカルな度合いによってリスクの識別という事前作業にも重点を置く必要があるだろう。
メインフレームの内部設計手順の中には「共通部品設計」があり、テンプレートやサブルーチンによる部品開発や再利用を推進してきた。オブジェクト指向の設計や言語を利用しても必ずしも再利用率が高まらないのは積極的な再利用部品開発を行っていないからとも言え、従来手法に学ぶところもある。
メインフレームのバッチシステム処理設計では CRUD マトリックス(*3)によって同一エンティティを使用するプロセスを調査し、重複プログラムを抽出・整理して一つのプログラムでできるなら統合するといった洗練を行う。オブジェクト指向設計であれば元々オブジェクトやクラスの属性、操作には責務単位のカプセル化が図られているので問題はなさそうに見えるが、この責務の割り当て方が問題なのである。Web システムを急いで構築する必要性が生じて言語は Java であっても巨大なコントロールクラスを作ってしまったり、メソッドがべた書きの構造のないものであったりして保守性を著しく欠いた実装も多いようである。
例えば、凝集度(*4)と結合度(*5)によるコンポーネント間の関係を吟味しながら凝集度を高く、結合度を低くして再利用性、保守性の高い設計をすることがオブジェクト指向開発においても必要である。
データ中心アプローチ（DOA）では重視されていたデータの整合性やデータ項目の標準化と管理体制についても、オープンシステムの時代になって軽視されているように思われる。図1 はデータ項目辞書の例であるが、DOA ではこのような辞書の運用規則と管理体制を定めて統制することを推奨していた。ここでドメインとあるのは同じ特性を持つデータ項目グループのことで、同じ入力チェック規則、同じ出力編集規則を持っており、システム上同じ取扱いができるので同音異義語や異音同義語の発見やデータ変更に関する影響波及分析に効果を発揮することからデータ項目命名規則に利用することを推奨したい。また ISO/IEC 11179 (*6) のデータ項目命名ガイドラインなどを参考にするとよい。このような統制をしなければ保守対象であるデータ項目は自然増殖して 2000 年問題(*7)のような深刻な状況は今後も繰り返す恐れがあると言えるだろう。
 |
| 図1 データ項目辞書 |
*3) プロセスモデルの各機能とデータモデルのエンティティの整合性を create, read, update, delete という 4 つのアクセスによって検証するための表
*4) コヒージョン（cohesion）のことでプログラムのひとつのコンポーネント（関数）の中に含まれる機能の純粋度を表す尺度
*5) カップリング（coupling）のことでプログラムの中で呼び出し関係にある２つのコンポーネントの関係を表す尺度。 コヒージョンとともにコンスタンチンとヨードンが「構造化設計」で提案した。
*6) データ要素および関連するメタデータの標準化と登録に関する仕様
*7) 西暦年を下二桁で表していた慣行によって引き起こされる 1999 年から 2000 年への移行時にプログラムが予期せぬ動きをするという問題。
レガシーマイグレーションではアーキテクチャ指向のアプローチが必要といわれる。それは、多様で複雑なビジネス・ニーズへの対応や Web ベースの技術変化といった機能、データ、技術や構造的な要求は過去のものとは大きく異なり、検討すべき要素が多く、しかもそれらの間に関連性があること、しかもその要求速度が速いために標準的で共通の情報アーキテクチャを考えなければ個別で独自の対応をすることが元々無理であるからである。また、レガシー・システムを引き続き使い続けたいという開発者の抵抗に対する有効な指針と計画がなければ変化への加速は期待できないこともある。ここではアーキテクチャ指向の再構築プロセスとそこに使われる技術、ツール、技法の紹介を行う。
全く新規にゼロから情報システムを開発する場合を除き、一般には古い既存のシステムがあって、ビジネスや技術の変化に応じて再構築する場合が多い。この場合には多かれ少なかれ既存システムの分析というステップが必ず入る。図2 に示すように要件定義段階で現行物理モデル(*8)、現行論理モデル(*9)、新論理モデル(*10)を作成し、新規の方式設計(*11)段階で新物理モデル(*12)を順に作成することで着実なステップを踏める。このような現行物理→現行論理→新論理→新物理という原則的な手順は既存システムに関するドキュメントの有無、設計と実装との一致度、新業務と旧業務の差異や現行機能保証の必要性などによって変わってくる。ここではこの原則手順に沿ったプロセス概要を説明する。
まず現行物理から現行論理に変換することがリバース・エンジニアリングであるが、このフェーズでは以下の作業を行う。
再構築対象の情報システム全体の規模や、複雑度を把握し、不要なシステムを区別することによりレガシーマイグレーションプロジェクト全体の工数見積や要員計画の基礎資料とする。効果測定のための評価基準を策定するのもこのフェーズである。
階層型 DB、ネットワーク DB、RDB について、DDL （データ定義言語）から論理構造を抽出するリバースツールなどを利用してデータ設計の再文書化を行う。
COBOL のソースコードや JCL（ジョブ制御言語）などからモジュール、バッチジョブの論理構造を抽出するリバースツールなどを利用してロジックの再文書化を行う。
次に現行論理から新たな業務ニーズを組み込んだ新論理モデルを策定する。次に新物理モデルの策定では、特に新たな業務を追加しないで稼働環境のみを変更するリホストの場合、特有のミドルウェアの使用、アセンブラの呼び出し、特殊なマクロの使用箇所などといった現行システムの問題を回避・修正する。特にメインフレーム処理の特徴であるバッチ処理と帳票出力については基本方針を決定したうえで個別対応するべきであろう。
例えば、バッチ処理については EUC への移行などによって最小限に絞ったうえでやむなくバッチ処理を取り込む場合でも RDB(SQL) 機能の有効活用、オンライン処理への代替など、バッチ処理の取り扱い方針を定めておくべきである。複雑な帳票の大量印刷や他システムとの関係、インタフェースによってはメインフレームに残さざるを得ないものも出てくるであろうが、UNIX / PC サーバー対応の高速プリンターも数多く出てきており、業務や帳票そのものの見直しや関連の深い他システムも移行プロジェクトの範囲に含めるなど、可能であれば特別な処理は極力避けてオープン化することが望ましい。
また、既存システムの COBOL コードを再利用する場合にはコンパイラ間の非互換、データの格納方式の違い、画面・帳票の違いなどに注意して新論理から新物理モデルを作成していく。
 |
| 図2 エンタープライズアーキテクチャとは |
エンタープライズアーキテクチャ（EA）は図2 に示すように情報システムだけでなくビジネスアーキテクチャも含めた各階層のモデルを辿って現行アーキテクチャからビジネス、データ、アプリケーション、テクノロジー各層の移行パスを決めて目標の（TO-BE）アーキテクチャに移行するものである。EA は「企業の外部環境（脅威や機会）と内部環境（強みや弱み）の変化に対応すべく策定される経営戦略を企業内の各レベルで実行するために、誰が、何を、どのように行うか経営資源を構造化して実行体を作り出すための企業構造設計図」である。この企業構造が産業モデル（規制緩和、グローバル化、eビジネス）、ビジネスモデル（合併、新製品・サービス、BPR）、目標としての情報技術アーキテクチャ（J2EE、.NET、Webサービス）、情報技術（Java、XML、協働ツール）の大きな変革への対応を迫られているのである。これらのニーズに個別対応するのではなく全体最適を狙って検討するための思考ツールが EA フレームワーク(*13)である。このフレームワーク上で情報システムを規定するものはデータ（What）、機能（How）、ネットワーク（Where）である。これらを日本政府の EA プロジェクトではそれぞれデータ・アーキテクチャ、アプリケーション・アーキテクチャ、テクノロジー・アーキテクチャとして情報システム調達の最適化計画を整備している。
経営管理、情報システム開発管理、IT ガバナンス(*14)、EA のすべてに渡って成熟度という概念が使われている。これは目標とすべき管理レベルを設定する際に、まず現在のレベルを診断してから無理のない目標設定をしなければ絵に書いた餅になって使いこなせなかったり、過剰な機能・品質になってしまうことを避けるためのマネジメント手法である。通常であれば現状が 0-1 のレベルで、目標とするのが 2-3 のレベルという場合が多い。米国会計検査院の EA 管理成熟度フレームワーク(*15)を表2 に示したので、移行先の EA レベル設定の参考にされたい。
| 表2 EA マネジメント成熟度 |
 |
表3 に META Group から提案されているインターネット上のサービス・パターン 4 つを加えた 7 つの機能分散パターンを示した。これらの典型的な Core Infrastructure Patterns のいずれかを目標の IT 基盤として利用することによって従来の独自の個別対応に比べて、変化に対する柔軟性を確保することが出来る。
| 表3 IT 基盤のパターン(*16) | ||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||
 |
*14) 企業が競争優位性を構築するために ＩＴ 戦略の策定・実行をコントロールし、あるべき方向へ導く組織能力のこと。IT ガバナンス協会と情報システムコントロール協会（ISACA）が制定した COBIT （Control Objectives for Information and related Technology）は ＩＴ のコントロールと監査全般のフレームワークに成熟度を組み込んでいる。
*15) A Framework for Assessing and Improving Enterprise Architecture Management
*16) META Group が提案しているアダプティブな企業の持つべき 7 つの IT 基盤パターン
移行の問題は、業務、データ、プログラム、運用の 4 つの領域で考えて行かねばならない。往々にして情報システムやデータを移行すれば良いと思いがちであるが、新規の情報システムを使った業務そのものの移行が完了してはじめて成功と言え、日々の業務に支障なく情報サービスを提供する安定運用が行われることが重要なのである。これらはメインフレームという大型の設備が集中的に管理されている場合には運用チームが存在して端末管理、サーバー管理、ネットワーク管理、施設管理などが厳格に行われていたが、オープン･システムで部門サーバーなどが分散配置されるに及んで責任の所在が不明確になったり、運用に関する十分な事前検討もなされないことが散見されるようになった。突然、新運用を開始するのではなく事前の利用者教育なども成功に至る重要な要素であることに注意されたい。
対処策選択の自由度を高め、影響範囲を限定してビジネスの急激な変化と複雑性の増大に対応するには、共通化と標準化が重要である。例えば情報技術のサプライサイドからでなく利用側から再利用部品化を考えていくサービス指向や多階層 C/S、ハブ＆スポーク、EC 型などインフラ構造の共通パターンを利用すること、共通技術（ネットワーク、RDB、 ミドルウェア、OS、ハードウェア）、共通プラットフォームを使うことなどによって変化に即応できるアジャイル（俊敏）でアダプティブ（適応力ある）な企業を指向すべきである。このような観点からレガシーマイグレーションの移行先として適用できる技術として「サービス指向」、「コンポーネント技術」、「UML」を取り上げたい。
まず、サービス指向（SOA）であるが、これはビジネスが行うサービスをどのようにシステマチックに構成するかという「アーキテクチャ」のパラダイムであり、今のところ Web サービスを前提のインフラとして成り立つ考え方である。図3 にあるように既存の ERP や CRM といったパッケージや既存システムを統合・連携するためのエンタープライズ・サービス・アーキテクチャを設けてプレゼンテーション層のみ、アプリケーションの複合、コンポーネントレベルの統合といった 3 つのレベルの統合を実現させるのである。
Web サービスや EAI によって一体化した既存のアプリケーションをサービスに分解して個別ニーズのユーザインタフェースと接続し、新規の業務フローを
UML のアクティビティ図や BPMN （Business Process Modeling Notation）などで定義してワークフローを自動生成するのが
BPEL （Business Process Execution Language ）である。欧米では EA のターゲット・アーキテクチャとして SOA
を指向する企業もあり、日本でも SOA を支援するサービスや製品が出てきていることから利用者主導の情報システム・アーキテクチャを実現するには考慮すべきであろう。
 |
| 図3 サービス指向アーキテクチャ（SOA） |
次にコンポーネント技術である。現在ではコンポーネント指向開発の基盤としては COM/.NET と EJB/J2EE の二つと言ってよい。ソフトウェアの制御構造の設計をソフトウェア・アーキテクチャというが、これをソースコードで実装して提供されるコンポーネントをアプリケーション・フレームワーク（単にフレームワーク）という。.NET や J2EE への移行を考える場合には必然的にコンポーネント指向開発になるし、.NET や J2EE から COBOL プログラム連携により並存させる場合には COBOL アクセス用 EJB などのコンポーネント開発環境が各社から提供されている。
最後に UML のレガシーマイグレーションにおける位置づけをはっきりしておきたい。UML は国際標準記法としてその地位を確立しており、この記法に沿ったモデリングの蓄積が各業界団体で進められていることから目標のアーキテクチャを定義するための中核の記法となる。表4
は OMG が推進している MDA (*17) の CIM(*18)、PIM(*19)、PSM(*20)
の Zachman framework における位置づけを示している(*21)。経営戦略から戦略情報化企画、情報化資源調達といった開発のフェーズを通してビジネスと情報システムを連結して整合性を確保するには表4
における抽象度レベルごとのモデルである上から下への横軸間連携とデータ、機能、ネットワークといった情報システムを定義する専門分野ごとの左右の縦軸間連携が必要であり、OMG
がモデルからコードの自動生成を狙って UML 2.0 を制定しているのもこれらの連携強化が目的である。経営戦略を定めるフェーズでは様々な問題解決のフレームワークやツールがあり、これを特定することにはあまり意味はないが、戦略をブレークダウンして組織内部にある経営資源を割り当て、「誰が」「何を」「どのように」実施するかといった構造を定義するビジネス・モデリングや情報システムを設計するシステム・モデリングの段階では
UML がその威力を発揮する。
| 表4 EA フレームワークにおける MDA |
 |
レガシーマイグレーションは既存システムの再利用率を高めるほど新規の業務要件の割合が少なくなって、戦略的投資よりもコスト削減のための後ろ向きの投資になってくる。このためにできるだけ単純かつ機械的な移行をツールでまず行ってから細かい調整を手作業で行うという方針が取られる。例えば IMS(*22) から RDB への移行などでは 1 セグメント＝ 1 レコードでまず変換してから後に微調整を行う。レガシーマイグレーションではデータリバース・ツールやモデリング・ツールなど多様なツールの力を借りて作業を行っていく。表5 には代表的なツールをレガシーマイグレーションの工程順にツールの機能とともに示した。具体的製品名については日本では販売されていないものや商品化されていないものも多いので省略したが、単純で機械的な変換や人手作業の支援についてはツール導入や自社内開発を検討されたい。
| 表5 レガシーマイグレーションツール | ||||||||||||||||||||||||||||||||||||||
|
*22) Information Management System の略で IBM の階層型データベース
ここではレガシーマイグレーションに関して留意点を補足する。
1 社に IT 製品やサービスを依存している場合には IT プロダクトのバージョンアップについては上位互換性が確保されるとともに、旧バージョンの保証期間やバージョンアップツールの提供など木目の細かいサポートが得られるが、オープン環境ではこれらの事項が必ずしも保証されないので十分な確認と代替手段の確保が必要である。自分が開発したプログラムについても、すでに利用者が存在する場合には上位互換性を前提とするといったようなミッションクリティカルな開発における開発基準の制定と遵守が重要である。
ソート、マージ、照合、データ変換や簡単なマクロツール、プリプロセッサなどのユーティリティツールやテストデータ、テストツールなどはメインフレーム・メーカーから提供されたり過去の長い利用者の蓄積で整備されていることが多いが、オープンシステムでは別途調達する必要がある。移行の費用を見積もるときに落としてしまうことも多いので注意が必要である。
オープンシステムではソフトウェア、ハードウェアともに多くのメーカー製品を組み合わせて利用することになる。問題がなければ顕在化しないが、インタフェースのトラブルや例外処理、異常処理などにおいて問題の切り分けが困難な場合があり、複数のメーカーやベンダーが協力して問題解決に当たる必要がある場合が発生するのもオープンシステムの特徴である。調達の条件や事前の契約によってサービスレベルを定義するなどの対策が必要である。
| © 2004 OGIS-RI Co., Ltd. |
|
