レガシーシステム移行
システム移行支援
概要
システムを刷新する時、何らかの現行システムが存在するわけです。その中で現行システムを2000年以前のメインフレーム（汎用機）、オフコンシステムをレガシーシステムと呼ぶ傾向があります。
2000年以降に構築されたシステム（UNIX, Windows上でC、Java、VBなどで開発されている）も、すでに20年以上経っています。UNIXやWindowsシステムだから移行が楽、ということも無いので、当社としては両者を同じ括りで捉えています。
システム移行を考えている多くの会社は、構築するシステムを次のように考えています。
- 現行システムは担当者属人的、メンテナンスを重ねてきたため「スパゲッティ状態」。だから現行システムを参考にする新システムは作らない。今のシステムに参考にすべき知識、技術はないと考える。一からシステム刷新する
- 数多ある業務システム（パッケージ）から導入選定すれば、自社に最適なシステムが導入できるはず
- 自社で業務システムを設計する時代は終わった。パッケージを導入して少しカスタマイズすれば安価に効率的にシステム構築できる
当社技術者は40年程度業務システムに携わってきました。1から3には大きな間違いがあると考えています。
1の考えがベースになって、2、3の考えが誘導されていると思います。これは、システムをラジオやテレビ、自動車の様な工業製品と捉えているからだと思います。
当社の「システム移行支援サービス」は、1の「担当者属人的、メンテナンスを重ねてきたためスパゲッティ状態」といわれる現行システムの「現状分析・調査」を大事にし、その上で「新システムをどう構築するのか」を技術者によってCOBOL言語などのプログラムを解読し、紙の上にモデル化（ERD（管理するデータ項目）、DFD（業務機能の関連）など）することを重要視しています。AIによる自動分析であるとか、自動変換によるシステム移行については、過度に着目していません。
調査結果を当社商品である「オンネット統合業務」にどう適合（カスタマイズ、データ移行）するか、を考えます。
当社の経験
当社の主なレガシーシステム移行経験は以下のシステムです。この経験から本ページで移行について述べて参ります。
- ・スタンダード市場化学会社の原価計算、生産管理システム（メインフレーム、COBOL800本からの移行）
- ・スタンダード市場化学会社の売掛管理（請求、入金、消込）システム（メインフレーム、COBOL500本からの移行）
- ・医療機器販売会社（VB、大手システム会社パッケージからの移行、端末規模100台程度）
- ・総合病院購買システム（VB、大手コンピュータ会社パッケージからの移行、端末、数十台）
●当社が考える移行の現実（一般論との違い）
当社の移行支援サービスでは、以下認識を起点にしています。
当社もシステム会社（運用サービスが主体になっています）ですので、以下の「論点」の内容を肯定して作業を進めれば良いのですが、システム開発の終盤で「考え違い」が表面化してしまうとプロジェクト進行がうまくいきません。
システム構築では導入先との関係において、①「システム開発着手時一番仲良し」、②「開発後半でギクシャク」、そして③「運用を通じてまた仲が良くなる」のです。
②を回避するために、現状分析（ここが本サービス）が非常に重要と申し上げたいのです。現状分析後、導入パッケージとの差異分析（単に表を作って〇✕ではない）を明確にすべきと思います。そうして初めて、新システムの開発難易度、コストが明確になり、移行方法も決まるのです。
| 論点 |
当社の考え |
①「現行システムは担当者属人的、メンテナンスを重ねてきたためスパゲッティ状態。
だから現行システムを参考にして新システムを作らない。参考にすべき知識、技術はない」 |
現行システムには業務手順や機能など管理すべき情報項目が定義されています。プログラムの再利用は難しいですが、システム（情報＋機能）は新システムに継承すべきです。そうしないとこれまでの業務資産をすべて捨てて最初から再構築になります。
自社業務に素人のシステム会社と構築するのですから、これまで整理した情報や機能が抜ける場合があります。また、当然ながら現行システムのデータ移行も必要になります。得意先や発注先、品目、組織などのマスタ情報の項目やコード体系を刷新したら現場は混乱する可能性があります。
|
| ②「数多ある業務システム（パッケージ）から導入選定すれば、自社に最適なシステムが導入できる」 |
業務パッケージは数多あります。それらから学ぶ点も多くあります。しかし当社の経験では自社業務にマッチしたものは「無い」です。40年の経験でパッケージ導入しそのままで稼働した販売、購買、在庫システムを経験していません。「自社の業務手順、知識より、買ってきた業務システムのそれが（完全に）優れている」という事も無いと思います。
当社も「カスタマイズはほとんどありません！」と言って「オンネット統合業務システム」を売りたいですが、相手先の業務内容はプロジェクトの途中で分かる事ですからそう簡単には言えません。
|
③「自社で業務システムを設計する時代は終わった。
パッケージを導入してカスタマイズすれば安価に効率的にシステム構築できる」 |
普通に考えて、パッケージの値段が500万円前後とすると部分修正なのでカスタマイズ開発は500万円以下と思うでしょう。システム開発ではそれが違うんです。カスタマイズの方が2倍、3倍になるんです。これに皆さん仰天します。②の「業務システム（パッケージ）」をほぼ自社業務にマッチした完成品と見るのに誤りがあると思います。 |
現行システム調査が大事
これまで述べてきたように、現行システムの調査が一番大事だと考えています。よく「スパゲッティ状態で分からない」と逃げる傾向がありますが、それなりの規模のシステムを調査なしで移行することは出来ません。「現行システムの調査なしにシステム移行はできない」と考えています。
よく広告には「自動解析する」とありますが、人手で調査する方法が効率的と考えています。当社ではCOBOLプログラム500本程度を目視解析した経験があります。
移行手順は概ね次のように進めます。
| 調査工程 |
作業内容 |
説明 |
| 1.全体システム資産の洗い出し |
システム資産表の作成
- ・JCL一覧
- ・構成プログラム一覧
- ・オンライン画面（イメージ）集
- ・帳票（イメージ）集
- ・DBテーブル一覧と項目
- ・SAM/VSAMファイル定義書
|
現行システムの棚卸です。この内容を以下の作業で調査・分析することになります。
|
| 2.ソースコード解析 |
- ・バッチプログラム読取り
- ・オンラインプログラム読取り
|
以前、大手汎用メーカの技術者から「人手読取りするなんて！」と何回か言われました。
しかし「人手によるプログラム読取り（調査）」は意外と効率的に進められます。人手によるプログラム調査が当社の訴求点です。
|
| 3.現行システムズの作成 |
|
システムは「機能と情報の繋がり」です。調査の段階でプログラム１本単位まで詳細化する必要は無いと思いますが、業務単位（括り）に図にすることで当社と導入先で同じ個所で、具体的な打ち合わせが可能になります。
|
| 4.移行対象の抽出 |
- ・外部仕様の明確化（画面、帳票）
- ・不要機能の削減
|
システムを利用するということは、入力（画面）と出力（画面、帳票）を作成することです。この一覧を作成することが重要です。調査工程から、現在未利用の機能やプログラムが多くあるハズです。これらを移行対象から外します。
|
| 5.現状システムの問題点、課題調査 |
・新システムで改善列記 |
「DXによって、ユーザフレンドリーな顧客視点の画面にする」などの意味不明用語の羅列ではダメです。機能と情報から改善点を明確にする必要があります。 |
新システムの構想作成
当社の知識、技術はほぼ「オンネット統合業務システム」（以下「統合業務システム」という）で定義されています。「ほぼ」の意味は、定義されていない経験、知識もあるだろうという意味です。
当社の移行支援は現状調査した現行システムを必要な機能のみを当社の「統合業務システム」に移行するものです。現行システムの情報と機能が、①「統合業務システム」に反映できるか、②存在機能のカスタマイズをどうするか、③不足機能をどう構築するか、の３点を検討することになります。「統合業務システム」を実際に参照し、基盤利用しながら作業を進めるので、具体的に確実に進めることができます。
実装はどうなるか
現行システムを下表のとおり移行します。
| 工程 |
「オンネット統合業務」対応 |
備考 |
| 1.マスタ移行 |
- ・現行マスタ情報の移行
- ・業務に関係するもの
- ・会社の組織構造に関係するもの
- ・認証・認可に関係するもの など
|
- ・「統合業務システム」の各マスタに移行する
- ・移行はSQLSで記述し、自動化する
|
| 2.機能移行（画面） |
・「オンネット統合業務」画面に移行
|
カスタマイズが発生する場合は画面プログラムをコピーし、コピー先に機能修正を実施 |
3.機能移行
（バッチ） |
|
- ・手続き言語によるバッチプログラムの作成は、ほぼ不要と考えている
- ・OJMSによる自動起動と結果確認
|
| 4.機能移行（帳票） |
- ・出力データは、DBからSQLSでデータ作成
- ・帳票出力は「風神レポート（アイ・コン社）」で作成
|
・データ作成部と帳票プログラムを分離する
|
（注記）
- ・SQLSとはSQLSequencerの略で、COBOLなどの手続き言語を非手続き言語のSQLを連続させて代替する仕組み。当社には800本のCOBOLプログラムの移行実績がある
- ・OJMSとはOnnet Job Manager Systemの略で、暦以外のカレンダ（会社、本社、工場など）とも連携し、プログラムの自動実行を行う
システム移行、テストをどうするか
データ移行ですが、それなりの工数を要します。データには、①マスタ、②トランザクション（受注データ、入出庫データなどの伝票データ）、③残高（売掛残高、買掛残高、在庫残高など）、そして移行前の④取引データ（過去の売上データ、検収データなど）があります。そして⑤結果データ（請求データ、検収データなど）も意識する必要があります。これらをまず頭に入れて、移行計画を練ります。
| 切替方式 |
説明 |
| 一斉切替え方式 |
前述した①から⑤までのデータをある時点で一斉に移行し、切り替える方式です。
切替時、初期トラブルはどうしても発生しますので、業務混乱が発生します。トラブルをコントロールさせながら安定化させます。移行時の影響が限定する範囲で実施するのが現実的です。 |
| 段階的切替方式 |
当社はこの方法をよく使っています。まず、①マスタ同期機能を準備、②画面プログラム、バッチプログラムを実行、③新旧結果確認プログラムで比較 します。 ②は新旧両方に同じデータを投入して頂けないのが実情です。必要により現行システムのトランザクションデータの同期機能も作成します。この方式では開発をしながら徐々にシステム移行が行えます。現場の混乱も最小化できます。
これが可能になるのは
- ・現行システムサーバと新システムサーバが通信可能であること
- ・現行システムと新システムのデータ構造
- ・業務手順がほぼ同じであること
が前提となります。 |
単純移行で意味があるの？
これまでの説明で、①現行システムの調査、②機能移行を述べて参りました。理由は、
・現場の移行混乱を最小化すること
・「ブラックボックス」と言われる現行システムを一気に最適化した理想システムを構築できない（当社はそう思っている）
の理由からです。
しかし、それでは、「お金を掛けて移行する意味ある？」となります。確かにそうかも知れません。ただ、移行が完了すると「データ構造が明確になる」点が大きい。明確になるとその入出力を今風の技術と連携することが可能になります。例えば、スマホからデータ登録する、WEBサイトに在庫データを開示するなどが容易に実現できます。
現行システムから理想システムを考える間に「現行システムを新しい実行環境で動作させる」を設けることが、着実に情報処理化を進めることになるかと考えます。
