COBOLコンソーシアム利用技術分科会
清水 真 (東京システムハウス株式会社 ビジネスイノベーション事業部)
短期間で移行を一気に進めるためには、上流工程（現行システムの調査分析、要件定義、変換仕様の策定）が鍵になります。現行システムを把握し、それをオープンシステムでどのように稼働させていくのかを詳細に定義した上で、実装に着手しなければなりません。また,事前にプロトタイプで検証を進めておくことも必須です。ここでは現行システムの調査分析、要件定義、移行計画書の作成（変更仕様の確定）、の順で上流工程における重要なポイントを見ていきましょう。
多くの場合、既存システムには使用/不使用のシステム資産が混在しています。調査分析工程では、現存するすべての資産を洗い出すことで、移行対象を検討する材料を作成できます。そこで調査に当たっては、漏れがないようにすることが大切です。あらかじめ必要な調査項目を列挙した調査シートを用意/記入し、概略を把握すると便利でしょう。以下では具体的な調査内容を解説していきます。
プログラム（COBOLプログラム/簡易言語/COBOL以外のプログラム）、画面、運用環境（JCL/ユーティリティ/システム・サブルーチン）などを機能や特徴別に分類し、本数や規模を整理します。さらに、プログラムとプログラム、プログラムと登録集原文（コピーファイル）、プログラムとJCLなどのシステム資産の関連図を作成しておきます。
帳票の種類（サイズ、単票/連帳、オーバーレイなど）、それぞれの出力先プリンタの種類と場所/台数/出力タイミングなどを調査します。また、センターでの一括印刷か端末での印刷か、即時印刷かスプール印刷かなど、印刷運用も合わせて調査するとよいでしょう。
ここではトランザクション量/データ量/最大同時アクセス数などを調査します。これはハードウエアの選定時の判断材料になります。
現行システムを理解する上で、仕様書やマニュアルなどの文書は欠かせません。単純移行でも後工程のテスト・データ作成などで仕様の理解は必須となるでしょう。
業務システムでは多くの場合、外部のシステムとの通信やデータの共有などを行っています。通信手順や、電文（ファイル）フォーマットと仕様、データの共有方法などを正確に押さえておく必要があります。
バッチ処理の起動方法（定時起動、トリガー起動、オペレータによる起動）、ジョブ・ネット、アプリケーションからのメッセージ表示方法、異常処理への対応など、バッチ処理の運用方法を整理します。
要件定義工程では、移行先システムのハードウエアや許容応答時間、移行後のシステム構成、データの本番前の移行手順、移行後の運用方法、などを決定します。移行計画書を作成し、移行後のイメージを明確にすると同時に、移行完了までのロードマップを描くことが大事です。
後から手戻り作業が発生しないよう、システムの中から代表的な機能や特に実現性が気になる機能をピックアップしてプロトタイプを作りましょう。
プロトタイプを実際に動かすことで、ユーザーに運用方法などの違いを実感してもらうことが近道です。
システム移行も新規開発と同様、システムに対するユーザーとの相互理解が最も重要です。大量の移行資産を抱えて移行期間も短いとなると、機能の取捨選択、データの移行手順、複数部門間で調整が必要な運用方法や他システムとの連携の仕方など、ユーザーに時間をかけて決定してもらうべきこと、折衝ごとがなおざりになり、慌てて移行に着手してしまう傾向があります。焦る気持ちを抑えて、プロトタイプを利用しながらできる限り最初の段階で細かいことまで決めてしまうことが大事でしょう。
以下、移行計画を作成する上で重要なポイントを整理していきます。
単純移行ではホスト・システムのメインフレーム/オフコンをUNIX/Linux/Windowsサーバーへリプレースします。この段階で重要なことは、システムの操作性などの違いを早くにユーザーに提示し、移行後のシステムに対する認識を共有することです。
調査したトランザクション量/データ量/最大同時アクセス数などから、ハードウエアの選定を行います。ハードウエアやメインフレームのベンダーは、メインフレームの機種に応じた、オープンシステムのサーバーのスペック表を作成しています。同時に、バックアップ装置やRAID、ネットワーク機器などの構成も決定しておくとよいでしょう。
移行後のシステムを明確にする意味で、移行対象のシステム資産は早期に確定しておくべきでしょう。まずは、前工程の調査分析の結果から自明に不要な資産を除きます。
次に、移行すべき機能を洗い出します。必要なアウトプットが分かれば、前工程で作成したシステム資産の関連図を基に移行すべきプログラムやデータ、JCLを把握きるでしょう。
簡易言語、システム・サブルーチンやユーティリティはホスト・コンピュータでは広く利用されています。しかしベンダー固有であるため、ベンダーの移行ツールなどがなければ、オープンシステム上でそのまま利用することはできません。機能を移行したい場合は、移行先の環境で同等のツールを探す、COBOLなどで代替機能を自作する、のいずれかの方策を検討する必要があります。
帳票運用をホスト・コンピュータと同じように実施したい、連票/単票、専用用紙/汎用紙など様々な種類の帳票を出力したいといった要件がある場合には、帳票ツールを利用することが有効でしょう。
多くの帳票ツールは、フォームを使ったオーバーレイ機能を備えています。ただし、機能の詳細は多様で、必要な機能を持ったツールを予算や環境に合わせて選定するのがよいでしょう。
オープンシステムでは、ホスト・コンピュータでごく当たり前に利用していた運用管理機能（自動ジョブ実行/メッセージ管理/システム監視/電源管理）などが装備されていません。そのため、運用管理ツールの導入が必須です。運用管理ツールは機能を選択して組み合わる構成になっているので、何をどこまで管理したいかをよく検討し、必要な機能を選択しましょう。
また、ホスト・コンピュータで数世代にわたって保存していた、バックアップの方法もよく検討しておかなければなりません。なお、システムが外部のシステムと連携している場合、移行の都合によるシステムの変更に相手は対応できるのか、どちらが費用負担をするのか、など条件が複雑になります。
システム移行では、移行前後の照合テストが重要になります。テストをユーザーと移行者側の協同作業とする場合、移行前のシステム仕様や操作に精通したユーザーの少なからぬ協力が進捗を上げます。
ユーザーに対し、照合テストがいかにシステムの信頼性を上げるために重要かを説明し、テスト手順と方法を十分理解してもらう必要があります。それと同時に、このテストのために十分な時間を確保してもらうことが重要です。