【DXレポートを読んで③】レガシーシステムの仕様を整理したいけどどうしたらいいの？
そんな悩みに活路を見出すため、
今回は「プラットフォーム変革手引書（第1版）」(情報処理推進機構（IPA）)に記述されている、レガシーシステムの仕様復元方法を紹介する。
なお、仕様復元の実施にあたり、現行システムの全体像を示す「全体システム構成図」が作成されていることが前提となる。全体システム構成図の作成については前回記事で説明している。
仕様復元の目的と変革手引書の活用方法
前回の記事 で、ブラックボックス化した現行システムの全体像を把握する方法として、「全体システム構成図」の作成方法を紹介した。
全体システム構成図を分析し、現行システムの問題点が明らかになると、次には現行ITシステムの再構築を行うことになる。
ただ、コストやリスクなどの問題で一度に全体の再構築が出来ない場合、現行システムの一部の仕様復元が必要になってくる。
そのため、プラットフォーム変革手引書（PF変革手引書）の「第3章 現行 IT システムの仕様復元」にて、現行システムの仕様復元方法が解説されている。
PF変革手引書の解説ではシステムをいくつかの形態に分類し、その形態ごとに適した整理の方法や、手順を示している。
ブラックボックス化したシステムの仕様を整理しようにも、何をしていいかわからないっといった時に参考になると思う。
ただ、整理の手順や作成するドキュメントについては、概要説明にとどまっているので、整理の方向性が定まったら、ドキュメントの作成方法の詳細などは別の資料や書籍で補完する必要がある。
次から、仕様復元方法について解説していく。
システム形態別の仕様復元の考え方
設計を分析するにあたっては、それぞれの機能を表すキーとなる設計情報（キー情報）
を明確にする必要がある。
キー情報はシステムの形態ごとに異なり、現状では4つの形態、バッチ型・オンライン型・Web型・ゲートウェイ型に分けられる。
それぞれのシステム形態の特徴と、キー情報を下表にまとめる。
| システム形態 | 特徴 | キー情報 |
|---|---|---|
| バッチ型 |
バッチ型はシーケンシャルなデータを読み込み順次処理をしていく形態 本形態の場合はデータ種類ごとに振る舞いを記述する |
DFD |
| オンライン型 | 業務の流れが明確となっている形態 ・クライアントサーバ ・Web ・メインフレーム |
業務フロー |
| Web型 | ・業務が一定方向ではなく前の業務に戻ったり、 他の業務画面を開 いたりする など 、業務の順番が規定できない形態となっている。 ※社内向けのシステムで一定の業務フローに沿って操作されるものは、オンライン型に属す。あくまでB2C 向けのシステム形態をさす |
画面遷移図 |
| ゲートウェイ型 | ・ゲートウェイ型は、外部システムとデータを会話型でやり取りするシステム形態 例） 証券会社と取引所で株の注文のやり取りをするように、他のシステムと接続するシステム形態 |
状態遷移図 |
次から、システム形態ごとの仕様復元方法を解説する。
バッチ型
バッチ型のITシステムでは、一つの業務は一連のバッチプログラム群が順に処理されて初めて完結する構成となっている。
そのため、単一のバッチプログラムだけを解析しても業務全体を把握することができ
ない。 バッチプログラム群を串刺しで解析し対象の処理の部分だけを抽出して初めて 業務の内容が理解できることになる。
したがって、バッチ型の IT システムを把握するためには、複数のプログラム処理中で、トランザクションごとに入出力処理・ＤＢの更新処理・演算処理などの処理を洗い出すこと が必要となる。
したがって、 こうした関係を整理するのには、
DFD(データフローダイアグラム)での表記が適しているのである。
DFDについてこの記事では詳しく触れないが、以下のサイトの説明がわかりやすい。
オンライン型
オンライン型は業務の中核を担っており、業務フローに沿って機能を実装している。
そのため、まず業務フローが重要になる。
【整理手順】
- 業務フローの整理
- オペレーション単位に画面を網羅的に洗い出し、画面一覧を作成
- さらに、以下の情報を一覧として整理
【一覧として整理するもの】
- 画面一覧
- 他のシステムとのインターフェース
- 他のシステムからの呼び出しや、他のシステムの呼び出し
- 他のシステムとの間のデータや処理の引き渡し
- 参照・更新・変更を行っているDB
- 帳票出力
Web型
Web型の特徴は、処理の順番が一定とは限らない点である。
例えば、Amazonで商品を購入する際には、商品を画面遷移しながら探したり、カートに入れたり、やっぱり取りけしたりしながら進むので、一方通行ではなく、行ったり来たりしながら一連の作業をする。
そのため、オンライン型のように画面の流れを業務フロー図として表すことが困難であり。
Web型の処理の分析整理は、画面遷移図を用いると具体的な処理内容を表記しやすい。
【手順】
- 業務そのものや業務マニュアルから業務画面を洗い出す
- 実際の画面メニューから業務画面を洗い出す。
- 画面定義から業務画面を洗い出す
- これら3つの業務画面の整合性をとり、本来必要な業務画面を確定する。
- 画面一覧を作成する
- 画面メニューを参考に画面間の関係を整理し画面遷移の流れを整理する。
ゲートウェイ型
PF変革手引書では、他の IT システムと情報を交換しながらお互いの IT システムが処理を進めるシステム形態を ゲートウェイ型と呼称している。
ゲートウェイ型の ITシステムでは、時間とともに状態が遷移するため、
状態遷移図を用いて分析・定義するのが適している。
状態遷移で表現を行う場合は、通信レイヤーの制御系と業務系処理の制御系の両方の整理が必要となる。
また、正常系・異常系それぞれの整理が必要となる。
- 正常系・・・主に業務に先立つセッションの確立や切断、認証処理や監視
- 異常系・・・自ステータス内での障害や呼び出し先もしくは呼び出し経路上での障害の制御方式。業務アプリ系では、業務的なエラー（メッセージの不整合やデータ型式の不一致）への対応、業務機能呼び出しのタイムアウトも含む。
【手順】
補足（ドキュメントのサンプル）
情報処理推進機構（IPA）のサイトで、ドキュメントのサンプルが紹介されている。
上記で紹介した仕様復元の手順の中で、ドキュメントの書き方に迷う場合の参考となる。
